public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [PATCH] RFC: tiny-dm: Proposal for using driver model in SPL
Date: Mon, 25 May 2020 15:47:37 -0400	[thread overview]
Message-ID: <20200525194737.GS12717@bill-the-cat> (raw)
In-Reply-To: <20200525093539.1.Ibf2d19439cde35e39192a9d4a8dad23539fae2e6@changeid>

On Mon, May 25, 2020 at 09:35:44AM -0600, Simon Glass wrote:

> This patch provides the documentation for a proposed enhancement to driver
> model to reduce overhead in SPL.
> 
> The actual patches are not included here because they are based on some
> pending work by Walter Lozano which is not in final form.
> 
> For now, the source tree is available at:
> 
>    https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/tree/dtoc-working
> 
> Comments welcome!

So here's my worry.  It's not clear, aside from the device tree, how
much re-use of existing code we get with this.  It feels like it might
be fairly minimal.  And at that point, are we not perhaps making too
much work for ourselves compared with just excepting that there will
need to be a place for non-abstracted-framework drivers?  What do we do
about TPL, when we get to the point of everything being converted to DM
and as-needed tiny-DM but there's still TPL drivers?  The reason we have
SPL_FRAMEWORK as a symbol today is that we already had some
SoCs/architectures (primarily PowerPC) that had "SPL" but it was very
centric to the SoCs in question.

The interface for example for mmc is:
int spl_mmc_load_image(struct spl_image_info *spl_image, struct
spl_boot_device *bootdev) and neither part of that is inherently DM.  So
let it be MMC_TINY for the non-DM case and regular DM_MMC for the DM
case.  I wonder if we could clean that up code a little if we let it be
separate.

The interface for example for spi is:
int spl_spi_load_image(struct spl_image_info *spl_image,
struct spl_boot_device *bootdev) and well, the same thing.  Or maybe we
can even push that up to the spi_flash_load() call.

But my worry is that a different set of abstractions here are still
going to bring us in more overhead than writing drivers for the
functionality we need directly, and if we define what's allowed in this
limited case well, that might be good enough.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200525/461b9c9c/attachment.sig>

  reply	other threads:[~2020-05-25 19:47 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-25 15:35 [PATCH] RFC: tiny-dm: Proposal for using driver model in SPL Simon Glass
2020-05-25 19:47 ` Tom Rini [this message]
2020-05-25 20:34   ` Simon Glass
2020-05-25 20:57     ` Tom Rini
2020-05-25 21:40       ` Simon Glass
2020-05-26 18:39         ` Walter Lozano
2020-06-01 20:55           ` Walter Lozano
2020-06-02 13:53             ` Tom Rini
2020-06-05  3:13               ` Simon Glass
2020-06-05 14:20                 ` Tom Rini
2020-06-05 16:18                   ` Walter Lozano
2020-06-05 16:32                     ` Tom Rini
2020-06-05 19:29                       ` Walter Lozano
2020-06-05 20:20                         ` Walter Lozano
2020-06-05  3:11             ` Simon Glass
2020-06-05  3:22               ` Simon Glass

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=20200525194737.GS12717@bill-the-cat \
    --to=trini@konsulko.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox