Re: playback-only code in snd-dice?

[Daniel R. <dro...@fu...>]

All,

Gerry resolved this issue. It was indeed a regression in the interrupt
code affecting 3.17+. I happen to have a SuperMicro motherboard that
has a weird interrupt setup. Gerry, thanks for your help! :) I am
attaching the fix below for reference.

I now have firewire audio working with 3.17.1. But I still have to
hack the kernel sources to get this to work... the remaining problem
with dice.c is the fact that it disables itself if it sees that the
device has record capabilities, assuming you will use FFADO. Well,
guess what? I would just like my firewire audio to just work in-kernel
without modifying source code. I request that you remove this
artificial limitation of the driver.

My Mytek DSD DAC is used for playback only, so just because a device
advertises record capability doesn't actually mean it is a record
device in practice. The module should load and function, and if the
user doesn't want to use it, they can blacklist it. My opinion of
course, but what good reason is there to have snd-dice *not* function
without hacking source code when it could by default?

Regards,

Daniel

Gerry's IRQ fix patch for my SuperMicro X8SIL motherboard below:

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index b436fc735aa4..1cf3354845cf 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -396,8 +396,10 @@ static int mp_register_gsi(struct device *dev, u32
gsi, int trigger,
                return gsi;

        /* Don't set up the ACPI SCI because it's already set up */
-       if (acpi_gbl_FADT.sci_interrupt == gsi)
-               return gsi;
+       if (acpi_gbl_FADT.sci_interrupt == gsi) {
+               pr_warn("irqdomain: shared GSI between SCI and PCI\n");
+               return mp_map_gsi_to_irq(gsi, 0);
+       }

        trigger = trigger == ACPI_EDGE_SENSITIVE ? 0 : 1;
        polarity = polarity == ACPI_ACTIVE_HIGH ? 0 : 1;
@@ -508,7 +510,7 @@ acpi_parse_int_src_ovr(struct acpi_subtable_header *

On Mon, Oct 20, 2014 at 9:56 AM, Jiang Liu <jia...@li...> wrote:
> Hi Daniel,
>         Thanks for bisecting and seems the regression is caused
> by the commit. But I can't find the full dmesg file posted by you
> through googling:(. So could you please help to send the full dmesg
> text with the failure kernel? Another dmesg with the working kernel
> (v3.16) is preferred too.
>         Please also send me the output of "acpidump > acpi.bin".
> Regards!
> Gerry
>
> On 2014/10/20 5:59, Daniel Robbins wrote:
>> I have identified the bad commit:
>>
>> plex linux-git # git bisect good
>> 84245af7297ced9e8fe837dc0fc4782438771bd2 is the first bad commit
>> commit 84245af7297ced9e8fe837dc0fc4782438771bd2
>> Author: Jiang Liu <jia...@li...>
>> Date:   Tue Jun 10 14:14:47 2014 +0800
>>
>>     x86, irq, ACPI: Change __acpi_register_gsi to return IRQ number
>> instead of GSI
>>
>>     Currently __acpi_register_gsi is defined to return GSI number and
>>     may be set to acpi_register_gsi_pic(), acpi_register_gsi_ioapic(),
>>     acpi_register_gsi_xen_hvm() and acpi_register_gsi_xen().
>>
>>     Among which, acpi_register_gsi_ioapic() returns GSI number, but
>>     acpi_register_gsi_xen_hvm() and acpi_register_gsi_xen() actually
>>     returns IRQ number instead of GSI. And for acpi_register_gsi_pic(),
>>     GSI number equals to IRQ number.
>>
>>     So change acpi_register_gsi_ioapic() to return IRQ number, it also
>>     simplifies the code.
>>
>>     Signed-off-by: Jiang Liu <jia...@li...>
>>     Cc: Konrad Rzeszutek Wilk <kon...@or...>
>>     Cc: Tony Luck <ton...@in...>
>>     Cc: Joerg Roedel <jo...@8b...>
>>     Cc: Paul Gortmaker <pau...@wi...>
>>     Cc: Greg Kroah-Hartman <gr...@li...>
>>     Cc: Benjamin Herrenschmidt <be...@ke...>
>>     Cc: Grant Likely <gra...@li...>
>>     Cc: Rafael J. Wysocki <rj...@rj...>
>>     Cc: Bjorn Helgaas <bhe...@go...>
>>     Cc: Randy Dunlap <rd...@in...>
>>     Cc: Yinghai Lu <yi...@ke...>
>>     Cc: Len Brown <len...@in...>
>>     Cc: Pavel Machek <pa...@uc...>
>>     Link: http://lkml.kernel.org/r/140...@li...
>>     Signed-off-by: Thomas Gleixner <tg...@li...>
>>
>> :040000 040000 e2ffe2a09062cc3fd40f2367a3f5e47fe3852277
>> 9b690563070c3d0de56a9c950e32cb2def10d08f M arch
>>
>> On Sun, Oct 19, 2014 at 1:40 PM, Daniel Robbins <dro...@fu...> wrote:
>>> And I will start a bisect between 3.16.0 and 3.17.0 and see what is causing
>>> this....
>>>
>>> -Daniel
>>>
>>> On Sun, Oct 19, 2014 at 1:16 PM, Daniel Robbins <dro...@fu...> wrote:
>>>>
>>>> This board only has one PCI slot, and I believe it is using the latest
>>>> BIOS.
>>>>
>>>> I am attaching dmesg from 3.16.0, where the firewire card is handled just
>>>> fine (using it to listen to music right now :) I am curious why it works
>>>> fine with 3.16.0 and not with 3.17.0+.
>>>>
>>>> -Daniel
>>>>
>>>> On Sun, Oct 19, 2014 at 1:10 PM, Clemens Ladisch <cl...@la...>
>>>> wrote:
>>>>>
>>>>> Daniel Robbins wrote:
>>>>>> [    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low
>>>>>> level)
>>>>>> [    2.699224] firewire_ohci 0000:06:00.0: failed to allocate interrupt
>>>>>> 20
>>>>>
>>>>> Interrupt 20 is actually interrupt 9, which is already used for ACPI
>>>>> events.
>>>>> (At least this is what the kernel thinks what the BIOS tells it.)
>>>>>
>>>>> In theory, the controller's "20" is bus_irq, which should not conflict.
>>>>> Could you bisect the kernel?
>>>>>
>>>>> Is this a controller card which you could plug into a different slot?
>>>>> Or could you update the motherboard BIOS?
>>>>>
>>>>>
>>>>> Regards,
>>>>> Clemens
>>>>
>>>>
>>>