linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Eugene Surovegin <ebs@ebshome.net>
To: "Jenkins, Clive" <Clive.Jenkins@xerox.com>
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Yosemite/440EP why are readl()/ioread32() setup toreadlittle-endian?
Date: Thu, 2 Feb 2006 02:44:15 -0800	[thread overview]
Message-ID: <20060202104415.GC12810@gate.ebshome.net> (raw)
In-Reply-To: <35786B99AB3FDC45A8215724617919736D921D@gbrwgceumf01.eu.xerox.net>

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

      reply	other threads:[~2006-02-02 10:44 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-02 10:28 Yosemite/440EP why are readl()/ioread32() setup toreadlittle-endian? Jenkins, Clive
2006-02-02 10:44 ` Eugene Surovegin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060202104415.GC12810@gate.ebshome.net \
    --to=ebs@ebshome.net \
    --cc=Clive.Jenkins@xerox.com \
    --cc=linuxppc-embedded@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).