lkml.org 
[lkml]   [1999]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Specifying properly the PCI driver model on all linux archite ctur es, (ioremap(), bus_to_virt() ...)
From
Date
>>>>> "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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.031 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site