[linux-yocto] Organization of Cfg/Features

[Tom Zanussi]

On Fri, 2014-02-07 at 12:53 -0800, Darren Hart wrote:
> I'm working on adding support for a specific SoC (Bay Trail specifically).
> I have a few things that it incorporates, Designware I2C, SPI, I2S/Sound,
> it needs LPSS, some PWM bits, the i915 driver, etc.
> 
> The i915 is separated out already, the others, not so much. I'm struggling
> with where to put them and would appreciate your thoughts.
> 
> I could add Designware configs to a general fragment for each of I2C and
> SPI. Same for the UART. I looked at the sound fragment, but it says it's
> for OSS ?!?! And doesn't include things like INTEL HDA, so it's not
> particularly useful.
> 
> I considered adding a cfg/SoC directory, but that might as well be in BSP
> and I was trying to make it more reusable.
> 
> And that's the final option, I could create a BSP that targets just this
> SoC and include that in the more generic intel-core* BSPs. My concern with
> this is the amount of redundancy that is likely to proliferate over time.
> 
> The current set of cfg and features is already fairly difficult to
> navigate.
> 
> And on that, my second topic.
> 
> As I understand it, the accepted best practice is to put cfg-only
> fragments under cfg while things requiring patches should go under
> features.... We've been lax if that's the case and we have a fair amount
> of cleanup to do.
> 

If that's the case then cfg will get very crowded, since most of the
stuff in features is cfg-only.  For that matter, since we're examining
things afresh, why have patches in features at all - why not just put
all the code (patches) in the machine branches?  In that case, we only
have one location, cfg/ (or features/, whichever)...

> The organization has deteriorated over time as well. I'm wondering if we
> should have a meta-cleanup-week where we all take a block and reorg it and
> the impacted BSPs to some agreed upon standard in time for the
> linux-yocto-dev conversion to a named release. Specifically I'm wondering
> if we should create a hierarchy in cfg that parallels the Kconfig
> hierarchy. Drivers/net/ethernet, for example. We could cap it at 2 layers
> to keep it from getting overly granular. This seems to me that it would
> provide some direction as to how to create fragments as well as make them
> easier to find and reuse.
> 
> Thoughts?
> 

A cleanup would definitely be in order - I've noticed while providing
fragments for tracing and profiling for another project that there's a
lot of overlap and even missing bits where there should be something.
To be expected having grown organically, but we can probably do better
now with hindsight..

Tom