Yosemite/440EP why are readl()/ioread32() setuptoreadlittle-endian?

[Jenkins, Clive]

I'm not sure all this fuss is justified in response to:

> What is the preferred way of accessing non-PCI devices then?
> Direct pointer access?
> Bye, Peter Korsgaard

Regardless of what standards or hardware might exist, I would be
happy if Linux provided alternatives to readl()... that converted
between big-endian and cpu-endian, so that I could write in my
driver, for example:

static inline my_readl(...)
{
#if (my interconnect is PCI or other little-endian)
    return(readl(...));
#else
    return(readl_be(...));
#endif
}

That must make my driver more portable in future circumstances.

Clive


-----Original Message-----
From: linuxppc-embedded-bounces at ozlabs.org
[mailto:linuxppc-embedded-bounces at ozlabs.org] On Behalf Of Eugene
Surovegin
Sent: 02 February 2006 10:44
To: Jenkins, Clive
Cc: linuxppc-embedded at ozlabs.org
Subject: Re: Yosemite/440EP why are readl()/ioread32()
setuptoreadlittle-endian?


On Thu, Feb 02, 2006 at 10:28:05AM -0000, Jenkins, Clive wrote:
> And what about direct connection to the local bus of the processor
chip?

What about it? It's _chip_ specific. And the way your "generic" stuff 
will be connected to it will be chip or even design specific (yeah, hw 
guys sometime wire it in some weird way). I fail to see how you can 
have _generic_ I/O accessors for this case.

>  
> > So basically, you have no _real_ life examples, so I'm wondering why

> > people need this "arch-independent" non-PCI I/O accessors for 
> > something which doesn't exist.
> 
> I could draft a design of such an example, and I could realise that
> design
> by building it. But I don't want to spend the time and money doing it.
> Neither do I want to spend time researching _real_ examples.
> It is much easier to allow for obvious possibilities that _could_
exist
> and probably will exist if they don't already, than searching the
world.

It's not as easy as you might think :). It must be 
arch/bus/device/board specific in the general case. 

You can try _specifying_ semantics for such generic accessors and 
_then_ we can discuss this and I will very likely give you _real_ 
world examples when they will not work.

> Why be PCI-centric now, when we have experienced no end of problems
> because Linux was x86-centric in the past?

Well, until there is another _standard_ bus which is used on 
different archs, having _generic_ cross-arch I/O accessors doesn't 
make any sense.

I don't understand your point about not being PCI specific. It's of no 
relevance what you or I think about PCI and x86. I have ported several 
"standard" bus drivers to chip specific interconnects (MIPS and PPC) 
and in every case code was bus or even board specific. I'm pretty much 
aware about problems and solutions. But this is not what is being 
discussed here. Until there is _standard_ for such interconnects (like 
PCI) everything else is just wishful thinking.

-- 
Eugene

_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded at ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded