Re: ((struct pci_dev*)dev)->resource[...].start
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 )? 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ((struct pci_dev*)dev)->resource[...].start
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 | - 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/
Re: ((struct pci_dev*)dev)->resource[...].start
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. - 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/
RE: ((struct pci_dev*)dev)->resource[...].start
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 )? 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
-
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/
Re: ((struct pci_dev*)dev)->resource[...].start
"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 )? 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 |
-
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/
Re: ((struct pci_dev*)dev)-resource[...].start
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 |
-
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/
RE: ((struct pci_dev*)dev)-resource[...].start
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
-
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/
Re: ((struct pci_dev*)dev)-resource[...].start
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. - 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/
Re: ((struct pci_dev*)dev)-resource[...].start
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 | - 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/
Re: ((struct pci_dev*)dev)-resource[...].start
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
