Thread (8 messages) 8 messages, 4 authors, 2013-08-07

[Ksummit-2013-discuss] [ARM ATTEND] arch/arm SoC organization

From: tony@atomide.com (Tony Lindgren)
Date: 2013-08-05 06:21:37
Also in: lkml

* Christian Daudt [off-list ref] [130802 16:13]:
On Fri, Aug 2, 2013 at 1:33 AM, Tony Lindgren [off-list ref] wrote:
quoted
* Jason Cooper [off-list ref] [130731 07:25]:
quoted
So, I'd like to propose we discuss some lessons learned and maybe arrive
at some best practices.  eg, should we just go with mach-$COMPANY/?  How
best to handle config symbols for efficient building?  Deprecation path
for legacy (unconverted) boards?
A lot of that problem goes away by initializing everything as late
as possible, and making things to live under drivers.
One category of items that we haven't found a good place for in this
new multiplatform world is where does dt-driven non-driver code reside
? e.g. we have a secure monitor access function that only kicks in if
the appropriate dt entry is available . It currently resides in
mach-bcm/bcm_kona_smc.c as it seems like the only location for it at
the moment, but that doesn't seem like the best place because (a)
mach-bcm might end up littered with one-of cases like this and (b)
anything in mach-bcm is not visible to arm64 SoCs, and some of those
in the future will need to share with their arm32 cousins.
 But putting in drivers (e.g. drivers/smc) seems like the wrong thing
to do also because this is not a driver.
 We have a couple of other smallish pieces of IP that just need a bit
of generic init code to keep them happy, which we were discussing
internally where to best land them. At present they are also headed to
mach-bcm.
 Ultimately the question is 'what is allowed to reside in mach-<misc>
?' And by extension: 'is there a good home for everything else ?''
Well I guess the question is how early do you need it?

We only need the following things early on that might be SoC specific:

1. Timers for clockevents

2. Interrupt controller

If you need the SoC specific code for the two items above, then
you probably want to set it up in the SoC specific init_early.

Everything else should be possible to do as device drivers with
initramfs. If the code has an interrupt handler, chances are it
can be a driver :)

Regards,

Tony
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help