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

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

[Jenkins, Clive]

> > On Thu, Feb 02, 2006 at 09:35:56AM -0000, Jenkins, Clive wrote:
> > A driver for some device that could be connected to (or plugged
into)
> > a variety of different platforms of different architecture.
> > A driver for a core that could be implemented within an FPGA on
> > multiple platforms.

> Well, this is all nice but I was wondering about _real_ examples.
> When you are talking about "connecting" or "plugging" you have to keep

> in mind actual bus interconnect. So far AFAIK PCI (and derivatives)=20
> are the only cross-arch bus.

Yes, I do realise that in most cases PCI is used for cross-arch
interconnect. But without knowing about all the relevant hardware in the
world, I couldn't say that there are no other cross-arch buses.
And what about direct connection to the local bus of the processor chip?
=20
> So basically, you have no _real_ life examples, so I'm wondering why=20
> people need this "arch-independent" non-PCI I/O accessors for=20
> 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.

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

> I think the reason why Linux doesn't have this stuff follows from the=20
> previous paragraph.

Clive

Re: Yosemite/440EP why are readl()/ioread32() setup toreadlittle-endian?

[Eugene Surovegin]

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