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

[Bruce Ashfield]

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 ?

> 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.

Bruce

>
> --
> Darren
>
>