* [PATCH 1/4] linux-firmware: Update SRCREV, pull in iwlwifi-7260 support
2013-09-05 0:18 [PATCH 0/4] Updates in support of genericx86* Darren Hart
@ 2013-09-05 0:18 ` Darren Hart
2013-09-05 1:04 ` Otavio Salvador
2013-09-05 0:18 ` [PATCH 2/4] xorg-driver-common: Add configure and install appends from meta-intel Darren Hart
` (3 subsequent siblings)
4 siblings, 1 reply; 33+ messages in thread
From: Darren Hart @ 2013-09-05 0:18 UTC (permalink / raw)
To: Poky, openembedded-core, Tom Zanussi; +Cc: yunguo.wei, Darren Hart
Fixes [YOCTO #5110]
Add support for the iwlwifi 7260 adapters. This creates a new package
and includes support in the default linux-firmware (everything) package.
Update the iwlwifi and radeon license checksums. Extensions to the
copyright date ranges were the only change to the LICENSE files.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Cc: yunguo.wei@windriver.com
---
.../linux-firmware/linux-firmware_git.bb | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
index 3825889..1b7db08 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
@@ -7,12 +7,12 @@ SECTION = "kernel"
LICENSE = "Proprietary"
-LIC_FILES_CHKSUM = "file://LICENSE.radeon;md5=e56b405656593a0c97e478513051ea0e \
+LIC_FILES_CHKSUM = "file://LICENSE.radeon;md5=9c2faab1bfca55e1510d6bde67206f9c \
file://LICENSE.dib0700;md5=f7411825c8a555a1a3e5eab9ca773431 \
file://LICENCE.xc5000;md5=1e170c13175323c32c7f4d0998d53f66 \
file://LICENCE.ralink-firmware.txt;md5=ab2c269277c45476fb449673911a2dfd \
file://LICENCE.qla2xxx;md5=4005328a134054f0fa077bdc37aa64f2 \
- file://LICENCE.iwlwifi_firmware;md5=11545778abf78c43d7644d4f171ea1c7 \
+ file://LICENCE.iwlwifi_firmware;md5=8b938534f77ffd453690eb34ed84ae8b \
file://LICENCE.i2400m;md5=14b901969e23c41881327c0d9e4b7d36 \
file://LICENCE.atheros_firmware;md5=30a14c7823beedac9fa39c64fdd01a13 \
file://LICENCE.agere;md5=af0133de6b4a9b2522defd5f188afd31 \
@@ -23,10 +23,10 @@ LIC_FILES_CHKSUM = "file://LICENSE.radeon;md5=e56b405656593a0c97e478513051ea0e \
file://LICENCE.via_vt6656;md5=e4159694cba42d4377a912e78a6e850f \
"
-SRCREV = "c530a75c1e6a472b0eb9558310b518f0dfcd8860"
+SRCREV = "600caefd83a406540b2a789be6415e44c9b87add"
PE = "1"
PV = "0.0+git${SRCPV}"
-PR = "r1"
+PR = "r0"
SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git"
@@ -172,10 +172,12 @@ ALTERNATIVE_TARGET_linux-firmware-bcm4334[brcmfmac-sdio.bin] = "/lib/firmware/br
RDEPENDS_${PN}-iwlwifi-6000g2a-5 = "${PN}-iwlwifi-license"
RDEPENDS_${PN}-iwlwifi-6000g2b-6 = "${PN}-iwlwifi-license"
+RDEPENDS_${PN}-iwlwifi-7260-7 = "${PN}-iwlwifi-license"
FILES_${PN}-iwlwifi-license = "/lib/firmware/LICENCE.iwlwifi_firmware"
FILES_${PN}-iwlwifi-6000g2a-5 = "/lib/firmware/iwlwifi-6000g2a-5.ucode"
FILES_${PN}-iwlwifi-6000g2b-6 = "/lib/firmware/iwlwifi-6000g2b-6.ucode"
+FILES_${PN}-iwlwifi-7260-7 = "/lib/firmware/iwlwifi-7260-7.ucode"
FILES_${PN} += "/lib/firmware/*"
--
1.7.9.5
^ permalink raw reply related [flat|nested] 33+ messages in thread* Re: [PATCH 1/4] linux-firmware: Update SRCREV, pull in iwlwifi-7260 support
2013-09-05 0:18 ` [PATCH 1/4] linux-firmware: Update SRCREV, pull in iwlwifi-7260 support Darren Hart
@ 2013-09-05 1:04 ` Otavio Salvador
2013-09-05 3:34 ` Darren Hart
0 siblings, 1 reply; 33+ messages in thread
From: Otavio Salvador @ 2013-09-05 1:04 UTC (permalink / raw)
To: Darren Hart
Cc: Poky, yunguo.wei, Patches and discussions about the oe-core layer
On Wed, Sep 4, 2013 at 9:18 PM, Darren Hart <dvhart@linux.intel.com> wrote:
> Fixes [YOCTO #5110]
>
> Add support for the iwlwifi 7260 adapters. This creates a new package
> and includes support in the default linux-firmware (everything) package.
>
> Update the iwlwifi and radeon license checksums. Extensions to the
> copyright date ranges were the only change to the LICENSE files.
>
> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
> Cc: yunguo.wei@windriver.com
> ---
> .../linux-firmware/linux-firmware_git.bb | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> index 3825889..1b7db08 100644
> --- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> @@ -7,12 +7,12 @@ SECTION = "kernel"
>
> LICENSE = "Proprietary"
>
> -LIC_FILES_CHKSUM = "file://LICENSE.radeon;md5=e56b405656593a0c97e478513051ea0e \
> +LIC_FILES_CHKSUM = "file://LICENSE.radeon;md5=9c2faab1bfca55e1510d6bde67206f9c \
> file://LICENSE.dib0700;md5=f7411825c8a555a1a3e5eab9ca773431 \
> file://LICENCE.xc5000;md5=1e170c13175323c32c7f4d0998d53f66 \
> file://LICENCE.ralink-firmware.txt;md5=ab2c269277c45476fb449673911a2dfd \
> file://LICENCE.qla2xxx;md5=4005328a134054f0fa077bdc37aa64f2 \
> - file://LICENCE.iwlwifi_firmware;md5=11545778abf78c43d7644d4f171ea1c7 \
> + file://LICENCE.iwlwifi_firmware;md5=8b938534f77ffd453690eb34ed84ae8b \
> file://LICENCE.i2400m;md5=14b901969e23c41881327c0d9e4b7d36 \
> file://LICENCE.atheros_firmware;md5=30a14c7823beedac9fa39c64fdd01a13 \
> file://LICENCE.agere;md5=af0133de6b4a9b2522defd5f188afd31 \
> @@ -23,10 +23,10 @@ LIC_FILES_CHKSUM = "file://LICENSE.radeon;md5=e56b405656593a0c97e478513051ea0e \
> file://LICENCE.via_vt6656;md5=e4159694cba42d4377a912e78a6e850f \
> "
>
> -SRCREV = "c530a75c1e6a472b0eb9558310b518f0dfcd8860"
> +SRCREV = "600caefd83a406540b2a789be6415e44c9b87add"
> PE = "1"
> PV = "0.0+git${SRCPV}"
> -PR = "r1"
> +PR = "r0"
I know this is OK but I'd prefer to omit the PR when it is r0;
specially now we use PRServer.
> SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git"
>
> @@ -172,10 +172,12 @@ ALTERNATIVE_TARGET_linux-firmware-bcm4334[brcmfmac-sdio.bin] = "/lib/firmware/br
>
> RDEPENDS_${PN}-iwlwifi-6000g2a-5 = "${PN}-iwlwifi-license"
> RDEPENDS_${PN}-iwlwifi-6000g2b-6 = "${PN}-iwlwifi-license"
> +RDEPENDS_${PN}-iwlwifi-7260-7 = "${PN}-iwlwifi-license"
>
> FILES_${PN}-iwlwifi-license = "/lib/firmware/LICENCE.iwlwifi_firmware"
> FILES_${PN}-iwlwifi-6000g2a-5 = "/lib/firmware/iwlwifi-6000g2a-5.ucode"
> FILES_${PN}-iwlwifi-6000g2b-6 = "/lib/firmware/iwlwifi-6000g2b-6.ucode"
> +FILES_${PN}-iwlwifi-7260-7 = "/lib/firmware/iwlwifi-7260-7.ucode"
>
> FILES_${PN} += "/lib/firmware/*"
>
> --
> 1.7.9.5
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: [PATCH 1/4] linux-firmware: Update SRCREV, pull in iwlwifi-7260 support
2013-09-05 1:04 ` Otavio Salvador
@ 2013-09-05 3:34 ` Darren Hart
2013-09-05 6:57 ` [poky] " Saul Wold
0 siblings, 1 reply; 33+ messages in thread
From: Darren Hart @ 2013-09-05 3:34 UTC (permalink / raw)
To: Otavio Salvador
Cc: Poky, yunguo.wei, Patches and discussions about the oe-core layer
On Wed, 2013-09-04 at 22:04 -0300, Otavio Salvador wrote:
> On Wed, Sep 4, 2013 at 9:18 PM, Darren Hart <dvhart@linux.intel.com> wrote:
> > Fixes [YOCTO #5110]
> >
> > Add support for the iwlwifi 7260 adapters. This creates a new package
> > and includes support in the default linux-firmware (everything) package.
> >
> > Update the iwlwifi and radeon license checksums. Extensions to the
> > copyright date ranges were the only change to the LICENSE files.
> >
> > Signed-off-by: Darren Hart <dvhart@linux.intel.com>
> > Cc: yunguo.wei@windriver.com
> > ---
> > .../linux-firmware/linux-firmware_git.bb | 10 ++++++----
> > 1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> > index 3825889..1b7db08 100644
> > --- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> > +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> > @@ -7,12 +7,12 @@ SECTION = "kernel"
> >
> > LICENSE = "Proprietary"
> >
> > -LIC_FILES_CHKSUM = "file://LICENSE.radeon;md5=e56b405656593a0c97e478513051ea0e \
> > +LIC_FILES_CHKSUM = "file://LICENSE.radeon;md5=9c2faab1bfca55e1510d6bde67206f9c \
> > file://LICENSE.dib0700;md5=f7411825c8a555a1a3e5eab9ca773431 \
> > file://LICENCE.xc5000;md5=1e170c13175323c32c7f4d0998d53f66 \
> > file://LICENCE.ralink-firmware.txt;md5=ab2c269277c45476fb449673911a2dfd \
> > file://LICENCE.qla2xxx;md5=4005328a134054f0fa077bdc37aa64f2 \
> > - file://LICENCE.iwlwifi_firmware;md5=11545778abf78c43d7644d4f171ea1c7 \
> > + file://LICENCE.iwlwifi_firmware;md5=8b938534f77ffd453690eb34ed84ae8b \
> > file://LICENCE.i2400m;md5=14b901969e23c41881327c0d9e4b7d36 \
> > file://LICENCE.atheros_firmware;md5=30a14c7823beedac9fa39c64fdd01a13 \
> > file://LICENCE.agere;md5=af0133de6b4a9b2522defd5f188afd31 \
> > @@ -23,10 +23,10 @@ LIC_FILES_CHKSUM = "file://LICENSE.radeon;md5=e56b405656593a0c97e478513051ea0e \
> > file://LICENCE.via_vt6656;md5=e4159694cba42d4377a912e78a6e850f \
> > "
> >
> > -SRCREV = "c530a75c1e6a472b0eb9558310b518f0dfcd8860"
> > +SRCREV = "600caefd83a406540b2a789be6415e44c9b87add"
> > PE = "1"
> > PV = "0.0+git${SRCPV}"
> > -PR = "r1"
> > +PR = "r0"
>
> I know this is OK but I'd prefer to omit the PR when it is r0;
> specially now we use PRServer.
Well, what is the official policy here? I'm happy to respin if
necessary, but I'd rather not burn cycles if the policy is hazy on the
subject.
Thanks,
Darren
>
> > SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git"
> >
> > @@ -172,10 +172,12 @@ ALTERNATIVE_TARGET_linux-firmware-bcm4334[brcmfmac-sdio.bin] = "/lib/firmware/br
> >
> > RDEPENDS_${PN}-iwlwifi-6000g2a-5 = "${PN}-iwlwifi-license"
> > RDEPENDS_${PN}-iwlwifi-6000g2b-6 = "${PN}-iwlwifi-license"
> > +RDEPENDS_${PN}-iwlwifi-7260-7 = "${PN}-iwlwifi-license"
> >
> > FILES_${PN}-iwlwifi-license = "/lib/firmware/LICENCE.iwlwifi_firmware"
> > FILES_${PN}-iwlwifi-6000g2a-5 = "/lib/firmware/iwlwifi-6000g2a-5.ucode"
> > FILES_${PN}-iwlwifi-6000g2b-6 = "/lib/firmware/iwlwifi-6000g2b-6.ucode"
> > +FILES_${PN}-iwlwifi-7260-7 = "/lib/firmware/iwlwifi-7260-7.ucode"
> >
> > FILES_${PN} += "/lib/firmware/*"
> >
> > --
> > 1.7.9.5
> >
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
>
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: [poky] [PATCH 1/4] linux-firmware: Update SRCREV, pull in iwlwifi-7260 support
2013-09-05 3:34 ` Darren Hart
@ 2013-09-05 6:57 ` Saul Wold
2013-09-05 8:50 ` Richard Purdie
0 siblings, 1 reply; 33+ messages in thread
From: Saul Wold @ 2013-09-05 6:57 UTC (permalink / raw)
To: Darren Hart
Cc: yunguo.wei, Poky, Otavio Salvador,
Patches and discussions about the oe-core layer
On 09/04/2013 08:34 PM, Darren Hart wrote:
> On Wed, 2013-09-04 at 22:04 -0300, Otavio Salvador wrote:
>> On Wed, Sep 4, 2013 at 9:18 PM, Darren Hart <dvhart@linux.intel.com> wrote:
>>> Fixes [YOCTO #5110]
>>>
>>> Add support for the iwlwifi 7260 adapters. This creates a new package
>>> and includes support in the default linux-firmware (everything) package.
>>>
>>> Update the iwlwifi and radeon license checksums. Extensions to the
>>> copyright date ranges were the only change to the LICENSE files.
>>>
>>> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
>>> Cc: yunguo.wei@windriver.com
>>> ---
>>> .../linux-firmware/linux-firmware_git.bb | 10 ++++++----
>>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
>>> index 3825889..1b7db08 100644
>>> --- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
>>> +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
>>> @@ -7,12 +7,12 @@ SECTION = "kernel"
>>>
>>> LICENSE = "Proprietary"
>>>
>>> -LIC_FILES_CHKSUM = "file://LICENSE.radeon;md5=e56b405656593a0c97e478513051ea0e \
>>> +LIC_FILES_CHKSUM = "file://LICENSE.radeon;md5=9c2faab1bfca55e1510d6bde67206f9c \
>>> file://LICENSE.dib0700;md5=f7411825c8a555a1a3e5eab9ca773431 \
>>> file://LICENCE.xc5000;md5=1e170c13175323c32c7f4d0998d53f66 \
>>> file://LICENCE.ralink-firmware.txt;md5=ab2c269277c45476fb449673911a2dfd \
>>> file://LICENCE.qla2xxx;md5=4005328a134054f0fa077bdc37aa64f2 \
>>> - file://LICENCE.iwlwifi_firmware;md5=11545778abf78c43d7644d4f171ea1c7 \
>>> + file://LICENCE.iwlwifi_firmware;md5=8b938534f77ffd453690eb34ed84ae8b \
>>> file://LICENCE.i2400m;md5=14b901969e23c41881327c0d9e4b7d36 \
>>> file://LICENCE.atheros_firmware;md5=30a14c7823beedac9fa39c64fdd01a13 \
>>> file://LICENCE.agere;md5=af0133de6b4a9b2522defd5f188afd31 \
>>> @@ -23,10 +23,10 @@ LIC_FILES_CHKSUM = "file://LICENSE.radeon;md5=e56b405656593a0c97e478513051ea0e \
>>> file://LICENCE.via_vt6656;md5=e4159694cba42d4377a912e78a6e850f \
>>> "
>>>
>>> -SRCREV = "c530a75c1e6a472b0eb9558310b518f0dfcd8860"
>>> +SRCREV = "600caefd83a406540b2a789be6415e44c9b87add"
>>> PE = "1"
>>> PV = "0.0+git${SRCPV}"
>>> -PR = "r1"
>>> +PR = "r0"
>>
>> I know this is OK but I'd prefer to omit the PR when it is r0;
>> specially now we use PRServer.
>
> Well, what is the official policy here? I'm happy to respin if
> necessary, but I'd rather not burn cycles if the policy is hazy on the
> subject.
>
Darren, sorry to say it is removal when possible.
Sau!
> Thanks,
>
> Darren
>
>>
>>> SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git"
>>>
>>> @@ -172,10 +172,12 @@ ALTERNATIVE_TARGET_linux-firmware-bcm4334[brcmfmac-sdio.bin] = "/lib/firmware/br
>>>
>>> RDEPENDS_${PN}-iwlwifi-6000g2a-5 = "${PN}-iwlwifi-license"
>>> RDEPENDS_${PN}-iwlwifi-6000g2b-6 = "${PN}-iwlwifi-license"
>>> +RDEPENDS_${PN}-iwlwifi-7260-7 = "${PN}-iwlwifi-license"
>>>
>>> FILES_${PN}-iwlwifi-license = "/lib/firmware/LICENCE.iwlwifi_firmware"
>>> FILES_${PN}-iwlwifi-6000g2a-5 = "/lib/firmware/iwlwifi-6000g2a-5.ucode"
>>> FILES_${PN}-iwlwifi-6000g2b-6 = "/lib/firmware/iwlwifi-6000g2b-6.ucode"
>>> +FILES_${PN}-iwlwifi-7260-7 = "/lib/firmware/iwlwifi-7260-7.ucode"
>>>
>>> FILES_${PN} += "/lib/firmware/*"
>>>
>>> --
>>> 1.7.9.5
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>>
>>
>
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: [poky] [PATCH 1/4] linux-firmware: Update SRCREV, pull in iwlwifi-7260 support
2013-09-05 6:57 ` [poky] " Saul Wold
@ 2013-09-05 8:50 ` Richard Purdie
2013-09-05 14:49 ` Darren Hart
0 siblings, 1 reply; 33+ messages in thread
From: Richard Purdie @ 2013-09-05 8:50 UTC (permalink / raw)
To: Saul Wold
Cc: yunguo.wei, Darren Hart, Poky, Otavio Salvador,
Patches and discussions about the oe-core layer
On Wed, 2013-09-04 at 23:57 -0700, Saul Wold wrote:
> On 09/04/2013 08:34 PM, Darren Hart wrote:
> > On Wed, 2013-09-04 at 22:04 -0300, Otavio Salvador wrote:
> >> On Wed, Sep 4, 2013 at 9:18 PM, Darren Hart <dvhart@linux.intel.com> wrote:
> >>> Fixes [YOCTO #5110]
> >>>
> >>> Add support for the iwlwifi 7260 adapters. This creates a new package
> >>> and includes support in the default linux-firmware (everything) package.
> >>>
> >>> Update the iwlwifi and radeon license checksums. Extensions to the
> >>> copyright date ranges were the only change to the LICENSE files.
> >>>
> >>> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
> >>> Cc: yunguo.wei@windriver.com
> >>> ---
> >>> .../linux-firmware/linux-firmware_git.bb | 10 ++++++----
> >>> 1 file changed, 6 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> >>> index 3825889..1b7db08 100644
> >>> --- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> >>> +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> >>> @@ -7,12 +7,12 @@ SECTION = "kernel"
> >>>
> >>> LICENSE = "Proprietary"
> >>>
> >>> -LIC_FILES_CHKSUM = "file://LICENSE.radeon;md5=e56b405656593a0c97e478513051ea0e \
> >>> +LIC_FILES_CHKSUM = "file://LICENSE.radeon;md5=9c2faab1bfca55e1510d6bde67206f9c \
> >>> file://LICENSE.dib0700;md5=f7411825c8a555a1a3e5eab9ca773431 \
> >>> file://LICENCE.xc5000;md5=1e170c13175323c32c7f4d0998d53f66 \
> >>> file://LICENCE.ralink-firmware.txt;md5=ab2c269277c45476fb449673911a2dfd \
> >>> file://LICENCE.qla2xxx;md5=4005328a134054f0fa077bdc37aa64f2 \
> >>> - file://LICENCE.iwlwifi_firmware;md5=11545778abf78c43d7644d4f171ea1c7 \
> >>> + file://LICENCE.iwlwifi_firmware;md5=8b938534f77ffd453690eb34ed84ae8b \
> >>> file://LICENCE.i2400m;md5=14b901969e23c41881327c0d9e4b7d36 \
> >>> file://LICENCE.atheros_firmware;md5=30a14c7823beedac9fa39c64fdd01a13 \
> >>> file://LICENCE.agere;md5=af0133de6b4a9b2522defd5f188afd31 \
> >>> @@ -23,10 +23,10 @@ LIC_FILES_CHKSUM = "file://LICENSE.radeon;md5=e56b405656593a0c97e478513051ea0e \
> >>> file://LICENCE.via_vt6656;md5=e4159694cba42d4377a912e78a6e850f \
> >>> "
> >>>
> >>> -SRCREV = "c530a75c1e6a472b0eb9558310b518f0dfcd8860"
> >>> +SRCREV = "600caefd83a406540b2a789be6415e44c9b87add"
> >>> PE = "1"
> >>> PV = "0.0+git${SRCPV}"
> >>> -PR = "r1"
> >>> +PR = "r0"
> >>
> >> I know this is OK but I'd prefer to omit the PR when it is r0;
> >> specially now we use PRServer.
> >
> > Well, what is the official policy here? I'm happy to respin if
> > necessary, but I'd rather not burn cycles if the policy is hazy on the
> > subject.
> >
> Darren, sorry to say it is removal when possible.
Policy was hazy, however to me at least its now clear.
PR values are to be handled by the PR server and therefore we're
clearing them out of recipes as and when we can (same applies to
INC_PR). Ultimately they should disappear, the sooner the better as far
as I'm concerned.
Cheers,
Richard
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: [poky] [PATCH 1/4] linux-firmware: Update SRCREV, pull in iwlwifi-7260 support
2013-09-05 8:50 ` Richard Purdie
@ 2013-09-05 14:49 ` Darren Hart
0 siblings, 0 replies; 33+ messages in thread
From: Darren Hart @ 2013-09-05 14:49 UTC (permalink / raw)
To: Richard Purdie
Cc: Patches and discussions about the oe-core layer, yunguo.wei, Poky,
Otavio Salvador
On Thu, 2013-09-05 at 09:50 +0100, Richard Purdie wrote:
> On Wed, 2013-09-04 at 23:57 -0700, Saul Wold wrote:
> > On 09/04/2013 08:34 PM, Darren Hart wrote:
> > > On Wed, 2013-09-04 at 22:04 -0300, Otavio Salvador wrote:
> > >> On Wed, Sep 4, 2013 at 9:18 PM, Darren Hart <dvhart@linux.intel.com> wrote:
> > >>> Fixes [YOCTO #5110]
> > >>>
> > >>> Add support for the iwlwifi 7260 adapters. This creates a new package
> > >>> and includes support in the default linux-firmware (everything) package.
> > >>>
> > >>> Update the iwlwifi and radeon license checksums. Extensions to the
> > >>> copyright date ranges were the only change to the LICENSE files.
> > >>>
> > >>> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
> > >>> Cc: yunguo.wei@windriver.com
> > >>> ---
> > >>> .../linux-firmware/linux-firmware_git.bb | 10 ++++++----
> > >>> 1 file changed, 6 insertions(+), 4 deletions(-)
> > >>>
> > >>> diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> > >>> index 3825889..1b7db08 100644
> > >>> --- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> > >>> +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> > >>> @@ -7,12 +7,12 @@ SECTION = "kernel"
> > >>>
> > >>> LICENSE = "Proprietary"
> > >>>
> > >>> -LIC_FILES_CHKSUM = "file://LICENSE.radeon;md5=e56b405656593a0c97e478513051ea0e \
> > >>> +LIC_FILES_CHKSUM = "file://LICENSE.radeon;md5=9c2faab1bfca55e1510d6bde67206f9c \
> > >>> file://LICENSE.dib0700;md5=f7411825c8a555a1a3e5eab9ca773431 \
> > >>> file://LICENCE.xc5000;md5=1e170c13175323c32c7f4d0998d53f66 \
> > >>> file://LICENCE.ralink-firmware.txt;md5=ab2c269277c45476fb449673911a2dfd \
> > >>> file://LICENCE.qla2xxx;md5=4005328a134054f0fa077bdc37aa64f2 \
> > >>> - file://LICENCE.iwlwifi_firmware;md5=11545778abf78c43d7644d4f171ea1c7 \
> > >>> + file://LICENCE.iwlwifi_firmware;md5=8b938534f77ffd453690eb34ed84ae8b \
> > >>> file://LICENCE.i2400m;md5=14b901969e23c41881327c0d9e4b7d36 \
> > >>> file://LICENCE.atheros_firmware;md5=30a14c7823beedac9fa39c64fdd01a13 \
> > >>> file://LICENCE.agere;md5=af0133de6b4a9b2522defd5f188afd31 \
> > >>> @@ -23,10 +23,10 @@ LIC_FILES_CHKSUM = "file://LICENSE.radeon;md5=e56b405656593a0c97e478513051ea0e \
> > >>> file://LICENCE.via_vt6656;md5=e4159694cba42d4377a912e78a6e850f \
> > >>> "
> > >>>
> > >>> -SRCREV = "c530a75c1e6a472b0eb9558310b518f0dfcd8860"
> > >>> +SRCREV = "600caefd83a406540b2a789be6415e44c9b87add"
> > >>> PE = "1"
> > >>> PV = "0.0+git${SRCPV}"
> > >>> -PR = "r1"
> > >>> +PR = "r0"
> > >>
> > >> I know this is OK but I'd prefer to omit the PR when it is r0;
> > >> specially now we use PRServer.
> > >
> > > Well, what is the official policy here? I'm happy to respin if
> > > necessary, but I'd rather not burn cycles if the policy is hazy on the
> > > subject.
> > >
> > Darren, sorry to say it is removal when possible.
>
> Policy was hazy, however to me at least its now clear.
>
> PR values are to be handled by the PR server and therefore we're
> clearing them out of recipes as and when we can (same applies to
> INC_PR). Ultimately they should disappear, the sooner the better as far
> as I'm concerned.
>
OK, I'll remove the PR and include in a V2 series.
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH 2/4] xorg-driver-common: Add configure and install appends from meta-intel
2013-09-05 0:18 [PATCH 0/4] Updates in support of genericx86* Darren Hart
2013-09-05 0:18 ` [PATCH 1/4] linux-firmware: Update SRCREV, pull in iwlwifi-7260 support Darren Hart
@ 2013-09-05 0:18 ` Darren Hart
2013-09-05 0:54 ` Otavio Salvador
2013-09-05 9:53 ` Burton, Ross
2013-09-05 0:18 ` [PATCH 3/4] xf86-video-mga: Pull in Matrox MGA support " Darren Hart
` (2 subsequent siblings)
4 siblings, 2 replies; 33+ messages in thread
From: Darren Hart @ 2013-09-05 0:18 UTC (permalink / raw)
To: Poky, openembedded-core, Tom Zanussi; +Cc: Darren Hart
As part of pulling in the more generic components of the meta-intel
xserver infrastructure, include the configure and install appends from
the meta-intel version of xorg-driver-common.
Modify the configure prepend to use ${S} in the paths explicitly as
without this the script appears to be running in a build/ directory
instead of the source directory, and cannot find the configure.ac.
This prepend is required for at least the -intel and -mga drivers.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Cc: Ross Burton <ross.burton@intel.com>
Cc: Nitin A Kamble <nitin.a.kamble@intel.com>
---
.../xorg-driver/xorg-driver-common.inc | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/xorg-driver/xorg-driver-common.inc b/meta/recipes-graphics/xorg-driver/xorg-driver-common.inc
index 5f5d282..2d4f2ce 100644
--- a/meta/recipes-graphics/xorg-driver/xorg-driver-common.inc
+++ b/meta/recipes-graphics/xorg-driver/xorg-driver-common.inc
@@ -5,7 +5,7 @@ SECTION = "x11/drivers"
LICENSE = "MIT-X"
PE = "2"
-INC_PR = "r21"
+INC_PR = "r22"
DEPENDS = "virtual/xserver xproto randrproto util-macros"
@@ -39,3 +39,18 @@ def add_abi_depends(d, name):
pn = d.getVar("PN", True)
d.appendVar('RDEPENDS_' + pn, ' ' + abi)
+
+# AC_CHECK_FILE doesn't work when cross compiling, so we create a replacement
+# macro that simply assumes the test succeeds. This is required for at least
+# the -intel and -mga drivers.
+do_configure_prepend () {
+ echo 'AC_DEFUN(CC_AC_CHECK_FILE, $2)' > ${S}/configure.ac.new
+ sed 's/AC_CHECK_FILE/CC_AC_CHECK_FILE/g' ${S}/configure.ac >> ${S}/configure.ac.new
+ mv ${S}/configure.ac.new ${S}/configure.ac
+}
+
+# FIXME: We don't want to include the libtool archives (*.la) from modules
+# directory, as they serve no useful purpose. Upstream should fix Makefile.am
+do_install_append() {
+ find ${D}${libdir}/xorg/modules -regex ".*\.la$" | xargs rm -f --
+}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 33+ messages in thread* Re: [PATCH 2/4] xorg-driver-common: Add configure and install appends from meta-intel
2013-09-05 0:18 ` [PATCH 2/4] xorg-driver-common: Add configure and install appends from meta-intel Darren Hart
@ 2013-09-05 0:54 ` Otavio Salvador
2013-09-05 3:33 ` Darren Hart
2013-09-05 9:53 ` Burton, Ross
1 sibling, 1 reply; 33+ messages in thread
From: Otavio Salvador @ 2013-09-05 0:54 UTC (permalink / raw)
To: Darren Hart; +Cc: Poky, Patches and discussions about the oe-core layer
On Wed, Sep 4, 2013 at 9:18 PM, Darren Hart <dvhart@linux.intel.com> wrote:
> As part of pulling in the more generic components of the meta-intel
> xserver infrastructure, include the configure and install appends from
> the meta-intel version of xorg-driver-common.
>
> Modify the configure prepend to use ${S} in the paths explicitly as
> without this the script appears to be running in a build/ directory
> instead of the source directory, and cannot find the configure.ac.
> This prepend is required for at least the -intel and -mga drivers.
>
> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
> Cc: Ross Burton <ross.burton@intel.com>
> Cc: Nitin A Kamble <nitin.a.kamble@intel.com>
> ---
> .../xorg-driver/xorg-driver-common.inc | 17 ++++++++++++++++-
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-graphics/xorg-driver/xorg-driver-common.inc b/meta/recipes-graphics/xorg-driver/xorg-driver-common.inc
> index 5f5d282..2d4f2ce 100644
> --- a/meta/recipes-graphics/xorg-driver/xorg-driver-common.inc
> +++ b/meta/recipes-graphics/xorg-driver/xorg-driver-common.inc
> @@ -5,7 +5,7 @@ SECTION = "x11/drivers"
> LICENSE = "MIT-X"
>
> PE = "2"
> -INC_PR = "r21"
> +INC_PR = "r22"
This is need because you had a PRINC?
> DEPENDS = "virtual/xserver xproto randrproto util-macros"
>
> @@ -39,3 +39,18 @@ def add_abi_depends(d, name):
>
> pn = d.getVar("PN", True)
> d.appendVar('RDEPENDS_' + pn, ' ' + abi)
> +
> +# AC_CHECK_FILE doesn't work when cross compiling, so we create a replacement
> +# macro that simply assumes the test succeeds. This is required for at least
> +# the -intel and -mga drivers.
> +do_configure_prepend () {
> + echo 'AC_DEFUN(CC_AC_CHECK_FILE, $2)' > ${S}/configure.ac.new
> + sed 's/AC_CHECK_FILE/CC_AC_CHECK_FILE/g' ${S}/configure.ac >> ${S}/configure.ac.new
> + mv ${S}/configure.ac.new ${S}/configure.ac
> +}
> +
> +# FIXME: We don't want to include the libtool archives (*.la) from modules
> +# directory, as they serve no useful purpose. Upstream should fix Makefile.am
> +do_install_append() {
> + find ${D}${libdir}/xorg/modules -regex ".*\.la$" | xargs rm -f --
> +}
Agreed.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: [PATCH 2/4] xorg-driver-common: Add configure and install appends from meta-intel
2013-09-05 0:54 ` Otavio Salvador
@ 2013-09-05 3:33 ` Darren Hart
0 siblings, 0 replies; 33+ messages in thread
From: Darren Hart @ 2013-09-05 3:33 UTC (permalink / raw)
To: Otavio Salvador; +Cc: Poky, Patches and discussions about the oe-core layer
On Wed, 2013-09-04 at 21:54 -0300, Otavio Salvador wrote:
> On Wed, Sep 4, 2013 at 9:18 PM, Darren Hart <dvhart@linux.intel.com> wrote:
> > As part of pulling in the more generic components of the meta-intel
> > xserver infrastructure, include the configure and install appends from
> > the meta-intel version of xorg-driver-common.
> >
> > Modify the configure prepend to use ${S} in the paths explicitly as
> > without this the script appears to be running in a build/ directory
> > instead of the source directory, and cannot find the configure.ac.
> > This prepend is required for at least the -intel and -mga drivers.
> >
> > Signed-off-by: Darren Hart <dvhart@linux.intel.com>
> > Cc: Ross Burton <ross.burton@intel.com>
> > Cc: Nitin A Kamble <nitin.a.kamble@intel.com>
> > ---
> > .../xorg-driver/xorg-driver-common.inc | 17 ++++++++++++++++-
> > 1 file changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-graphics/xorg-driver/xorg-driver-common.inc b/meta/recipes-graphics/xorg-driver/xorg-driver-common.inc
> > index 5f5d282..2d4f2ce 100644
> > --- a/meta/recipes-graphics/xorg-driver/xorg-driver-common.inc
> > +++ b/meta/recipes-graphics/xorg-driver/xorg-driver-common.inc
> > @@ -5,7 +5,7 @@ SECTION = "x11/drivers"
> > LICENSE = "MIT-X"
> >
> > PE = "2"
> > -INC_PR = "r21"
> > +INC_PR = "r22"
>
> This is need because you had a PRINC?
>
It is my understanding that this change will ensure recipes including
this file will get rebuilt after this patch is merged and will get the
updated install append, clearing the .la files.
Yes/No?
Thanks for the review,
Darren
> > DEPENDS = "virtual/xserver xproto randrproto util-macros"
> >
> > @@ -39,3 +39,18 @@ def add_abi_depends(d, name):
> >
> > pn = d.getVar("PN", True)
> > d.appendVar('RDEPENDS_' + pn, ' ' + abi)
> > +
> > +# AC_CHECK_FILE doesn't work when cross compiling, so we create a replacement
> > +# macro that simply assumes the test succeeds. This is required for at least
> > +# the -intel and -mga drivers.
> > +do_configure_prepend () {
> > + echo 'AC_DEFUN(CC_AC_CHECK_FILE, $2)' > ${S}/configure.ac.new
> > + sed 's/AC_CHECK_FILE/CC_AC_CHECK_FILE/g' ${S}/configure.ac >> ${S}/configure.ac.new
> > + mv ${S}/configure.ac.new ${S}/configure.ac
> > +}
> > +
> > +# FIXME: We don't want to include the libtool archives (*.la) from modules
> > +# directory, as they serve no useful purpose. Upstream should fix Makefile.am
> > +do_install_append() {
> > + find ${D}${libdir}/xorg/modules -regex ".*\.la$" | xargs rm -f --
> > +}
>
> Agreed.
>
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 2/4] xorg-driver-common: Add configure and install appends from meta-intel
2013-09-05 0:18 ` [PATCH 2/4] xorg-driver-common: Add configure and install appends from meta-intel Darren Hart
2013-09-05 0:54 ` Otavio Salvador
@ 2013-09-05 9:53 ` Burton, Ross
2013-09-05 11:37 ` Otavio Salvador
2013-09-05 15:00 ` Darren Hart
1 sibling, 2 replies; 33+ messages in thread
From: Burton, Ross @ 2013-09-05 9:53 UTC (permalink / raw)
To: Darren Hart; +Cc: Poky, OE-core
On 5 September 2013 01:18, Darren Hart <dvhart@linux.intel.com> wrote:
> +# AC_CHECK_FILE doesn't work when cross compiling, so we create a replacement
> +# macro that simply assumes the test succeeds. This is required for at least
> +# the -intel and -mga drivers.
> +do_configure_prepend () {
> + echo 'AC_DEFUN(CC_AC_CHECK_FILE, $2)' > ${S}/configure.ac.new
> + sed 's/AC_CHECK_FILE/CC_AC_CHECK_FILE/g' ${S}/configure.ac >> ${S}/configure.ac.new
> + mv ${S}/configure.ac.new ${S}/configure.ac
> +}
I've been systematically fixing the drivers that use AC_CHECK_FILE so
now as far as I know we're left with just one (-mga), for which my
patch has been submitted upstream.
I'd prefer to see the patch retained and upstream fixed instead of
working around the breakage, because the test that configure.ac is
attempting to do is valid, it's just done wrong.
>+# FIXME: We don't want to include the libtool archives (*.la) from modules
>+# directory, as they serve no useful purpose. Upstream should fix Makefile.am
>+do_install_append() {
>+ find ${D}${libdir}/xorg/modules -regex ".*\.la$" | xargs rm -f --
>+}
Sadly when using libtool you can't "opt-out" of installing .la files
unless you delete the files that just got installed. In my opinion
this is something that needs to be done globally instead of
per-recipe.
Ross
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: [PATCH 2/4] xorg-driver-common: Add configure and install appends from meta-intel
2013-09-05 9:53 ` Burton, Ross
@ 2013-09-05 11:37 ` Otavio Salvador
2013-09-05 11:40 ` Burton, Ross
2013-09-05 15:00 ` Darren Hart
1 sibling, 1 reply; 33+ messages in thread
From: Otavio Salvador @ 2013-09-05 11:37 UTC (permalink / raw)
To: Burton, Ross; +Cc: Darren Hart, Poky, OE-core
On Thu, Sep 5, 2013 at 6:53 AM, Burton, Ross <ross.burton@intel.com> wrote:
> On 5 September 2013 01:18, Darren Hart <dvhart@linux.intel.com> wrote:
>> +# AC_CHECK_FILE doesn't work when cross compiling, so we create a replacement
>> +# macro that simply assumes the test succeeds. This is required for at least
>> +# the -intel and -mga drivers.
>> +do_configure_prepend () {
>> + echo 'AC_DEFUN(CC_AC_CHECK_FILE, $2)' > ${S}/configure.ac.new
>> + sed 's/AC_CHECK_FILE/CC_AC_CHECK_FILE/g' ${S}/configure.ac >> ${S}/configure.ac.new
>> + mv ${S}/configure.ac.new ${S}/configure.ac
>> +}
>
> I've been systematically fixing the drivers that use AC_CHECK_FILE so
> now as far as I know we're left with just one (-mga), for which my
> patch has been submitted upstream.
>
> I'd prefer to see the patch retained and upstream fixed instead of
> working around the breakage, because the test that configure.ac is
> attempting to do is valid, it's just done wrong.
So I think this should be dropped from here.
>>+# FIXME: We don't want to include the libtool archives (*.la) from modules
>>+# directory, as they serve no useful purpose. Upstream should fix Makefile.am
>>+do_install_append() {
>>+ find ${D}${libdir}/xorg/modules -regex ".*\.la$" | xargs rm -f --
>>+}
>
> Sadly when using libtool you can't "opt-out" of installing .la files
> unless you delete the files that just got installed. In my opinion
> this is something that needs to be done globally instead of
> per-recipe.
So autotools.bbclass?
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: [PATCH 2/4] xorg-driver-common: Add configure and install appends from meta-intel
2013-09-05 11:37 ` Otavio Salvador
@ 2013-09-05 11:40 ` Burton, Ross
2013-09-05 12:14 ` Richard Purdie
0 siblings, 1 reply; 33+ messages in thread
From: Burton, Ross @ 2013-09-05 11:40 UTC (permalink / raw)
To: Otavio Salvador; +Cc: Darren Hart, Poky, OE-core
On 5 September 2013 12:37, Otavio Salvador <otavio@ossystems.com.br> wrote:
>> Sadly when using libtool you can't "opt-out" of installing .la files
>> unless you delete the files that just got installed. In my opinion
>> this is something that needs to be done globally instead of
>> per-recipe.
>
> So autotools.bbclass?
Exactly. Phil sent patches to do this previously, and I've a
branch... somewhere that has another unfinished version.
Ross
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 2/4] xorg-driver-common: Add configure and install appends from meta-intel
2013-09-05 11:40 ` Burton, Ross
@ 2013-09-05 12:14 ` Richard Purdie
2013-09-05 12:23 ` Phil Blundell
0 siblings, 1 reply; 33+ messages in thread
From: Richard Purdie @ 2013-09-05 12:14 UTC (permalink / raw)
To: Burton, Ross; +Cc: Darren Hart, Poky, Otavio Salvador, OE-core
On Thu, 2013-09-05 at 12:40 +0100, Burton, Ross wrote:
> On 5 September 2013 12:37, Otavio Salvador <otavio@ossystems.com.br> wrote:
> >> Sadly when using libtool you can't "opt-out" of installing .la files
> >> unless you delete the files that just got installed. In my opinion
> >> this is something that needs to be done globally instead of
> >> per-recipe.
> >
> > So autotools.bbclass?
>
> Exactly. Phil sent patches to do this previously, and I've a
> branch... somewhere that has another unfinished version.
I continue to have mixed feelings about this:
* We've not done side by side build comparisons with something like
buildhistory.
* Figuring out any runtime issues with dlopen is the hardest part and we
don't actually have real data on whether there are issues there or not.
* We'd be deviating from the way the libtool authors suggest their tool
should operate. This makes filing bug reports and interacting with
upstream harder. I continue to dream of a libtool with working sysroot
support for example instead of carrying our hacks/workarounds/bugfixes.
* They are used in places, for example the darwin shlibs code currently
uses them. It could be updated to use otool these days mind but I'd
probably make the current code a fallback for unknown arches since it is
guaranteed to work everywhere.
So whilst I know several people love to just delete them, its a slightly
more complex issue than that.
Cheers,
Richard (who isn't keen on libtool and would rather replace that instead)
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 2/4] xorg-driver-common: Add configure and install appends from meta-intel
2013-09-05 12:14 ` Richard Purdie
@ 2013-09-05 12:23 ` Phil Blundell
2013-09-05 13:48 ` Burton, Ross
2013-09-05 15:32 ` Richard Purdie
0 siblings, 2 replies; 33+ messages in thread
From: Phil Blundell @ 2013-09-05 12:23 UTC (permalink / raw)
To: Richard Purdie; +Cc: Darren Hart, Poky, Otavio Salvador, OE-core
On Thu, 2013-09-05 at 13:14 +0100, Richard Purdie wrote:
> * Figuring out any runtime issues with dlopen is the hardest part and we
> don't actually have real data on whether there are issues there or not.
Do we have any particular reason to believe that there would be issues
(and if so, what they might be)? I guess it should be easy enough to
gather data if we know what we're looking for.
Right now the .la files go into the -dev packages anyway and hence
aren't usually going to be available at runtime for anything calling
dlopen() on the target. Is it native packages you're concerned about?
> * We'd be deviating from the way the libtool authors suggest their tool
> should operate. This makes filing bug reports and interacting with
> upstream harder.
This is true, though interacting with libtool upstream already seems to
be hard enough that I'm not sure this would make a material difference.
> * They are used in places, for example the darwin shlibs code currently
> uses them. It could be updated to use otool these days mind but I'd
> probably make the current code a fallback for unknown arches since it is
> guaranteed to work everywhere.
There's no reason in principle that folks on darwin (and/or
hitherto-undiscovered architectures) couldn't retain the .la files if
they wanted. The original patch that I sent used a DISTRO_FEATURE to
control this and those people building for darwin could simply refrain
from setting it. Alternatively we could make it explicitly conditional
on TARGET_OS or some such if there are reasons to believe that some
targets do genuinely require this stuff.
p.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 2/4] xorg-driver-common: Add configure and install appends from meta-intel
2013-09-05 12:23 ` Phil Blundell
@ 2013-09-05 13:48 ` Burton, Ross
2013-09-05 15:32 ` Richard Purdie
1 sibling, 0 replies; 33+ messages in thread
From: Burton, Ross @ 2013-09-05 13:48 UTC (permalink / raw)
To: Phil Blundell; +Cc: Darren Hart, Otavio Salvador, Poky, OE-core
On 5 September 2013 13:23, Phil Blundell <pb@pbcl.net> wrote:
> On Thu, 2013-09-05 at 13:14 +0100, Richard Purdie wrote:
>> * Figuring out any runtime issues with dlopen is the hardest part and we
>> don't actually have real data on whether there are issues there or not.
>
> Do we have any particular reason to believe that there would be issues
> (and if so, what they might be)? I guess it should be easy enough to
> gather data if we know what we're looking for.
There won't be any problems with dlopen() because that only looks at
.so files. Any issues will be at build time, I wouldn't be surprised
if some dependencies changed due to a difference in eg pkgconfig vs
.la linkage. Then again some other distros blanket-delete .la files
by default so I don't expect any critical problems.
>> * They are used in places, for example the darwin shlibs code currently
>> uses them. It could be updated to use otool these days mind but I'd
>> probably make the current code a fallback for unknown arches since it is
>> guaranteed to work everywhere.
>
> There's no reason in principle that folks on darwin (and/or
> hitherto-undiscovered architectures) couldn't retain the .la files if
> they wanted. The original patch that I sent used a DISTRO_FEATURE to
> control this and those people building for darwin could simply refrain
> from setting it. Alternatively we could make it explicitly conditional
> on TARGET_OS or some such if there are reasons to believe that some
> targets do genuinely require this stuff.
I don't think a distro feature is the right approach, but however it's
set can easily be forced using a machine override for Darwin.
Ross
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 2/4] xorg-driver-common: Add configure and install appends from meta-intel
2013-09-05 12:23 ` Phil Blundell
2013-09-05 13:48 ` Burton, Ross
@ 2013-09-05 15:32 ` Richard Purdie
2013-09-05 16:23 ` Burton, Ross
1 sibling, 1 reply; 33+ messages in thread
From: Richard Purdie @ 2013-09-05 15:32 UTC (permalink / raw)
To: Phil Blundell; +Cc: Darren Hart, Poky, Otavio Salvador, OE-core
On Thu, 2013-09-05 at 13:23 +0100, Phil Blundell wrote:
> On Thu, 2013-09-05 at 13:14 +0100, Richard Purdie wrote:
> > * Figuring out any runtime issues with dlopen is the hardest part and we
> > don't actually have real data on whether there are issues there or not.
>
> Do we have any particular reason to believe that there would be issues
> (and if so, what they might be)? I guess it should be easy enough to
> gather data if we know what we're looking for.
>
> Right now the .la files go into the -dev packages anyway and hence
> aren't usually going to be available at runtime for anything calling
> dlopen() on the target. Is it native packages you're concerned about?
The -dev package argument is a good one, we seem to be surviving without
those and that probably addresses the concern I was thinking of. I'm
also thinking of ltdl and its dlopen wrapping, not dlopen itself which
is a much smaller subset of recipes.
> > * We'd be deviating from the way the libtool authors suggest their tool
> > should operate. This makes filing bug reports and interacting with
> > upstream harder.
>
> This is true, though interacting with libtool upstream already seems to
> be hard enough that I'm not sure this would make a material difference.
It does seem somewhat tricky, agreed.
> > * They are used in places, for example the darwin shlibs code currently
> > uses them. It could be updated to use otool these days mind but I'd
> > probably make the current code a fallback for unknown arches since it is
> > guaranteed to work everywhere.
>
> There's no reason in principle that folks on darwin (and/or
> hitherto-undiscovered architectures) couldn't retain the .la files if
> they wanted. The original patch that I sent used a DISTRO_FEATURE to
> control this and those people building for darwin could simply refrain
> from setting it. Alternatively we could make it explicitly conditional
> on TARGET_OS or some such if there are reasons to believe that some
> targets do genuinely require this stuff.
There are ways to avoid problems for darwin. Using otool instead of
the .la files would be nice, equally mangling DISTRO_FEATURES based on
an SDK override is possible, albeit ugly. The la handling code will
likely bitrot as soon as its disabled by default and metadata starts
getting dropped which is probably a bigger concern. The number of SDK
darwin builds is currently a tiny portion of the usercase and codebase.
I guess the .la files just don't seem to be a big issue that some people
seem to paint them as. Why do we need to remove them and deviate from
the upstream?
Anyhow, if someone can show some world builds with and without the .la
files and see what build history shows we'd be closer to taking a patch
to turning them off. If we do it, we'll have to do it everywhere for
everything since the remaining code will bitrot badly IMO otherwise.
Cheers,
Richard
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 2/4] xorg-driver-common: Add configure and install appends from meta-intel
2013-09-05 15:32 ` Richard Purdie
@ 2013-09-05 16:23 ` Burton, Ross
0 siblings, 0 replies; 33+ messages in thread
From: Burton, Ross @ 2013-09-05 16:23 UTC (permalink / raw)
To: Richard Purdie; +Cc: Darren Hart, Poky, Otavio Salvador, OE-core
On 5 September 2013 16:32, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> I guess the .la files just don't seem to be a big issue that some people
> seem to paint them as. Why do we need to remove them and deviate from
> the upstream?
You appear to be defending choices made by libtool upstream here. Are
you unwell? :)
> Anyhow, if someone can show some world builds with and without the .la
> files and see what build history shows we'd be closer to taking a patch
> to turning them off. If we do it, we'll have to do it everywhere for
> everything since the remaining code will bitrot badly IMO otherwise.
I'll try and hack something up this week as a proof of concept.
Ross
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 2/4] xorg-driver-common: Add configure and install appends from meta-intel
2013-09-05 9:53 ` Burton, Ross
2013-09-05 11:37 ` Otavio Salvador
@ 2013-09-05 15:00 ` Darren Hart
1 sibling, 0 replies; 33+ messages in thread
From: Darren Hart @ 2013-09-05 15:00 UTC (permalink / raw)
To: Burton, Ross; +Cc: Poky, OE-core
On Thu, 2013-09-05 at 10:53 +0100, Burton, Ross wrote:
> On 5 September 2013 01:18, Darren Hart <dvhart@linux.intel.com> wrote:
> > +# AC_CHECK_FILE doesn't work when cross compiling, so we create a replacement
> > +# macro that simply assumes the test succeeds. This is required for at least
> > +# the -intel and -mga drivers.
> > +do_configure_prepend () {
> > + echo 'AC_DEFUN(CC_AC_CHECK_FILE, $2)' > ${S}/configure.ac.new
> > + sed 's/AC_CHECK_FILE/CC_AC_CHECK_FILE/g' ${S}/configure.ac >> ${S}/configure.ac.new
> > + mv ${S}/configure.ac.new ${S}/configure.ac
> > +}
>
> I've been systematically fixing the drivers that use AC_CHECK_FILE so
> now as far as I know we're left with just one (-mga), for which my
> patch has been submitted upstream.
The xf86-video-intel driver also appears to need it (just FYI re your
comment on mga).
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH 3/4] xf86-video-mga: Pull in Matrox MGA support from meta-intel
2013-09-05 0:18 [PATCH 0/4] Updates in support of genericx86* Darren Hart
2013-09-05 0:18 ` [PATCH 1/4] linux-firmware: Update SRCREV, pull in iwlwifi-7260 support Darren Hart
2013-09-05 0:18 ` [PATCH 2/4] xorg-driver-common: Add configure and install appends from meta-intel Darren Hart
@ 2013-09-05 0:18 ` Darren Hart
2013-09-05 9:57 ` Burton, Ross
2013-09-05 0:18 ` [PATCH 4/4] genericx86: Create a x86-common.inc base for the x86 BSPs Darren Hart
2013-09-05 1:16 ` [PATCH 0/4] Updates in support of genericx86* Otavio Salvador
4 siblings, 1 reply; 33+ messages in thread
From: Darren Hart @ 2013-09-05 0:18 UTC (permalink / raw)
To: Poky, openembedded-core, Tom Zanussi; +Cc: Darren Hart
In support of the more generic x86 BSPs, pull in the Matrox driver
recipe from meta-intel.
Remove the checkfile patch from Ross as this is now handled adequately
with the configure prepend hack which assumes success for any checkfile
calls.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Cc: Ross Burton <ross.burton@intel.com>
Cc: Nitin A Kamble <nitin.a.kamble@intel.com>
---
meta/conf/machine/include/ia32-base.inc | 2 ++
.../xorg-driver/xf86-video-mga_1.6.2.bb | 20 ++++++++++++++++++++
2 files changed, 22 insertions(+)
create mode 100644 meta/recipes-graphics/xorg-driver/xf86-video-mga_1.6.2.bb
diff --git a/meta/conf/machine/include/ia32-base.inc b/meta/conf/machine/include/ia32-base.inc
index cb542a5..e13cfca 100644
--- a/meta/conf/machine/include/ia32-base.inc
+++ b/meta/conf/machine/include/ia32-base.inc
@@ -45,6 +45,8 @@ XSERVER_IA32_I965 = "xf86-video-intel \
mesa-driver-i965 \
"
+XSERVER_IA32_MATROX_MGA = "xf86-video-mga"
+
XSERVER_IA32_VESA = "xf86-video-vesa"
XSERVER_IA32_FBDEV = "xf86-video-fbdev"
diff --git a/meta/recipes-graphics/xorg-driver/xf86-video-mga_1.6.2.bb b/meta/recipes-graphics/xorg-driver/xf86-video-mga_1.6.2.bb
new file mode 100644
index 0000000..3fc2c77
--- /dev/null
+++ b/meta/recipes-graphics/xorg-driver/xf86-video-mga_1.6.2.bb
@@ -0,0 +1,20 @@
+require recipes-graphics/xorg-driver/xorg-driver-video.inc
+
+SUMMARY = "X.Org X server -- Matrox MGA display driver"
+
+DESCRIPTION = "mga is an Xorg driver for Matrox video cards"
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=bc1395d2cd32dfc5d6c57d2d8f83d3fc"
+
+DEPENDS += "virtual/libx11 drm xf86driproto glproto virtual/libgl libpciaccess"
+
+EXTRA_OECONF += "--enable-dri"
+
+PR = "r1"
+
+COMPATIBLE_HOST = '(i.86.*-linux|x86_64.*-linux)'
+
+SRC_URI[md5sum] = "f543877db4e260d8b43c7da3095605ed"
+SRC_URI[sha256sum] = "3f89ce250eea93f0de890954687790e06c0bab9e3e303df393e8759a187eca6c"
+
+RDEPENDS_${PN} = "xserver-xorg-module-exa"
--
1.7.9.5
^ permalink raw reply related [flat|nested] 33+ messages in thread* Re: [PATCH 3/4] xf86-video-mga: Pull in Matrox MGA support from meta-intel
2013-09-05 0:18 ` [PATCH 3/4] xf86-video-mga: Pull in Matrox MGA support " Darren Hart
@ 2013-09-05 9:57 ` Burton, Ross
2013-09-05 13:04 ` Tom Zanussi
2013-09-05 14:52 ` Darren Hart
0 siblings, 2 replies; 33+ messages in thread
From: Burton, Ross @ 2013-09-05 9:57 UTC (permalink / raw)
To: Darren Hart; +Cc: Poky, OE-core
On 5 September 2013 01:18, Darren Hart <dvhart@linux.intel.com> wrote:
> In support of the more generic x86 BSPs, pull in the Matrox driver
> recipe from meta-intel.
What machine is this for in particular? In discussion with Nitin
about MGA a few weeks back the conclusion was that the vesa driver
should be sufficient. As far as I'm aware the reference platforms
don't ship with MGA hardware so it's up to the owner of the platform
to install whatever they have to hand (mga, nvidia, ATI, etc), or am I
wrong about that?
> Remove the checkfile patch from Ross as this is now handled adequately
> with the configure prepend hack which assumes success for any checkfile
> calls.
Assuming success in an distro where opengl isn't enabled will result
in the driver believing that DRI is enabled when it isn't, so expect
to see build failures from this.
Ross
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 3/4] xf86-video-mga: Pull in Matrox MGA support from meta-intel
2013-09-05 9:57 ` Burton, Ross
@ 2013-09-05 13:04 ` Tom Zanussi
2013-09-05 14:52 ` Darren Hart
1 sibling, 0 replies; 33+ messages in thread
From: Tom Zanussi @ 2013-09-05 13:04 UTC (permalink / raw)
To: Burton, Ross; +Cc: Saxena, Rahul, Darren Hart, OE-core, Seow, Chen Yong, Poky
On Thu, 2013-09-05 at 10:57 +0100, Burton, Ross wrote:
> On 5 September 2013 01:18, Darren Hart <dvhart@linux.intel.com> wrote:
> > In support of the more generic x86 BSPs, pull in the Matrox driver
> > recipe from meta-intel.
>
> What machine is this for in particular? In discussion with Nitin
> about MGA a few weeks back the conclusion was that the vesa driver
> should be sufficient. As far as I'm aware the reference platforms
> don't ship with MGA hardware so it's up to the owner of the platform
> to install whatever they have to hand (mga, nvidia, ATI, etc), or am I
> wrong about that?
>
It's my understanding that some of these server-type systems like Romley
and Crystal Forest have on-chip graphics disabled and ship with ancient
MGA graphics, which apparently we have a cheap source of chips for...
Probably vesa would work for these systems, cc'ing those in the know...
Tom
> > Remove the checkfile patch from Ross as this is now handled adequately
> > with the configure prepend hack which assumes success for any checkfile
> > calls.
>
> Assuming success in an distro where opengl isn't enabled will result
> in the driver believing that DRI is enabled when it isn't, so expect
> to see build failures from this.
>
> Ross
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 3/4] xf86-video-mga: Pull in Matrox MGA support from meta-intel
2013-09-05 9:57 ` Burton, Ross
2013-09-05 13:04 ` Tom Zanussi
@ 2013-09-05 14:52 ` Darren Hart
2013-09-05 15:11 ` Burton, Ross
[not found] ` <5229303F.1090209@windriver.com>
1 sibling, 2 replies; 33+ messages in thread
From: Darren Hart @ 2013-09-05 14:52 UTC (permalink / raw)
To: Burton, Ross, yunguo.wei, Kamble, Nitin A; +Cc: Poky, OE-core
On Thu, 2013-09-05 at 10:57 +0100, Burton, Ross wrote:
> On 5 September 2013 01:18, Darren Hart <dvhart@linux.intel.com> wrote:
> > In support of the more generic x86 BSPs, pull in the Matrox driver
> > recipe from meta-intel.
>
> What machine is this for in particular?
This was reported when someone was testing on a Romley machine.
> In discussion with Nitin
> about MGA a few weeks back the conclusion was that the vesa driver
> should be sufficient. As far as I'm aware the reference platforms
> don't ship with MGA hardware so it's up to the owner of the platform
> to install whatever they have to hand (mga, nvidia, ATI, etc), or am I
> wrong about that?
Nitin?
Yunguo?
>
> > Remove the checkfile patch from Ross as this is now handled adequately
> > with the configure prepend hack which assumes success for any checkfile
> > calls.
>
> Assuming success in an distro where opengl isn't enabled will result
> in the driver believing that DRI is enabled when it isn't, so expect
> to see build failures from this.
Should we be adding a distro depends on opengl for this driver as is
being done for others currently?
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: [PATCH 3/4] xf86-video-mga: Pull in Matrox MGA support from meta-intel
2013-09-05 14:52 ` Darren Hart
@ 2013-09-05 15:11 ` Burton, Ross
2013-09-05 15:21 ` Burton, Ross
[not found] ` <5229303F.1090209@windriver.com>
1 sibling, 1 reply; 33+ messages in thread
From: Burton, Ross @ 2013-09-05 15:11 UTC (permalink / raw)
To: Darren Hart; +Cc: yunguo.wei, Poky, OE-core
On 5 September 2013 15:52, Darren Hart <dvhart@linux.intel.com> wrote:
>> Assuming success in an distro where opengl isn't enabled will result
>> in the driver believing that DRI is enabled when it isn't, so expect
>> to see build failures from this.
>
> Should we be adding a distro depends on opengl for this driver as is
> being done for others currently?
No, because DRI is optional in this driver. Follow opengl and flip
--enable/disable-dri.
(assuming I don't change the server to always build DRI)
Ross
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: [PATCH 3/4] xf86-video-mga: Pull in Matrox MGA support from meta-intel
2013-09-05 15:11 ` Burton, Ross
@ 2013-09-05 15:21 ` Burton, Ross
0 siblings, 0 replies; 33+ messages in thread
From: Burton, Ross @ 2013-09-05 15:21 UTC (permalink / raw)
To: Darren Hart; +Cc: yunguo.wei, Poky, OE-core
On 5 September 2013 16:11, Burton, Ross <ross.burton@intel.com> wrote:
> On 5 September 2013 15:52, Darren Hart <dvhart@linux.intel.com> wrote:
>>> Assuming success in an distro where opengl isn't enabled will result
>>> in the driver believing that DRI is enabled when it isn't, so expect
>>> to see build failures from this.
>>
>> Should we be adding a distro depends on opengl for this driver as is
>> being done for others currently?
>
> No, because DRI is optional in this driver. Follow opengl and flip
> --enable/disable-dri.
>
> (assuming I don't change the server to always build DRI)
Follow-up. Using PACKAGECONFIG to respecting the "opengl"
DISTRO_FEATURE and --enable/--disable-dri should work for the MGA
driver. dri.h is part of Mesa, so obviously opengl and DRI are
entwined.
Ross
^ permalink raw reply [flat|nested] 33+ messages in thread
[parent not found: <5229303F.1090209@windriver.com>]
* Re: [PATCH 3/4] xf86-video-mga: Pull in Matrox MGA support from meta-intel
[not found] ` <5229303F.1090209@windriver.com>
@ 2013-09-10 2:37 ` Darren Hart
[not found] ` <522E9996.8000107@windriver.com>
0 siblings, 1 reply; 33+ messages in thread
From: Darren Hart @ 2013-09-10 2:37 UTC (permalink / raw)
To: Yunguo Wei; +Cc: Poky, OE-core
On Fri, 2013-09-06 at 09:30 +0800, Yunguo Wei wrote:
> On 09/05/2013 10:52 PM, Darren Hart wrote:
> > On Thu, 2013-09-05 at 10:57 +0100, Burton, Ross wrote:
> >> On 5 September 2013 01:18, Darren Hart <dvhart@linux.intel.com> wrote:
> >>> In support of the more generic x86 BSPs, pull in the Matrox driver
> >>> recipe from meta-intel.
> >> What machine is this for in particular?
> > This was reported when someone was testing on a Romley machine.
>
> Yes, it is Intel SDP S2R3, Romley-EP IVY refresh.
> >
> >> In discussion with Nitin
> >> about MGA a few weeks back the conclusion was that the vesa driver
> >> should be sufficient. As far as I'm aware the reference platforms
> >> don't ship with MGA hardware so it's up to the owner of the platform
> >> to install whatever they have to hand (mga, nvidia, ATI, etc), or am I
> >> wrong about that?
> > Nitin?
> >
> > Yunguo?
>
> We thought vesa is supposed to work.
>
> Intel OSVe team reported this problem against WRLinux 5.0.1, and I fixed
> it by adding mga package.
> Note that, mga kernel driver was not built-in or as a module.
I missed that the kernel module was missing. Oops. That's easy enough to
add to the common-pc graphics fragment. But what we need to know is if
we should try to get MGA into oe-core or not. I honestly don't
understand why we shouldn't, with intel and omap in there already. It
seems silly to have a special layer for the xorg driver when mesa and
the kernel already build their part for the same hardware....
Are there any compelling arguments for not including the mga driver in
oe-core?
>
>
> Regards,
> Yunguo
> >
> >>> Remove the checkfile patch from Ross as this is now handled adequately
> >>> with the configure prepend hack which assumes success for any checkfile
> >>> calls.
> >> Assuming success in an distro where opengl isn't enabled will result
> >> in the driver believing that DRI is enabled when it isn't, so expect
> >> to see build failures from this.
> > Should we be adding a distro depends on opengl for this driver as is
> > being done for others currently?
> >
>
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH 4/4] genericx86: Create a x86-common.inc base for the x86 BSPs
2013-09-05 0:18 [PATCH 0/4] Updates in support of genericx86* Darren Hart
` (2 preceding siblings ...)
2013-09-05 0:18 ` [PATCH 3/4] xf86-video-mga: Pull in Matrox MGA support " Darren Hart
@ 2013-09-05 0:18 ` Darren Hart
2013-09-05 1:16 ` [PATCH 0/4] Updates in support of genericx86* Otavio Salvador
4 siblings, 0 replies; 33+ messages in thread
From: Darren Hart @ 2013-09-05 0:18 UTC (permalink / raw)
To: Poky, openembedded-core, Tom Zanussi; +Cc: yunguo.wei, Darren Hart
Fixes [YOCTO #5108] (adds support for xf86-video-mga to generic-x86*)
The genericx86 and genericx86-64 machines share a great deal in common
in terms of machine features, required packages, etc. Use a common
include file to simplify changes to both machine definitions and avoid
accidental omissions.
Replace the hard-coded XSERVER assignment with the XSERVER_IA32*
defines from ia32-base.inc.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Cc: Ross Burton <ross.burton@intel.com>
Cc: yunguo.wei@windriver.com
---
meta-yocto-bsp/conf/machine/genericx86-64.conf | 29 +-----------------
meta-yocto-bsp/conf/machine/genericx86.conf | 31 +-------------------
meta-yocto-bsp/conf/machine/include/x86-common.inc | 26 ++++++++++++++++
3 files changed, 28 insertions(+), 58 deletions(-)
create mode 100644 meta-yocto-bsp/conf/machine/include/x86-common.inc
diff --git a/meta-yocto-bsp/conf/machine/genericx86-64.conf b/meta-yocto-bsp/conf/machine/genericx86-64.conf
index 7825bae..d4b0466 100644
--- a/meta-yocto-bsp/conf/machine/genericx86-64.conf
+++ b/meta-yocto-bsp/conf/machine/genericx86-64.conf
@@ -4,31 +4,4 @@
#@DESCRIPTION: Machine configuration for generic X86_64 (64-bit) PCs and servers. Supports a moderately wide range of drivers that should boot and be usable on "typical" hardware.
include conf/machine/include/tune-x86_64.inc
-
-MACHINE_FEATURES = "screen keyboard pci usbhost ext2 ext3 x86 wifi acpi alsa efi pcbios"
-
-KERNEL_IMAGETYPE = "bzImage"
-
-PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-PREFERRED_VERSION_linux-yocto ?= "3.10%"
-PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
-XSERVER ?= "xserver-xorg \
- xserver-xorg-extension-glx \
- xf86-input-mouse \
- xf86-input-keyboard \
- xf86-input-evdev \
- xf86-input-synaptics \
- xf86-video-fbdev \
- xf86-video-modesetting \
- xf86-video-vesa \
- xf86-video-intel \
- mesa-driver-i915 \
- mesa-driver-i965"
-
-MACHINE_EXTRA_RRECOMMENDS = "kernel-modules eee-acpi-scripts linux-firmware v86d"
-
-IMAGE_FSTYPES ?= "ext3 cpio.gz live"
-
-GLIBC_ADDONS = "nptl"
-
-EXTRA_OECONF_append_pn-matchbox-panel-2 = " --with-battery=acpi"
+include conf/machine/include/x86-common.inc
diff --git a/meta-yocto-bsp/conf/machine/genericx86.conf b/meta-yocto-bsp/conf/machine/genericx86.conf
index ff5cbc9..1e1107d 100644
--- a/meta-yocto-bsp/conf/machine/genericx86.conf
+++ b/meta-yocto-bsp/conf/machine/genericx86.conf
@@ -4,33 +4,4 @@
#@DESCRIPTION: Machine configuration for generic X86 (32-bit) PCs. Supports a moderately wide range of drivers that should boot and be usable on "typical" hardware.
include conf/machine/include/tune-atom.inc
-
-MACHINE_FEATURES = "screen keyboard pci usbhost ext2 ext3 x86 wifi acpi alsa"
-
-KERNEL_IMAGETYPE = "bzImage"
-
-PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-PREFERRED_VERSION_linux-yocto ?= "3.10%"
-PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
-XSERVER ?= "xserver-xorg \
- xserver-xorg-extension-glx \
- xf86-input-mouse \
- xf86-input-keyboard \
- xf86-input-evdev \
- xf86-input-synaptics \
- xf86-video-fbdev \
- xf86-video-modesetting \
- xf86-video-vesa \
- xf86-video-intel \
- mesa-driver-i915 \
- mesa-driver-i965"
-
-#MACHINE_EXTRA_RDEPENDS = "rt2860"
-
-MACHINE_EXTRA_RRECOMMENDS = "kernel-modules eee-acpi-scripts linux-firmware v86d"
-
-IMAGE_FSTYPES ?= "ext3 cpio.gz live"
-
-GLIBC_ADDONS = "nptl"
-
-EXTRA_OECONF_append_pn-matchbox-panel-2 = " --with-battery=acpi"
+include conf/machine/include/x86-common.inc
diff --git a/meta-yocto-bsp/conf/machine/include/x86-common.inc b/meta-yocto-bsp/conf/machine/include/x86-common.inc
new file mode 100644
index 0000000..0454fdd
--- /dev/null
+++ b/meta-yocto-bsp/conf/machine/include/x86-common.inc
@@ -0,0 +1,26 @@
+include conf/machine/include/ia32-base.inc
+MACHINE_FEATURES = "screen keyboard pci usbhost ext2 ext3 x86 wifi acpi alsa \
+ efi pcbios"
+
+KERNEL_IMAGETYPE = "bzImage"
+
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+PREFERRED_VERSION_linux-yocto ?= "3.10%"
+PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
+XSERVER ?= "${XSERVER_IA32_BASE} \
+ ${XSERVER_IA32_EXT} \
+ ${XSERVER_IA32_I915} \
+ ${XSERVER_IA32_I965} \
+ ${XSERVER_IA32_MATROX_MGA} \
+ ${XSERVER_IA32_FBDEV} \
+ ${XSERVER_IA32_VESA} \
+ ${XSERVER_IA32_MODESETTING} \
+ "
+
+MACHINE_EXTRA_RRECOMMENDS = "kernel-modules eee-acpi-scripts linux-firmware v86d"
+
+IMAGE_FSTYPES ?= "ext3 cpio.gz live"
+
+GLIBC_ADDONS = "nptl"
+
+EXTRA_OECONF_append_pn-matchbox-panel-2 = " --with-battery=acpi"
--
1.7.9.5
^ permalink raw reply related [flat|nested] 33+ messages in thread* Re: [PATCH 0/4] Updates in support of genericx86*
2013-09-05 0:18 [PATCH 0/4] Updates in support of genericx86* Darren Hart
` (3 preceding siblings ...)
2013-09-05 0:18 ` [PATCH 4/4] genericx86: Create a x86-common.inc base for the x86 BSPs Darren Hart
@ 2013-09-05 1:16 ` Otavio Salvador
2013-09-05 3:35 ` Darren Hart
4 siblings, 1 reply; 33+ messages in thread
From: Otavio Salvador @ 2013-09-05 1:16 UTC (permalink / raw)
To: Darren Hart
Cc: Poky, yunguo.wei, Patches and discussions about the oe-core layer
On Wed, Sep 4, 2013 at 9:18 PM, Darren Hart <dvhart@linux.intel.com> wrote:
> As this series bridges both oe-core and poky and is best viewed as one series, I
> opted to send the series to both lists.
>
> These patches address bugs/feature requests for additional support of
> linux-firmware and xorg-video-* drivers for the new meta-yocto-bsp genericx86
> and genericx86-64 machines.
>
> Some of the oe-core changes could be contained in the meta-yocto-bsp layer, but
> as these changes come from meta-intel, they are needed by multiple layers, and I
> felt it might make more sense in oe-core. If people object to the mga or intel
> xserver video drivers, I can respin those for meta-yocto-bsp.
QEMU does not need them so they should be in meta-yocto-bsp.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: [PATCH 0/4] Updates in support of genericx86*
2013-09-05 1:16 ` [PATCH 0/4] Updates in support of genericx86* Otavio Salvador
@ 2013-09-05 3:35 ` Darren Hart
2013-09-05 9:47 ` [poky] " Burton, Ross
0 siblings, 1 reply; 33+ messages in thread
From: Darren Hart @ 2013-09-05 3:35 UTC (permalink / raw)
To: Otavio Salvador
Cc: Poky, yunguo.wei, Patches and discussions about the oe-core layer
On Wed, 2013-09-04 at 22:16 -0300, Otavio Salvador wrote:
> On Wed, Sep 4, 2013 at 9:18 PM, Darren Hart <dvhart@linux.intel.com> wrote:
> > As this series bridges both oe-core and poky and is best viewed as one series, I
> > opted to send the series to both lists.
> >
> > These patches address bugs/feature requests for additional support of
> > linux-firmware and xorg-video-* drivers for the new meta-yocto-bsp genericx86
> > and genericx86-64 machines.
> >
> > Some of the oe-core changes could be contained in the meta-yocto-bsp layer, but
> > as these changes come from meta-intel, they are needed by multiple layers, and I
> > felt it might make more sense in oe-core. If people object to the mga or intel
> > xserver video drivers, I can respin those for meta-yocto-bsp.
>
> QEMU does not need them so they should be in meta-yocto-bsp.
>
I'm fine with that if that is the consensus. Does anyone else care to
weigh in?
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [poky] [PATCH 0/4] Updates in support of genericx86*
2013-09-05 3:35 ` Darren Hart
@ 2013-09-05 9:47 ` Burton, Ross
2013-09-05 11:06 ` Richard Purdie
0 siblings, 1 reply; 33+ messages in thread
From: Burton, Ross @ 2013-09-05 9:47 UTC (permalink / raw)
To: Darren Hart
Cc: yunguo.wei, Poky, Otavio Salvador,
Patches and discussions about the oe-core layer
On 5 September 2013 04:35, Darren Hart <dvhart@linux.intel.com> wrote:
>> > Some of the oe-core changes could be contained in the meta-yocto-bsp layer, but
>> > as these changes come from meta-intel, they are needed by multiple layers, and I
>> > felt it might make more sense in oe-core. If people object to the mga or intel
>> > xserver video drivers, I can respin those for meta-yocto-bsp.
>>
>> QEMU does not need them so they should be in meta-yocto-bsp.
>
> I'm fine with that if that is the consensus. Does anyone else care to
> weigh in?
By that logic nearly all the X drivers in oe-core should be in
meta-yocto-bsp (synaptics, intel, modesetting, omap, omapfb, keyboard,
mouse), but then we'd be forcing people using anything other than qemu
to use meta-yocto-bsp (or duplicate the recipes). A more nuanced
rationale for keeping modesettings/intel/etc is that whilst the driver
isn't used on QEMU it is in use on a large number of machines so it
can be centrally maintained in oe-core. I'm not convinced this holds
for -mga (unless you're reading this from the late 90s) so it should
be in meta-yocto-bsp.
Ross
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [poky] [PATCH 0/4] Updates in support of genericx86*
2013-09-05 9:47 ` [poky] " Burton, Ross
@ 2013-09-05 11:06 ` Richard Purdie
2013-09-05 11:40 ` Otavio Salvador
0 siblings, 1 reply; 33+ messages in thread
From: Richard Purdie @ 2013-09-05 11:06 UTC (permalink / raw)
To: Burton, Ross
Cc: yunguo.wei, Darren Hart, Poky, Otavio Salvador,
Patches and discussions about the oe-core layer
On Thu, 2013-09-05 at 10:47 +0100, Burton, Ross wrote:
> On 5 September 2013 04:35, Darren Hart <dvhart@linux.intel.com> wrote:
> >> > Some of the oe-core changes could be contained in the meta-yocto-bsp layer, but
> >> > as these changes come from meta-intel, they are needed by multiple layers, and I
> >> > felt it might make more sense in oe-core. If people object to the mga or intel
> >> > xserver video drivers, I can respin those for meta-yocto-bsp.
> >>
> >> QEMU does not need them so they should be in meta-yocto-bsp.
> >
> > I'm fine with that if that is the consensus. Does anyone else care to
> > weigh in?
>
> By that logic nearly all the X drivers in oe-core should be in
> meta-yocto-bsp (synaptics, intel, modesetting, omap, omapfb, keyboard,
> mouse), but then we'd be forcing people using anything other than qemu
> to use meta-yocto-bsp (or duplicate the recipes). A more nuanced
> rationale for keeping modesettings/intel/etc is that whilst the driver
> isn't used on QEMU it is in use on a large number of machines so it
> can be centrally maintained in oe-core. I'm not convinced this holds
> for -mga (unless you're reading this from the late 90s) so it should
> be in meta-yocto-bsp.
There is some thinking going on at the moment about merging genericx86
and qemux86 since the two machines are converging and any differences
could be dealt with at runtime. To me, this is a key detail.
I agree that -mga is a push for OE-Core but the other drivers are useful
and I can see a case for moving them towards the core rather than having
several layers needing them.
Cheers,
Richard
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [poky] [PATCH 0/4] Updates in support of genericx86*
2013-09-05 11:06 ` Richard Purdie
@ 2013-09-05 11:40 ` Otavio Salvador
0 siblings, 0 replies; 33+ messages in thread
From: Otavio Salvador @ 2013-09-05 11:40 UTC (permalink / raw)
To: Richard Purdie
Cc: yunguo.wei, Darren Hart, Poky,
Patches and discussions about the oe-core layer
On Thu, Sep 5, 2013 at 8:06 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Thu, 2013-09-05 at 10:47 +0100, Burton, Ross wrote:
>> On 5 September 2013 04:35, Darren Hart <dvhart@linux.intel.com> wrote:
>> >> > Some of the oe-core changes could be contained in the meta-yocto-bsp layer, but
>> >> > as these changes come from meta-intel, they are needed by multiple layers, and I
>> >> > felt it might make more sense in oe-core. If people object to the mga or intel
>> >> > xserver video drivers, I can respin those for meta-yocto-bsp.
>> >>
>> >> QEMU does not need them so they should be in meta-yocto-bsp.
>> >
>> > I'm fine with that if that is the consensus. Does anyone else care to
>> > weigh in?
>>
>> By that logic nearly all the X drivers in oe-core should be in
>> meta-yocto-bsp (synaptics, intel, modesetting, omap, omapfb, keyboard,
>> mouse), but then we'd be forcing people using anything other than qemu
>> to use meta-yocto-bsp (or duplicate the recipes). A more nuanced
>> rationale for keeping modesettings/intel/etc is that whilst the driver
>> isn't used on QEMU it is in use on a large number of machines so it
>> can be centrally maintained in oe-core. I'm not convinced this holds
>> for -mga (unless you're reading this from the late 90s) so it should
>> be in meta-yocto-bsp.
>
> There is some thinking going on at the moment about merging genericx86
> and qemux86 since the two machines are converging and any differences
> could be dealt with at runtime. To me, this is a key detail.
>
> I agree that -mga is a push for OE-Core but the other drivers are useful
> and I can see a case for moving them towards the core rather than having
> several layers needing them.
I am not sure Intel's driver should be in OE-Core; if that's the case
we'd need nouveau and ati drivers there as well as they are largely
used in PCs.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 33+ messages in thread