((struct pci_dev*)dev)->resource[...].start

((struct pci_dev*)dev)->resource[...].start

[Khachaturov, Vassilii]

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?

2) (Basically, the question is "Do I understand Documentation/IO-mapping.txt
right?")
PCI memory, whenever IO type or memory type, can not be dereferenced but
should be accessed with readb() etc. On i386, PCI mem (memory type) can be
accessed by direct pointer access, but this is not portable.

Kind regards,
	Vassilii

Re: ((struct pci_dev*)dev)->resource[...].start

[Jeff Garzik]

"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).

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.

Finally, make sure to use pci_resource_{start,end,len,flags} macros to
make your core more portable and future-proof.

> 2) (Basically, the question is "Do I understand Documentation/IO-mapping.txt
> right?")
> PCI memory, whenever IO type or memory type, can not be dereferenced but
> should be accessed with readb() etc. On i386, PCI mem (memory type) can be
> accessed by direct pointer access, but this is not portable.

We will yell at you mightily if you directly access PCI mem with a
pointer.  As you say it only works on i386 -- but IIRC since ioremap is
required, we are perfectly free to change or modify that assumption. 
For example ioremap might [have to] care about whether or not a pci mem
region is prefetchable.

-- 
Jeff Garzik      | Game called on account of naked chick
Building 1024    |
MandrakeSoft     |

Re: ((struct pci_dev*)dev)->resource[...].start

[Jonathan Lundell]

At 5:37 PM -0400 2001-05-16, Jeff Garzik wrote:
>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).

Would you please elaborate? If I understand what you're saying, you 
can't rely on the "pointer" returned by ioremap() because the OS 
might reprogram the relevant BAR out from under you. So one would 
need to know: when does a driver have to re-ioremap() due to the BAR 
having been (potentially) changed? I'd expect the answer to be: for 
all practical purposes never.

-- 
/Jonathan Lundell.

Re: ((struct pci_dev*)dev)->resource[...].start

[Jeff Garzik]

Jonathan Lundell wrote:
> 
> At 5:37 PM -0400 2001-05-16, Jeff Garzik wrote:
> >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).
> 
> Would you please elaborate? If I understand what you're saying, you
> can't rely on the "pointer" returned by ioremap() because the OS
> might reprogram the relevant BAR out from under you. So one would
> need to know: when does a driver have to re-ioremap() due to the BAR
> having been (potentially) changed? I'd expect the answer to be: for
> all practical purposes never.

no-no-no.  I DON'T mean that OS will reprogram the BARs underneath you.

Only that it is the responsibility of the OS to program the BARs, and
that you should be getting the BAR info out of dev->resource[].

Note only does this make the code much cleaner, but this gives us a lot
more flexibility about when and how we program the PCI bus.  The PCI
driver only needs to know the location and size of the region it needs
to access.  If the OS, in the future, has to support some weird IOMMU or
PCI mapping capabilities, we don't have to go through and change all the
drivers which are suddenly broken by this new hardware... we just change
it in one canonical place: the PCI core.  (at this point the lecture
turns into why APIs exist and should be used, and it gets more boring
from there...)

-- 
Jeff Garzik      | Game called on account of naked chick
Building 1024    |
MandrakeSoft     |

Re: ((struct pci_dev*)dev)->resource[...].start

[Albert D. Cahalan]

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?

RE: ((struct pci_dev*)dev)->resource[...].start

[Khachaturov, Vassilii]

Jeff,
Many thanks for the clarifications.

> From: Jeff Garzik
> "Khachaturov, Vassilii" wrote:
[snip]
> > 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).
[snip]

I am not a bus driver, and I do call pci_enable_device once my device gets 
probed and recognized by my driver. I always read from dev->resource[].
But what are the "certain times" you've mentioned? What is the scope
within which I know the BARs didn't change?
 
> Finally, make sure to use pci_resource_{start,end,len,flags} macros to
> make your core more portable and future-proof.
I didn't use the macros - now I do, thanks for the tip!

> > 2) (Basically, the question is "Do I understand 
> Documentation/IO-mapping.txt
> > right?")
> > PCI memory, whenever IO type or memory type, can not be 
> dereferenced but
> > should be accessed with readb() etc. On i386, PCI mem 
> (memory type) can be
> > accessed by direct pointer access, but this is not portable.
> 
> We will yell at you mightily if you directly access PCI mem with a
> pointer.  As you say it only works on i386 -- but IIRC since 

Right now I am porting a driver to Linux which has so much i386 things in it

(esp. byte order stuff). So far I haven't spoilt it with PCI i386 hacks
though...

> ioremap is
> required, we are perfectly free to change or modify that assumption. 
> For example ioremap might [have to] care about whether or not 
> a pci mem
> region is prefetchable.

A really silly q. (I don't quite understand the Linux internals yet):
Is ioremap() needed (in general vs. i386) for memory type PCI memory too, 
or only for IO type?
(In case the default size of the region associated with a BAR is fine with
me?)

Thanks,
	Vassilii