[linux-yocto] [PATCH 4/4] intel-common: Add intel-common BSPs

[Darren Hart]

On 2/6/14, 8:55, "Bruce Ashfield" <bruce.ashfield at windriver.com> wrote:

>On 14-02-06 11:35 AM, Darren Hart wrote:
>> On 2/6/14, 8:09, "Bruce Ashfield" <bruce.ashfield at windriver.com> wrote:
>>
>>> On 14-02-06 10:55 AM, Darren Hart wrote:
>>>> On 2/6/14, 6:27, "Bruce Ashfield" <bruce.ashfield at gmail.com> wrote:
>>>>
>>>>> On Wed, Feb 5, 2014 at 7:37 PM, Darren Hart <dvhart at linux.intel.com>
>>>>> wrote:
>>>>>> Create the intel-core2-32 and intel-corei7-64 BSP descriptions.
>>>>>>These
>>>>>> BSPs include all the core support for the other Intel BSPs in the
>>>>>> repository by including the corresponding BSP scc file.
>>>>>>
>>>>>> This is an initial step to get the machines available and testing.
>>>>>> Further refactoring is expected to take place to reduce duplication
>>>>>> and
>>>>>> ultimately obviate the need for many of the other BSP descriptions,
>>>>>>at
>>>>>> least the -standard versions which should be adequately covered by
>>>>>> these
>>>>>> generic versions.
>>>>>>
>>>>>> Signed-off-by: Darren Hart <dvhart at linux.intel.com>
>>>>>> ---
>>>>>>    .../bsp/intel-common/intel-common-standard.scc     |    7 +++++
>>>>>>    .../kernel-cache/bsp/intel-common/intel-common.scc |   30
>>>>>> ++++++++++++++++++++
>>>>>>    .../bsp/intel-common/intel-core2-32-standard.scc   |    9 ++++++
>>>>>>    .../bsp/intel-common/intel-core2-32.scc            |   10 +++++++
>>>>>>    .../bsp/intel-common/intel-corei7-64-standard.scc  |    9 ++++++
>>>>>>    .../bsp/intel-common/intel-corei7-64.scc           |   12
>>>>>>++++++++
>>>>>>    6 files changed, 77 insertions(+)
>>>>>>    create mode 100644
>>>>>> meta/cfg/kernel-cache/bsp/intel-common/intel-common-standard.scc
>>>>>>    create mode 100644
>>>>>> meta/cfg/kernel-cache/bsp/intel-common/intel-common.scc
>>>>>>    create mode 100644
>>>>>> meta/cfg/kernel-cache/bsp/intel-common/intel-core2-32-standard.scc
>>>>>>    create mode 100644
>>>>>> meta/cfg/kernel-cache/bsp/intel-common/intel-core2-32.cfg
>>>>>>    create mode 100644
>>>>>> meta/cfg/kernel-cache/bsp/intel-common/intel-core2-32.scc
>>>>>>    create mode 100644
>>>>>> meta/cfg/kernel-cache/bsp/intel-common/intel-corei7-64-standard.scc
>>>>>>    create mode 100644
>>>>>> meta/cfg/kernel-cache/bsp/intel-common/intel-corei7-64.cfg
>>>>>>    create mode 100644
>>>>>> meta/cfg/kernel-cache/bsp/intel-common/intel-corei7-64.scc
>>>>>>
>>>>>> diff --git
>>>>>> a/meta/cfg/kernel-cache/bsp/intel-common/intel-common-standard.scc
>>>>>> b/meta/cfg/kernel-cache/bsp/intel-common/intel-common-standard.scc
>>>>>> new file mode 100644
>>>>>> index 0000000..509f32e
>>>>>> --- /dev/null
>>>>>> +++ 
>>>>>>b/meta/cfg/kernel-cache/bsp/intel-common/intel-common-standard.scc
>>>>>> @@ -0,0 +1,7 @@
>>>>>> +include ktypes/standard/standard.scc
>>>>>> +
>>>>>> +# default policy for standard kernels
>>>>>> +include cfg/usb-mass-storage.scc
>>>>>> +include cfg/boot-live.scc
>>>>>> +include features/latencytop/latencytop.scc
>>>>>> +include features/profiling/profiling.scc
>>>>>> diff --git a/meta/cfg/kernel-cache/bsp/intel-common/intel-common.scc
>>>>>> b/meta/cfg/kernel-cache/bsp/intel-common/intel-common.scc
>>>>>> new file mode 100644
>>>>>> index 0000000..8e3e06f
>>>>>> --- /dev/null
>>>>>> +++ b/meta/cfg/kernel-cache/bsp/intel-common/intel-common.scc
>>>>>> @@ -0,0 +1,30 @@
>>>>>> +include cfg/efi.scc
>>>>>> +
>>>>>> +include cfg/dmaengine.scc
>>>>>> +include features/usb/usb-gadgets.scc
>>>>>> +include features/usb/touchscreen-composite.scc
>>>>>> +include cfg/vesafb.scc
>>>>>> +include features/uio/uio.scc
>>>>>> +
>>>>>> +# Common devices
>>>>>> +# Earlyprintk and port debug requires 8250
>>>>>> +kconf hardware cfg/8250.scc
>>>>>> +include features/usb/ehci-hcd.scc
>>>>>> +include features/usb/ohci-hcd.scc
>>>>>> +include features/usb/xhci-hcd.scc
>>>>>> +include cfg/timer/hpet.scc
>>>>>> +include cfg/timer/rtc.scc
>>>>>> +include features/eg20t/eg20t.scc
>>>>>> +include features/i915/i915.scc
>>>>>> +include features/igb/igb.scc
>>>>>> +include features/ixgbe/ixgbe.scc
>>>>>> +
>>>>>> +# Intel technology
>>>>>> +include features/amt/mei/mei.scc
>>>>>> +include features/power/intel.scc
>>>>>> +
>>>>>> +# Subsystems and interfaces
>>>>>> +include features/hugetlb/hugetlb.scc
>>>>>> +include features/i2c/i2cdev.scc
>>>>>> +include features/leds/leds.scc
>>>>>> +include features/spi/spidev.scc
>>>>>> diff --git
>>>>>> a/meta/cfg/kernel-cache/bsp/intel-common/intel-core2-32-standard.scc
>>>>>> b/meta/cfg/kernel-cache/bsp/intel-common/intel-core2-32-standard.scc
>>>>>> new file mode 100644
>>>>>> index 0000000..89ee64a
>>>>>> --- /dev/null
>>>>>> +++
>>>>>> b/meta/cfg/kernel-cache/bsp/intel-common/intel-core2-32-standard.scc
>>>>>> @@ -0,0 +1,9 @@
>>>>>> +define KMACHINE intel-core2-32
>>>>>> +define KARCH i386
>>>>>> +define KTYPE standard
>>>>>> +
>>>>>> +include intel-core2-32.scc
>>>>>> +include intel-common-standard.scc
>>>>>> +
>>>>>> +# Pile of common drivers for the standard ktype
>>>>>> +include bsp/common-pc/common-pc-standard.scc
>>>>>
>>>>> You'd be wise to include this first, and then your new core2 and
>>>>> common fragments,
>>>>> since the last option through the gate wins, a change to common-pc
>>>>> will have more
>>>>> impact than a change to your new fragments.
>>>>
>>>>
>>>> Right, general to specialized ordering. Will change.
>>>>
>>>>>
>>>>> A second comment on this, any opinion on renaming .. or just
>>>>> continuing on with the
>>>>
>>>> Erm... Renaming intel-common? To what?
>>>
>>> That's the kicker .. names suck. I actually did think of intel-common,
>>> intel-base, or something along those lines. But again, nothing is
>>>perfect.
>>>
>>>>
>>>>> "common-pc" branch naming ? By including this fragment we are
>>>>>following
>>>>> the
>>>>> standard/common-pc naming convention that has been around for 5+
>>>>>years
>>>>> now.
>>>>> I've never really come up with a better name, but I thought I'd throw
>>>>> that thought out.
>>>>
>>>> But here you're talking about branches and not the bps/* scc paths...
>>>>So
>>>> I'm not sure what you're asking. The reason I'm doing something
>>>> independent of common-pc is these BSPs will cater to showcasing Intel
>>>> technologies and I didn't want it to be bound to common-pc.
>>>>Eventually,
>>>> the common-pc include needs to be removed in favor of building from
>>>>some
>>>> driver-group fragments - but those are currently buried in the
>>>>common-pc
>>>> BSP. Incremental work and all that.
>>>>
>>>> So... Can you rephrase, I think I might be missing the main point.
>>>
>>> When you include the common-pc-standard fragement, it has within it
>>> "branch common-pc", which is what is creating standard/common-pc. So
>>> if you want to build from a single, common branch, that fragement
>>> is going to force a naming convention on you.
>>>
>>> I'm all for fixing the branch (removing/renaming) statement, so you'll
>>> build from where you expect.
>>
>>
>> Oh, right! Thank you for catching that. Do we need the branch in
>> common-pc? It should just build from standard/base too right? The whole
>> common-pc* branch hierarchy always seemed strange to me. If anything
>> shouldn't need a machine-branch, it's a common PC.
>
>We needed it in the past, but now there aren't any patches being
>carried, so it strictly isn't necessary.
>
>>
>> So if the branch statement can go, great. If not, I can just pull the
>> major driver fragments in instead of the entire BSP scc file. That might
>> be better anyway. I could then do it in one shot in
>
>That part is up to you, I'm fine with removing the branch statement
>in the dev kernel, but are you targeting 3.10, or the next yocto
>kernel ?

Linux-yocto-dev for sure
I am considering 3.10 now that we have LTSI in... Would be nice to get
these there as well.

>
>> intel-common-standard.scc rather than in each of the
>>core2/corei7-standard
>> files. Thoughts?
>
>That's up to you as well, if you were to do this .. wouldn't we just
>remove common-pc completely ? That's fine with me as well :) As long
>as qemux86 continues to boot with your definition, no one will really
>know.

There are the genericx86* machines as well, which are not Intel specific.

The right thing to do is to select the driver groups and put them in the
intel-common-standard and avoid the common-pc standard bsp include all
together.

I'll refactor and resubmit.

--
Darren