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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/