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

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@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Eugene
Surovegin
Sent: 02 February 2006 10:44
To: Jenkins, Clive
Cc: linuxppc-embedded@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=20
will be connected to it will be chip or even design specific (yeah, hw=20
guys sometime wire it in some weird way). I fail to see how you can=20
have _generic_ I/O accessors for this case.

=20

quoted

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

quoted

people need this "arch-independent" non-PCI I/O accessors for=20
something which doesn't exist.

=20
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=20
arch/bus/device/board specific in the general case.=20

You can try _specifying_ semantics for such generic accessors and=20
_then_ we can discuss this and I will very likely give you _real_=20
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=20
different archs, having _generic_ cross-arch I/O accessors doesn't=20
make any sense.

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

--=20
Eugene

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

On Thu, Feb 02, 2006 at 11:26:22AM -0000, Jenkins, Clive wrote:

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

Huh?

If you re-read this thread, you'll notice that I was responding to 
e-mail where original poster did NOT want to do exactly this in his 
driver. But you are suggesting what we were discussing on how to  
_avoid_. I'm really confused, what is your point?

What I was talking, in short, that if we _really_ want generic non-PCI 
accessors, we need something similar to the way IDE layer defines its 
I/O operations - bunch of per-bus/device function pointers which can 
be overridden depending on arch, bus and the way peripheral is wired.

-- 
Eugene