lkml.org 
[lkml]   [2005]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: 2.6.13-rc3-mm3


    On Sun, 31 Jul 2005, Manuel Lauss wrote:
    >
    > something broke the sonypi driver a bit after -mm2:
    > I can no longer set bluetooth-power for instance, and it logs these
    > messages:
    >
    > sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 605)
    > sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 607)
    > sonypi command failed at drivers/char/sonypi.c : sonypi_call1 (line 594)
    >
    > setting/getting brightness, getting battery/ac status still work.
    >
    >
    > The ioports assignments have changed a bit between -mm2 and -mm3:

    The diff shows:

    -/proc/ioports on -mm2:
    +/proc/ioports on -mm3:
    0000-001f : dma1
    0020-0021 : pic1
    0040-0043 : timer0
    @@ -25,13 +25,13 @@
    0540-055f : 0000:00:1f.3
    0540-054f : i801-smbus
    0cf8-0cff : PCI conf1
    -1080-109f : Sony Programable I/O Device
    +1000-1fff : PCI CardBus #03
    + 1080-109f : Sony Programable I/O Device
    +2000-2fff : PCI CardBus #03
    c000-cfff : PCI Bus #01
    c800-c8ff : 0000:01:00.0
    c800-c8ff : radeonfb
    d000-dfff : PCI Bus #02
    - d000-d1ff : PCI CardBus #03
    - d400-d5ff : PCI CardBus #03
    dc00-dc3f : 0000:02:03.0
    dc00-dc3f : e1000
    e000-e03f : 0000:00:1f.5

    ie the difference is that the PCI cardbus resources have been moved from
    inside PCI Bus #2 to outside of it, and as a side effect the sonypi
    device just happened to be allocated inside the Cardbus IO space.

    Now, this is really unlucky. There are two issues here:

    - the -mm2 iomap just _looks_ better. I can't tell what the exact
    difference is, but it looks like one of the PCI resource allocation
    patches got reverted or re-applied.

    However, I'm almost positive that this is the Intel transparent bridge
    thing, and it doesn't really matter where the CardBus resources got
    allocated. So the _real_ breakage is probably due to a totally
    unrelated issue:

    - The SonyPI driver just allocates IO regions in random areas. It's got a
    list of places to try allocating in, and the 1080 area just happens to
    be the first on the list, and since it's not used by anything else, it
    succeeds (never mind that it's on totally the wrong bus).
    and I think the real bug here is the SonyPI driver.

    It should either use an IO port in the legacy motherboard resource area
    (ie allocate itself somewhere in IO ports 0x100-0x3ff), _or_ it should
    play well as a PCI device, and actually try to work with the PCI IO port
    allocation layer.

    So instead of just saying "I want port 1080" (which may be on some other
    bus entirely), it _could_ (and should) do something like

    /*
    * Use "device resource 6" for this: it's traditionally
    * the PCI ROM resource, but we don't have a ROM, so we take it
    * over for our special IO region.
    */
    struct resource *res = dev->resource + 6;
    int ret;
    res->flags = IORESOURCE_IO;
    ret = pci_bus_alloc_resource(dev->bus, /* bus */
    res, /* resource */
    SONYPI_TYPE2_REGION_SIZE, /* size */,
    SONYPI_TYPE2_REGION_SIZE, /* alignment */,
    PCIBIOS_MIN_IO, /* Min starting pos */
    IORESOURCE_IO, /* IO type */
    pcibios_align_resource, /* Standard alignment */
    dev);
    if (ret < 0)
    return -ENODEV;
    .. use port "res->start" ..

    which should do the right thing.

    Stelian? The above is untested, but it should give roughly the right
    behaviour - you might need to tweak it a bit, but I think it should be a
    lot better than just picking random IO ports out of your hat and seeing if
    they are already used by something else...

    Linus
    -
    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/

    \
     
     \ /
      Last update: 2009-11-18 23:46    [W:6.876 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site