Subject: Re: Changing the BAR of a PCI device at driver load time
To: Vincent <10.50@free.fr>
From: Nathan J. Williams <nathanw@wasabisystems.com>
List: tech-kern
Date: 09/05/2003 11:54:00
Vincent <10.50@free.fr> writes:

> since I have updated the Bios on my Compaq Presario laptop, the EHCI
> driver has quit to work. The registers won't read anything else than FF
> in MEM space, while the conf space accesses works fine.

Do you have the same failure with the OHCI or UHCI drivers? The EHCI
stuff is still a bit bleeding-edge, as I understand it, so it may not
be worth the trouble.

> I tinkered around in the ehci_pci.c code, and found nothing. At last, I
> suspected a BIOS bug in the programming of the PCI bridge. To check it
> out, in the driver, I reprogrammed the BAR to close up to another chip
> which works, and, indeed, I could read normally at least one of the
> registers whose access was impossible before.

What value is originally in the BAR, and what are you setting it to?

> Yet, if I could read the capability register, a write access
> generated a page fault, and I was thrown into ddb with a uvm_page_fault
> (even after a pci_mapreg_map with the updated BAR value).

And there's no mapping of the old address before you change it?

> So, my question is : what to do to write a workaround ?

I have a similar hack for one of my systems (Alpha SRM firmware
doesn't cope very well with &*^(^&* PC-oriented PCI cards that only
use the lower 16 bits of the I/O space address), and it works fine to
reprogram the BAR in the driver.

        - Nathan