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.
next prev 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