Messages in this thread | | | Subject | Re: Specifying properly the PCI driver model on all linux archite ctur es, (ioremap(), bus_to_virt() ...) | From | Jes Sorensen <> | Date | 02 Nov 1999 17:23:24 +0100 |
| |
>>>>> "Patrick" == Patrick Lerda <LERDA@microprocess.com> writes:
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/
| |