this gets fixed/changed in later HW revisions it
will no longer be applied.
v2: incorporated Takashi Iwai's suggestion for the quirk application
method
Signed-off-by: Anssi Hannula
Cc:
---
It took a bit longer than expected for me to get back to this, but here
goes :)
sound/usb/mixe
Avoid getting sample rate on AudioQuest DragonFly as it is unsupported
and causes noisy "cannot get freq at ep 0x1" messages when playback
starts.
Signed-off-by: Anssi Hannula
Cc:
---
No changes to this one.
sound/usb/quirks.c | 1 +
1 file changed, 1 insertion(+)
diff --git a
ed-by: Staffan Lindberg
Signed-off-by: Anssi Hannula
Cc: stable@vger.kernel.org
---
This also affects stable 3.7, but not earlier versions.
sound/pci/hda/patch_hdmi.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/pat
sue on the affected NVIDIA "ION2" hardware, and for the initial
bug report of the issue. Testing of the final version on NVIDIA ION2 was
done by OpenELEC user "MrXIII". Testing on Intel PantherPoint was done
by myself.
Signed-off-by: Anssi Hannula
Cc: stable@vger.kernel.org
being shown wrongly due to a separate issue with
from_cea_slot().
Signed-off-by: Anssi Hannula
Signed-off-by: Takashi Iwai
---
sound/pci/hda/patch_hdmi.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index
codec.
Reported-by: MysterX on #openelec
Tested-by: MysterX on #openelec
Signed-off-by: Anssi Hannula
Cc: # 3.8+
---
sound/pci/hda/patch_hdmi.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index 556d47231f11..f5060
that changing
the sink speaker mask allowed HBR output.
Reported-by: GrimGriefer
Reported-by: Ashecrow
Reported-by: Frank Zafka
Reported-by: Peter Frühberger
Signed-off-by: Anssi Hannula
Cc:
---
Hopefully this fixes HBR (HD passthrough) for the remaining Intel users
who were still experiencing
by keeping track of the last programmed channel map and making
hdmi_setup_audio_infoframe() always update the hardware mapping if the
channel map has changed.
Signed-off-by: Anssi Hannula
Cc:
---
BTW, is there some mechanism preventing hdmi_chmap_ctl_put() to be called
at the same
Takashi Iwai kirjoitti 2013-10-07 10:48:
At Wed, 2 Oct 2013 21:13:32 +0300,
Anssi Hannula wrote:
Currently hdmi_setup_audio_infoframe() reprograms the HDA channel
mapping only when the infoframe is not up-to-date or the non-PCM flag
has changed.
However, when just the channel map has been
Takashi Iwai kirjoitti 2013-10-07 13:43:
At Mon, 07 Oct 2013 13:31:17 +0300,
Anssi Hannula wrote:
Takashi Iwai kirjoitti 2013-10-07 10:48:
> At Wed, 2 Oct 2013 21:13:32 +0300,
> Anssi Hannula wrote:
>
> Currently hdmi_setup_audio_infoframe() reprograms the HDA channel
> mappin
by always programming the channel map in
hdmi_setup_audio_infoframe(). Tested on Intel HDMI.
Signed-off-by: Anssi Hannula
Cc:
---
Here is a simpler version of the map switch fix.
sound/pci/hda/patch_hdmi.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a
-by: Elias Vanderstuyft
[anssi.hann...@iki.fi: added description and CCs]
Signed-off-by: Anssi Hannula
Cc: Simon Wood
Cc:
---
Simon, does this look OK to you, or do you think it should be an lg4ff
device? Though I guess lg2ff is better than nothing even in that case.
Jiri, lets see if we get a
deadzone like other Logitech wheels.
>>
>> Kconfig description etc are also updated accordingly.
>>
>> Signed-off-by: Elias Vanderstuyft
>> [anssi.hann...@iki.fi: added description and CCs]
>> Signed-off-by: Anssi Hannula
>> Cc: Simon Wood
>> Cc:
nr_dirty is updated without locking, causing it to drift so that it is
non-zero (either a small positive integer, or a very large one when an
underflow occurs) even when there are no actual dirty blocks.
Fix that by using an atomic type for nr_dirty.
Signed-off-by: Anssi Hannula
Cc: Joe
01.08.2014, 18:17, Joe Thornber kirjoitti:
> On Thu, Jul 31, 2014 at 09:31:27PM +0300, Anssi Hannula wrote:
>> I did notice that after a reboot (after having incorrect nr_dirty) the
>> entire cache was considered to be dirty and a full writeback occurred,
>> but I don't k
currently sent in such cases (such as when unplugging or replugging a
sink).
Fix the code to always set eld_changed if eld_valid value is changed,
and therefore to always send the change event when the user-visible
value changes.
Signed-off-by: Anssi Hannula
Cc: David Henningsson
Cc: # 3.9
efore calling cell_defer().
Incoming bios for that block will then be detained in the cell and
released only after clear_dirty() has completed, so the race will not
occur.
Found by inspecting the code after noticing spurious dirty counts
(scenario B).
Signed-off-by: Anssi Hannula
Cc: Joe Thornbe
ve a wrong channel mapping.
However, adding back just setting the converter channel count even in
no-monitor case is the safest change which at least fixes the stereo
playback regression on SiI1390 codec. Do that.
Signed-off-by: Anssi Hannula
Reported-by: Stephan Raue
Tested-by: Stephan Raue
C
nth and day got swapped for some reason.
Not a big issue I guess, but worth looking into if it is something in
your workflow causing this :)
Noticed these strange Dates while looking at Greg's stable-queue repo.
--
Anssi Hannula
--
To unsubscribe from this list: send the line "unsubscribe
tra unused stream numbers do not matter" assumption), causing
non-working audio regressions for AMD Radeon HDMI users on v3.14.
Change the stream numbers to be assigned in increasing order instead.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77002
Reported-by: Christian Güdel
Signed
Anssi Hannula wrote:
> Currently stream numbers are assigned in reverse order.
>
> Unfortunately commit 7546abfb8e1f9933b5 ("ALSA: hda - Increment
> default stream numbers for AMD HDMI controllers") assumed this was not
> the case (specifically, it had the "ol
08.04.2014 10:35, Takashi Iwai kirjoitti:
> At Mon, 7 Apr 2014 22:36:38 +0300,
> Anssi Hannula wrote:
>>
>> Currently stream numbers are assigned in reverse order.
>>
>> Unfortunately commit 7546abfb8e1f9933b5 ("ALSA: hda - Increment
>> default stream n
Avoid getting sample rate on AudioQuest DragonFly as it is unsupported
and causes noisy "cannot get freq at ep 0x1" messages when playback
starts.
Signed-off-by: Anssi Hannula
Cc:
---
sound/usb/quirks.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/usb/quirks.c b/sound/us
MAX_TLV_RANGE_SIZE).
Tested on AudioQuest DragonFly HW v1.2. The quirk is only applied if the
range is 0..50, so if this gets fixed/changed in later HW revisions it
will no longer be applied.
Signed-off-by: Anssi Hannula
Cc:
---
sound/usb/mixer_quirks.c | 37
Hi,
17.08.2015, 17:16, Takashi Iwai kirjoitti:
> On Sun, 16 Aug 2015 14:50:12 +0200,
> Anssi Hannula wrote:
>>
>> AudioQuest DragonFly DAC reports a volume control range of 0..50
>> (0x..0x0032) which in USB Audio means a range of 0 .. 0.2dB, which
>> is
25 matches
Mail list logo
