[PATCH 3/3] PNP: add AD1815 and AD1816 quirks - Kernel

This is a discussion on [PATCH 3/3] PNP: add AD1815 and AD1816 quirks - Kernel ; Hi Bjorn. The AD181x chip doesn't support an IRQ-less MPU401 option but works fine without one. This adds (priority: functional) IRQ-less options for each port option to help systems with few available IRQs. The AD1815 quirk can't use pnp_register_irq_resource() due ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: [PATCH 3/3] PNP: add AD1815 and AD1816 quirks

  1. [PATCH 3/3] PNP: add AD1815 and AD1816 quirks

    Hi Bjorn.

    The AD181x chip doesn't support an IRQ-less MPU401 option but works
    fine without one. This adds (priority: functional) IRQ-less options
    for each port option to help systems with few available IRQs.

    The AD1815 quirk can't use pnp_register_irq_resource() due to doubly
    penalizing the IRQ. Also, while not a practical issue due to no IRQ
    option being present for the dependents, this needs to add in front,
    not back.

    Doesn't use pnp_register_port_resource() for symetry with above.

    This does not delete the AD1815 independent option even though it
    should be empty after the IRQ transfer due to AD1816 coming with an
    empty but still present independent option by default.

    Was tested on AD1815 and AD1816. The ALSA driver also support the
    AZT2002 ID for MPU401 but this doesn't as I was unable to test it.

    Signed-off-by: Rene Herman


    commit effa66095a52cecd415c3f34043ed505561a5139
    Author: Rene Herman
    Date: Tue May 6 02:07:59 2008 +0200

    PNP: add AD1815 and AD1816 quirks.

    The AD181x chip doesn't support an IRQ-less MPU401 option but works
    fine without one. This adds (priority: functional) IRQ-less options
    for each port option to help systems with few available IRQs.

    The AD1815 quirk can't use pnp_register_irq_resource() due to doubly
    penalizing the IRQ. Also, while not a practical issue due to no IRQ
    option being present for the dependents, this needs to add in front,
    not back.

    Doesn't use pnp_register_port_resource() for symetry with above.

    This does not delete the AD1815 independent option even though it
    should be empty after the IRQ transfer due to AD1816 coming with an
    empty but still present independent option by default.

    Was tested on AD1815 and AD1816. The ALSA driver also support the
    AZT2002 ID for MPU401 but this doesn't as I was unable to test it.

    Signed-off-by: Rene Herman

    diff --git a/drivers/pnp/quirks.c b/drivers/pnp/quirks.c
    index 10b1295..e4b049c 100644
    --- a/drivers/pnp/quirks.c
    +++ b/drivers/pnp/quirks.c
    @@ -108,6 +108,114 @@ static void quirk_sb16audio_resources(struct pnp_dev *dev)
    "pnp: SB audio device quirk - increasing port range\n");
    }

    +static struct pnp_option *quirk_ad181x_mpu_resources(struct pnp_dev *dev)
    +{
    + struct pnp_option *head = NULL;
    + struct pnp_option *prev = NULL;
    + struct pnp_option *res;
    +
    + /*
    + * Build a functional IRQ-less variant of each MPU option.
    + */
    +
    + for (res = dev->dependent; res; res = res->next) {
    + struct pnp_option *curr;
    + struct pnp_port *port;
    + struct pnp_port *copy;
    +
    + port = res->port;
    + if (!port || !res->irq)
    + continue;
    +
    + copy = pnp_alloc(sizeof *copy);
    + if (!copy)
    + break;
    +
    + copy->min = port->min;
    + copy->max = port->max;
    + copy->align = port->align;
    + copy->size = port->size;
    + copy->flags = port->flags;
    +
    + curr = pnp_build_option(PNP_RES_PRIORITY_FUNCTIONAL);
    + if (!curr) {
    + kfree(copy);
    + break;
    + }
    + curr->port = copy;
    +
    + if (prev)
    + prev->next = curr;
    + else
    + head = curr;
    + prev = curr;
    + }
    + return head;
    +}
    +
    +static void quirk_ad1815_mpu_resources(struct pnp_dev *dev)
    +{
    + struct pnp_option *res;
    + struct pnp_irq *irq;
    +
    + /*
    + * Distribute the independent IRQ over the dependent options
    + */
    +
    + res = dev->independent;
    + if (!res)
    + return;
    +
    + irq = res->irq;
    + if (!irq || irq->next)
    + return;
    +
    + res = dev->dependent;
    + if (!res)
    + return;
    +
    + while (1) {
    + struct pnp_irq *copy;
    +
    + copy = pnp_alloc(sizeof *copy);
    + if (!copy)
    + return;
    +
    + memcpy(copy->map, irq->map, sizeof copy->map);
    + copy->flags = irq->flags;
    +
    + copy->next = res->irq; /* Yes, this is NULL */
    + res->irq = copy;
    +
    + if (!res->next)
    + break;
    + res = res->next;
    + }
    + kfree(irq);
    +
    + res->next = quirk_ad181x_mpu_resources(dev);
    +
    + res = dev->independent;
    + res->irq = NULL;
    +
    + printk(KERN_INFO "pnp: adding IRQ-less AD1815 MPU options\n");
    +}
    +
    +static void quirk_ad1816_mpu_resources(struct pnp_dev *dev)
    +{
    + struct pnp_option *res;
    +
    + res = dev->dependent;
    + if (!res)
    + return;
    +
    + while (res->next)
    + res = res->next;
    +
    + res->next = quirk_ad181x_mpu_resources(dev);
    +
    + printk(KERN_INFO "pnp: adding IRQ-less AD1816 MPU options\n");
    +}

    #include

    @@ -202,6 +310,10 @@ static struct pnp_fixup pnp_fixups[] = {
    {"CTL0043", quirk_sb16audio_resources},
    {"CTL0044", quirk_sb16audio_resources},
    {"CTL0045", quirk_sb16audio_resources},
    + /* Add IRQ-less AD1815 MPU options */
    + {"ADS7151", quirk_ad1815_mpu_resources},
    + /* Add IRQ-less AD1816 MPU options */
    + {"ADS7181", quirk_ad1816_mpu_resources},
    {"PNP0c01", quirk_system_pci_resources},
    {"PNP0c02", quirk_system_pci_resources},
    {""}



  2. Re: [PATCH 3/3] PNP: add AD1815 and AD1816 quirks

    On Monday 05 May 2008 07:08:19 pm Rene Herman wrote:
    > The AD181x chip doesn't support an IRQ-less MPU401 option but works
    > fine without one. This adds (priority: functional) IRQ-less options
    > for each port option to help systems with few available IRQs.
    >
    > The AD1815 quirk can't use pnp_register_irq_resource() due to doubly
    > penalizing the IRQ. Also, while not a practical issue due to no IRQ
    > option being present for the dependents, this needs to add in front,
    > not back.
    >
    > Doesn't use pnp_register_port_resource() for symetry with above.
    >
    > This does not delete the AD1815 independent option even though it
    > should be empty after the IRQ transfer due to AD1816 coming with an
    > empty but still present independent option by default.
    >
    > Was tested on AD1815 and AD1816. The ALSA driver also support the
    > AZT2002 ID for MPU401 but this doesn't as I was unable to test it.
    >
    > Signed-off-by: Rene Herman


    I'm not opposed to this in principle, but I don't understand
    it well enough to really have an informed opinion.

    IIRC, we give up some seldom-used functionality when running
    the MPU401 without an IRQ. Does the driver mention the fact
    that there's something it can't do because we don't have an IRQ?
    The user might like to know in case he needs that functionality
    and wants to fiddle with other devices to free up IRQs.

    I'm vaguely uncomfortable because this quirk isn't really working
    around a hardware/firmware issue; it's stepping around the fact
    that Linux doesn't know how to allocate IRQs between ISA and PCI.
    Does anybody know how Windows handles this? If Windows can do it
    without user intervention, maybe we can too.

    If we continue down the quirk path, would you mind using dev_info()
    instead of plain printk()?

    Bjorn
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [PATCH 3/3] PNP: add AD1815 and AD1816 quirks

    On 06-05-08 21:08, Bjorn Helgaas wrote:

    > On Monday 05 May 2008 07:08:19 pm Rene Herman wrote:


    >> The AD181x chip doesn't support an IRQ-less MPU401 option but works
    >> fine without one. This adds (priority: functional) IRQ-less options
    >> for each port option to help systems with few available IRQs.
    >>
    >> The AD1815 quirk can't use pnp_register_irq_resource() due to doubly
    >> penalizing the IRQ. Also, while not a practical issue due to no IRQ
    >> option being present for the dependents, this needs to add in front,
    >> not back.
    >>
    >> Doesn't use pnp_register_port_resource() for symetry with above.
    >>
    >> This does not delete the AD1815 independent option even though it
    >> should be empty after the IRQ transfer due to AD1816 coming with an
    >> empty but still present independent option by default.
    >>
    >> Was tested on AD1815 and AD1816. The ALSA driver also support the
    >> AZT2002 ID for MPU401 but this doesn't as I was unable to test it.
    >>
    >> Signed-off-by: Rene Herman

    >
    > I'm not opposed to this in principle, but I don't understand
    > it well enough to really have an informed opinion.
    >
    > IIRC, we give up some seldom-used functionality when running
    > the MPU401 without an IRQ.


    Not even that in fact. When assigned one, the MPU401 IRQ is used for MIDI
    recording but the ALSA MPU401 driver can record without problem without an
    assigned IRQ as well...

    General information, in case it's useful; the MPU401 is the UART that sits
    behind that 15-pin joystick/midi connector on the back of (older, by now)
    soundcards.

    If so inclined, you'd attach for example an external MIDI keyboard (keyboard
    in the piano sense) to it after which you can record what you play and/or
    relay the data to a running software synthesizer to turn your keypresses
    into sound.

    The difference between an assigned IRQ and no assigned IRQ is (I suppose, I
    should say) just that in the latter case you might experience some worse
    latency due to the polled operation.

    However, not many people have external MIDI gear hooked up to an MPU401 in
    the first place and of those that do, none are still using old ISA cards;
    especially not those that care at all about latency. Those people are in
    fact very explicitly likely to use fairly expensive equipment specifically
    for low latency purposes.

    (and modern keyboards connect through USB, not MPU401).

    The other direction, playing MIDI _to_ the MPU401, is a bit more applicable
    to old hardware still due to soundcards with their own onboard wavetable
    synthesizer that takes its input from the MPU401 ("hardware MIDI") but in
    that direction, nothing changes at all, not even latency.

    > Does the driver mention the fact that there's something it can't do
    > because we don't have an IRQ? The user might like to know in case he
    > needs that functionality and wants to fiddle with other devices to free
    > up IRQs.


    So no, there's nothing it can't do without an IRQ and ALSA has always been
    fine with IRQ-less MPU401. It's just that normally the hardware exposes an
    IRQ-less option itself so that the device enables without problem even when
    no IRQ is available for it while the AD181x neglects to do so so that the
    PnP layer complains that it can't enable the device when it's not finding a
    free IRQ -- the situation that drew the complaint/report that led to this
    thread.

    Moreover, for any readers, please note that the patch doesn't make the
    MPU401 operate without an IRQ -- it just provides it with the last resort
    _option_ of functioning without one if none are available (or if the user
    specifically picks that option manually ofcourse).

    > I'm vaguely uncomfortable because this quirk isn't really working
    > around a hardware/firmware issue; it's stepping around the fact
    > that Linux doesn't know how to allocate IRQs between ISA and PCI.
    > Does anybody know how Windows handles this? If Windows can do it
    > without user intervention, maybe we can too.


    Yes, I can appreciate the vague uncomfort. This is improving the hardware
    more then it is fixing it and that might feel like a bit of a misuse of
    quirks. However, given Linux's ability to operate the MPU401 fully without
    an assigned IRQ I feel it does make sense. The hardware shouldn't become
    unavailable just because the system can't find a free IRQ for it.

    As such, it's not really stepping around much of anything; it's just being
    friendly. Do feel it makes sense. Also feel it makes sense to treat an ISA
    card that insists on an MPU401 IRQ to a ride in a blender but there are in
    fact some nice-ish AD1816A cards such as the TerraTec EWS64S still around.

    However, with respect to your direct worry I get sort of foggy. All my ISA
    capable systems seem to have a BIOS that assigns IRQs to each PCI card that
    I put in as evidenced by the neat list of them that most of them print out
    just before the screen says "Verifying DMI Pool Data" and loading linux, an
    OS which I don't recall having ever seen deviate from the BIOS assigned
    values either.

    That is, I'm not sure in how far Linux is involved at all :-?

    > If we continue down the quirk path, would you mind using dev_info()
    > instead of plain printk()?


    Yes. Will regenerate against current mainline. My ISA test machine is
    chugging away on things at the moment. Will repost when it's done.

    Rene.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [PATCH 3/3] PNP: add AD1815 and AD1816 quirks

    On Tuesday 06 May 2008 03:06:14 pm Rene Herman wrote:
    > ...
    > > I'm vaguely uncomfortable because this quirk isn't really working
    > > around a hardware/firmware issue; it's stepping around the fact
    > > that Linux doesn't know how to allocate IRQs between ISA and PCI.
    > > Does anybody know how Windows handles this? If Windows can do it
    > > without user intervention, maybe we can too.

    >
    > Yes, I can appreciate the vague uncomfort. This is improving the hardware
    > more then it is fixing it and that might feel like a bit of a misuse of
    > quirks. However, given Linux's ability to operate the MPU401 fully without
    > an assigned IRQ I feel it does make sense. The hardware shouldn't become
    > unavailable just because the system can't find a free IRQ for it.


    OK, thanks a lot for the explanation. It makes a lot more sense
    now, and I'm happy with your approach now. It shouldn't make anything
    worse, and it should make the card useful in some cases where it
    wasn't before.

    > However, with respect to your direct worry I get sort of foggy. All my ISA
    > capable systems seem to have a BIOS that assigns IRQs to each PCI card that
    > I put in as evidenced by the neat list of them that most of them print out
    > just before the screen says "Verifying DMI Pool Data" and loading linux, an
    > OS which I don't recall having ever seen deviate from the BIOS assigned
    > values either.
    >
    > That is, I'm not sure in how far Linux is involved at all :-?


    This part is just my general unhappiness about options like
    "acpi_irq_nobalance" and "acpi_irq_isa=". I was just wondering
    what Windows does when it can't assign PNP IRQs. Does it assign
    them all before PCI, so they know they have enough? Do it
    dynamically move PCI interrupts? Do it require explicit boot
    flags like Linux does? Or maybe nobody even needs those flags
    on Linux, and the flags are effectively unused.

    Bjorn
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [PATCH 3/3] PNP: add AD1815 and AD1816 quirks

    On 06-05-08 23:27, Bjorn Helgaas wrote:

    > This part is just my general unhappiness about options like
    > "acpi_irq_nobalance" and "acpi_irq_isa=". I was just wondering
    > what Windows does when it can't assign PNP IRQs. Does it assign
    > them all before PCI, so they know they have enough? Do it
    > dynamically move PCI interrupts? Do it require explicit boot
    > flags like Linux does? Or maybe nobody even needs those flags
    > on Linux, and the flags are effectively unused.


    That's for Len. I haven't used Windows in eight or nine years now and am
    consequently progressively ignorant of it.

    Rene.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [PATCH 3/3] PNP: add AD1815 and AD1816 quirks

    On 06-05-08 23:06, Rene Herman wrote:

    > Yes. Will regenerate against current mainline. My ISA test machine is
    > chugging away on things at the moment. Will repost when it's done.


    Ofcourse, on .26-rc1 nothing actually works anymore. One of its 1643 other
    regressions is getting in the way I presume. It's quite impossible to test
    -rc1 kernels on something that actually takes some time to do so...

    And especially .26-rc1. Anyways, will need some time. Can also not test your
    dynamic resource code on that machine until then.

    Rene.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread