All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marek.vasut@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC PATCH v2 1/6] fdt: ARM: Add device tree control of U-Boot (CONFIG_OF_CONTROL)
Date: Tue, 13 Sep 2011 07:18:01 +0200	[thread overview]
Message-ID: <201109130718.01732.marek.vasut@gmail.com> (raw)
In-Reply-To: <CAPnjgZ3kZJoAGJFkPkxQp+-jnztYECUaEtLZ0nvgzV1f-xUQgQ@mail.gmail.com>

On Tuesday, September 13, 2011 06:52:34 AM Simon Glass wrote:
> Hi Merek,
> 
> On Mon, Sep 12, 2011 at 8:10 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> > On Tuesday, September 13, 2011 12:04:22 AM Simon Glass wrote:
> >> This adds a device tree pointer to the global data. It can be set by
> >> board code. A later commit will add support for embedding it in U-Boot.
> >> 
> >> Signed-off-by: Simon Glass <sjg@chromium.org>
> >> ---
> >>  README                             |   11 +++++++++++
> >>  arch/arm/include/asm/global_data.h |    1 +
> >>  2 files changed, 12 insertions(+), 0 deletions(-)
> > 
> > Hi,
> > 
> > do you actually intend to introduce some kind of a driver model to uboot
> > ?
> 
> I would love to, yes. To some extent there is a bit of this already,
> at least for specific subsystems. Clearly the fdt would work better if
> we could just hand U-Boot the fdt and say 'init yourself'. It would
> then scan the tree and init all the drivers for all active devices.
> 
> However, we can achieve most of the aims using something along the
> lines of what I have proposed, where the existing call (say to
> nand_init()) can look up the fdt for its node, and then get the
> information it needs. The only really difference is the explicit
> hard-coded call to nand_init, rather than a general purpose routine to
> find a nand node and then locate a driver for it.
> 
> To some extent that way of doing things would invert the way U-Boot
> currently works. It would also introduce questions about dealing with
> multiple devices of the same type (e.g. two different i2c controllers
> (not just instances) or driving two displays. These sorts of things
> are tricky in U-Boot at the moment.
> 
> So overall I think a unified driver model is a separate problem, and
> one that we should discuss and perhaps move forward on separately.

Well, I have this kind of stuff in mind and I plan to try pushing it as a 
university project in a month or so.

But (!) if you plan to init U-Boot according to FDT and I plan to add driver 
model, we should keep in tight contact so the driver model would be close to the 
FDT.

And yea -- dealing with the "dirty work" like fixing subsystems etc. would be 
part of the driver model stuff.

Cheers
> 
> Regards.
> Simon

  reply	other threads:[~2011-09-13  5:18 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-12 22:04 [U-Boot] [RFC PATCH v2 0/6] Run-time configuration of U-Boot via a flat device tree (fdt) Simon Glass
2011-09-12 22:04 ` [U-Boot] [RFC PATCH v2 1/6] fdt: ARM: Add device tree control of U-Boot (CONFIG_OF_CONTROL) Simon Glass
2011-09-13  3:10   ` Marek Vasut
2011-09-13  4:52     ` Simon Glass
2011-09-13  5:18       ` Marek Vasut [this message]
2011-09-13  9:47       ` Wolfgang Denk
2011-09-13 11:44         ` Simon Glass
2011-09-13 11:57           ` Wolfgang Denk
2011-09-13 12:14             ` Simon Glass
2011-09-13 13:12               ` Wolfgang Denk
2011-09-13 18:16   ` Mike Frysinger
2011-09-13 18:24     ` Simon Glass
2011-09-12 22:04 ` [U-Boot] [RFC PATCH v2 2/6] fdt: Add support for embedded device tree (CONFIG_OF_EMBED) Simon Glass
2011-09-12 23:37   ` Jason
2011-09-13  0:12     ` Simon Glass
2011-09-13 14:37       ` Jason
2011-09-13 21:06         ` Simon Glass
2011-09-14 13:47           ` Jason
2011-09-14 15:47             ` Simon Glass
2011-09-14 16:11               ` Jason
2011-09-14 17:45                 ` Simon Glass
2011-09-14 19:50                   ` Jason
2011-09-14 20:05                     ` Simon Glass
2011-09-14 20:16                       ` Jason
2011-09-14 20:24                         ` Simon Glass
2011-09-14 20:35                           ` Jason
2011-09-14 16:45   ` Grant Likely
2011-09-14 18:03     ` Simon Glass
2011-09-14 19:17       ` Grant Likely
2011-09-14 19:22         ` Simon Glass
2011-09-14 20:11     ` Wolfgang Denk
2011-09-14 20:32       ` Simon Glass
2011-09-14 21:09       ` Grant Likely
2011-09-12 22:04 ` [U-Boot] [RFC PATCH v2 3/6] fdt: Add support for a separate device tree (CONFIG_OF_SEPARATE) Simon Glass
2011-09-14 16:48   ` Grant Likely
2011-09-14 18:25     ` Simon Glass
2011-09-12 22:04 ` [U-Boot] [RFC PATCH v2 4/6] fdt: ARM: Implement embedded and separate device tree Simon Glass
2011-09-12 22:04 ` [U-Boot] [RFC PATCH v2 5/6] fdt: add decode helper library Simon Glass
2011-09-12 22:04 ` [U-Boot] [RFC PATCH v2 6/6] fdt: example modification of i2c driver for fdt control Simon Glass
2011-09-13 18:28 ` [U-Boot] [RFC PATCH v2 0/6] Run-time configuration of U-Boot via a flat device tree (fdt) Simon Glass
2011-09-15 13:54 ` [U-Boot] [RFC PATCH 0/4 v1] Use fdt to init mvrtc driver for dreamplug Jason Cooper
2011-09-15 13:54   ` [U-Boot] [RFC PATCH 1/4 v1] fdt: remove i2c example code Jason Cooper
2011-09-16  7:31     ` Kumar Gala
2011-09-16 12:00       ` Jason
2011-09-15 13:54   ` [U-Boot] [RFC PATCH 2/4 v1] fdt_decode: make more available Jason Cooper
2011-09-15 19:18     ` Simon Glass
2011-09-15 19:48       ` Jason
2011-09-15 13:54   ` [U-Boot] [RFC PATCH 3/4 v1] mvrtc: add fdt support Jason Cooper
2011-09-15 19:23     ` Simon Glass
2011-09-15 20:01       ` Jason
2011-10-06 21:31     ` Wolfgang Denk
2011-10-06 21:42       ` Simon Glass
2011-10-12  0:16         ` Simon Glass
2011-09-15 13:54   ` [U-Boot] [RFC PATCH 4/4 v1] dreamplug: enable fdt Jason Cooper
2011-09-15 19:25     ` Simon Glass
2011-09-15 19:50       ` Jason
2011-09-15 19:16   ` [U-Boot] [RFC PATCH 0/4 v1] Use fdt to init mvrtc driver for dreamplug Simon Glass
2011-09-15 19:46     ` Jason

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=201109130718.01732.marek.vasut@gmail.com \
    --to=marek.vasut@gmail.com \
    --cc=u-boot@lists.denx.de \
    /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.