FW: TI1510 probelm - can you help direct me?

Pavel Roskin proski at gnu.org
Thu May 6 20:28:45 BST 2004

On Thu, 6 May 2004, Pavel Roskin wrote:

> In my case, I have found that the I/O window at 0x4000-0x40ff should not
> be used by cardbus.  It can be achieved by adding "reserve=0x4000,0x100"
> to the kernel command line.

I enabled CONFIG_PNPBIOS in the kernel and found what uses that range.
>From lspnp output (lspnp utility is included with pcmcia-cs):

0a PNP0a03 bridge controller: PCI
        io 0x0294-0x0297
        io 0x04d0-0x04d1
        io 0x0cf8-0x0cff
        io 0x0480-0x048f
        io 0x4000-0x40f7

CONFIG_PNPBIOS wasn't enabled because it was unavailable without
CONFIG_ISA defined.  And CONFIG_ISA wasn't defined because I assumed from
the help that it's responsible only for ISA cards: "Find out whether you
have ISA slots on your motherboard."

I think it's a bad idea to make CONFIG_PNPBIOS dependent on CONFIG_ISA.
I think CONFIG_PNPBIOS should be made independent and should be strongly
recommended or even defined without asking the user if some other features
(like ACPI, PCI or PCMCIA) are enabled.

Unfortunately, enabling CONFIG_PNPBIOS didn't reserve the regions as shown
in /proc/iomem.  yenta_socket would still use 0x4000-0x40ff.

I understand the reason.  The PNPBIOS cannot be reserved unconditionally.
A driver for the device described by PNPBIOS (PCI bridge in this case)
should be able to claim the resource.  Other drivers (yenta_socket) should
not use that resource.

I remember seeing a discussion about this issue in this list.  I hope this
problem will be addressed.

An interim solution would be to increase PCIBIOS_MIN_CARDBUS_IO from
0x4000 to 0x5000, as Pavel Machek suggested.  It won't grow to 0xffff -
the kernel will honor PNPBIOS resources before it happens.

And by the way, prism54 started working for me once I reserved the
0x4000-0x40ff range.  It used to fail.

Pavel Roskin

More information about the linux-pcmcia mailing list