[linux-yocto] [PATCH] meta: features/drm-gma500/drm-gma3600: add

[Bruce Ashfield]

On 13-08-21 01:31 PM, Darren Hart wrote:
> On Wed, 2013-08-21 at 17:42 +0100, Ross Burton wrote:
>> Add feature fragment for the GMA3600/GMA3650 GPU, as used in the Cedar Trail
>> platform.
>>
>> Signed-off-by: Ross Burton <ross.burton at intel.com>
>> ---
>>   meta/cfg/kernel-cache/features/drm-gma500/drm-gma3600.cfg |    1 +
>
>
> hrm.... under drm-gma500 ? Are they related? Ah, yes, yes they are. OK.
>
>>   meta/cfg/kernel-cache/features/drm-gma500/drm-gma3600.scc |    3 +++
>>   2 files changed, 4 insertions(+)
>>   create mode 100644 meta/cfg/kernel-cache/features/drm-gma500/drm-gma3600.cfg
>>   create mode 100644 meta/cfg/kernel-cache/features/drm-gma500/drm-gma3600.scc
>>
>> diff --git a/meta/cfg/kernel-cache/features/drm-gma500/drm-gma3600.cfg b/meta/cfg/kernel-cache/features/drm-gma500/drm-gma3600.cfg
>> new file mode 100644
>> index 0000000..52caac5
>> --- /dev/null
>> +++ b/meta/cfg/kernel-cache/features/drm-gma500/drm-gma3600.cfg
>> @@ -0,0 +1 @@
>> +CONFIG_DRM_GMA3600=y
>
> Arg, another 1-liner. Surely there are dependencies here? ... Ah, just
> the gma500 below. And it's =y because it is just part of gma500. OK.
>
>
>> diff --git a/meta/cfg/kernel-cache/features/drm-gma500/drm-gma3600.scc b/meta/cfg/kernel-cache/features/drm-gma500/drm-gma3600.scc
>> new file mode 100644
>> index 0000000..69ba80e
>> --- /dev/null
>> +++ b/meta/cfg/kernel-cache/features/drm-gma500/drm-gma3600.scc
>> @@ -0,0 +1,3 @@
>> +kconf hardware drm-gma3600.cfg
>> +
>> +include features/drm-gma500/drm-gma500.scc
>
> I prefer the include at the top as dependencies come first in my head,
> but no need to resend for that, just for future reference.
>
> So, any idea how much space we save by not enabling GMA3600 as part of
> the gma500 cfg? I suspect the amount is very very small. I would suggest
> you update this patch to just modify the drm-gma500.cfg to include
> GMA600 and GMA3600 by default. If finer granularity is needed, we can
> always break them up later.
>
> I see that 600 is already broken out, so there is precedent and it makes
> sense for you to have done it this way looking at those as examples.
>
> Bruce, your call. I would prefer we just merge these together into a
> single gma500 fragment. Any reason you can think of not to?

I'd prefer to merge them, since we already have a set of gma* fragments,
it would be nice to consolidate them at this point (which is what happens
when we see trend of more small ones being added) .. so yah, can we rebase
this one and squash the options together into a single feature ?

Bruce

>
> Thanks,
>