[linux-yocto] Organization of Cfg/Features

[Darren Hart]

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.

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?

-- 
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center