Patrick> In my opinion the best way to implement ioremap() is with a
Patrick> physical memory pointer as argument, not a PCI bus memory
Patrick> pointer. But no specification exists, and the different
Patrick> answers are not clear. This question is fundamental on
Patrick> architectures like PREP PowerPC where all memory spaces are
Patrick> different and need a translation.
The definition _is_ clear, ioremap() is called with what you find in
the base_address[] pointer(s).
Patrick> The specification of base_address[] is missing too, and need
Patrick> to be defined. I think using the physical address for
Patrick> base_address is the best way.
It varies on different architectures if I remember correctly -
basically all you need to know is that whats found in base_address[]
is handed to ioremap().
Patrick> Physical memory is the only memory space with a different
Patrick> segment for all space available: SDRAM memory, PCI memory,
Patrick> PCI IO memory... With this definition ioremap don't change on
Patrick> x86 platform and can be used to get a virtual memory pointer
Patrick> an a PCI IO space. I think this is the right way.
Thats the x86 way, but since we want PCI drivers to work across
multiple architectures, you need to use the portable API - even if it
is obvious that readl/writel turns into direct accesses on the x86.
Patrick> Functions like readl() or writel() can't in my opinion be
Patrick> compatible with ioremap(). ioremap() returns a virtual memory
Patrick> pointer, and if an indirect access must be used to access PCI
Patrick> memory, an other programming model must be used... The file
Patrick> IO-mapping.txt is obsolete...
Of course they are, thats how the API is defined - there are no
problems with this at all. If you want one example where this is done
correctly, take a look at drivers/net/acenic.[ch] (there was a minor
update to make it run on big endian machines posted recently, the
updated driver version is at
http://home.cern.ch/~jes/gige/acenic.html). Yes this is my code, I am
not trying to state it is perfect, but it does handle the PCI aspects
correctly.
Patrick> I agree with you Bret, we must clarify and write this
Patrick> documentation.
Oh I never disagreed on this, if anyone feels like writing more
documentation, please do. I'd be happy to read it and provide comments
if you write something up.
Jes
-
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/