All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Scott Anderson <scott_anderson@mvista.com>
Cc: Tom Rini <trini@kernel.crashing.org>,
	Armin Kuster <akuster@mvista.com>,
	linuxppc-embedded@lists.linuxppc.org,
	Paul Mackerras <paulus@samba.org>
Subject: Re: Trivial cleanup in ocp_uart.c
Date: Thu, 27 Jun 2002 10:41:44 +1000	[thread overview]
Message-ID: <20020627004144.GR9087@zax> (raw)
In-Reply-To: <3D19F965.86668872@mvista.com>


On Wed, Jun 26, 2002 at 10:27:01AM -0700, Scott Anderson wrote:
>
> David Gibson wrote:
> > Basically there are two quite distinct approaches either of which
> > would make sense (for any given peripheral/bus type):
> >         a) Register each device as it is discovered.  Register each
> > driver as the appropriate module loads.  Whenever either event happens
> > the common code calls init or probe callbacks in a driver to connect
> > it to any devices of appropriate type.
> >         b) No registration.  When a driver loads, it searches for all
> > devices of appropriate type, and initializes each of them in turn.
> >
> > Examples of (a) include the new PCI interface, PCMCIA, and the 2.5
> > unified device model.  Examples of (b) include the old PCI interface
> > (pci_find_device()) and (some?/all?) non-PCI devices on OF machines
> > (e.g. Airport).
> >
> > Approach (a) is clearly needed to handle hotplug.  But that's not an
> > issue for OCPs (indeed device (not driver) registration will always be
> > degenerate) so either approach would do.  Frankly (a) seems overkill
> > for OCPs, but it does have the advantage of being easily integrated
> > into the unified device model.
>
> I wouldn't be quite so quick to dismiss the issue of hotplug from OCP.
> I have heard rumblings of people having FPGAs with on-chip processors
> wanting to reprogram the FPGAs on the fly with different sets of
> peripherals.

Eek, wibble.  It still seems somewhat unlikely to me that you'd be
changing the peripherals "on the fly" in a real life embedded
application.  Especially considering that reboots are likely to be
much less of an issue on an embedded system than on a big server.

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2002-06-27  0:41 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-20  7:34 Trivial cleanup in ocp_uart.c David Gibson
2002-06-20 15:50 ` Tom Rini
2002-06-21  0:52   ` David Gibson
2002-06-21 14:39     ` Tom Rini
2002-06-24  7:40       ` David Gibson
2002-06-26 17:27         ` Scott Anderson
2002-06-27  0:41           ` David Gibson [this message]
2002-06-27 16:23             ` Scott Anderson
2002-06-27 16:52               ` Kenneth Johansson
2002-06-28  0:59               ` David Gibson
2002-06-28 14:57                 ` Tom Rini
2002-06-27 21:21         ` Armin Kuster
2002-06-27 20:30           ` Paul Mackerras
2002-06-27 21:12             ` Kenneth Johansson

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=20020627004144.GR9087@zax \
    --to=david@gibson.dropbear.id.au \
    --cc=akuster@mvista.com \
    --cc=linuxppc-embedded@lists.linuxppc.org \
    --cc=paulus@samba.org \
    --cc=scott_anderson@mvista.com \
    --cc=trini@kernel.crashing.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.