public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] ARM: Generic cache ops skeleton
Date: Mon, 07 Nov 2011 13:36:42 +0100	[thread overview]
Message-ID: <4EB7D0DA.9070407@aribaud.net> (raw)
In-Reply-To: <CAPnjgZ1MyXxS4JtdO+o6Zf8cx5WNBLYPE85Hv5Uj8xRr215QPA@mail.gmail.com>

Le 06/11/2011 20:29, Simon Glass a ?crit :

> It's actually a lot more than cache ops. SOCs have there own clock
> stuff, pinmux things, power mgmt, timers and the like. While it might
> be desirable to provide this feature it is a fair bit of work and we
> need to be careful not to make things more complex.

Agreed.

> I would settle for an initial step of getting some sort of unified but
> simple clock/pinmux support in across all ARM. Anyone interested in
> that? I mean an API that covers the lot, not an implementation. Also
> it would be nice to avoid the heavy-weight data structures and strings
> that Linux has. If we got that far then we could make the interface
> virtual as Marek has done for caches.

On a general note, if we set our goal is to have in U-Boot what Linux 
has, U-Boot will end up being... Linux, which I don't think is a good 
thing unless we consider that U-Boot is redundant.

Besides, I don't think 'virtual' interfaces are necessarily the way to 
go either, not for the sole sake of it anyway. We might well get there 
with a driver model, and then we might want to see how things are done 
in Linux, but certainly not import the Linux model without thinking of 
what makes sense rather than what would be nice. U-Boot's basic 
principles are fundamentally different from those of an OS like Linux.

We can start, within the "single-SoC binary" model for now, by simply 
adding relevant SoC-specific or board-specific mechanisms, and using 
those already in place.

> On this particular patch, I feel it should be more explicit about L1
> cache, which is what I think it deals with. We may want to support L2
> also through a similar API. And a CONFIG option is a good idea.
>
> Finally, even the CP15/cache/MMU code is duplicated in different
> arch/arm/cpu subdirs. Can we unify this a bit?

I think our recent discussion opens the way for this unification in that 
cp15 code should be able to go away from start.S and into the (fewer) 
cache lib(s).

> Regards,
> Simon

Amicalement,
-- 
Albert.

  parent reply	other threads:[~2011-11-07 12:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-06  1:16 [U-Boot] [PATCH] ARM: Generic cache ops skeleton Marek Vasut
2011-11-06  8:36 ` Mike Frysinger
2011-11-06 12:39   ` Marek Vasut
2011-11-06 18:03     ` Mike Frysinger
2011-11-06 18:07       ` Marek Vasut
2011-11-06 19:29         ` Simon Glass
2011-11-07  1:09           ` Mike Frysinger
2011-11-07  3:10             ` Simon Glass
2011-11-07 12:36           ` Albert ARIBAUD [this message]
2011-11-07  1:03         ` Mike Frysinger
2011-11-07 12:21 ` Albert ARIBAUD

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=4EB7D0DA.9070407@aribaud.net \
    --to=albert.u.boot@aribaud.net \
    --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