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

[Tom Rini]

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.  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).  In the latter case, it
doesn't make sense for company X to put their board in
boards/SOM-vendor/.

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/.  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.  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/).

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/20170519/945407f8/attachment.sig>