All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Porter <mporter@kernel.crashing.org>
To: Yasushi SHOJI <yashi@atmark-techno.com>
Cc: linuxppc-embedded <linuxppc-embedded@ozlabs.org>
Subject: Re: ppc_sys.c with platform device model or create opb bus?
Date: Sat, 23 Jul 2005 07:48:42 -0700	[thread overview]
Message-ID: <20050723074842.C5431@cox.net> (raw)
In-Reply-To: <87hdeuosmq.wl@mail2.atmark-techno.com>; from yashi@atmark-techno.com on Sun, Jul 17, 2005 at 03:26:21PM +0900

On Sun, Jul 17, 2005 at 03:26:21PM +0900, Yasushi SHOJI wrote:
> Hi all,
> 
> I've been reading some posts regarding to the transition of OCP to
> platform device mode while searching for a good way to implement a
> device driver for our fpga base platform. And now I have one question
> regarding to ppc_sys.c
> 
>   should I use ppc_sys_*() for platform like fpga?
> 
> since I'm working on FPGA base platform, ppc_sys_spec seems to be too
> static. that is, IMHO, having static array of device list isn't ideal
> for a dynamic system like fpga.
> 
> I feel that the ppc_sys_spec is for SoC, which doesn't dynamically
> change the peripherals it has.  otoh, fpga based platform can have
> arbitrary number of devices if you configured so.
> 
> I usually implement a device with PLB or OPB.  for those bus, should I
> use platform device model or create new buses for each?

Use the platform model.  When you run into a case that can't be
handled properly then the platform model should be expanded to handle
it. If you instantiate a "platform device" by configuring the FPGA
from userspace then that's a hotplug event.  The platform model
should be extended to handle hotplug for these kind of cases since
they are pretty common.

-Matt

  reply	other threads:[~2005-07-23 14:48 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-17  6:26 ppc_sys.c with platform device model or create opb bus? Yasushi SHOJI
2005-07-23 14:48 ` Matt Porter [this message]
2005-07-23 17:03 ` Grant Likely
2005-07-23 18:34   ` Need SEC 1.0 Descriptor programmer's guide Vikas Aggarwal

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=20050723074842.C5431@cox.net \
    --to=mporter@kernel.crashing.org \
    --cc=linuxppc-embedded@ozlabs.org \
    --cc=yashi@atmark-techno.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 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.