| Age | Commit message (Collapse) | Author |
|---|
|
ATI/AMD HDMI codecs do not include standard HDA HDMI HBR support (which
is required for bitstreaming DTS-HD and Dolby TrueHD), instead they have
custom verbs for checking and enabling it.
Add support for the ATI/AMD HDMI HBR verbs.
The specification is available at:
http://www.x.org/docs/AMD/AMD_HDA_verbs_v2.pdf
v2: adapted to hdmi_ops infrastructure
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Tested-by: Peter Frühberger <fritsch@xbmc.org> # v1
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
ATI/AMD HDMI/DP codecs do not include standard HDA ELD (EDID-like data)
support.
In place of providing access to an ELD buffer, various vendor-specific
verbs are provided to provide the relevant information. Revision ID 3
and later (0x100300 as reported by procfs codec#X) have support for
providing more information than the previous revisions (but only if
supported by the display driver).
Generate ELD from the information provided by the vendor-specific verbs
on ATI/AMD codecs.
The specification is available at:
http://www.x.org/docs/AMD/AMD_HDA_verbs_v2.pdf
v2: moved code to hda_eld.c and cleaned it up
v3: adapted to hdmi_ops infrastructure
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Tested-by: Peter Frühberger <fritsch@xbmc.org> # v2
Tested-by: Olivier Langlois <olivier@trillion01.com> # v2
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
ATI/AMD codecs do not support all the standard HDA HDMI/DP functions,
instead various vendor-specific verbs are provided.
This commit addresses these missing functions:
- standard channel mapping support
- standard infoframe configuration support
ATI/AMD provides their own verbs that allow the following:
- setting CA for infoframe
- setting down-mix information for infoframe
- channel pair remapping
- individual channel remapping (revision ID 3+, 0x100300+)
The documentation for the verbs has now been released by AMD:
http://www.x.org/docs/AMD/AMD_HDA_verbs_v2.pdf
Add support for the ATI/AMD specific verbs and use them instead of the
generic methods on ATI/AMD codecs. This allows multi-channel PCM audio
to work.
Channel remapping is restricted to pairwise mapping on codecs with
revision ID 2 (0x100200 as reported by procfs codec#X) or lower. This
means cards up to Radeon HD7670 as far as I know. This will not affect
standard multi-channel modes since these codecs support automatic
FC-LFE swapping for HDMI.
ATI/AMD codecs do not advertise all of their supported rates, formats
and channel counts, therefore that information is forced accordingly so
that all HDMI 1.x PCM parameters are marked as supported.
Support for multiple ports is also added to patch_atihdmi so that
0x1002aa01 codecs with multiple ports will work properly when switched
back to that patch.
v2: splitted ELD emulation to a separate patch, tlv fixes
v3: adapted to the new hdmi_ops infrastructure, fixed rev3+ vendor id
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Tested-by: Peter Frühberger <fritsch@xbmc.org> # v2
Tested-by: Olivier Langlois <olivier@trillion01.com> # v2+rev3fix
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Upcoming AMD multichannel support requires many customized operations
(channel mapping, ELD, HBR) but can otherwise share most of its code
with the generic patch.
Add a local struct hdmi_ops containing customizable HDMI-specific
callbacks and move the current code to those callbacks. Functionality is
unaltered.
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Shifting page->index on 32 bit systems was overflowing, causing
data corruption of > 4GB files. Fix this by casting it first.
https://launchpad.net/bugs/1243636
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reported-by: Lars Duesing <lars.duesing@camelotsweb.de>
Cc: stable@vger.kernel.org # v3.11+
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
|
commit 4b6271a6 fix a menory leak but one more existed in driver so fix that
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
|
When it fails to allocate a slot, edesc should be free'd before return;
Signed-off-by: Valentin Ilie <valentin.ilie@gmail.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
|
Some machine with 85ms delay might be happen pop noise when codec
enter to D3. Raise up to 100ms delay will be match for more machine.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
We are using the Python scripting interface in perf to extract kernel
events relevant for performance analysis of HPC codes. We noticed that
the "perf script" call allocates a significant amount of memory (in the
order of several 100 MiB) during it's run, e.g. 125 MiB for a 25 MiB
input file:
$> perf record -o perf.data -a -R -g fp \
-e power:cpu_frequency -e sched:sched_switch \
-e sched:sched_migrate_task -e sched:sched_process_exit \
-e sched:sched_process_fork -e sched:sched_process_exec \
-e cycles -m 4096 --freq 4000
$> /usr/bin/time perf script -i perf.data -s dummy_script.py
0.84user 0.13system 0:01.92elapsed 51%CPU (0avgtext+0avgdata
125532maxresident)k
73072inputs+0outputs (57major+33086minor)pagefaults 0swaps
Upon further investigation using the valgrind massif tool, we noticed
that Python objects that are created in trace-event-python.c via
PyString_FromString*() (and their Integer and Long counterparts) are
never free'd.
The reason for this seem to be missing Py_DECREF calls on the objects
that are returned by these functions and stored in the Python
dictionaries. The Python dictionaries do not steal references (as
opposed to Python tuples and lists) but instead add their own reference.
Hence, the reference that is returned by these object creation functions
is never released and the memory is leaked. (see [1,2])
The attached patch fixes this by wrapping all relevant calls to
PyDict_SetItemString() and decrementing the reference counter
immediately after the Python function call.
This reduces the allocated memory to a reasonable amount:
$> /usr/bin/time perf script -i perf.data -s dummy_script.py
0.73user 0.05system 0:00.79elapsed 99%CPU (0avgtext+0avgdata
49132maxresident)k
0inputs+0outputs (0major+14045minor)pagefaults 0swaps
For comparison, with a 120 MiB input file the memory consumption
reported by time drops from almost 600 MiB to 146 MiB.
The patch has been tested using Linux 3.8.2 with Python 2.7.4 and Linux
3.11.6 with Python 2.7.5.
Please let me know if you need any further information.
[1] http://docs.python.org/2/c-api/tuple.html#PyTuple_SetItem
[2] http://docs.python.org/2/c-api/dict.html#PyDict_SetItemString
Signed-off-by: Joseph Schuchart <joseph.schuchart@tu-dresden.de>
Reviewed-by: Tom Zanussi <tom.zanussi@linux.intel.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Tom Zanussi <tom.zanussi@linux.intel.com>
Link: http://lkml.kernel.org/r/1381468543-25334-4-git-send-email-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
The drain and drain_notify callback were blocked by low level driver untill the
draining was complete. Due to this being invoked with big fat mutex held, others
ops like reading timestamp, calling pause, drop were blocked.
So to fix this we add a new snd_compr_drain_notify() API. This would be required
to be invoked by low level driver when drain or partial drain has been completed
by the DSP. Thus we make the drain and partial_drain callback as non blocking
and driver returns immediately after notifying DSP.
The waiting is done while relasing the lock so that other ops can go ahead.
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
CC: stable@vger.kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
It turned out that we can't use gen_pool_*() functions on archs
without CONFIG_GENERIC_ALLOCATOR (resulting in missing symbols), since
linux/genalloc.h doesn't provide dummy functions for all. We'd be
able to fix linux/genalloc.h size, but I take an easier path for
now...
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
It also contains a minor style cleanup.
Signed-off-by: Denis Carikli <denis@eukrea.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
