[U-Boot] [RFC] Rearrange CONFIG_* macros

[Tom Rini]

On Tue, Sep 27, 2016 at 06:24:09PM +0000, york sun wrote:
> On 09/27/2016 10:51 AM, Tom Rini wrote:
> > On Tue, Sep 27, 2016 at 05:39:55PM +0000, york sun wrote:
> >> Guys,
> >>
> >> I want to discuss to rearrange the current CONFIG_* macros used by
> >> Freescale Layerscape SoCs. We have been encouraged to use CONFIG_SYS_*
> >> macros to define hardware setting, and other CONFIG_* macros for user
> >> setting. Clearly this has changed. Kconfig options are used for most
> >> user settings from now on. I am OK with it. But for existing
> >> CONFIG_SYS_* macros, we need a plan to either move them out of CONFIG_*
> >> name space, or move some to Kconfig, if that makes sense. Since most our
> >> CONFIG_SYS_* macros are cross platforms (including armv7 and armv8), if
> >> using Kconfig option, do we add another mach-fsl folder to host the
> >> Kconfig, or somewhere else? We also have macros cross ARM and PowerPC.
> >> So we either move them out of arch/, or duplicate them for both arch.
> >>
> >> If we move them to another name space, for example SYS_FSL_*, do we want
> >> to move them out of config.h?
> >>
> >> Any suggestion/comment?
> >
> > Well, if something is cross-platform the code is somewhere
> > cross-platform too, yes?  For example, if anything DDR related makes
> > sense to stay as CONFIG_SYS_FSL_... it could go in to
> > drivers/ddr/fsl/Kconfig and be visible in both cases.  Otherwise
> > <asm/arch/fsl_ddr.h> and SYS_FSL_... (or whatever makes sense, looking
> > at the am33xx and mx6 cases, there's no SYS_ type prefix on the defines,
> > just the IP block names) for the defines.
> >
> 
> The benefit of keeping things together is easier to add a different SoC. 
> For example, when we have LS2080A and need to add LS1046A, we pay 
> attention to the difference. If the settings are scattered into IP 
> drivers, it is not that obvious to track.
> 
> Looking at am33xx, it doesn't use many Kconfig options, but a lot in 
> hardware*.h files. I need to see if we can do the same way.

It's an imperfect implementation, but yes, between
arch/arm/cpu/armv7/omap-common/, am33xx/ and omap*/ we have a large
number of IP blocks that have been evolving over time in a similar way
to the FSL blocks I suspect.  I also suspect there should be a bit more
in Kconfig than is there.

-- 
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/20160927/9d2a86a9/attachment.sig>