What exactly is it that ioremap() returns?
> >> This one is not allowed to be accessed directly by the CPU but must
> >> use the readl/writel macros, or __raw_readl/__raw_writel ones.
>
> Bret> Where in the heck did you find that?
>
> By following Linux kernel.
This would be part of the problem I mentioned.
It also totally destroys Alan Cox's and other peoples statements in the past
about Linux being faster than something like UDI because it doesn't have to
go through a routine just to access the bus.
> Bret> I was under the impression that the readb/w/l and writeb/w/l
> Bret> were only for spaces marked as I/O space in PCI. I thought that
> Bret> if it was in PCI memory space you could directly reference the
> Bret> address after you used ioremap().
>
> I/O space as in I/O ports registers or as in PCI shared memory?
I/O space as in marked as I/O in the PCI configuration registers. I think
there is a
> Bret> If this is true, you can't just directly access the virtual
> Bret> address, then somebody should really add this information to the
> Bret> Documentation/pci.txt file.
>
> The problem here is that some PCI implementations will not provide a
> direct linear mapping of the PCI shared memory space, like on some
> Alphas which come with sparse memory.
I thought they got rid of that sparse addressing junk. It was always a
kludge to work around lack of a true access of less than one word.
> >> Remember that the base_address[] value are not some that we just
> >> make out of nowhere, they are assigned by the hardware/bios at boot
> >> time and we read them out of registers.
>
> Bret> Actually, my understanding is that the base_address[] is
> Bret> assigned in the PCI configuration.
>
> Correct, maybe I wasn't clear enough on this one.
>
> Bret> If people really want to get the device drivers all working
> Bret> correctly, you should probably start by agreeing on AND
> Bret> DOCUMENTING exactly what 'correct' is. Without such information
> Bret> available, people are going to keep on having problems writing
> Bret> device drivers.
>
> I thought it was already documented, but I guess you are
> right. Documentation/pci.txt still refers to the old and deprecated
> pcibios_foo() functions and Documentation/IO-mapping.txt doesn't
> mention sparse memory directly, though it does state that one should
> use readl/writel.
Check a more recent copy of the file.
Documentation/pci.txt does state that the old pcibios functions are
depreciated. It also includes warning about having to use the values from
struct pci_dev for ioremap(), although the description could be improved.
In rereading it, I see that the IO-mapping.txt file does mention that you
need to use the readl/w/b and writel/w/b functions. This statement really
needs to be added to section 4 of the pci.txt file, since most of the
documentation is talking about things needed for PCI DMA masters.
I'm really getting to dislike Linux because of this kind of stuff.
It is no surprise to me that many of the drivers don't do things correctly,
considering how tough it is to determine what correct is.
-Bret
-------------------------------------------------------------
SBS Technologies, Connectivity Products
... solutions for real-time connectivity
Bret Indrelee, Engineer
SBS Technologies, Inc., Connectivity Products
1284 Corporate Center Drive, St. Paul MN 55121
Direct: (651) 905-4731
Main: (651) 905-4700 Fax: (651) 905-4701
E-mail: bindrelee@sbs-cp.com http://www.sbs.com
-------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/