linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: David Miller <davem@davemloft.net>
Cc: linuxppc-dev@ozlabs.org, thunderbird2k@gmail.com, John.Linn@xilinx.com
Subject: Re: Musings on PCI busses
Date: Thu, 21 May 2009 07:56:09 +1000	[thread overview]
Message-ID: <1242856569.16901.199.camel@pasglop> (raw)
In-Reply-To: <20090520.122453.169463011.davem@davemloft.net>


> I mean that all OF devices have fully resolved MMIO resources.  So
> very early serial devices that sit in I/O space on sparc64 end
> up being OF device drivers.  See for example, drivers/net/sunsu.c
> which is simply a 8250 chip that sits behind Sun's I/O space bus
> that sits on PCI and provides things normally found via ISA on
> x86 machines.  Another example is drivers/serial/sunsab.c

Right. On Cell, we use the "normal" 8250 driver, via of_serial which
basically initializes it from the of device and associated resources.

It gets a bit messy because we -also- create a platform driver that can
be matched by 8250, in fact, we have a bit of generic powerpc code that
does that early at boot, initializes our low level very early udbg
thingy with it and creates the platform devices.

And then the serial port can -also- be detected by 8250_pci.c when it's
on a PCI based UART :-)

Now, generally thinks work fine even if you use all 3 drivers because
they have the same resources and 8250 has some smarts to figure that out
and not re-create ports. It somewhat fails in the case where we end up
with IO looking like MMIO on one side and looking like PCI IO on another
tho.

We -could- try to standardize on a single of those 3 methods of course.
The of_serial one has some appeal but I quite like the platform driver
approach at this stage because we have code to handle all sort of weirdo
special cases in there (more or less insane device-tree's, weird SoC's,
etc...) and still pump out something 8250_platform can grok, and that
code can run -very- early and provide a udbg backend for early debug and
xmon usage.

> I would make these device drivers OF device drivers.
> 
> Another option is to make use of the "address" property if present.
> You can bypass all of the hassle of figuring out what the 'reg'
> property resolves to by using that and if the device is the
> console it is pretty reliable to expect OF to provide that "address"
> property.
> 
> Of course this doesn't work well for non-console devices.

Also we have various broken firmwares with non usable "address"
properties to deal with.

Ben.

      parent reply	other threads:[~2009-05-20 21:56 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-19 15:28 Musings on PCI busses Grant Likely
2009-05-19 16:12 ` Arnd Bergmann
2009-05-19 19:05   ` David Miller
2009-05-19 20:02     ` Grant Likely
2009-05-20  5:33     ` Benjamin Herrenschmidt
2009-05-19 16:25 ` Stephen Neuendorffer
2009-05-19 16:30   ` Grant Likely
2009-05-20  3:02   ` Benjamin Herrenschmidt
2009-05-20  3:17     ` Grant Likely
2009-05-20  5:31       ` Benjamin Herrenschmidt
2009-05-20  3:01 ` Benjamin Herrenschmidt
2009-05-20  5:51   ` David Miller
2009-05-20  6:51     ` Benjamin Herrenschmidt
2009-05-20 19:24       ` David Miller
2009-05-20 20:06         ` Grant Likely
2009-05-20 21:59           ` Benjamin Herrenschmidt
2009-05-20 22:28             ` Grant Likely
2009-05-20 22:41             ` David Miller
2009-05-20 22:49               ` Benjamin Herrenschmidt
2009-05-20 21:56         ` Benjamin Herrenschmidt [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=1242856569.16901.199.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=John.Linn@xilinx.com \
    --cc=davem@davemloft.net \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=thunderbird2k@gmail.com \
    /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).