[U-Boot] litesom.c: Board stuff in SOC ?

[Tom Rini]

On Fri, May 19, 2017 at 04:13:29PM +0200, Stefano Babic wrote:
> Hi Tom,
> 
> On 19/05/2017 15:39, Tom Rini wrote:
> > On Fri, May 19, 2017 at 12:51:18PM +0200, Stefano Babic wrote:
> >> Hi Marcin,
> >>
> >> On 19/05/2017 12:41, Marcin Niestroj wrote:
> >>> Hi Stefano,
> >>>
> >>> I've added Tom to the discussion.
> >>
> >> Of course !
> >>
> >>> So if we make some changes to SOM
> >>> code position in u-boot tree, let's make sure we do it for all
> >>> architectures the same 
> >>
> >> We have already not done in this way. We have all boards / SOM code
> >> inside bords/, the only exceptions are yours. If there is a decision to
> >> add an abstraction for SOM, we have to put coherently all SOMs that are
> >> now stored in the boards directory.
> >>
> >> What you mention are just exception - that I would like to clean up.
> > 
> > So, we do have a problem with the layout today.
> 
> Indeed, true. There is not an abstraction for SOM today.
> 
> >  The point of SOMs is
> > that yes, you can drop them into a carrier from the same vendor (and
> > this is true for both "3rd party" ones like
> > litesom/chilisom/solidrun/etc and vendor ones like more recent NXP eval
> > boards) or company X buys the SOMs and puts them in their own custom
> > carrier (which hell, we have customers that do).
> 
> Right, this is the common case.
> 
> >  In the latter case, it
> > doesn't make sense for company X to put their board in
> > boards/SOM-vendor/.
> 
> The question is how they reference to the common / SOM code. I am quite
> sure that the object should be part of the board library, that is at the
> end part of board/<vendor>/<board name>/lib.a.

I am less concerned with "board" vs "arch" than I am with making it
clearly and easily re-usable, but also not adding further complex
Makefile logic to handle inclusion.

> > In my mind, arch/arm/mach-omap2/am33xx/chilisom.c is the right solution
> > and the big problem with i.MX right now is that arch/arm/imx-common and
> > arch/arm/cpu/armv7/mx* need to get some re-organization under
> > arch/arm/mach-imx/.
> 
> Sure the SOM code should be not under cpu/....mx6. This is wrong.

So we agree, good, yes, OK :)

> imx-common was created (as far as I can still remember) as solution to
> put code shared between all i.MX processors, from imx.2x up to i.MX6 or
> i.MX7. Code that does not belong to a single SOC.
> 
> As far as I see, there is not a single solution for SOM in u-boot. In
> some cases (what you mention) are in mach-*, in some other cases they
> are under board/<vendor>. Just check the number of "common" directories
> under boards. In most cases they are SOM, and I am sure I am still
> missing a lot of them.

Well, I think the answer is that arch/arm/imx-common/ needs to become
arch/arm/mach-imx (ala the kernel) and arch/arm/cpu/armv7/mx* needs to
move to this new directory, in whatever layout you feel is cleanest (the
kernel has this flat, except for include/mach).  I don't know if I was
clear enough in my first reply, so I'm following up here, now.

> >  And I'm not going to claim that arch/arm/mach-omap2
> > is best organized here, I largely moved the old omap-common to
> > mach-omap2 and everything else into subdirs of that.
> 
> Nevertheless, this is a much more sustainable solution. If imx-common is
> changed into mach-imx, and it contains subdirectories for the specific
> type, we could simplify imx-common/Makefile, that is become messy with
> two many filters in a way as in mach-omap2.
> And then, moving litesom.c in a place as arch/arm/mach-imx/som/mx6 seems
> much more appropriate.

Yeah, there's a little bit of clean-up I want to do to that Makefile at
some point and partly relies on adding more Kconfig symbols and merging
more of the common-IP-different-src things we still have.  But that's
another story...

> >  I can certainly
> > see an argument for arch/arm/mach-$X/som/ (or mach-$X/$soc/som/) instead
> > of just putting them in arch/arm/mach-$X/ (or again, mach-$X/$soc/).
> 
> mach-$X/$soc/som/ is  my preferred choice if we vote.. :-)

Make it so in mach-imx and we'll move from there :)  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170522/4bd90e5a/attachment.sig>