lkml.org 
[lkml]   [2001]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: ((struct pci_dev*)dev)->resource[...].start
    Date
    Jeff Garzik writes:
    > "Khachaturov, Vassilii" wrote:

    >> Can someone please confirm if my assumptions below are correct:
    >> 1) Unless someone specifically tampered with my driver's device
    >> since the OS bootup, the mapping of the PCI base address registers
    >> to virtual memory will remain the same (just as seen in /proc/pci,
    >> and as reflected in <subj>)? If not, is there a way to freeze it
    >> for the time I want to access it?
    >
    > This is not a safe assumption, because the OS may reprogram the
    > PCI BARs at certain times. The rule is: ALWAYS read from
    > dev->resource[] unless you are a bus driver (PCI bridges, for
    > example, need to assign resources).

    Well, I have a bus driver. Just how do I get a bus number?
    My hardware comes up as a regular device, then mutates into
    a bridge when I flip a bit in a config register. The header
    even changes from type 1 to type 2. The class code is always
    the same, a bridge device, but not PCI-to-PCI. It's kind of
    like hot-plug PCI over a network, with all sorts of extra
    alignment restrictions on address space allocation.

    So maybe this card is on bus 42. I need a secondary bus number,
    plus a few more in case there are more bridges downstream.
    I can't just grab 42..44 because they might be used elsewhere,
    and I can't just grab 253..255 either because that upsets the
    whole system of bus number assignment being done by carving up
    the space granted to upstream bridges.

    BTW, is there any reason why the primary bus register of a
    bridge would have to be set correctly? I have to set mine equal
    to the secondary bus register to keep the hardware happy.

    > Further, access to PCI BARs -and- dev->resource[] in a driver is
    > wrong until you have called pci_enable_device. Resource and IRQ
    > assignment potentially occurs at pci_enable_device time, so BAR
    > is [potentially] undefined before then.

    Hmmm. I can use device-specific config space registers to change
    the size of a BAR. (or limit & base, whatever) Say I want to have
    512 MB, but the bridge upstream only has 128 MB allotted to it.
    How do I fix this?


    -
    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: 2005-03-22 12:53    [W:0.024 / U:0.132 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site