Re: [linux-yocto] [PATCH 0/1] power/intel update for 3.17
-Original Message- From: linux-yocto-boun...@yoctoproject.org [mailto:linux-yocto- boun...@yoctoproject.org] On Behalf Of Bruce Ashfield Sent: Monday, November 03, 2014 8:15 AM To: Tom Zanussi; linux-yocto@yoctoproject.org Subject: Re: [linux-yocto] [PATCH 0/1] power/intel update for 3.17 On 14-11-03 10:38 AM, Tom Zanussi wrote: This adds X86_INTEL_PSTATE to the intel power feature. Boot-tested on both nuc and crownbay-noemgd. Please pull into linux-yocto-3.17. The following changes since commit 229ce533868773f201f9ab36e2b4248b381309ec: meta: bump kver to v3.17.1 (2014-10-15 10:09:49 -0400) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-contrib.git tzanussi/3.17-power- pstate http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-contrib/log/?h=t zanussi/3.17-power-pstate Thanks Tom. This is merged, update your meta SRCREVs to take advantage of the functionality. Bruce Hi Bruce, I do not see the change online yet. http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.17/log/?h=meta Can you check whether the commit has been pushed upstream? Thanks, Nitin Tom Zanussi (1): meta: Enable native P state management for power/intel meta/cfg/kernel-cache/features/power/intel.cfg | 1 + 1 file changed, 1 insertion(+) -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH] serial, 8250_dw: fix linux-yocto merge build issue since v3.10.48
On 10/7/14, 11:39 PM, Ong Boon Leong boon.leong@intel.com wrote:
There is an build issue in following merge-point:
Merge tag 'v3.10.48' into standard/base
60a9d9fc565e4503dbb8705803e83d906afc4ad2
For 8250_dw.c: dw8250_handle_irq() requires the following line
to be restored in order to build successfully.
Signed-off-by: Ong Boon Leong boon.leong@intel.com
I have seen this issue, and I also came up with the exact same fix on my
end.
Acked-By: Nitin A Kamble nitin.a.kam...@intel.com
Nitin
---
drivers/tty/serial/8250/8250_dw.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/8250/8250_dw.c
b/drivers/tty/serial/8250/8250_dw.c
index 36fe9d9..5caf10e 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -217,6 +217,7 @@ static unsigned int dw8250_serial_in32(struct
uart_port *p, int offset)
static int dw8250_handle_irq(struct uart_port *p)
{
+ struct dw8250_data *d = p-private_data;
unsigned int iir = p-serial_in(p, UART_IIR);
if (serial8250_handle_irq(p, iir)) {
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 0/3] [3.14][dev] meta: Add .scc file for tunnelcreek SoC
For the series: ACKED-BY: Nitin A Kamble nitin.a.kam...@intel.com -Original Message- From: linux-yocto-boun...@yoctoproject.org [mailto:linux-yocto- boun...@yoctoproject.org] On Behalf Of Max Eliaser Sent: Wednesday, September 03, 2014 1:48 PM To: linux-yocto@yoctoproject.org Subject: [linux-yocto] [PATCH 0/3] [3.14][dev] meta: Add .scc file for tunnelcreek SoC Hello list, This series adds a .scc file for the tunnelcreek SoC, similar to the existing baytrail one. The scc file is also included by default in intel-core2-32. This also has the effect of adding the GMA500 DRM driver to intel-core2-32. This, in turn, breaks intel-core2-32 on the FRI2. While the series includes a patch to build the driver as a kernel module, the actual work of blacklisting the gma500_gfx driver on FRI2 has not been done. This series closes bug 6619. [1] This is for the meta branch of linux-yocto 3.14. Regards, -Max Eliaser [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=6619 The following changes since commit 8f553f77e0ad3c9c200d3ecc4ffb59bccc56997a: meta: Create kernel config and scc for CRIU (2014-08-28 15:23:21 -0400) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-contrib meliaser/3.14-meta- tunnelcreek-scc http://git.yoctoproject.org/cgit.cgi/linux-yocto- contrib/log/?h=meliaser/3.14-meta-tunnelcreek-scc Max Eliaser (3): soc: tunnelcreek: create tunnelcreek scc intel-common: intel-core-32: use tunnelcreek.scc drm-gma500: build GMA500 DRM driver as kernel module .../kernel-cache/bsp/intel-common/intel-core2-32.scc | 4 +--- .../kernel- cache/features/drm-gma500/drm-gma500.cfg | 2 +- .../features/soc/tunnelcreek/tunnelcreek.scc | 20 3 files changed, 22 insertions(+), 4 deletions(-) create mode 100644 meta/cfg/kernel-cache/features/soc/tunnelcreek/tunnelcreek.scc -- 1.8.3.2 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 00/28][3.10] Baytrail LPSS I/O feature backport
-Original Message- From: linux-yocto-boun...@yoctoproject.org [mailto:linux-yocto- boun...@yoctoproject.org] On Behalf Of rebecca.swee.fun.ch...@intel.com Sent: Thursday, August 28, 2014 3:52 AM To: linux-yocto@yoctoproject.org Subject: [linux-yocto] [PATCH 00/28][3.10] Baytrail LPSS I/O feature backport From: Chang Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com Hi all, Here is a series of patches that I've cherry-picked from mainline kernel into linux-yocto-3.10. These patches are Baytrail PCI mode LPSS I/O features. The patches consists of PWM, DMA, UART, USB device mode, I2C, and SPI device drivers. These patches was in valleyisland-io-1.0 currently. I will then rebase the valleyisland-io feature branch to reduce the maintenance effort in feature branch. Hi Rebecca, Will the older commit keep working after your rebase? If not, then you may want to create a new feature branch. Nitin To help you in review process, one of the patch is actually pending to mainline and it is now queuing in linux-next git repo. The patch that I mentioned is: e4f08d7 spi/pxa2xx-pci: Add common clock framework support in PCI glue layer while the other patches are confirmed picked from mainline. This series of patches had been built and tested on Bakersports, and MinnowBoard MAX. Please review the series of patches and merge them into linux-yocto-3.10 standard/base branch for feature enabling purposes. Thanks in advance Rebecca The following changes since commit aa677a2d02677ec92d59a8c36d001cf2f5cf3260: usb/core: fix merge issue (2014-06-16 12:24:47 -0400) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-contrib rebeccas/baytrail-backport- features http://git.yoctoproject.org/cgit.cgi/linux-yocto- contrib/log/?h=rebeccas/baytrail-backport-features Adrian Hunter (1): mmc: sdhci: Allow for irq being shared Alan Cox (1): pwm: lpss: Add support for PCI devices Alan Stern (1): usb: gadget: don't fail when DMA isn't present Andy Shevchenko (2): dmaengine: dw: introduce dwc_dostart_first_queued() helper dmaengine: dw: don't perform DMA when dmaengine_submit is called Antonio Ospite (1): spi/pxa2xx: fix runtime PM enabling order Chew, Chiau Ee (8): ACPI / LPSS: Add Intel BayTrail ACPI mode PWM dma: dw: Add suspend and resume handling for PCI mode DW_DMAC. i2c: designware-pci: add 10-bit addressing mode functionality for BYT I2C i2c: designware-pci: set ideal HCNT, LCNT and SDA hold time value spi/pxa2xx-pci: Add PCI mode support for BayTrail LPSS SPI spi/pxa2xx: change default supported DMA burst size to 1 spi/pxa2xx: fix incorrect SW mode chipselect setting for BayTrail LPSS SPI spi/pxa2xx-pci: Add common clock framework support in PCI glue layer Felipe Balbi (1): usb: gadget: udc-core: move sysfs_notify() to a workqueue H Hartley Sweeten (1): pwm: Add sysfs interface Heikki Krogerus (3): serial: 8250_dma: check the result of TX buffer mapping serial: 8250: don't change the fifo trigger level when using dma serial: 8250_pci: add support for Intel BayTrail Jingoo Han (2): spi: remove DEFINE_PCI_DEVICE_TABLE macro spi: pxa2xx: remove unnecessary OOM messages Loic Poulain (1): 8250_dw: Support all baudrates on baytrail Maurice Petallo (2): mmc: sdhci: Preset value not supported in Baytrail eMMC mmc: sdhci: add DDR50 1.8V mode support for BayTrail eMMC Controller Mika Westerberg (3): pwm: add support for Intel Low Power Subsystem PWM i2c: designware-pci: Add Baytrail PCI IDs spi/pxa2xx: Prevent DMA from transferring too many bytes Thierry Reding (1): pwm: lpss: Fix const qualifier and sparse warnings Documentation/ABI/testing/sysfs-class-pwm | 79 +++ Documentation/pwm.txt | 37 +++ drivers/acpi/acpi_lpss.c | 11 + drivers/dma/TODO | 1 - drivers/dma/dw/core.c | 38 ++-- drivers/dma/dw/pci.c | 33 +++ drivers/i2c/busses/i2c-designware-pcidrv.c | 66 +- drivers/mmc/host/sdhci-acpi.c | 4 +- drivers/mmc/host/sdhci-pci.c | 3 +- drivers/mmc/host/sdhci.c | 4 +- drivers/pwm/Kconfig| 14 ++ drivers/pwm/Makefile | 2 + drivers/pwm/core.c | 25 +- drivers/pwm/pwm-lpss.c | 282 +++ drivers/pwm/sysfs.c| 352 + drivers/spi/Kconfig| 2 +- drivers/spi/spi-dw-pci.c | 2 +- drivers/spi/spi-pxa2xx-dma.c | 18 +- drivers/spi/spi-pxa2xx-pci.c | 97 ++-- drivers/spi/spi-pxa2xx.c | 28 ++- drivers/spi/spi-topcliff-pch.c | 2 +-
Re: [linux-yocto] [PATCH 0/1] meta: update valleyisland scc to merge new feature branch
Hi Rebecca, As this will be changing the kernel version as well. This change brings in the risk of further delay for the valleyland BSP with the meta-intel 1.6.1 release. How much validation have you done with this change? As some components from SDK image are sensitive to the kernel version. Validation of the sdk image is minimum for pushing this in. Nitin -Original Message- From: linux-yocto-boun...@yoctoproject.org [mailto:linux-yocto- boun...@yoctoproject.org] On Behalf Of rebecca.swee.fun.ch...@intel.com Sent: Tuesday, June 17, 2014 9:55 PM To: linux-yocto@yoctoproject.org Subject: [linux-yocto] [PATCH 0/1] meta: update valleyisland scc to merge new feature branch From: Chang Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com Hi all, Valley Island I/O feature branch was recently rebased to new version and I would like to push this patch into meta branch so that we can merge the new feature branch with standard/base. This patch is about updating the scc file of Valley Island BSP to merge valleyisland-io-2.0 instead of valleyisland-io-1.0. Please help to merge into linux-yocto-3.10 meta branch. Hope that this will be merge in soon so that I could update the meta branch SRCREV in kernel recipe under meta-intel. After the update for meta-intel are all in place, I will inform Bruce again to remove the old feature branch. Thanks in advance. Regards Rebecca The following changes since commit 199943142f7e0a283240246ee6c02f4376b315f0: meta: bump kver to v3.10.43 (2014-06-16 00:34:31 -0400) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-contrib rebeccas/meta-dev http://git.yoctoproject.org/cgit.cgi/linux-yocto- contrib/log/?h=rebeccas/meta-dev Chang Rebecca Swee Fun (1): meta: update valleyisland scc to merge feature branch meta/cfg/kernel-cache/features/valleyisland-io/valleyisland-io-pci.scc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.9.1 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] Back-porting a new driver to Yocto kernel(s)..and device firmware
On 6/18/2014 4:24 PM, Allan, Bruce W wrote: We have a new hardware crypto device driver currently out for RFC on the linux-crypto mailing list and would like to back-port it to the Yocto Linux kernels once it is committed upstream. What is the process for getting it into the current dev kernel as well as linux-yocto-3.10 and linux-yocto-3.14? I’ve already done the back-port to the three Yocto Linux kernels and found that just 1 or 2 (depending on the kernel) other patches would also be needed. Is back-porting these patches also allowed as long as they do no harm to anything else? Hi Bruce, The right way is to push these backported patches in the respective stable kernel trees. If that is not working, then the patches can be pushed in the linux-yocto kernel repositories as features. The device also requires a firmware component which has already been committed to the upstream linux-firmware repository. How does this get into Yocto? Then there may not be any thing done for the linux-firmware, as we always try to be up to date with upstream. If you need automatic loading of some modules, then you nay need to add configuration for that to BSPs. Which hardware is this feature for? Possibly we already has a BSP for that hardware, otherwise a new BSP can be created. Nitin Thanks, Bruce Allan. -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 5/5] mei.cfg: configure Intel MEI driver as module
On 5/16/2014 6:58 AM, Ong, Boon Leong wrote: --- a/meta/cfg/kernel-cache/features/amt/mei/mei.cfg +++ b/meta/cfg/kernel-cache/features/amt/mei/mei.cfg @@ -1,4 +1,4 @@ CONFIG_STAGING=y CONFIG_WATCHDOG_CORE=y CONFIG_INTEL_MEI=y The CONFIG_INTEL_MEI also need to be converted to module. I realize that there is no CONFIG_INTEL_MEI_TXE which is meant for BayTrail. mei.scc is added in meta-intel/common/recipes-kernel/linux/linux-yocto_3.10.bbappend with comment for NUC valleyisland. So, I think this is a miss for Baytrail case. I notice that the feature CONFIG_INTEL_MEI_TXE is not in the standard/base branch, so it should not be enabledin a common way. And need to be enabled only with the patches which enable this functionality. Nitin Ya, agree that we should make all of the following configs as module. CONFIG_INTEL_MEI=m CONFIG_INTEL_MEI_ME=m CONFIG_INTEL_MEI_TXE=m I am curious why etc/modprobe.d/blacklist is needed if these are kernel module and the user should have the wisdom to know whether its Romley platform has the correct ME firmware or not. Adding the blacklist will reject any Romley platform with correct ME firmware to load the kernel altogether. + -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 0/5] [linux-yocto-3.10] Update meta for Romley platform configuration
On 5/15/2014 12:22 PM, wei.sern.c...@intel.com wrote: From: Chan Wei Sern wei.sern.c...@intel.com Hi All, This is a patch series targetting linux-yocto-3.10:meta branch. This is a patch series that consist of below: 1. Removed using of common-pc-64.scc from romley. 2. Start using ktypes/standard/standard.scc for romley platforms to align with YP1.6 Intel common kernel. 3. Add back RTC configuration for romley after changing from common-pc-64.scc to standard.scc. 4. Add back USB HID configuration for romley after changing from common-pc-64.scc to standard.scc. 5. Due to not all platform's BIOS comes ready with AMT/MEI firmware. So will change The issue here is not of missing firmware, but of broken MEI firmware on the target. It is actually a hardware/fimware issue which we are trying to deal with in the OS. CONFIG_INTEL_MEI_ME from built-in driver to as module driver. This will then make possible for appending this driver on /etc/modprobe.d/blacklist to allow Romley to reboot without issue. ( Will place a note on the README to mention that user has to append on /etc/modprobe.d/blacklist to make the reboot happened ). This need be done in a custon recipe for the BSP, instead of mentioning in the README. For this patch series, I have done below:- 1. Build smoothly and boot test on romley. 2. Boot test on Romley via USB drive and SATA. 3. Confirm all the IO drivers are loaded propperly. 4. Confirm reboot issue is solved. Did just converting to modules solved the issue? Or blacklisting of the MEI module was also needed? Thanks, Nitin Thanks. Regards, Chan Wei Sern The following changes since commit d07bc7ba4ff00ddcd77db1026a63c327b81a35d8: meta: crystalforest: included USB HID configuration (2014-05-12 16:47:35 -0400) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-contrib wchan9/romley-common-meta http://git.yoctoproject.org/cgit.cgi/linux-yocto-contrib/log/?h=wchan9/romley-common-meta Sreeju Selvaraj (4): meta: romley: removed using of common-pc-64.scc meta: romley: added power management meta: romley: included USB HID Configuration meta: romley: included RTC configuration Sreeju Slevaraj (1): mei.cfg: configure Intel MEI driver as module meta/cfg/kernel-cache/bsp/romley/romley-preempt-rt.scc |1 - meta/cfg/kernel-cache/bsp/romley/romley-standard.scc |3 +-- meta/cfg/kernel-cache/bsp/romley/romley.cfg|4 meta/cfg/kernel-cache/bsp/romley/romley.scc|3 +++ meta/cfg/kernel-cache/features/amt/mei/mei.cfg |2 +- 5 files changed, 9 insertions(+), 4 deletions(-) -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 1/5] meta: romley: removed using of common-pc-64.scc
On 5/15/2014 12:22 PM, wei.sern.c...@intel.com wrote: From: Sreeju Selvaraj sreeju.armughanx.selva...@intel.com Removed using of bsp/common-pc-64/common-pc-64.scc from romley-preempt-rt.scc and romley-standard.scc Added ktypes/standard/standard.scc for romley-standard.scc This is because we are migrating the BSP to use intel-common. Signed-off-by: Sreeju Selvaraj sreeju.armughanx.selva...@intel.com Signed-off-by: Chan Wei Sern wei.sern.c...@intel.com Acked-By: Nitin A Kamble nitin.a.kam...@intel.com --- meta/cfg/kernel-cache/bsp/romley/romley-preempt-rt.scc |1 - meta/cfg/kernel-cache/bsp/romley/romley-standard.scc |3 +-- 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/meta/cfg/kernel-cache/bsp/romley/romley-preempt-rt.scc b/meta/cfg/kernel-cache/bsp/romley/romley-preempt-rt.scc index 1ecdbbc..ad0a5e7 100644 --- a/meta/cfg/kernel-cache/bsp/romley/romley-preempt-rt.scc +++ b/meta/cfg/kernel-cache/bsp/romley/romley-preempt-rt.scc @@ -4,7 +4,6 @@ define KARCH x86_64 # no new branch required, re-use the ktypes/preempt-rt/preempt-rt.scc branch include ktypes/preempt-rt/preempt-rt.scc -include bsp/common-pc-64/common-pc-64.scc include romley.scc # default policy for preempt-rt kernels diff --git a/meta/cfg/kernel-cache/bsp/romley/romley-standard.scc b/meta/cfg/kernel-cache/bsp/romley/romley-standard.scc index 113ac8c..fcf4a99 100644 --- a/meta/cfg/kernel-cache/bsp/romley/romley-standard.scc +++ b/meta/cfg/kernel-cache/bsp/romley/romley-standard.scc @@ -2,7 +2,6 @@ define KMACHINE romley define KTYPE standard define KARCH x86_64 -include bsp/common-pc-64/common-pc-64-standard.scc -branch romley +include ktypes/standard/standard.scc include romley.scc -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 2/5] meta: romley: added power management
On 5/15/2014 12:22 PM, wei.sern.c...@intel.com wrote: From: Sreeju Selvaraj sreeju.armughanx.selva...@intel.com Since migrating this BSP to use intel-common, we need to add configuration required for power management Signed-off-by: Sreeju Selvaraj sreeju.armughanx.selva...@intel.com Signed-off-by: Chan Wei Sern wei.sern.c...@intel.com Acked-By: Nitin A Kamble nitin.a.kam...@intel.com --- meta/cfg/kernel-cache/bsp/romley/romley.scc |2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/cfg/kernel-cache/bsp/romley/romley.scc b/meta/cfg/kernel-cache/bsp/romley/romley.scc index c4d1c4f..9967407 100644 --- a/meta/cfg/kernel-cache/bsp/romley/romley.scc +++ b/meta/cfg/kernel-cache/bsp/romley/romley.scc @@ -8,6 +8,8 @@ include features/hugetlb/hugetlb.scc include features/ixgbe/ixgbe.scc include features/igb/igb.scc +# generic power management +include features/power/intel.scc include features/latencytop/latencytop.scc include features/profiling/profiling.scc -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 4/5] meta: romley: included RTC configuration
On 5/15/2014 12:22 PM, wei.sern.c...@intel.com wrote: From: Sreeju Selvaraj sreeju.armughanx.selva...@intel.com Since migrating this BSP to use intel-common, we need to add RTC configuration to enable real time clock. Signed-off-by: Sreeju Selvaraj sreeju.armughanx.selva...@intel.com Signed-off-by: Chan Wei Sern wei.sern.c...@intel.com Acked-By: Nitin A Kamble nitin.a.kam...@intel.com --- meta/cfg/kernel-cache/bsp/romley/romley.scc |1 + 1 file changed, 1 insertion(+) diff --git a/meta/cfg/kernel-cache/bsp/romley/romley.scc b/meta/cfg/kernel-cache/bsp/romley/romley.scc index 9967407..3020fd8 100644 --- a/meta/cfg/kernel-cache/bsp/romley/romley.scc +++ b/meta/cfg/kernel-cache/bsp/romley/romley.scc @@ -11,6 +11,7 @@ include features/igb/igb.scc # generic power management include features/power/intel.scc +include cfg/timer/rtc.scc include features/latencytop/latencytop.scc include features/profiling/profiling.scc -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 3/5] meta: romley: included USB HID Configuration
On 5/15/2014 12:22 PM, wei.sern.c...@intel.com wrote: From: Sreeju Selvaraj sreeju.armughanx.selva...@intel.com Since migrating this BSP to use intel-common, we need to add the configuration required to enable USB HID Signed-off-by: Sreeju Selvaraj sreeju.armughanx.selva...@intel.com Signed-off-by: Chan Wei Sern wei.sern.c...@intel.com Acked-By: Nitin A Kamble nitin.a.kam...@intel.com --- meta/cfg/kernel-cache/bsp/romley/romley.cfg |4 1 file changed, 4 insertions(+) diff --git a/meta/cfg/kernel-cache/bsp/romley/romley.cfg b/meta/cfg/kernel-cache/bsp/romley/romley.cfg index 28f6d71..3b5a7b9 100644 --- a/meta/cfg/kernel-cache/bsp/romley/romley.cfg +++ b/meta/cfg/kernel-cache/bsp/romley/romley.cfg @@ -59,3 +59,7 @@ CONFIG_BLK_DEV_INITRD=y CONFIG_RD_GZIP=y CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ISO8859_1=y + +# USB HID Support +CONFIG_USB_HID=y +CONFIG_USB_HIDDEV=y -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 5/5] mei.cfg: configure Intel MEI driver as module
On 5/15/2014 12:22 PM, wei.sern.c...@intel.com wrote: From: Sreeju Slevaraj sreeju.armughanx.selva...@intel.com Changing the flag of this CONFIG_INTEL_MEI_ME from built-in to as module driver. As not all BIOS comes ready with AMT/MEI firmware. Signed-off-by: Sreeju Slevaraj sreeju.armughanx.selva...@intel.com Signed-off-by: Chan Wei Sern wei.sern.c...@intel.com --- meta/cfg/kernel-cache/features/amt/mei/mei.cfg |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/cfg/kernel-cache/features/amt/mei/mei.cfg b/meta/cfg/kernel-cache/features/amt/mei/mei.cfg index 313084b..3088128 100644 --- a/meta/cfg/kernel-cache/features/amt/mei/mei.cfg +++ b/meta/cfg/kernel-cache/features/amt/mei/mei.cfg @@ -1,4 +1,4 @@ CONFIG_STAGING=y CONFIG_WATCHDOG_CORE=y CONFIG_INTEL_MEI=y The CONFIG_INTEL_MEI also need to be converted to module. Thanks, Nitin -CONFIG_INTEL_MEI_ME=y +CONFIG_INTEL_MEI_ME=m -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] pruning of unused branches from linux-yocto-3.14 kernel repository
Hi Bruce, As most of the BSPs from meta-intel layer are using the standard/base for KBRANCH, these kernel branches from the linux-yocto-3.14 repository are not needed anymore, and can be deleted to reduce the branch count. Darren, Tom, Do you see any of these branches used anywhere else? standard/common-pc-64/chiefriver standard/common-pc-64/crystalforest standard/common-pc-64/jasperforest standard/common-pc-64/mohonpeak standard/common-pc-64/rangeley standard/common-pc-64/romley standard/common-pc-64/sugarbay standard/common-pc/atom-pc standard/crownbay standard/emenlow standard/fri2 standard/preempt-rt/base standard/sys940x standard/tiny/fri2 Bruce, If there is no objection you can proceed with deleting of these branches from the L-Y v3.14 kernel repository. Thanks, Nitin -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] pruning of unused branches from linux-yocto-3.14 kernel repository
On 5/13/2014 2:54 PM, Bruce Ashfield wrote: On 14-05-13 01:06 PM, Kamble, Nitin A wrote: Hi Bruce, As most of the BSPs from meta-intel layer are using the standard/base for KBRANCH, these kernel branches from the linux-yocto-3.14 repository are not needed anymore, and can be deleted to reduce the branch count. I'll delete the old intel BSP branches, but as I just replied, -rt/base will stay. Bruce Thanks Bruce, Nitin Darren, Tom, Do you see any of these branches used anywhere else? standard/common-pc-64/chiefriver standard/common-pc-64/crystalforest standard/common-pc-64/jasperforest standard/common-pc-64/mohonpeak standard/common-pc-64/rangeley standard/common-pc-64/romley standard/common-pc-64/sugarbay standard/common-pc/atom-pc standard/crownbay standard/emenlow standard/fri2 standard/preempt-rt/base standard/sys940x standard/tiny/fri2 Bruce, If there is no objection you can proceed with deleting of these branches from the L-Y v3.14 kernel repository. Thanks, Nitin -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 0/5] Update meta branch for meta-ISGs platforms configuration
On 5/12/2014 3:20 PM, wei.sern.c...@intel.com wrote: From: Chan Wei Sern wei.sern.c...@intel.com Hi All, This is a patch series that consist of below: 1. Removed using of common-pc-64.scc from haswell-wc,crystalforest and mohonpeak. 2. Start using ktypes/standard/standard.scc for meta-ISG platforms. 3. Add back RTC configuration for crystalforest after changing from common-pc-64.scc to standard.scc. 4. Add back USB HID configuration for crystalforest after changing from common-pc-64.scc to standard.scc. All the commits in this pull requests are well contained, and should not affect other BSPs. Still the common kernel may get affected, and other BSPs using the common kernel need to validated these changes. Wei Sern, Have you done any validation with other BSPs using the same kernel? Nitin Please help to pull this patch into linux-yocto-3.10:meta branch. Thanks. Regards, Chan Wei Sern The following changes since commit 617c6158c3d5b931f0d6131e0b0a7b374c792599: mei.cfg: enable Intel chipsets (2014-05-05 09:46:42 -0400) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-contrib wchan9/intel-common-meta http://git.yoctoproject.org/cgit.cgi/linux-yocto-contrib/log/?h=wchan9/intel-common-meta Chan Wei Sern (2): meta: haswell-wc: removed using of common-pc-64.scc meta: mohonpeak: removed using of common-pc-64.scc Sreeju Slevaraj (3): meta: crystalforest: removed using of common-pc-64.scc meta: crystalforest: included RTC configuration meta: crystalforest: included USB HID configuration .../cfg/kernel-cache/bsp/crystalforest/crystalforest-preempt-rt.scc |1 - meta/cfg/kernel-cache/bsp/crystalforest/crystalforest-standard.scc |3 +-- meta/cfg/kernel-cache/bsp/crystalforest/crystalforest.cfg |3 +++ meta/cfg/kernel-cache/bsp/crystalforest/crystalforest.scc |2 ++ meta/cfg/kernel-cache/bsp/haswell-wc/haswell-wc-preempt-rt.scc |2 +- meta/cfg/kernel-cache/bsp/haswell-wc/haswell-wc-standard.scc|2 +- meta/cfg/kernel-cache/bsp/mohonpeak/mohonpeak-preempt-rt.scc|1 - 7 files changed, 8 insertions(+), 6 deletions(-) -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 0/5] Update meta branch for meta-ISGs platforms configuration
On 5/12/2014 9:05 AM, Kamble, Nitin A wrote: On 5/12/2014 3:20 PM, wei.sern.c...@intel.com wrote: From: Chan Wei Sern wei.sern.c...@intel.com Hi All, This is a patch series that consist of below: 1. Removed using of common-pc-64.scc from haswell-wc,crystalforest and mohonpeak. 2. Start using ktypes/standard/standard.scc for meta-ISG platforms. 3. Add back RTC configuration for crystalforest after changing from common-pc-64.scc to standard.scc. 4. Add back USB HID configuration for crystalforest after changing from common-pc-64.scc to standard.scc. All the commits in this pull requests are well contained, and should not affect other BSPs. Still the common kernel may get affected, and other BSPs using the common kernel need to validated these changes. Wei Sern, Have you done any validation with other BSPs using the same kernel? The somewhat disruption changes here are for v3.10 kernel for intel-corei7-64 BSP, and we do not have any 64 bit non-ISG BSP in meta-intel using the v3.10 kernel as default. so I am not much nervous about these changes to common kernel now. For all the commits from the pull request: Acked-By: Nitin A Kamble nitin.a.kam...@intel.com Chan, Can you mention the kernel repository version in the pull request next time? This time, it was not clear weather these commits were for v3.10 kernel repo or v3.14 kernel repo. Thanks, Nitin Nitin Please help to pull this patch into linux-yocto-3.10:meta branch. Thanks. Regards, Chan Wei Sern The following changes since commit 617c6158c3d5b931f0d6131e0b0a7b374c792599: mei.cfg: enable Intel chipsets (2014-05-05 09:46:42 -0400) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-contrib wchan9/intel-common-meta http://git.yoctoproject.org/cgit.cgi/linux-yocto-contrib/log/?h=wchan9/intel-common-meta Chan Wei Sern (2): meta: haswell-wc: removed using of common-pc-64.scc meta: mohonpeak: removed using of common-pc-64.scc Sreeju Slevaraj (3): meta: crystalforest: removed using of common-pc-64.scc meta: crystalforest: included RTC configuration meta: crystalforest: included USB HID configuration .../cfg/kernel-cache/bsp/crystalforest/crystalforest-preempt-rt.scc |1 - meta/cfg/kernel-cache/bsp/crystalforest/crystalforest-standard.scc |3 +-- meta/cfg/kernel-cache/bsp/crystalforest/crystalforest.cfg |3 +++ meta/cfg/kernel-cache/bsp/crystalforest/crystalforest.scc |2 ++ meta/cfg/kernel-cache/bsp/haswell-wc/haswell-wc-preempt-rt.scc |2 +- meta/cfg/kernel-cache/bsp/haswell-wc/haswell-wc-standard.scc |2 +- meta/cfg/kernel-cache/bsp/mohonpeak/mohonpeak-preempt-rt.scc |1 - 7 files changed, 8 insertions(+), 6 deletions(-) -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 1/1] meta: enable USB features for Mohonpeak
On 5/9/2014 5:09 AM, rebecca.swee.fun.ch...@intel.com wrote: From: Chang Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com Added USB host controller driver support for Mohonpeak. This also enable live bootable image to be able to boot through USB devices. Signed-off-by: Chang Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com Acked-By: Nitin A Kamble nitin.a.kam...@intel.com Hi Bruce, If you can pull this in fast, this can be part of the 1.6 meta-intel release. Thanks, Nitin --- meta/cfg/kernel-cache/bsp/mohonpeak/mohonpeak.scc | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/meta/cfg/kernel-cache/bsp/mohonpeak/mohonpeak.scc b/meta/cfg/kernel-cache/bsp/mohonpeak/mohonpeak.scc index a4b6d83..dff0a89 100644 --- a/meta/cfg/kernel-cache/bsp/mohonpeak/mohonpeak.scc +++ b/meta/cfg/kernel-cache/bsp/mohonpeak/mohonpeak.scc @@ -7,10 +7,15 @@ include features/power/intel.scc include features/ixgbe/ixgbe.scc include features/igb/igb.scc -# required for Intel DPDK Support +include features/usb/ehci-hcd.scc +include features/usb/xhci-hcd.scc +include features/usb/uhci-hcd.scc +include features/usb/ohci-hcd.scc + +# These features are required for Intel DPDK Support include features/intel-dpdk/intel-dpdk.scc -#These features are required for Intel QAT Software +# These features are required for Intel QAT Software include features/pci-iov/pci-iov.scc include features/pci/pci.scc include features/ciphers/ciphers.scc @@ -18,8 +23,8 @@ include features/crypto/crypto.scc include cfg/efi.scc -#Add smp support +# Add smp support include cfg/smp.scc -#Enable GCC inlining +# Enable GCC inlining include features/inline/inline.scc -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 1/1] mei.cfg: enable Intel chipsets
-Original Message- From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] Sent: Monday, May 05, 2014 6:38 AM To: Kamble, Nitin A; Hart, Darren; linux-yocto@yoctoproject.org Subject: Re: [PATCH 1/1] mei.cfg: enable Intel chipsets On 14-05-02 08:01 PM, Kamble, Nitin A wrote: On 4/25/2014 8:51 AM, Hart, Darren wrote: On 4/24/14, 18:42, Kamble, Nitin A nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com Enable Intel Chipsets in the AMT/MEI driver. Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com Acked-by: Darren Hart dvh...@linux.intel.com Hi Bruce, Can you pull this fix in the v3.10 kernel repository as well? No problem. I'm doing some -stable updates and will put this on top of them. Thanks Bruce, Let me know when you pull the commit in, I will be firing a build with that. Nitin Cheers, Bruce Thanks, Nitin --- meta/cfg/kernel-cache/features/amt/mei/mei.cfg | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/cfg/kernel-cache/features/amt/mei/mei.cfg b/meta/cfg/kernel-cache/features/amt/mei/mei.cfg index c1c2ace..313084b 100644 --- a/meta/cfg/kernel-cache/features/amt/mei/mei.cfg +++ b/meta/cfg/kernel-cache/features/amt/mei/mei.cfg @@ -1,3 +1,4 @@ CONFIG_STAGING=y CONFIG_WATCHDOG_CORE=y CONFIG_INTEL_MEI=y +CONFIG_INTEL_MEI_ME=y -- 1.8.1.4 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 1/1] mei.cfg: enable Intel chipsets
On 4/25/2014 8:51 AM, Hart, Darren wrote: On 4/24/14, 18:42, Kamble, Nitin A nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com Enable Intel Chipsets in the AMT/MEI driver. Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com Acked-by: Darren Hart dvh...@linux.intel.com Hi Bruce, Can you pull this fix in the v3.10 kernel repository as well? Thanks, Nitin --- meta/cfg/kernel-cache/features/amt/mei/mei.cfg | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/cfg/kernel-cache/features/amt/mei/mei.cfg b/meta/cfg/kernel-cache/features/amt/mei/mei.cfg index c1c2ace..313084b 100644 --- a/meta/cfg/kernel-cache/features/amt/mei/mei.cfg +++ b/meta/cfg/kernel-cache/features/amt/mei/mei.cfg @@ -1,3 +1,4 @@ CONFIG_STAGING=y CONFIG_WATCHDOG_CORE=y CONFIG_INTEL_MEI=y +CONFIG_INTEL_MEI_ME=y -- 1.8.1.4 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 1/1] meta: smp.scc: increase default NR_CPUS to 64
On 4/10/2014 4:20 AM, boon.leong@intel.com wrote: From: Ong Boon Leong boon.leong@intel.com Change CONFIG_NR_CPUS from 8 to 64 so that platform with processors count more than 8 will be all activited. Acked-By: Nitin A Kamble nitin.a.kam...@intel.com Signed-off-by: Ong Boon Leong boon.leong@intel.com --- meta/cfg/kernel-cache/cfg/smp.cfg |3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/cfg/kernel-cache/cfg/smp.cfg b/meta/cfg/kernel-cache/cfg/smp.cfg index f53b969..2204774 100644 --- a/meta/cfg/kernel-cache/cfg/smp.cfg +++ b/meta/cfg/kernel-cache/cfg/smp.cfg @@ -1,2 +1,5 @@ CONFIG_SMP=y CONFIG_SCHED_SMT=y +# Increase default NR_CPUS from 8 to 64 so that platform with +# more than 8 processors can be all activated at boot time +CONFIG_NR_CPUS=64 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 10/29] usb: dwc3: pci: Enable/disable ulpi phy refclk
On 4/7/2014 8:18 AM, rebecca.swee.fun.ch...@intel.com wrote:
From: Maurice Petallo mauricex.r.peta...@intel.com
Due to power saving purpose, BIOS disabled ulpi phy refclk by default.
Hence, the refclk will only be enabled during device/driver probing.
and disabled during driver removal.
If this commit is not already pushed upstream, I would suggest to
improve the wording
of the commit message here. I will replace the commit message with
something like this.
For the purpose of saving power, BIOS has disabled ulpi phy refclk by
default.
Hence, for the conservation of power, the refclk is enabled only at
the time of
device/driver probing, and is disabled at the time of of driver removal.
Nitin
Signed-off-by: Maurice Petallo mauricex.r.peta...@intel.com
Signed-off-by: Chew, Chiau Ee chiau.ee.c...@intel.com
---
drivers/usb/dwc3/dwc3-pci.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 2357c4e..4ebe49a 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -51,6 +51,10 @@
#define PCI_DEVICE_ID_INTEL_BYT 0x0f37
#define PCI_DEVICE_ID_INTEL_MRFLD 0x119e
+#define DWC3_PCI_GEN_REGRW1 0xa0
+#define DWC3_PCI_GEN_REGRW1_REFCLK_EN(n) (n 0xfffd)
+#define DWC3_PCI_GEN_REGRW1_REFCLK_DIS(n) (n | 0x02)
+
struct dwc3_pci {
struct device *dev;
struct platform_device *dwc3;
@@ -112,6 +116,19 @@ err1:
return ret;
}
+static void dwc3_pci_ulpiphy_refclk(struct pci_dev *pci, int enable)
+{
+ u32 val;
+
+ pci_read_config_dword(pci, DWC3_PCI_GEN_REGRW1, val);
+ if (enable)
+ val = DWC3_PCI_GEN_REGRW1_REFCLK_EN(val);
+ else
+ val = DWC3_PCI_GEN_REGRW1_REFCLK_DIS(val);
+
+ pci_write_config_dword(pci, DWC3_PCI_GEN_REGRW1, val);
+}
+
static int dwc3_pci_probe(struct pci_dev *pci,
const struct pci_device_id *id)
{
@@ -183,6 +200,9 @@ static int dwc3_pci_probe(struct pci_dev *pci,
goto err3;
}
+ /* enable ulpi phy refclk */
+ dwc3_pci_ulpiphy_refclk(pci, 1);
+
return 0;
err3:
@@ -198,6 +218,9 @@ static void dwc3_pci_remove(struct pci_dev *pci)
{
struct dwc3_pci *glue = pci_get_drvdata(pci);
+ /* disable ulpi phy refclk */
+ dwc3_pci_ulpiphy_refclk(pci, 0);
+
platform_device_unregister(glue-dwc3);
platform_device_unregister(glue-usb2_phy);
platform_device_unregister(glue-usb3_phy);
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 13/29] i2c: designware-pcidrv: Option to set custom HCNT, LCNT and SDA value
On 4/7/2014 8:18 AM, rebecca.swee.fun.ch...@intel.com wrote:
From: Chew, Chiau Ee chiau.ee.c...@intel.com
Provide option to set the HCNT, LCNT and SDA if the target values are known
ahead. Instead of depends on formula to calculate the HCNT and LCNT.
If it is not already pushed upstream, I will reword this commit message too.
I will reword it to something like this:
Provide options to set the HCNT, LCNT and SDA values, if the target
values are known
ahead of time. This will make the boot process more efficient by
avoiding calculation
of the HCNT and LCNT values at runtime.
Nitin
Signed-off-by: Chew, Chiau Ee chiau.ee.c...@intel.com
Signed-off-by: Maurice Petallo mauricex.r.peta...@intel.com
---
drivers/i2c/busses/i2c-designware-pcidrv.c | 55
1 file changed, 55 insertions(+)
diff --git a/drivers/i2c/busses/i2c-designware-pcidrv.c
b/drivers/i2c/busses/i2c-designware-pcidrv.c
index 3599a6b..4f4398f 100644
--- a/drivers/i2c/busses/i2c-designware-pcidrv.c
+++ b/drivers/i2c/busses/i2c-designware-pcidrv.c
@@ -70,6 +70,12 @@ struct dw_pci_controller {
u32 tx_fifo_depth;
u32 rx_fifo_depth;
u32 clk_khz;
+ u32 ss_hcnt;
+ u32 ss_lcnt;
+ u32 fs_hcnt;
+ u32 fs_lcnt;
+ u32 ss_sda;
+ u32 fs_sda;
};
#define INTEL_MID_STD_CFG (DW_IC_CON_MASTER | \
@@ -150,6 +156,12 @@ static struct dw_pci_controller dw_pci_controllers[] = {
.tx_fifo_depth = 32,
.rx_fifo_depth = 32,
.clk_khz = 10,
+ .ss_hcnt= 0x200,
+ .ss_lcnt= 0x200,
+ .fs_hcnt= 0x55,
+ .fs_lcnt= 0x99,
+ .ss_sda = 0x6,
+ .fs_sda = 0x6,
},
[byt_1] = {
.bus_num = 1,
@@ -157,6 +169,12 @@ static struct dw_pci_controller dw_pci_controllers[] = {
.tx_fifo_depth = 32,
.rx_fifo_depth = 32,
.clk_khz = 10,
+ .ss_hcnt= 0x200,
+ .ss_lcnt= 0x200,
+ .fs_hcnt= 0x55,
+ .fs_lcnt= 0x99,
+ .ss_sda = 0x6,
+ .fs_sda = 0x6,
},
[byt_2] = {
.bus_num = 2,
@@ -164,6 +182,12 @@ static struct dw_pci_controller dw_pci_controllers[] = {
.tx_fifo_depth = 32,
.rx_fifo_depth = 32,
.clk_khz = 10,
+ .ss_hcnt= 0x200,
+ .ss_lcnt= 0x200,
+ .fs_hcnt= 0x55,
+ .fs_lcnt= 0x99,
+ .ss_sda = 0x6,
+ .fs_sda = 0x6,
},
[byt_3] = {
.bus_num = 3,
@@ -171,6 +195,12 @@ static struct dw_pci_controller dw_pci_controllers[] = {
.tx_fifo_depth = 32,
.rx_fifo_depth = 32,
.clk_khz = 10,
+ .ss_hcnt= 0x200,
+ .ss_lcnt= 0x200,
+ .fs_hcnt= 0x55,
+ .fs_lcnt= 0x99,
+ .ss_sda = 0x6,
+ .fs_sda = 0x6,
},
[byt_4] = {
.bus_num = 4,
@@ -178,6 +208,12 @@ static struct dw_pci_controller dw_pci_controllers[] = {
.tx_fifo_depth = 32,
.rx_fifo_depth = 32,
.clk_khz = 10,
+ .ss_hcnt= 0x200,
+ .ss_lcnt= 0x200,
+ .fs_hcnt= 0x55,
+ .fs_lcnt= 0x99,
+ .ss_sda = 0x6,
+ .fs_sda = 0x6,
},
[byt_5] = {
.bus_num = 5,
@@ -185,6 +221,12 @@ static struct dw_pci_controller dw_pci_controllers[] = {
.tx_fifo_depth = 32,
.rx_fifo_depth = 32,
.clk_khz = 10,
+ .ss_hcnt= 0x200,
+ .ss_lcnt= 0x200,
+ .fs_hcnt= 0x55,
+ .fs_lcnt= 0x99,
+ .ss_sda = 0x6,
+ .fs_sda = 0x6,
},
[byt_6] = {
.bus_num = 6,
@@ -192,6 +234,12 @@ static struct dw_pci_controller dw_pci_controllers[] = {
.tx_fifo_depth = 32,
.rx_fifo_depth = 32,
.clk_khz = 10,
+ .ss_hcnt= 0x200,
+ .ss_lcnt= 0x200,
+ .fs_hcnt= 0x55,
+ .fs_lcnt= 0x99,
+ .ss_sda = 0x6,
+ .fs_sda = 0x6,
},
};
static struct i2c_algorithm i2c_dw_algo = {
@@ -315,7 +363,14 @@ static int i2c_dw_pci_probe(struct pci_dev *pdev,
I2C_FUNC_SMBUS_BYTE_DATA |
Re: [linux-yocto] [PATCH 14/29] spi/pxa2xx-pci: Add support for Intel BYT SPI
On 4/7/2014 8:18 AM, rebecca.swee.fun.ch...@intel.com wrote:
From: Chew, Chiau Ee chiau.ee.c...@intel.com
The pxa2xx pci glue layer only support CE4100 SPI port
by default. To add BYT SPI port support, we make it a
generic PCI glue layer by renaming ce4100_xxx to
pxa2xx_spi_xxx.
This commit is created in reference to Mika's commit
during kernel-3.5 development, as below:
spi/pxa2xx-pci: convert to use pxa2xx-spi core
spi/pxa2xx-pci: add support for different PCI port types
spi/pxa2xx-pci: add support for ValleyView2 SPI
For upstreaming keeping commits small and concise helps a lot.
As a suggestion, for the upstreaming effort this commit can be broken
down into these 3 separate commits again.
Nitin
Signed-off-by: Chew, Chiau Ee chiau.ee.c...@intel.com
Signed-off-by: Maurice Petallo mauricex.r.peta...@intel.com
---
drivers/spi/Kconfig |5 ++-
drivers/spi/spi-pxa2xx-pci.c | 85 ++
2 files changed, 74 insertions(+), 16 deletions(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 92775c5..f3fecc4 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -337,7 +337,10 @@ config SPI_PXA2XX
additional documentation can be found a Documentation/spi/pxa2xx.
config SPI_PXA2XX_PCI
- def_tristate SPI_PXA2XX PCI
+ tristate PCI glue for PXA2xx SSP SPI master
+ depends on SPI_PXA2XX PCI
+ help
+ This enables using PXA2xx SPI controller via PCI interface.
config SPI_RSPI
tristate Renesas RSPI controller
diff --git a/drivers/spi/spi-pxa2xx-pci.c b/drivers/spi/spi-pxa2xx-pci.c
index 74bc187..974d4fe 100644
--- a/drivers/spi/spi-pxa2xx-pci.c
+++ b/drivers/spi/spi-pxa2xx-pci.c
@@ -7,10 +7,48 @@
#include linux/of_device.h
#include linux/module.h
#include linux/spi/pxa2xx_spi.h
+#include linux/clk.h
-static int ce4100_spi_probe(struct pci_dev *dev,
+enum {
+ PORT_CE4100,
+ PORT_BYT,
+};
+
+struct pxa2xx_spi_pci_config {
+ enum pxa_ssp_type type;
+ int num_cs;
+ int bus_num;
+ int tx_slave_id;
+ int tx_chan_id;
+ int rx_slave_id;
+ int rx_chan_id;
+};
+
+static struct pxa2xx_spi_pci_config spi_pci_configs[] = {
+ [PORT_CE4100] = {
+ .type = PXA25x_SSP,
+ .num_cs = -1,
+ .bus_num = -1,
+ .tx_slave_id = -1,
+ .tx_chan_id = -1,
+ .rx_slave_id = -1,
+ .rx_chan_id = -1,
+ },
+ [PORT_BYT] = {
+ .type = LPSS_SSP,
+ .num_cs = 1,
+ .bus_num = 0,
+ .tx_slave_id = 0,
+ .tx_chan_id = 0,
+ .rx_slave_id = 1,
+ .rx_chan_id = 1,
+ },
+};
+
+static int pxa2xx_spi_probe(struct pci_dev *dev,
const struct pci_device_id *ent)
{
+ struct pxa2xx_spi_pci_config *c;
struct platform_device_info pi;
int ret;
struct platform_device *pdev;
@@ -25,8 +63,16 @@ static int ce4100_spi_probe(struct pci_dev *dev,
if (ret)
return ret;
+
+ c = spi_pci_configs[ent-driver_data];
+
memset(spi_pdata, 0, sizeof(spi_pdata));
- spi_pdata.num_chipselect = dev-devfn;
+ spi_pdata.num_chipselect = (c-num_cs = 0) ? c-num_cs : dev-devfn;
+ spi_pdata.tx_slave_id = c-tx_slave_id;
+ spi_pdata.tx_chan_id = c-tx_chan_id;
+ spi_pdata.rx_slave_id = c-rx_slave_id;
+ spi_pdata.rx_chan_id = c-rx_chan_id;
+ spi_pdata.enable_dma = c-rx_slave_id = 0 c-tx_slave_id = 0;
ssp = spi_pdata.ssp;
ssp-phys_base = pci_resource_start(dev, 0);
@@ -35,9 +81,15 @@ static int ce4100_spi_probe(struct pci_dev *dev,
dev_err(dev-dev, failed to ioremap() registers\n);
return -EIO;
}
+ ssp-clk = devm_clk_get(dev-dev, NULL);
+ if (IS_ERR(ssp-clk)) {
+ dev_err(dev-dev, failed to get clock\n);
+ return PTR_ERR(ssp-clk);
+ }
+
ssp-irq = dev-irq;
- ssp-port_id = dev-devfn;
- ssp-type = PXA25x_SSP;
+ ssp-port_id = (c-bus_num = 0) ? c-bus_num : dev-devfn;
+ ssp-type = c-type;
memset(pi, 0, sizeof(pi));
pi.parent = dev-dev;
@@ -55,28 +107,31 @@ static int ce4100_spi_probe(struct pci_dev *dev,
return 0;
}
-static void ce4100_spi_remove(struct pci_dev *dev)
+static void pxa2xx_spi_remove(struct pci_dev *dev)
{
struct platform_device *pdev = pci_get_drvdata(dev);
platform_device_unregister(pdev);
}
-static DEFINE_PCI_DEVICE_TABLE(ce4100_spi_devices) = {
- { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x2e6a) },
+static DEFINE_PCI_DEVICE_TABLE(pxa2xx_spi_devices) = {
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x2e6a),
+ .driver_data = PORT_CE4100 },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0f0e),
+ .driver_data = PORT_BYT },
{ },
};
-MODULE_DEVICE_TABLE(pci,
Re: [linux-yocto] [PATCH 15/29] spi/pxa2xx: Fix BYT ACPI mode SPI DMA transfer failure at low speeds
On 4/7/2014 8:18 AM, rebecca.swee.fun.ch...@intel.com wrote: From: Chew, Chiau Ee chiau.ee.c...@intel.com BYT ACPI mode SPI not read/writing correctly at low speeds using DMA mode. Fix the issue by changing DMA SRC_MSIZE and DEST_MSIZE of SPI FIFO side from 16 to 32. I think a bit of explanation is needed here, why changing the sizes from 16 to 32 fixes the issue. Also I will correct grammatical errors in the commit message. As these commits logs go in public tree, and stay there forever, it is important, to not leave any grammatical mistakes in the commit logs. Nitin Signed-off-by: Chew, Chiau Ee chiau.ee.c...@intel.com Signed-off-by: Maurice Petallo mauricex.r.peta...@intel.com --- drivers/spi/spi-pxa2xx-dma.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi-pxa2xx-dma.c b/drivers/spi/spi-pxa2xx-dma.c index 3c0b551..79515ed 100644 --- a/drivers/spi/spi-pxa2xx-dma.c +++ b/drivers/spi/spi-pxa2xx-dma.c @@ -385,7 +385,7 @@ int pxa2xx_spi_set_dma_burst_and_threshold(struct chip_data *chip, * otherwise we use the default. Also we use the default FIFO * thresholds for now. */ - *burst_code = chip_info ? chip_info-dma_burst_size : 16; + *burst_code = chip_info ? chip_info-dma_burst_size : 32; *threshold = SSCR1_RxTresh(RX_THRESH_DFLT) | SSCR1_TxTresh(TX_THRESH_DFLT); -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 18/29] pwm: add support for Intel Low Power Subsystem PWM
On 4/7/2014 8:18 AM, rebecca.swee.fun.ch...@intel.com wrote:
From: Mika Westerberg mika.westerb...@linux.intel.com
Add support for Intel Low Power I/O subsystem PWM controllers found on some
newer intel chipsets.
Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com
This patch is pulled from Mika's git tree previousy. The git
tree is no longer accessible now.
This git tree status information is not useful in the commit message.
You can include it
in the pull request email, and drop it from the commit message here.
Nitin
Signed-off-by: Chew, Chiau Ee chiau.ee.c...@intel.com
Signed-off-by: Maurice Petallo mauricex.r.peta...@intel.com
---
drivers/pwm/Kconfig| 10 +++
drivers/pwm/Makefile |1 +
drivers/pwm/pwm-lpss.c | 183
3 files changed, 194 insertions(+)
create mode 100644 drivers/pwm/pwm-lpss.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 14a9122..f2b0948 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -87,6 +87,16 @@ config PWM_LPC32XX
To compile this driver as a module, choose M here: the module
will be called pwm-lpc32xx.
+config PWM_LPSS
+ tristate Intel LPSS PWM support
+ depends on ACPI
+ help
+ Generic PWM framework driver for Intel Low Power Subsystem PWM
+ controller.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-lpio.
+
config PWM_MXS
tristate Freescale MXS PWM support
depends on ARCH_MXS OF
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 5aa815f..6a5e723 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_PWM_BFIN) += pwm-bfin.o
obj-$(CONFIG_PWM_IMX) += pwm-imx.o
obj-$(CONFIG_PWM_JZ4740) += pwm-jz4740.o
obj-$(CONFIG_PWM_LPC32XX) += pwm-lpc32xx.o
+obj-$(CONFIG_PWM_LPSS) += pwm-lpss.o
obj-$(CONFIG_PWM_MXS) += pwm-mxs.o
obj-$(CONFIG_PWM_PUV3)+= pwm-puv3.o
obj-$(CONFIG_PWM_PXA) += pwm-pxa.o
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
new file mode 100644
index 000..fb3548c
--- /dev/null
+++ b/drivers/pwm/pwm-lpss.c
@@ -0,0 +1,183 @@
+/*
+ * Intel Low Power Subsystem PWM controller driver
+ *
+ * Copyright (C) 2013, Intel Corporation
+ * Author: Mika Westerberg mika.westerb...@linux.intel.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/acpi.h
+#include linux/clk.h
+#include linux/device.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/pwm.h
+#include linux/platform_device.h
+
+#define PWM0x
+#define PWM_ENABLE BIT(31)
+#define PWM_SW_UPDATE BIT(30)
+#define PWM_BASE_UNIT_SHIFT8
+#define PWM_BASE_UNIT_MASK 0x0000
+#define PWM_ON_TIME_DIV_MASK 0x00ff
+
+struct pwm_lpss_chip {
+ struct pwm_chip chip;
+ void __iomem *regs;
+ struct clk *clk;
+};
+
+static inline struct pwm_lpss_chip *to_lpwm(struct pwm_chip *chip)
+{
+ return container_of(chip, struct pwm_lpss_chip, chip);
+}
+
+static void pwm_lpss_set_state(struct pwm_lpss_chip *lpwm, bool enable)
+{
+ u32 ctrl;
+
+ ctrl = readl(lpwm-regs + PWM);
+ if (enable)
+ ctrl |= PWM_ENABLE;
+ else
+ ctrl = ~PWM_ENABLE;
+ writel(ctrl, lpwm-regs + PWM);
+}
+
+static int pwm_lpss_config(struct pwm_chip *chip, struct pwm_device *pwm,
+ int duty_ns, int period_ns)
+{
+ struct pwm_lpss_chip *lpwm = to_lpwm(chip);
+ u8 base_unit_hi, base_unit_lo, on_time_div;
+ unsigned long c = clk_get_rate(lpwm-clk);
+ unsigned long hz, cycle_cnt;
+ u32 ctrl;
+
+ hz = 10UL / period_ns;
+
+ /*
+* There is no duty cycle resolution if base_unit value is higher
+* than 128.
+*/
+ base_unit_hi = (hz * 256) / c;
+ if (base_unit_hi 128)
+ return -EINVAL;
+
+ base_unit_lo = (hz * 65536) / c;
+ cycle_cnt = base_unit_hi ? 256 / base_unit_hi : 256;
+
+ if (duty_ns = 0)
+ duty_ns = 1;
+
+ on_time_div = cycle_cnt / (period_ns / duty_ns);
+
+ ctrl = readl(lpwm-regs + PWM);
+ ctrl = ~(PWM_BASE_UNIT_MASK | PWM_ON_TIME_DIV_MASK);
+ ctrl |= (base_unit_hi | base_unit_lo) PWM_BASE_UNIT_SHIFT;
+ ctrl |= on_time_div;
+ /* request PWM to update on next cycle */
+ ctrl |= PWM_SW_UPDATE;
+ writel(ctrl, lpwm-regs + PWM);
+
+ return 0;
+}
+
+static int pwm_lpss_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct pwm_lpss_chip *lpwm = to_lpwm(chip);
+
+ clk_prepare_enable(lpwm-clk);
+ pwm_lpss_set_state(lpwm, true);
+ return 0;
+}
+
+static void
Re: [linux-yocto] [PATCH 23/29] x86/byt: Fix device name string for clkdev registration
On 4/7/2014 8:18 AM, rebecca.swee.fun.ch...@intel.com wrote: From: Maurice Petallo mauricex.r.peta...@intel.com Use BYT DMA PCI domain:bus:slot.func identification as device name input during clkdev registration. Signed-off-by: Maurice Petallo mauricex.r.peta...@intel.com --- arch/x86/platform/byt/byt-board.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/platform/byt/byt-board.c b/arch/x86/platform/byt/byt-board.c index be4ed4d..e94a377 100644 --- a/arch/x86/platform/byt/byt-board.c +++ b/arch/x86/platform/byt/byt-board.c @@ -47,7 +47,7 @@ static int byt_clk_setup(void) if (IS_ERR(clk)) return PTR_ERR(clk); - clk_register_clkdev(clk, hclk, dw_dmac.0); + clk_register_clkdev(clk, hclk, :00:1e.0); Such kind of hard-coded constant addresses are not well received for upstreaming. Can this address instead be deduced at runtime? Nitin clk = clk_register_fixed_rate(NULL, spi_clk, lpss_clk, 0, 5000); if (IS_ERR(clk)) -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 26/29] pinctrl-baytrail: unmap interrupt when free the gpio pin
On 4/7/2014 8:18 AM, rebecca.swee.fun.ch...@intel.com wrote: From: Chew, Kean Ho kean.ho.c...@intel.com In to_irq() callback, we create the hwirq to linux irq mapping for the requested GPIO pin. Hence, we unamp typo: unamp/unmap the mapping when the gpio pin is being released. Signed-off-by: Chew, Kean Ho kean.ho.c...@intel.com Signed-off-by: Chew, Chiau Ee chiau.ee.c...@intel.com Signed-off-by: Sreeju Selvaraj sreeju.armughanx.selva...@intel.com --- drivers/pinctrl/pinctrl-baytrail.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/pinctrl/pinctrl-baytrail.c b/drivers/pinctrl/pinctrl-baytrail.c index c0ef8e2..554e279 100644 --- a/drivers/pinctrl/pinctrl-baytrail.c +++ b/drivers/pinctrl/pinctrl-baytrail.c @@ -177,11 +177,14 @@ static void byt_gpio_free(struct gpio_chip *chip, unsigned offset) struct byt_gpio *vg = to_byt_gpio(chip); void __iomem *reg = byt_gpio_reg(vg-chip, offset, BYT_CONF0_REG); u32 value; + unsigned int virq; /* clear interrupt triggering */ value = readl(reg); value = ~(BYT_TRIG_POS | BYT_TRIG_NEG | BYT_TRIG_LVL); writel(value, reg); + virq = irq_find_mapping(vg-domain, offset); + irq_dispose_mapping(virq); pm_runtime_put(vg-pdev-dev); } -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 29/29] i2c: i801: Enable BYT SMBUS support
On 4/7/2014 8:18 AM, rebecca.swee.fun.ch...@intel.com wrote:
From: Chang, Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com
Add PCI ID of BYT SMBUS.
Signed-off-by: Chew, Kean Ho kean.ho.c...@intel.com
Signed-off-by: Maurice Petallo mauricex.r.peta...@intel.com
Signed-off-by: Chang, Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com
---
drivers/i2c/busses/Makefile |2 +-
drivers/i2c/busses/i2c-i801.c |2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index f35b079..5bbf680 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -12,7 +12,6 @@ obj-$(CONFIG_I2C_ALI15X3) += i2c-ali15x3.o
obj-$(CONFIG_I2C_AMD756) += i2c-amd756.o
obj-$(CONFIG_I2C_AMD756_S4882)+= i2c-amd756-s4882.o
obj-$(CONFIG_I2C_AMD8111) += i2c-amd8111.o
-obj-$(CONFIG_I2C_I801) += i2c-i801.o
obj-$(CONFIG_I2C_ISCH)+= i2c-isch.o
obj-$(CONFIG_I2C_ISMT)+= i2c-ismt.o
obj-$(CONFIG_I2C_NFORCE2) += i2c-nforce2.o
@@ -41,6 +40,7 @@ obj-$(CONFIG_I2C_DESIGNWARE_PLATFORM) +=
i2c-designware-platform.o
i2c-designware-platform-objs := i2c-designware-platdrv.o
obj-$(CONFIG_I2C_DESIGNWARE_PCI) += i2c-designware-pci.o
i2c-designware-pci-objs := i2c-designware-pcidrv.o
+obj-$(CONFIG_I2C_I801) += i2c-i801.o
Can you explain in the commit log, why this line is moved in the Makefile?
Nitin
obj-$(CONFIG_I2C_EG20T) += i2c-eg20t.o
obj-$(CONFIG_I2C_GPIO)+= i2c-gpio.o
obj-$(CONFIG_I2C_HIGHLANDER) += i2c-highlander.o
diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index 8763b22..b667b2b 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -175,6 +175,7 @@
#define PCI_DEVICE_ID_INTEL_WELLSBURG_SMBUS_MS1 0x8d7e
#define PCI_DEVICE_ID_INTEL_WELLSBURG_SMBUS_MS2 0x8d7f
#define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_SMBUS0x9c22
+#define PCI_DEVICE_ID_INTEL_BYT_SMBUS 0x0f12
struct i801_mux_config {
char *gpio_chip;
@@ -792,6 +793,7 @@ static DEFINE_PCI_DEVICE_TABLE(i801_ids) = {
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801CA_3) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801DB_3) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801EB_3) },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT_SMBUS) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB_4) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_16) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_17) },
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 00/29] Create new feature branch for Valley Island BSP
On 4/7/2014 8:17 AM, rebecca.swee.fun.ch...@intel.com wrote: From: Chang Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com Hi all, Here is a request to create feature branch to host Valley Island PCI enumerated LPSS I/O device drivers. We expect the patch series to be removed over time. This will give us time to stage a working code while we are working on up-stream commits to mainline and eventually back-port them into LTS/LTSI. As per previous internal discussion, we think that feature branch is a right approach for ISG. This new branch is named: isg-1.0 with -1.0 suffix as the initial version of this feature branch. This feature branch was branched out from linux-yocto-3.10 standard/base at the commit: 3e0a296fae952d8d93eb0f96566bf6d4a978c8ee minnowboard-keys: Bind MinnowBoard buttons to arrow keys This branch was built tested to ensure no merge issues during build time. The PCI enumerated I/O drivers are sanity tested by checking dmesg, lspci -k and lsmod. Please help to create a new branch named isg-1.0 in linux-yocto-3.10 and pull the entire patch series into the feature branch. Thanks. Rebecca Hi Rebecca, I have sent my review feedback by email to many of the commits. The commits which did not get feedback from me, are already in good shape. Thanks, Nitin The following changes since commit 3e0a296fae952d8d93eb0f96566bf6d4a978c8ee: minnowboard-keys: Bind MinnowBoard buttons to arrow keys (2014-02-12 00:08:25 -0500) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-contrib rebeccas/isg-1.0 http://git.yoctoproject.org/cgit.cgi/linux-yocto-contrib/log/?h=rebeccas/isg-1.0 Alan Stern (1): usb: gadget: don't fail when DMA isn't present Chang, Rebecca Swee Fun (1): i2c: i801: Enable BYT SMBUS support Chew, Chiau Ee (14): x86/Kconfig: add PCI dependency for CONFIG_X86_INTEL_LPSS x86/byt: enable board file for BYT LPSS PCI mode dma: dw: Fix Intel MID DMA driver and Designware DMA driver loading sequence dma: dw: Implement suspend/resume callbacks serial: 8250_dw: Added support for 1M, 2M, 3M and 4M exat baud rate i2c: designware-pci: Add support for Intel BayTrail LPSS I2C i2c: designware-pcidrv: Add 10-bit addressing mode functionality i2c: designware-pcidrv: Option to set custom HCNT, LCNT and SDA value spi/pxa2xx-pci: Add support for Intel BYT SPI spi/pxa2xx: Fix BYT ACPI mode SPI DMA transfer failure at low speeds sdhc: acpi: Fix SDCARD card detection failure pwm: lpss: Enable BYT PCI mode PWM pwm: lpss: Fix base_unit calculation ACPI / LPSS: Add BYT ACPI mode PWM Chew, Kean Ho (5): mmc: sdhci: Force BYT SDCARD host to run with SDR25 mode pinctrl-baytrail: add function mux checking in gpio pin request pinctrl-baytrail: unmap interrupt when free the gpio pin pinctrl-baytrail: enable platform device in the absent of ACPI enumeration pinctrl-baytrail: setup IOAPIC interrupt for GPIO clusters on non-ACPI system Felipe Balbi (1): usb: gadget: udc-core: move sysfs_notify() to a workqueue H Hartley Sweeten (1): pwm: Add sysfs interface Heikki Krogerus (2): serial: 8250: don't change the fifo trigger level when using dma serial: 8250_pci: add support for Intel BayTrail Maurice Petallo (3): usb: dwc3: pci: Enable/disable ulpi phy refclk x86/byt: Fix device name string for clkdev registration mmc: sdhci: Fix continuous warning prints in ISR if shared interrupt Mika Westerberg (1): pwm: add support for Intel Low Power Subsystem PWM Documentation/ABI/testing/sysfs-class-pwm | 79 +++ Documentation/pwm.txt | 37 +++ arch/x86/Kconfig | 11 +- arch/x86/platform/Makefile |3 + arch/x86/platform/byt/Makefile |1 + arch/x86/platform/byt/byt-board.c | 84 +++ drivers/acpi/acpi_lpss.c | 11 + drivers/dma/Makefile |2 +- drivers/dma/dw/pci.c | 36 +++ drivers/i2c/busses/Makefile|2 +- drivers/i2c/busses/i2c-designware-pcidrv.c | 126 +- drivers/i2c/busses/i2c-i801.c |2 + drivers/mmc/host/sdhci-acpi.c |7 +- drivers/mmc/host/sdhci-pci.c |3 +- drivers/mmc/host/sdhci.c | 17 +- drivers/pinctrl/Kconfig| 19 +- drivers/pinctrl/Makefile |1 + drivers/pinctrl/pinctrl-baytrail-dev.c | 159 + drivers/pinctrl/pinctrl-baytrail.c | 76 +- drivers/pwm/Kconfig| 21 ++ drivers/pwm/Makefile |3 + drivers/pwm/core.c | 25 +- drivers/pwm/pwm-lpss-pci.c | 118 ++ drivers/pwm/pwm-lpss.c | 186 +++ drivers/pwm/pwm-lpss.h | 19 ++
Re: [linux-yocto] [PATCH 0/1] a fix for v3.10 LTSI branch
-Original Message- From: Hart, Darren Sent: Monday, March 31, 2014 1:34 PM To: Kamble, Nitin A; Ashfield, Bruce (Wind River); linux- yo...@yoctoproject.org Subject: Re: [PATCH 0/1] a fix for v3.10 LTSI branch On 3/31/14, 13:24, Kamble, Nitin A nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com I was noticing emenlow BSP failing to boot since LTSI was integrated in the v3.10 kernel. After debugging I found out that kernel code was doing an invalid memory access, causing kernel panic. Here is the fix for the issue, which I am also pushing to the upstream v3.10 LTSI kernel repository. Is this a backport from mainline? If so, it needs the cherry-pick ID. If not, this needs to go upstream first and then back to 3.10 stable (which LTSI will pick up). If neither of these seems like the right approach to you - what did you have in mind and why? This is not a backport. But I am planning to send it to LTSI upstream. As you say this will be back ported, once it goes upstream in the LTSI repo. Nitin Thanks, -- Darren Hart Yocto Project - Linux Kernel Intel Open Source Technology Center -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 0/1] a fix for v3.10 LTSI branch
On 3/31/2014 2:01 PM, Hart, Darren wrote: On 3/31/14, 13:56, Kamble, Nitin A nitin.a.kam...@intel.com wrote: -Original Message- From: Hart, Darren Sent: Monday, March 31, 2014 1:34 PM To: Kamble, Nitin A; Ashfield, Bruce (Wind River); linux- yo...@yoctoproject.org Subject: Re: [PATCH 0/1] a fix for v3.10 LTSI branch On 3/31/14, 13:24, Kamble, Nitin A nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com I was noticing emenlow BSP failing to boot since LTSI was integrated in the v3.10 kernel. After debugging I found out that kernel code was doing an invalid memory access, causing kernel panic. Here is the fix for the issue, which I am also pushing to the upstream v3.10 LTSI kernel repository. Is this a backport from mainline? If so, it needs the cherry-pick ID. If not, this needs to go upstream first and then back to 3.10 stable (which LTSI will pick up). If neither of these seems like the right approach to you - what did you have in mind and why? This is not a backport. But I am planning to send it to LTSI upstream. As you say this will be back ported, once it goes upstream in the LTSI repo. Please do not send it to LTSI. LTSI is not a development target. LTSI tracks stable and gets new features *from mainline* that stable cannot. Please send this to lkml with the stable line included (see the stable-kernel-rules.txt). This should get picked up into the LTSI release as a matter of course after it lands in 3.10 stable. Got it. I pulled the trigger for LTSI ML too fast then. I will post it on LKML for 3.10 stable now. Thanks for the clarification. Nitin -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [yocto] [meta-intel] [common][dora][PATCH] emgd-driver-bin: limit build to x86*
-Original Message-
From: meta-intel-boun...@yoctoproject.org [mailto:meta-intel-
boun...@yoctoproject.org] On Behalf Of Darren Hart
Sent: Friday, February 14, 2014 9:26 AM
To: Koen Kooi; meta-in...@lists.yoctoproject.org
Cc: yo...@lists.yoctoproject.org
Subject: Re: [meta-intel] [common][dora][PATCH] emgd-driver-bin: limit
build to x86*
On 2/14/14, 7:21, Koen Kooi k...@dominion.thruhere.net wrote:
When building GL apps for non-x86 machines (e.g. raspberrypi)
emgd-driver-bin is being dragged in as a valid provider. To avoid build
breakage fix it at the source by limiting emgd-driver-bin to x86
architectures.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
common/recipes-graphics/xorg-driver/emgd-driver-bin_1.16.bb | 2 ++
common/recipes-graphics/xorg-driver/emgd-driver-bin_1.18.bb | 2 ++
2 files changed, 4 insertions(+)
diff --git
a/common/recipes-graphics/xorg-driver/emgd-driver-bin_1.16.bb
b/common/recipes-graphics/xorg-driver/emgd-driver-bin_1.16.bb
index c8ca726..8cb088e 100644
--- a/common/recipes-graphics/xorg-driver/emgd-driver-bin_1.16.bb
+++ b/common/recipes-graphics/xorg-driver/emgd-driver-bin_1.16.bb
@@ -9,6 +9,8 @@ LICENSE = Intel-software-license-emgd-1.16
Intel-user-space-graphics-driver-b
LICENSE_FLAGS = license_${PN}_${PV}
PR = r0
+COMPATIBLE_HOST = (i.86|x86_64).*-linux
And you can drop the x86_64 as well as this is a 32bit only driver.
Agreed.
Nitin
--
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center
___
meta-intel mailing list
meta-in...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-intel][common][dora][PATCHv2] emgd-driver-bin: limit build to x86
On 2/14/2014 10:24 AM, Koen Kooi wrote:
When building GL apps for non-x86 machines (e.g. raspberrypi) emgd-driver-bin
is being
dragged in as a valid provider. To avoid build breakage fix it at the
source by limiting emgd-driver-bin to x86 architectures.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
Acked-By: Nitin A Kamble nitin.a.kam...@intel.com
---
common/recipes-graphics/xorg-driver/emgd-driver-bin_1.16.bb | 2 ++
common/recipes-graphics/xorg-driver/emgd-driver-bin_1.18.bb | 2 ++
2 files changed, 4 insertions(+)
diff --git a/common/recipes-graphics/xorg-driver/emgd-driver-bin_1.16.bb
b/common/recipes-graphics/xorg-driver/emgd-driver-bin_1.16.bb
index c8ca726..8cb088e 100644
--- a/common/recipes-graphics/xorg-driver/emgd-driver-bin_1.16.bb
+++ b/common/recipes-graphics/xorg-driver/emgd-driver-bin_1.16.bb
@@ -9,6 +9,8 @@ LICENSE = Intel-software-license-emgd-1.16
Intel-user-space-graphics-driver-b
LICENSE_FLAGS = license_${PN}_${PV}
PR = r0
+COMPATIBLE_HOST = (i.86).*-linux
+
EMGD_LIC_DIR = IEMGD_HEAD_Linux/License
EMGD_RPM_DIR = IEMGD_HEAD_Linux/MeeGo1.2
EMGD_VIDEO_PLUGIN_DIR = ../common/video_plugin
diff --git a/common/recipes-graphics/xorg-driver/emgd-driver-bin_1.18.bb
b/common/recipes-graphics/xorg-driver/emgd-driver-bin_1.18.bb
index b3bf0d2..cf6d855 100644
--- a/common/recipes-graphics/xorg-driver/emgd-driver-bin_1.18.bb
+++ b/common/recipes-graphics/xorg-driver/emgd-driver-bin_1.18.bb
@@ -9,6 +9,8 @@ LICENSE = Intel-software-license-emgd-1.18
Intel-user-space-graphics-driver-b
LICENSE_FLAGS = license_${PN}_${PV}
PR = r1
+COMPATIBLE_HOST = (i.86).*-linux
+
EMGD_LIC_DIR = IEMGD_HEAD_Linux/License
EMGD_RPM_DIR = IEMGD_HEAD_Linux/MeeGo1.2
EMGD_VIDEO_PLUGIN_DIR = ../common/video_plugin
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] [PATCH v2 12/17] media-platform: A feature for platform media devices
-Original Message- From: Hart, Darren Sent: Monday, December 09, 2013 8:32 AM To: Kamble, Nitin A Cc: bruce.ashfi...@windriver.com; linux-yocto@yoctoproject.org Subject: Re: [PATCH v2 12/17] media-platform: A feature for platform media devices On Fri, 2013-12-06 at 21:51 -0800, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com Create a feature fragment for enabling platform media devices. This one seems like it might be incomplete. The first option enables a block of other options, but only DEINTERLACE was enabled of the entire block. This isn't Nitin's doing, it's just what was in the media.cfg blob I tossed over the over the wall to him. Hrm. I don't see any dependencies on DEINTERLACE from other drivers... but it is a generic deinterlacing driver for V4L... which seems to me to be something we would want in general... while the others, not so much. So... OK, I guess it's the right way to go... despite looking a bit odd. I had similar feeling while creating this fragment. I also tried to avoid creating this. Putting it in the media.cfg was not working well, because it was enabling some of the unwanted media drivers without asking. Thanks, Nitin Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com Reviewed-by: Darren Hart dvh...@linux.intel.com --- meta/cfg/kernel-cache/features/media/media-platform.cfg | 5 + meta/cfg/kernel-cache/features/media/media-platform.scc | 6 ++ 2 files changed, 11 insertions(+) create mode 100644 meta/cfg/kernel-cache/features/media/media-platform.cfg create mode 100644 meta/cfg/kernel-cache/features/media/media-platform.scc diff --git a/meta/cfg/kernel-cache/features/media/media-platform.cfg b/meta/cfg/kernel-cache/features/media/media-platform.cfg new file mode 100644 index 000..31b53bd --- /dev/null +++ b/meta/cfg/kernel-cache/features/media/media-platform.cfg @@ -0,0 +1,5 @@ +# +# Media Platform Configuration +# +CONFIG_V4L_MEM2MEM_DRIVERS=y +CONFIG_VIDEO_MEM2MEM_DEINTERLACE=m diff --git a/meta/cfg/kernel-cache/features/media/media-platform.scc b/meta/cfg/kernel-cache/features/media/media-platform.scc new file mode 100644 index 000..474406c --- /dev/null +++ b/meta/cfg/kernel-cache/features/media/media-platform.scc @@ -0,0 +1,6 @@ +define KFEATURE_DESCRIPTION Enable Configuration For Platform Media devices +define KFEATURE_COMPATIBILITY all + +include media.scc + +kconf hardware media-platform.cfg -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 00/16] linux-yocto-3.10: config fragments for minnow BSP
-Original Message- From: Hart, Darren Sent: Friday, November 22, 2013 12:48 PM To: Kamble, Nitin A Cc: linux-yo...@yoctoproject.org; bruce.ashfi...@windriver.com Subject: Re: [PATCH 00/16] linux-yocto-3.10: config fragments for minnow BSP On Fri, 2013-11-22 at 11:36 -0800, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com This patch series imports the 500 line media.cfg from the kernel recipe in to the linux-yocto-3.10 meta branch, by splitting it into many fragments. It replaces some of the existing webcam media fragments, and hence BSPs configs using the old media fragments is changed accordingly. This has been tested the following way. * It gives the same minnow kernel config as with the big media.cfg on SRC_URI * This changes the kernel config for sugarbay and genericx86-64 BSPs, and the sugarbay BSP is validated to work as expected with this change. Fantastic, thank you Nitin. Did you also verify that no new issues are reported by the config validation task and logged in the .meta/standard/$KMACHINE/* log files? missing, etc? I did verify that there are no errors in those log file. Nitin -- Darren Thanks, Nitin The following changes since commit 4a04774a6562ab37a769404920e070b70acf3c4c: minnow: Remove branch statements from minnow scc files (2013-11-14 22:56:03 -0500) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-contrib nitin/meta http://git.yoctoproject.org/cgit.cgi/linux-yocto-contrib/log/?h=nitin/ meta Nitin A Kamble (16): minnow.cfg: Enable TEA575X sound driver firmware.scc/cfg : Feature for firmware loading remove old MEDIA config fragments media.scc : A feature for Media infrastructure media/common : A feature for common media support media/usb: A feature for USB media devices. media/i2c: A feature for i2c media devices media/pci-capture : A feature for PCI media capture devices media/platform : A feature for platform media devices media/radio : A feature for AM/FM radio devices media/rc : A feature for remote control media devices media/tuners: A feature for tuner media devices media/usb_tv: A feature for usb tv media adapters media/dvb-frontends : A feature for Digital Video Broadcast Devices minnow.scc: enable media firmware features common-pc-64.scc: update as per changes in the media config fragments .../kernel-cache/bsp/common-pc-64/common-pc-64.scc | 3 +- meta/cfg/kernel-cache/bsp/minnow/minnow.cfg| 1 + meta/cfg/kernel-cache/bsp/minnow/minnow.scc| 9 ++ .../kernel-cache/features/firmware/firmware.cfg| 8 ++ .../kernel-cache/features/firmware/firmware.scc| 4 + meta/cfg/kernel-cache/features/media/common.cfg| 15 +++ meta/cfg/kernel-cache/features/media/common.scc| 6 ++ .../kernel-cache/features/media/dvb_frontends.cfg | 116 + .../kernel-cache/features/media/dvb_frontends.scc | 6 ++ meta/cfg/kernel-cache/features/media/i2c.cfg | 74 + meta/cfg/kernel-cache/features/media/i2c.scc | 7 ++ .../kernel-cache/features/media/media-camera.cfg | 4 - .../kernel-cache/features/media/media-camera.scc | 4 - meta/cfg/kernel-cache/features/media/media.cfg | 54 ++ meta/cfg/kernel-cache/features/media/media.scc | 4 + .../kernel-cache/features/media/pci-capture.cfg| 80 ++ .../kernel-cache/features/media/pci-capture.scc| 8 ++ meta/cfg/kernel-cache/features/media/platform.cfg | 15 +++ meta/cfg/kernel-cache/features/media/platform.scc | 6 ++ meta/cfg/kernel-cache/features/media/radio.cfg | 24 + meta/cfg/kernel-cache/features/media/radio.scc | 6 ++ meta/cfg/kernel-cache/features/media/rc.cfg| 18 meta/cfg/kernel-cache/features/media/rc.scc| 6 ++ meta/cfg/kernel-cache/features/media/tuners.cfg| 30 ++ meta/cfg/kernel-cache/features/media/tuners.scc| 7 ++ meta/cfg/kernel-cache/features/media/usb.cfg | 76 ++ meta/cfg/kernel-cache/features/media/usb.scc | 7 ++ meta/cfg/kernel-cache/features/media/usb_tv.cfg| 82 +++ meta/cfg/kernel-cache/features/media/usb_tv.scc| 8 ++ meta/cfg/kernel-cache/features/media/v4l2.cfg | 21 meta/cfg/kernel-cache/features/media/v4l2.scc | 6 -- .../cfg/kernel-cache/features/usb/usb-uvcvideo.cfg | 3 - .../cfg/kernel-cache/features/usb/usb-uvcvideo.scc | 7 -- 33 files changed, 678 insertions(+), 47 deletions(-) create mode 100644 meta/cfg/kernel-cache/features/firmware/firmware.cfg create mode 100644 meta/cfg/kernel-cache/features/firmware/firmware.scc create mode 100644 meta/cfg/kernel-cache/features/media/common.cfg create mode 100644 meta/cfg/kernel-cache/features/media
Re: [linux-yocto] [PATCH 01/16] minnow.cfg: Enable TEA575X sound driver
-Original Message- From: Darren Hart [mailto:dvh...@linux.intel.com] Sent: Friday, November 22, 2013 12:50 PM To: Kamble, Nitin A Cc: linux-yo...@yoctoproject.org; bruce.ashfi...@windriver.com Subject: Re: [PATCH 01/16] minnow.cfg: Enable TEA575X sound driver On Fri, 2013-11-22 at 11:35 -0800, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com The TEA575X sound driver configuration is relocated from the kernel recipe's media.cfg to here. This isn't required for the minnowboard, it uses an HDA. This should be part of a more generic sound fragment that can be included by BSPs like genericx86*. The only reason for adding this was, because minnow board used it in it's media.cfg. If it is not needed for minnow, then why to keep it? Nitin -- Darren Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com --- meta/cfg/kernel-cache/bsp/minnow/minnow.cfg | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/cfg/kernel-cache/bsp/minnow/minnow.cfg b/meta/cfg/kernel-cache/bsp/minnow/minnow.cfg index 2be4ea4..b08f411 100644 --- a/meta/cfg/kernel-cache/bsp/minnow/minnow.cfg +++ b/meta/cfg/kernel-cache/bsp/minnow/minnow.cfg @@ -8,6 +8,7 @@ CONFIG_MTRR=y # Basic hardware support for the box - network, USB, PCI, sound CONFIG_PCI=y CONFIG_PCIEPORTBUS=y +CONFIG_SND_TEA575X=m # Ensure we can boot over MMC CONFIG_MMC=y -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 03/16] remove old MEDIA config fragments
-Original Message- From: Darren Hart [mailto:dvh...@linux.intel.com] Sent: Friday, November 22, 2013 12:53 PM To: Kamble, Nitin A Cc: linux-yo...@yoctoproject.org; bruce.ashfi...@windriver.com Subject: Re: [PATCH 03/16] remove old MEDIA config fragments On Fri, 2013-11-22 at 11:35 -0800, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com These are getting replaced with newer extensive MEDIA config fragments. OK, but this should come last, after the others are in place and used by the BSPs. The commit can be shifted easily. As you can guess, I was not concerned about for couple of reasons. The pull request bunches all the concerned commits together. And BSPs would not get affected unless one intends to break, by setting random commit IDs without testing. Anyway it is a quick fix so I won't argue. Nitin -- Darren Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com --- .../kernel-cache/features/media/media-camera.cfg| 4 .../kernel-cache/features/media/media-camera.scc| 4 meta/cfg/kernel-cache/features/media/v4l2.cfg | 21 - meta/cfg/kernel-cache/features/media/v4l2.scc | 6 -- meta/cfg/kernel-cache/features/usb/usb-uvcvideo.cfg | 3 --- meta/cfg/kernel-cache/features/usb/usb-uvcvideo.scc | 7 --- 6 files changed, 45 deletions(-) delete mode 100644 meta/cfg/kernel-cache/features/media/media-camera.cfg delete mode 100644 meta/cfg/kernel-cache/features/media/media-camera.scc delete mode 100644 meta/cfg/kernel-cache/features/media/v4l2.cfg delete mode 100644 meta/cfg/kernel-cache/features/media/v4l2.scc delete mode 100644 meta/cfg/kernel-cache/features/usb/usb-uvcvideo.cfg delete mode 100644 meta/cfg/kernel-cache/features/usb/usb-uvcvideo.scc diff --git a/meta/cfg/kernel-cache/features/media/media-camera.cfg b/meta/cfg/kernel-cache/features/media/media-camera.cfg deleted file mode 100644 index 6e173a9..000 --- a/meta/cfg/kernel-cache/features/media/media-camera.cfg +++ /dev/null @@ -1,4 +0,0 @@ -# Enable Multimedia and Camera Device support - CONFIG_MEDIA_SUPPORT=m -CONFIG_MEDIA_CAMERA_SUPPORT=y - CONFIG_MEDIA_SUBDRV_AUTOSELECT=y diff --git a/meta/cfg/kernel-cache/features/media/media-camera.scc b/meta/cfg/kernel-cache/features/media/media-camera.scc deleted file mode 100644 index 15d04e4..000 --- a/meta/cfg/kernel-cache/features/media/media-camera.scc +++ /dev/null @@ -1,4 +0,0 @@ -define KFEATURE_DESCRIPTION Enable camera media device as a module -define KFEATURE_COMPATIBILITY all - -kconf non-hardware media-camera.cfg diff --git a/meta/cfg/kernel-cache/features/media/v4l2.cfg b/meta/cfg/kernel-cache/features/media/v4l2.cfg deleted file mode 100644 index 614886c..000 --- a/meta/cfg/kernel-cache/features/media/v4l2.cfg +++ /dev/null @@ -1,21 +0,0 @@ -# Enable the V4L2 core and API -CONFIG_VIDEO_DEV=m -CONFIG_VIDEO_V4L2=m -VIDEO_V4L2_SUBDEV_API=y - -# Used by drivers that need v4l2-mem2mem.ko - V4L2_MEM2MEM_DEV=m - -# Used by drivers that need Videobuf modules -VIDEOBUF_GEN=m -VIDEOBUF_DMA_SG=m -VIDEOBUF_VMALLOC=m - VIDEOBUF_DMA_CONTIG=m -VIDEOBUF_DVB=m - -# Used by drivers that need Videobuf2 modules -CONFIG_VIDEOBUF2_CORE=m -CONFIG_VIDEOBUF2_MEMOPS=m -CONFIG_VIDEOBUF2_VMALLOC=m -VIDEOBUF2_DMA_CONTIG=m -VIDEOBUF2_DMA_SG=m diff --git a/meta/cfg/kernel-cache/features/media/v4l2.scc b/meta/cfg/kernel-cache/features/media/v4l2.scc deleted file mode 100644 index 09ab7d6..000 --- a/meta/cfg/kernel-cache/features/media/v4l2.scc +++ /dev/null @@ -1,6 +0,0 @@ -define KFEATURE_DESCRIPTION Enable Video for Linux 2 as a module -define KFEATURE_COMPATIBILITY all - -include media-camera.scc - -kconf non-hardware v4l2.cfg diff --git a/meta/cfg/kernel-cache/features/usb/usb-uvcvideo.cfg b/meta/cfg/kernel-cache/features/usb/usb-uvcvideo.cfg deleted file mode 100644 index 366f08b..000 --- a/meta/cfg/kernel-cache/features/usb/usb-uvcvideo.cfg +++ /dev/null @@ -1,3 +0,0 @@ -# Enable USB Video Class camera support - CONFIG_MEDIA_USB_SUPPORT=y -CONFIG_USB_VIDEO_CLASS=m diff --git a/meta/cfg/kernel-cache/features/usb/usb-uvcvideo.scc b/meta/cfg/kernel-cache/features/usb/usb-uvcvideo.scc deleted file mode 100644 index a8cd0f1..000 --- a/meta/cfg/kernel-cache/features/usb/usb-uvcvideo.scc +++ /dev/null @@ -1,7 +0,0 @@ -define KFEATURE_DESCRIPTION Enable USB UVC Video Camera Module -define KFEATURE_COMPATIBILITY board - -include usb-base.scc -include features/media/media-camera.scc - -kconf hardware usb-uvcvideo.cfg -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 04/16] media.scc : A feature for Media infrastructure
-Original Message- From: Hart, Darren Sent: Friday, November 22, 2013 12:56 PM To: Kamble, Nitin A Cc: linux-yo...@yoctoproject.org; bruce.ashfi...@windriver.com Subject: Re: [PATCH 04/16] media.scc : A feature for Media infrastructure On Fri, 2013-11-22 at 11:35 -0800, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com This replaces the previous limited media config fragments. Other hardware media features depends on this feature. Please include the intent of this particular feature here. This adds the infrastructure V4L2, tuner, camera, and radio, to be included by driver- specific features. Ack. Makes sense. BTW, the real intent is to covert the minnow's media.cfg, ;) Nitin But, yes, good abstraction. -- Darren Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com --- meta/cfg/kernel-cache/features/media/media.cfg | 54 ++ meta/cfg/kernel-cache/features/media/media.scc | 4 ++ 2 files changed, 58 insertions(+) create mode 100644 meta/cfg/kernel-cache/features/media/media.cfg create mode 100644 meta/cfg/kernel-cache/features/media/media.scc diff --git a/meta/cfg/kernel-cache/features/media/media.cfg b/meta/cfg/kernel-cache/features/media/media.cfg new file mode 100644 index 000..b7b5f5e --- /dev/null +++ b/meta/cfg/kernel-cache/features/media/media.cfg @@ -0,0 +1,54 @@ +# +# Enable support for multimedia devices such as webcams and Video +grabber devices # CONFIG_MEDIA_SUPPORT=m +CONFIG_MEDIA_CAMERA_SUPPORT=y CONFIG_MEDIA_ANALOG_TV_SUPPORT=y +CONFIG_MEDIA_DIGITAL_TV_SUPPORT=y +CONFIG_MEDIA_RADIO_SUPPORT=y +CONFIG_MEDIA_CONTROLLER=y + +# +# Enable the V4L2 core and API +# +CONFIG_VIDEO_DEV=m +CONFIG_VIDEO_V4L2=m +CONFIG_VIDEO_V4L2_SUBDEV_API=y + +# +# Used by drivers that need v4l2-mem2mem.ko # +CONFIG_V4L2_MEM2MEM_DEV=m + +# +# Used by drivers that need Videobuf modules # CONFIG_VIDEOBUF_GEN=m +CONFIG_VIDEOBUF_DMA_SG=m CONFIG_VIDEOBUF_DMA_CONTIG=m +CONFIG_VIDEOBUF_VMALLOC=m CONFIG_VIDEOBUF_DVB=m + +# +# Used by drivers that need Videobuf2 modules # +CONFIG_VIDEOBUF2_CORE=m CONFIG_VIDEOBUF2_MEMOPS=m +CONFIG_VIDEOBUF2_DMA_SG=m CONFIG_VIDEOBUF2_DMA_CONTIG=m +CONFIG_VIDEOBUF2_VMALLOC=m + +# +# Digital Video Broadcast support +# +CONFIG_DVB_CORE=y +CONFIG_DVB_NET=y +CONFIG_DVB_MAX_ADAPTERS=8 +CONFIG_DVB_DYNAMIC_MINORS=y + +# +# Autoselect ancillary drivers (tuners, sensors, i2c, frontends) # +CONFIG_MEDIA_SUBDRV_AUTOSELECT=y + +CONFIG_MEDIA_ATTACH=y diff --git a/meta/cfg/kernel-cache/features/media/media.scc b/meta/cfg/kernel-cache/features/media/media.scc new file mode 100644 index 000..838782d --- /dev/null +++ b/meta/cfg/kernel-cache/features/media/media.scc @@ -0,0 +1,4 @@ +define KFEATURE_DESCRIPTION Enable support for multimedia devices such as webcams and Video grabber devices +define KFEATURE_COMPATIBILITY all + +kconf non-hardware media.cfg -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 2/2] common-pc-64: add kernel CONFIG options for sugarbay platform
-Original Message- From: linux-yocto-boun...@yoctoproject.org [mailto:linux-yocto- boun...@yoctoproject.org] On Behalf Of Darren Hart Sent: Tuesday, September 24, 2013 12:21 PM To: Development list for the linux-yocto*.git Linux kernel repositories Subject: Re: [linux-yocto] [PATCH 2/2] common-pc-64: add kernel CONFIG options for sugarbay platform On Tue, 2013-09-24 at 18:23 +, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com Add these Kernel driver config options for Sugarbay platform. - i915 graphics - 8250 serial port - usb webcam drivers - generic power management support to enable proper suspend/resume Fixes Bug: [YOCTO #5117] Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com --- meta/cfg/kernel-cache/bsp/common-pc-64/common-pc-64.scc | 13 + 1 file changed, 13 insertions(+) diff --git a/meta/cfg/kernel-cache/bsp/common-pc-64/common-pc-64.scc b/meta/cfg/kernel-cache/bsp/common-pc-64/common-pc-64.scc index c841875..e98a254 100644 --- a/meta/cfg/kernel-cache/bsp/common-pc-64/common-pc-64.scc +++ b/meta/cfg/kernel-cache/bsp/common-pc-64/common-pc-64.scc @@ -13,3 +13,16 @@ include features/usb/touchscreen-composite.scc include features/intel-e1/intel-e100.scc include features/intel-e1/intel-e1.scc include features/scsi/cdrom.scc + +# generic power management +include features/power/intel.scc + +# serial port +include cfg/8250.scc + +# webcam +include features/usb/usb-uvcvideo +include features/media/v4l2 + Please use the explicit path (including the .scc) Updated the commit in the contrib branch to use the full path with .scc. Thanks, Nitin +# sugarbay graphics +include features/i915/i915.scc -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH] meta: add genericx86 BSP
-Original Message- From: linux-yocto-boun...@yoctoproject.org [mailto:linux-yocto- boun...@yoctoproject.org] On Behalf Of Bruce Ashfield Sent: Friday, September 13, 2013 9:56 AM To: Development list for the linux-yocto*.git Linux kernel repositories Subject: Re: [linux-yocto] [PATCH] meta: add genericx86 BSP On 13-09-13 12:03 PM, Darren Hart wrote: This is not being added, we're using common-pc. What is pending is my update to the common-pc and common-pc-64 BSPs which Paul G. provided some feedback for and I updated the branch which is ready to be pulled here: git://git.yoctoproject.org/linux-yocto-contrib dvhart/3.10/meta http://git.yoctoproject.org/cgit.cgi/linux-yocto-contrib/log/?h=dvhart /3.10/meta This should be all that is outstanding for genericx86/common-pc in linux-yocto currently. Aha. My misunderstanding, it got a bit muddy in the middle. As you can see in your inbox, I've merged these, pushed them out and sent the pull request for the SRCREV update. Darren, Does this impact other BSPs? Or in other words does this demand srcrev updates for other BSPs? Thanks, Nitin Bruce -- Darren On Fri, 2013-09-13 at 09:12 -0400, Bruce Ashfield wrote: ping again. I still haven't seen an updated, an reposted merge of this with common- pc. Did my mail client manage to drop it ? Bruce On Mon, Sep 9, 2013 at 2:06 PM, Bruce Ashfield bruce.ashfi...@gmail.com wrote: On Wed, Aug 21, 2013 at 4:17 PM, Bruce Ashfield bruce.ashfi...@windriver.com wrote: On 13-08-21 01:33 PM, Darren Hart wrote: On Wed, 2013-08-21 at 17:57 +0100, Ross Burton wrote: This BSP aims at supporting a broad range of Intel platforms, from Atom up to Xeon. As such the kernel includes a range of drivers, and the corresponding machine configuration in meta-yocto-bsp includes a range of user-space drivers. Signed-off-by: Ross Burton ross.bur...@intel.com --- .../bsp/genericx86/genericx86-standard.scc | 28 1 file changed, 28 insertions(+) create mode 100644 meta/cfg/kernel-cache/bsp/genericx86/genericx86-standard.scc diff --git a/meta/cfg/kernel-cache/bsp/genericx86/genericx86-standard.scc b/meta/cfg/kernel-cache/bsp/genericx86/genericx86-standard.scc new file mode 100644 index 000..94d8ca7 --- /dev/null +++ b/meta/cfg/kernel-cache/bsp/genericx86/genericx86- standard.sc +++ c @@ -0,0 +1,28 @@ +define KMACHINE genericx86 +define KTYPE standard +define KARCH i386 + +# TODO: long-term move away from common-pc? +include bsp/common-pc/common-pc-standard.scc +branch atom-pc + +include cfg/x86.scc +include cfg/boot-live.scc + +include features/power/intel.scc + +# Ideally all of these below would be modules instead of built-in. + +# common-pc brings in the other USB controllers include +features/usb/xhci-hcd.scc And should really bring this one in too... Agreed! + +# Intel ethernet, old and new Intel wireless. +include features/rfkill/rfkill.scc include +features/intel-e1/intel-e1.scc +include features/iwlwifi/iwlwifi.scc include +features/iwlegacy/iwlegacy.scc + +# Intel Gen and GMA500. common-pc provides Vesa framebuffer. +include features/i915/i915.scc +include features/drm-gma500/drm-gma500.scc +include features/drm-gma500/drm-gma3600.scc This is really a fairly small change. Any reason this shouldn't just be an update to common-pc? Is there a conceptual difference here? I'd like to see them just merge. They are both targeting a similar set of commodity hardware platforms. Sure, qemux86 will pick these up as well, but as qemu gains more functionality we can use more and more of the options. ping. Did we collectively slip on this ? I was just trying to debug a serial 8250 issue, and realized that none of the generic x86 parts have merged. Bruce Cheers, Bruce ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto -- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 3/3] emgd-1.18 fix build issues with v3.8 kernel
-Original Message-
From: linux-yocto-boun...@yoctoproject.org [mailto:linux-yocto-
boun...@yoctoproject.org] On Behalf Of Bruce Ashfield
Sent: Wednesday, July 03, 2013 9:01 PM
To: Development list for the linux-yocto*.git Linux kernel repositories
Subject: Re: [linux-yocto] [PATCH 3/3] emgd-1.18 fix build issues with v3.8
kernel
On Tue, Jul 2, 2013 at 3:51 PM, nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
These changes are done according to these existing commits in the v3.8
tree
b0071efe827f68cf173e1a8868b70618e9aca7d7
760285e7e7ab282c25b5e90816f7c47000557f4f
56550d94cbaeaa195cb98c95d012b301cbd65a8d
314e51b9851b4f4e8ab302243ff5a6fc6147f379
a69ac9ea85d87b57166a1c017c5019447b854a68
Can you tweak this header with short hashes and short logs ? That way on a
glance, we can get a feel for what you are adapting to ?
All of the changes look good to me. A resend of just a pull request with that
tweaked header and I'll get this merged.
Bruce
Hi Bruce,
The commit is tweaked as requested. I am not pushing the pull request again,
as these patches are huge.
So instead you can just pull from here:
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-contrib/log/?h=nitin/emgd-1.18
Thanks,
Nitin
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
drivers/gpu/drm/emgd/emgd/drm/emgd_connector.c | 2 +-
drivers/gpu/drm/emgd/emgd/drm/emgd_drv.c| 3 +--
drivers/gpu/drm/emgd/emgd/drm/emgd_fb.c | 10 +-
drivers/gpu/drm/emgd/emgd/drm/emgd_interface.c | 2 +-
drivers/gpu/drm/emgd/emgd/drm/emgd_mmap.c | 2 +-
drivers/gpu/drm/emgd/emgd/drm/emgd_test_pvrsrv.c| 2 +-
drivers/gpu/drm/emgd/pvr/services4/srvkm/env/linux/mmap.c | 2 +-
drivers/gpu/drm/emgd/pvr/services4/srvkm/env/linux/module.c | 2 +-
drivers/gpu/drm/emgd/pvr/services4/srvkm/env/linux/osfunc.c | 2 +-
9 files changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/emgd/emgd/drm/emgd_connector.c
b/drivers/gpu/drm/emgd/emgd/drm/emgd_connector.c
index b62c2ca..6aa461a 100644
--- a/drivers/gpu/drm/emgd/emgd/drm/emgd_connector.c
+++ b/drivers/gpu/drm/emgd/emgd/drm/emgd_connector.c
@@ -299,7 +299,7 @@ static int emgd_connector_set_property(struct
drm_connector *connector,
/* Set the property value to the new one. This doesn't actually
change
* anything on the HW. */
- ret = drm_connector_property_set_value(connector, property,
value);
+ ret = drm_object_property_set_value(connector-base,
+ property, value);
if (ret) {
return ret;
}
diff --git a/drivers/gpu/drm/emgd/emgd/drm/emgd_drv.c
b/drivers/gpu/drm/emgd/emgd/drm/emgd_drv.c
index 58927c6..21f1c41 100755
--- a/drivers/gpu/drm/emgd/emgd/drm/emgd_drv.c
+++ b/drivers/gpu/drm/emgd/emgd/drm/emgd_drv.c
@@ -2372,7 +2372,7 @@ irqreturn_t emgd_driver_irq_handler(int irq,
void *arg) } /* emgd_driver_irq_handler() */
-static int __devinit emgd_pci_probe(struct pci_dev *pdev,
+static int emgd_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *ent) {
if (PCI_FUNC(pdev-devfn)) {
@@ -2503,7 +2503,6 @@ static struct drm_driver driver = {
.irq_postinstall= emgd_driver_irq_postinstall,
.irq_uninstall = emgd_driver_irq_uninstall,
.irq_handler= emgd_driver_irq_handler,
- .reclaim_buffers= drm_core_reclaim_buffers,
#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,37)
.get_map_ofs= drm_core_get_map_ofs,
.get_reg_ofs= drm_core_get_reg_ofs,
diff --git a/drivers/gpu/drm/emgd/emgd/drm/emgd_fb.c
b/drivers/gpu/drm/emgd/emgd/drm/emgd_fb.c
index 8683477..6bd3a47 100644
--- a/drivers/gpu/drm/emgd/emgd/drm/emgd_fb.c
+++ b/drivers/gpu/drm/emgd/emgd/drm/emgd_fb.c
@@ -41,7 +41,7 @@
#include linux/module.h
#endif
#include drmP.h
-#include drm.h
+#include uapi/drm/drm.h
#include drm_crtc.h
#include drm_crtc_helper.h
#include drm_fb_helper.h
@@ -539,7 +539,7 @@ static void create_connector_properties(struct
drm_device *dev,
continue;
}
- drm_connector_attach_property(drm_connector, new_prop,
current_value);
+ drm_object_attach_property(drm_connector-base,
+ new_prop, current_value);
emgd_connector-properties[num_of_properties++] = new_prop;
}
@@ -646,12 +646,12 @@ static void create_connectors(struct drm_device
*dev,
#if 0
-drm_connector_attach_property(connector-base,
+drm_object_attach_property(connector-base,
dev-mode_config.scaling_mode_property,
DRM_MODE_SCALE_FULLSCREEN);
-
Re: [linux-yocto] v3.8 kernel recipes in meta-intel
So the topic branch commit is present much deeper in the branch with different commit-id. May be merging of the emgd branch resulted it. Is it issue with the emgd branch rebased to an undesired point? It shouldn't be. That commit shouldn't be present in the repository at all (it isn't in mine). The emgd branches are off master, same repo and can't bring in something like this. Right. I think it got placed there after merge with the emgd branch done by the kernel-tools. So something is getting tied in a knot when the repository is fetched into the source dir. I don't see any issue with the fetch. As noemgd BSPs are working as expected. For your builds that work, do you have that commit present ? The emenlow-noemgd build sees the right HEAD commit. So the issue is definitely something to do with the merge with the emgd branch. Nitin ___ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] v3.8 kernel recipes in meta-intel
-Original Message- From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] Sent: Tuesday, March 05, 2013 9:50 AM To: Kamble, Nitin A Cc: linux-yo...@yoctoproject.org Subject: Re: v3.8 kernel recipes in meta-intel On 13-03-05 12:35 PM, Kamble, Nitin A wrote: So the topic branch commit is present much deeper in the branch with different commit-id. May be merging of the emgd branch resulted it. Is it issue with the emgd branch rebased to an undesired point? It shouldn't be. That commit shouldn't be present in the repository at all (it isn't in mine). The emgd branches are off master, same repo and can't bring in something like this. Right. I think it got placed there after merge with the emgd branch done by the kernel-tools. That doesn't make sense either. The merge of the emgd branch is just the git merge of a locally staged branch in the linux-yocto repository. That commit you reference shouldn't be in the emgd branch, or any branch if a clean linux-yocto-3.8 tree is being used. Right, so the kernl tools are producing unwanted state of the topic branch when emgd branch is considered. And I guess you would know better why kernl tools are doing it. Nitin Cheers, Bruce So something is getting tied in a knot when the repository is fetched into the source dir. I don't see any issue with the fetch. As noemgd BSPs are working as expected. For your builds that work, do you have that commit present ? The emenlow-noemgd build sees the right HEAD commit. So the issue is definitely something to do with the merge with the emgd branch. Nitin ___ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] v3.8 kernel recipes in meta-intel
Not exactly, I must not be understanding what you are describing. There's no way for the kern-tools to create a commit ID. They can only work with what's present in the tree. If you see the SRCREV to foo, and validate_branches is telling you that foo isn't present in the tree at all, that's not related to the kern tools at all. It's related to the repository that is cloned into the WORKDIR for building. If you can make your recipes and updates public, I can try and do a build here. Bruce, I think I found the issue. The problem is the SRC_URI in the .bbappend is pointing to the linux-yocto-dev repo. I guess that explains all the behavior. Thanks for looking into this. Now it does not look like kern tools issue. Nitin ___ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] v3.8 kernel recipes in meta-intel
-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, March 05, 2013 8:41 AM
To: Kamble, Nitin A
Cc: linux-yocto@yoctoproject.org
Subject: Re: v3.8 kernel recipes in meta-intel
On 13-03-05 11:39 AM, Kamble, Nitin A wrote:
-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, March 05, 2013 8:37 AM
To: Kamble, Nitin A
Cc: linux-yocto@yoctoproject.org
Subject: Re: v3.8 kernel recipes in meta-intel
On 13-03-05 11:33 AM, Kamble, Nitin A wrote:
Hi Bruce,
I am seeing some unexpected behavior of the v3.8 kernel bits.
Here is what I am trying to do.
Something is up with your linux-yocto clone:
Hi Bruce,
This is not with the local repo. As you can see the SRC_URI it is
pointing to the Upstream repo.
By local, I meant the repository the fetcher creates. That commit ID is valid
in
the upstream repository, so there's nothing I can say about why it isn't in
the
clone that is presented for building.
Bruce
Bruce,
I tried doing bitbake cleanall for the linux-yocto recipe. And it removed
my local copy,
and in the next build, it did take lot of time to clone it. But still the same
build error.
I wonder why the same commit topic branch is working for emenlow-noemgd BSP
and does not working for emenlow? The only relevant difference I see here is
SRCURI.
Nitin
Nitin
git show b170394a475b96ecc92cbc9e4b002bed0a9f69c5
commit b170394a475b96ecc92cbc9e4b002bed0a9f69c5
Author: Tom Zanussi tom.zanu...@intel.com
Date: Fri Oct 5 11:35:26 2012 -0500
perf annotate: replace 'expand' with equivalent sed expression
We don't have 'expand' in our userspace so we need to accomplish the
same thing using 'sed', which we do have.
Signed-off-by: Tom Zanussi tom.zanu...@intel.com
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 07aaeea..ff162ae 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -826,7 +826,7 @@ fallback:
snprintf(command, sizeof(command),
%s %s%s --start-address=0x%016 PRIx64
--stop-address=0x%016 PRIx64
- -d %s %s -C %s|grep -v %s|expand,
+ -d %s %s -C %s|grep -v %s|sed 's/\t//g',
objdump_path ? objdump_path : objdump,
disassembler_style ? -M : ,
disassembler_style ? disassembler_style : ,
git branch --contains b170394a475b96ecc92cbc9e4b002bed0a9f69c5
standard/arm-versatile-926ejs
standard/base
standard/beagleboard
standard/ck
standard/common-pc-64/base
standard/common-pc-64/chiefriver
standard/common-pc-64/crystalforest
standard/common-pc-64/jasperforest
standard/common-pc-64/rangeley
standard/common-pc-64/romley
standard/common-pc-64/sugarbay
standard/common-pc/atom-pc
standard/common-pc/base
standard/crownbay
standard/edf
standard/emenlow
standard/fri2
standard/fsl-mpc8315e-rdb
standard/mti-malta32
standard/mti-malta64
standard/preempt-rt/base
standard/preempt-rt/fri2
standard/preempt-rt/qemuppc
standard/preempt-rt/routerstationpro
standard/qemuppc
standard/routerstationpro
standard/sys940x
standard/tiny/base
standard/tiny/common-pc
standard/tiny/fri2
Whereas the tree you have locally doesn't have the commit at all.
Bruce
I am seeing this build error:
ERROR: Function failed: do_validate_branches (see
/srv/home/nitin/build-test-bsps/build-emenlow/tmp/work/emenlow-
poky-li
nux/linux-
yocto/3.8+gitAUTOINC+c2ed0f16fdec628242a682897d5d86df4547cf2
4_b170394a475b96ecc9
2cbc9e4b002bed0a9f69c5-r4.0/temp/log.do_validate_branches.3414 for
further information)
ERROR: Logfile of failure stored in:
/srv/home/nitin/build-test-bsps/build-emenlow/tmp/work/emenlow-
poky-li
nux/linux-
yocto/3.8+gitAUTOINC+c2ed0f16fdec628242a682897d5d86df4547cf2
4_b170394a475b96ecc92cbc9e4b002bed0a9f69c5-
r4.0/temp/log.do_validate_b
ranches.3414
Log data follows:
| DEBUG: Executing shell function do_validate_branches
| error: no such commit b170394a475b96ecc92cbc9e4b002bed0a9f69c5
This is with the master branches of poky oecore + v3.8 bbappends
in the meta-intel layer.
* poky.git : master: commit
93ec7b4d1550e07caec86e2998d0f94a01c7e785
* meta-intel.git : master: commit
4ffe40409f8cd0f354a7488113ef888b42867033
And this is my v3.8 bbappend in the meta-intel
meta-emenlow/recipes-kernel/linux/linux-yocto_3.8.bbappend :
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
COMPATIBLE_MACHINE_emenlow = emenlow
KMACHINE_emenlow = emenlow
KBRANCH_emenlow = standard/emenlow
KERNEL_FEATURES_emenlow_append = features/drm
Re: [linux-yocto] [PATCH 2/2] new feature for I/OAT DMA driver
-Original Message- From: linux-yocto-boun...@yoctoproject.org [mailto:linux-yocto- boun...@yoctoproject.org] On Behalf Of Tom Zanussi Sent: Friday, March 01, 2013 9:19 PM To: Development list for the linux-yocto*.git Linux kernel repositories Subject: Re: [linux-yocto] [PATCH 2/2] new feature for I/OAT DMA driver On Fri, 2013-03-01 at 17:05 -0800, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com This commit implements a new ioatdma feature by providing a config fragment to enable Crystal Forest DMA/DCA (ioatdma) driver configuration for BSP kernels. I'm just wondering if there's any overlap or conflict with the existing dca feature - it seems that they at least have the CONFIG_INTEL_IOATDMA option in common, so wondering whether the existing dca feature could either use the ioatdma feature, or whether this new stuff could be using the dca feature instead. I'm not too familiar with it, so can't say off the top of my head, just pointing it out in case you missed it... features/dca/dca.cfg: CONFIG_INTEL_IOATDMA=m and features/dca/dca.scc: define KFEATURE_DESCRIPTION Enable DCA for IOATDMA capable devices define KFEATURE_COMPATIBILITY board kconf hardware dca.cfg include cfg/dmaengine.scc Hi Tom, Good you found this overlap. This is the same feature with a different name. I will update my pull request accordingly. Nitin Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com --- meta/cfg/kernel-cache/features/ioatdma/ioatdma.cfg |1 + meta/cfg/kernel-cache/features/ioatdma/ioatdma.scc |1 + 2 files changed, 2 insertions(+), 0 deletions(-) create mode 100644 meta/cfg/kernel-cache/features/ioatdma/ioatdma.cfg create mode 100644 meta/cfg/kernel- cache/features/ioatdma/ioatdma.scc diff --git a/meta/cfg/kernel-cache/features/ioatdma/ioatdma.cfg b/meta/cfg/kernel-cache/features/ioatdma/ioatdma.cfg new file mode 100644 index 000..b62aab2 --- /dev/null +++ b/meta/cfg/kernel-cache/features/ioatdma/ioatdma.cfg @@ -0,0 +1 @@ +CONFIG_INTEL_IOATDMA=y diff --git a/meta/cfg/kernel-cache/features/ioatdma/ioatdma.scc b/meta/cfg/kernel-cache/features/ioatdma/ioatdma.scc new file mode 100644 index 000..f1951a6 --- /dev/null +++ b/meta/cfg/kernel-cache/features/ioatdma/ioatdma.scc @@ -0,0 +1 @@ +kconf hardware ioatdma.cfg ___ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto ___ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 0/2] NTB IOATDMA features for v3.8 kernel repo
-Original Message- From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] Sent: Friday, March 01, 2013 9:07 PM To: Kamble, Nitin A Cc: linux-yo...@yoctoproject.org Subject: Re: [PATCH 0/2] NTB IOATDMA features for v3.8 kernel repo On 13-03-01 8:05 PM, nitin.a.kam...@intel.com wrote: From: Nitin A Kamblenitin.a.kam...@intel.com Hi Bruce, I have prepared commits for enabling non-transparent-bridge and Crystal-Beach-DMA/DCA drivers in the kernel. This is needed to implement features in this bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2465 I have created a new ntb git branch for the ntb feature. The branch is pushed here: http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-contrib/log/?h=n itin/ntb As it is a new branch for kernel repo, I am not sending individual commits over ML. You can directly fetch the ntb branch in the v3.8 repo. And new features for ioatdma (aka Crystal Beach DMA/DCA) ntb (non transparent bridge) are created in the meta branch over here: http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-contrib/log/?h=n itin/meta Nitin, In general this looks pretty good. I've been tracking NTB development for quite some time, so luckily I'm aware of the challenges working with the feature. Just a few questions. - I assume this has passed build tests ? - Who's doing the NTB runtime testing ? I've seen this code in the past, and while it builds relatively easily .. getting it tested is more of a challenge. And a request .. I realize that this wouldn't have been obvious when you were working on this, but that's what the mailing list review is for! This feature in particular shouldn't be staged as a branch and merged, so just set it up as a .scc file (as you have it) without the patches. If you want the patches to be applied whenever ntb-common.scc is included, let me know and that's where I'll place them. I'll then merge these changes to the standard/base branch to make them available to all BSPs. You are probably wondering why it shouldn't be a topic branch and merged. The reason comes down to the fact that it will conflict with both mainline development and BSP work. This is an active area of development (and hence bug fixing as well), so the chances of a topic branch conflicting and failing to merge are high. I'll need to resolve those conflicts in tree while stacking patches, I can't do that with a topic branch. Features that usually get a topic branch are: - features that are largely developed out of tree - features that are orthogonal to other code in the tree, and don't touch many common files - features that may have active development, where we want to track the history separately (versus patch based history) or we want to track a significant amount of commits. - features that will update/upgrade and migrate over time. - just because :) With that set of criteria, things like graphics drivers (emgd, or schedulers (EDF)) get topic branches. But other features like preempt-rt (it will always conflict) or lttng-1.x don't get topic branches. And that's why ntb really shouldn't have one either. IF we have to many topic branches, we'll end up with patch time merge failures of the topic branches .. which are difficult to resolve. It should be a simple thing to re-order (since the content is all largely the same) .. and will take less time that I did typing all this up :) Cheers, Bruce Hi Bruce, Thanks for explaining the process to me. I understand and agree with the reason of putting these bits in the base branch. This pull request from me was more of a RFC. I will do some more build testing with the new layout of commits. And send another pull for this. Thanks, Nitin Thanks, Nitin The following changes since commit c2ed0f16fdec628242a682897d5d86df4547cf24: checkpoint dir: meta (2013-02-24 22:43:59 -0500) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-contrib nitin/meta http://git.yoctoproject.org/cgit.cgi/linux-yocto-contrib/log/?h=nitin/ meta Nitin A Kamble (2): new feature for non-transparent-bridge driver new feature for I/OAT DMA driver meta/cfg/kernel-cache/features/ioatdma/ioatdma.cfg |1 + meta/cfg/kernel-cache/features/ioatdma/ioatdma.scc |1 + meta/cfg/kernel-cache/features/ntb/ntb.cfg |1 + meta/cfg/kernel-cache/features/ntb/ntb.scc |2 ++ 4 files changed, 5 insertions(+), 0 deletions(-) create mode 100644 meta/cfg/kernel- cache/features/ioatdma/ioatdma.cfg create mode 100644 meta/cfg/kernel- cache/features/ioatdma/ioatdma.scc create mode 100644 meta/cfg/kernel-cache/features/ntb/ntb.cfg create mode 100644 meta/cfg/kernel-cache/features/ntb/ntb.scc ___ linux-yocto mailing list
Re: [linux-yocto] [PATCH 0/1] meta: add emgd-1.16 driver support
-Original Message- From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] Sent: Tuesday, January 22, 2013 1:04 PM To: Kamble, Nitin A Cc: linux-yo...@yoctoproject.org Subject: Re: [PATCH 0/1] meta: add emgd-1.16 driver support On 13-01-22 03:38 PM, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com Here is a commit which adds an scc file for emgd-1.16 feature. It depends on the emgd-1.16 branch in the kernel repo, for which a pull request is already sent. This commit keeps the emgd-1.14 driver support in the repo intact. merged. and pushed. SRCREV updates to follow, but you can test it locally before I do the updates. Bruce With current autorev it's ok. I am checking it here locally. Thanks for pushing, Nitin Thanks, Nitin The following changes since commit c0b3904d60830e24b3930b0fa606a48b2758d979: meta: add config fragment for gma600 graphics driver (2013-01-18 23:07:15 -0500) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-2.6.37-contrib nitin/meta http://git.yoctoproject.org/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h =nitin/meta Nitin A Kamble (1): meta: add a kernel feature for drm-emgd-1.16 driver .../features/drm-emgd/drm-emgd-1.16.scc|2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) create mode 100644 meta/cfg/kernel-cache/features/drm-emgd/drm-emgd-1.16.scc ___ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] a new kernel repo branch for emgd 1.16 driver
Hi Bruce, I have created a branch for emgd-1.16 kernel driver for the v3.4 kernel repo over here. http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=nitin/emgd-1.16 It consists of mainly following 2 commits on top of the standard/base branch. Can you pull this branch in the v3.4 YP kernel repository so that BSPs can start using emgd 1.16 driver for graphics? Thanks, Nitin commit 39fa5392e05b98a1bd107a5c77f06679adc917e6 Author: Nitin A Kamble nitin.a.kam...@intel.com Date: Fri Jan 18 21:02:20 2013 -0800 emgd: enable building within the kernel sources Modify the build mechanism so that emgd can be configured and built as a feature of the kernel. Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com commit 99ae3010eeb048bd6fd63b554e2e3c6fddd80afa Author: Nitin A Kamble nitin.a.kam...@intel.com Date: Fri Jan 18 19:51:03 2013 -0800 emgd: add emgd 1.16 driver sources This is starting-point code that subsequent patches will modify. This is a virgin copy of the code from the emgd 1.16 driver. This code is coming from IEMGD_HEAD_Linux/common/drm/emgd_drm.tgz which is a piece from the 'Linux Tar Ball' release of EMGD 1.16 downloaded from here: https://edc.intel.com/App_Shared/Downloads/LIN_IEMGD_1_16_GOLD_3228.tgz Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com ___ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [meta branch v3 01/12] meta: relocate git-merge of emgd branch
-Original Message- From: Zanussi, Tom Sent: Thursday, January 17, 2013 1:55 PM To: Kamble, Nitin A Cc: bruce.ashfi...@windriver.com; Hart, Darren; linux- yo...@yoctoproject.org Subject: Re: [meta branch v3 01/12] meta: relocate git-merge of emgd branch On Wed, 2013-01-16 at 11:23 -0800, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com Move git-merge of emgd branch out from the bsp area and into the features area Just a minor nit - can you please proofread for obvious typos like below before submitting? Thanks Tom for catching this, and sorry for I missing these typos. I have corrected these from all the commit messages on the contrib branch. Nitin This change avoids getting emged sources unnecessarily included in the ^ noemgd bsp kernel sources. This addresses this bug/feature rquest: ^^ Thanks, Tom [YOCTO #2268] Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com --- .../bsp/crownbay/crownbay-standard.scc |2 -- .../kernel-cache/bsp/emenlow/emenlow-standard.scc |2 -- meta/cfg/kernel-cache/bsp/fri2/fri2-standard.scc |2 -- .../kernel-cache/bsp/sys940x/sys940x-standard.scc |2 -- .../kernel-cache/features/drm-emgd/drm-emgd.scc|1 + 5 files changed, 1 insertions(+), 8 deletions(-) diff --git a/meta/cfg/kernel-cache/bsp/crownbay/crownbay-standard.scc b/meta/cfg/kernel-cache/bsp/crownbay/crownbay-standard.scc index 3db03de..9fe4776 100644 --- a/meta/cfg/kernel-cache/bsp/crownbay/crownbay-standard.scc +++ b/meta/cfg/kernel-cache/bsp/crownbay/crownbay-standard.scc @@ -5,8 +5,6 @@ define KARCH i386 include ktypes/standard branch crownbay -git merge emgd-1.14 - include crownbay.scc # default policy for standard kernels diff --git a/meta/cfg/kernel-cache/bsp/emenlow/emenlow-standard.scc b/meta/cfg/kernel-cache/bsp/emenlow/emenlow-standard.scc index a2094ef..3526a18 100644 --- a/meta/cfg/kernel-cache/bsp/emenlow/emenlow-standard.scc +++ b/meta/cfg/kernel-cache/bsp/emenlow/emenlow-standard.scc @@ -5,8 +5,6 @@ define KARCH i386 include ktypes/standard branch emenlow -git merge emgd-1.14 - include emenlow.scc # default policy for standard kernels diff --git a/meta/cfg/kernel-cache/bsp/fri2/fri2-standard.scc b/meta/cfg/kernel-cache/bsp/fri2/fri2-standard.scc index fc47a2e..029eafa 100644 --- a/meta/cfg/kernel-cache/bsp/fri2/fri2-standard.scc +++ b/meta/cfg/kernel-cache/bsp/fri2/fri2-standard.scc @@ -5,8 +5,6 @@ define KARCH i386 include ktypes/standard branch fri2 -git merge emgd-1.14 - include fri2.scc # Extra fri2 configs above the minimal defined in fri2.scc diff --git a/meta/cfg/kernel-cache/bsp/sys940x/sys940x-standard.scc b/meta/cfg/kernel-cache/bsp/sys940x/sys940x-standard.scc index 3149a3e..7b21cbc 100644 --- a/meta/cfg/kernel-cache/bsp/sys940x/sys940x-standard.scc +++ b/meta/cfg/kernel-cache/bsp/sys940x/sys940x-standard.scc @@ -5,8 +5,6 @@ define KARCH i386 include ktypes/standard branch sys940x -git merge emgd-1.14 - include sys940x.scc include cfg/efi-ext.scc diff --git a/meta/cfg/kernel-cache/features/drm-emgd/drm-emgd.scc b/meta/cfg/kernel-cache/features/drm-emgd/drm-emgd.scc index 672ee2e..01bcec8 100644 --- a/meta/cfg/kernel-cache/features/drm-emgd/drm-emgd.scc +++ b/meta/cfg/kernel-cache/features/drm-emgd/drm-emgd.scc @@ -1 +1,2 @@ kconf hardware drm-emgd.cfg +git merge emgd-1.14 ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [yocto] [PATCH 0/1] Misc: detect trailing space in the patches
From: Daniel Stone [mailto:dan...@fooishbar.org] Sent: Wednesday, December 05, 2012 9:48 PM To: Martin Jansa Cc: Kamble, Nitin A; yocto@yoctoproject.org Subject: Re: [yocto] [PATCH 0/1] Misc: detect trailing space in the patches Hi, On 6 December 2012 15:23, Martin Jansa martin.ja...@gmail.commailto:martin.ja...@gmail.com wrote: Can you add also detection of mixed whitespace? E.g. tab followed by space in multilinear indentation? Only as warning. Thanks These checks can generate infuriating false positives when your patch modifies upstream code which has trailing or mixed whitespace in either context or removal lines; in this case, removing a line with trailing whitespace and replacing it with one which doesn't would generate a warning. Mixed whitespace is also part of some coding styles, notably the kernel's. Cheers, Daniel This code checks for the trialing whitespace only in the lines added by the patches. The context lines or removed lines are not checked. It is easy to check for mixed whitespace also, but before doing that I would like to know the final decision about it, as I see some objection to it too. Thanks, Nitin ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/4] misc fixes for 1.3 meta-intel release
-Original Message- From: Zanussi, Tom Sent: Wednesday, October 31, 2012 1:58 PM To: Burton, Ross Cc: Kamble, Nitin A; Hart, Darren; yocto@yoctoproject.org Subject: Re: [PATCH 0/4] misc fixes for 1.3 meta-intel release On Wed, 2012-10-31 at 20:53 +, Burton, Ross wrote: On 31 October 2012 15:21, Burton, Ross ross.bur...@intel.com wrote: On 31 October 2012 15:17, Tom Zanussi tom.zanu...@intel.com wrote: That just leaves cedartrail before we can pull this in. That's odd, I was just about to write a mail. My current images are broken as they are based on master which has a duff udev. I'll do a rebuild against danny but that might not happen promptly. Just tested on Cedar Trail, good old Sintel plays fine at 4% CPU. OK, sounds like it works everywhere, so can be pulled in, but... Nitin, did you need to refresh this patchset to .18 or should I pull this in and pull in a .18 update later? Tom, The patch set is not at the latest versions of libva components. Nitin Tom Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Patch v2 0/4] Misc Fixes for meta-intel 1.3 release
-Original Message- From: Zanussi, Tom Sent: Thursday, November 01, 2012 6:33 AM To: Hart, Darren Cc: Kamble, Nitin A; yocto@yoctoproject.org; Burton, Ross Subject: Re: [Patch v2 0/4] Misc Fixes for meta-intel 1.3 release On Wed, 2012-10-31 at 22:26 -0700, Darren Hart wrote: On 10/31/2012 10:14 PM, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com This v2 pull request is with newer version of libva-intel-driver. These commits tested on All the BSPs I am maintaining with expected results. Nitin, do these patches fix any specific bug? Such as 3348? You mention a couple, but not clearly that these patches fix them. If so, please include: Fixes [YOCTO #] in the commit log for the associated patch(es). To save time, I'll go ahead and add that to those 2 patches when I pull it in... Thanks Tom, Nitin Tom Otherwise this looks to be what we have discussed. Thanks, Darren Thanks, Nitin The following changes since commit 43b2e9c34363ade4241a60f699b47179929c6fb6: n450: Add WEBTITLE and boilerplate README (2012-10-31 08:40:15 -0700) are available in the git repository at: git://git.yoctoproject.org/meta-intel-contrib nitin/misc http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=nitin /misc Nitin A Kamble (3): libva: update to the latest version libva-intel-driver: update to the latest version mesa-dri.bbappend: avoid conflict with emgd-driver-bin Ross Burton (1): libva: remove redundant libva 1.0.12 .../recipes-graphics/mesa/mesa-dri_8.0.4.bbappend | 27 +--- .../libva/libva-intel-driver.inc |2 +- .../libva/libva-intel-driver_1.0.15.bb |8 -- .../libva/libva-intel-driver_1.0.18.bb |8 ++ common/recipes-multimedia/libva/libva_1.0.12.bb|8 -- common/recipes-multimedia/libva/libva_1.0.15.bb|8 -- common/recipes-multimedia/libva/libva_1.0.16.bb|8 ++ 7 files changed, 40 insertions(+), 29 deletions(-) delete mode 100644 common/recipes-multimedia/libva/libva-intel-driver_1.0.15.bb create mode 100644 common/recipes-multimedia/libva/libva-intel-driver_1.0.18.bb delete mode 100644 common/recipes-multimedia/libva/libva_1.0.12.bb delete mode 100644 common/recipes-multimedia/libva/libva_1.0.15.bb create mode 100644 common/recipes-multimedia/libva/libva_1.0.16.bb ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 4/4] mesa-dri.bbappend: avoid conflict with emgd-driver-bin
-Original Message- From: Burton, Ross [mailto:ross.bur...@intel.com] Sent: Wednesday, October 31, 2012 10:14 AM To: Kamble, Nitin A Cc: Zanussi, Tom; Hart, Darren; yocto@yoctoproject.org Subject: Re: [yocto] [PATCH 4/4] mesa-dri.bbappend: avoid conflict with emgd-driver-bin Hi, On 31 October 2012 02:23, nitin.a.kam...@intel.com wrote: Extend the mesa-dri recipe from oecore to avoid conflict with files generated by emgd-driver-bin recipe. The same problem happens with cdv-pvr-driver, right? Yes, I have heard about the issue from Rahul. It turns out that the binary DRI drivers these closed driver packages install are very dependent on the Mesa - so it's likely that they just don't work with our Mesa 8.0.4. cdv-pvr-driver needs Mesa 7.11. I can't see anything in the documentation about what version of Mesa EMGD expects. EMGD tarball release notes do mention Mesa version dependencies. We have not seen issues with the newer version of mesa, so went ahead with the newer versions of Mesa, while pinning the Mesa version in the machine.conf. I think we've two options: either don't ship libGL in our BSP packages, or ship a version that should actually work. This means shipping a mesa recipe in meta-intel so that it's under meta-intel's control, with the useful side effect that we can make it just build libGL and nothing else. These are the right options IMO. We can also get complete mesa recipe in meta-intel, which will override the one from oecore layer completely. Then we have full control of mesa from meta-intel layers. Currently extending the oecore mesa recipe from meta-intel is not very elegant, but at least it is working as we want. Also making few changes to the oecore mesa recipe will make it easier to extend it from other layers. Nitin Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/4] misc fixes for 1.3 meta-intel release
-Original Message- From: Zanussi, Tom Sent: Wednesday, October 31, 2012 8:18 AM To: Kamble, Nitin A Cc: Hart, Darren; yocto@yoctoproject.org; Burton, Ross Subject: Re: [PATCH 0/4] misc fixes for 1.3 meta-intel release On Tue, 2012-10-30 at 19:23 -0700, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com Tested these on all BSPs i maintain with results as expected. Also this testing Acks the kernel SRCREV bumps done by Tom today. I've verified this works fine on crownbay and you've verified on sugarbay and chiefriver, correct? Correct. I tested this with all BSPs I am maintaining. That just leaves cedartrail before we can pull this in. As Ross mentioned we can update the libva-intel-driver further to 1.0.18. I will try that here today. Even if we don't get that we still have a working tree for BSPs now. Nitin Tom Thanks, Nitin The following changes since commit 76d2942087d7563ae42f0bea6d97460ee2561f3e: crystalforest: Update the README Instructions. (2012-10-30 08:47:40 -0500) are available in the git repository at: git://git.yoctoproject.org/meta-intel-contrib nitin/misc http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=nitin/m isc Nitin A Kamble (3): libva: update to the latest version libva-intel-driver: update to the latest version mesa-dri.bbappend: avoid conflict with emgd-driver-bin Ross Burton (1): libva: remove redundant libva 1.0.12 .../recipes-graphics/mesa/mesa-dri_8.0.4.bbappend | 27 +--- .../libva/libva-intel-driver.inc |2 +- .../libva/libva-intel-driver_1.0.15.bb |8 -- .../libva/libva-intel-driver_1.0.17.bb |9 ++ common/recipes-multimedia/libva/libva_1.0.12.bb|8 -- common/recipes-multimedia/libva/libva_1.0.15.bb|8 -- common/recipes-multimedia/libva/libva_1.0.16.bb|8 ++ 7 files changed, 41 insertions(+), 29 deletions(-) delete mode 100644 common/recipes-multimedia/libva/libva-intel-driver_1.0.15.bb create mode 100644 common/recipes-multimedia/libva/libva-intel-driver_1.0.17.bb delete mode 100644 common/recipes-multimedia/libva/libva_1.0.12.bb delete mode 100644 common/recipes-multimedia/libva/libva_1.0.15.bb create mode 100644 common/recipes-multimedia/libva/libva_1.0.16.bb ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 3/6] crownbay README: add WebTitle Compliance information
-Original Message- From: Zanussi, Tom Sent: Wednesday, October 24, 2012 9:43 AM To: Kamble, Nitin A Cc: yocto@yoctoproject.org; Hart, Darren Subject: Re: [PATCH 3/6] crownbay README: add WebTitle Compliance information On Wed, 2012-10-24 at 11:06 -0500, Kamble, Nitin A wrote: -Original Message- From: Zanussi, Tom Sent: Tuesday, October 23, 2012 2:16 PM To: Kamble, Nitin A Cc: yocto@yoctoproject.org; Hart, Darren Subject: Re: [PATCH 3/6] crownbay README: add WebTitle Compliance information On Tue, 2012-10-23 at 13:24 -0700, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com The WebTitle will be used to publish the BSP on the Yocto Project Website. And adding the Yocto Project Compliance information for the 1.3 release. Also specifying all the layers used from meta-intel repository. Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com --- meta-crownbay/README | 13 +++-- 1 files changed, 11 insertions(+), 2 deletions(-) diff --git a/meta-crownbay/README b/meta-crownbay/README index 4bc9f31..3996a94 100644 --- a/meta-crownbay/README +++ b/meta-crownbay/README @@ -2,13 +2,22 @@ This README file contains information on building the meta-crownbay BSP layer, and booting the images contained in the /binary directory. Please see the corresponding sections below for details. -The Crown Bay platform consists of the Intel Atom Z6xx processor, +The Crown Bay platform consists of the Intel Atom E6xx processor, plus the Intel EG20T Platform Controller Hub (Tunnel Creek + Topcliff). It also supports the E6xx embedded on-chip graphics via the Intel Embedded Media and Graphics Driver (EMGD) 1.14 Driver. +WebTitle: Intel Atom E6xx processor with Intel EG20T Controller +Hub development kit (crownbay) + I'm not sure this kind of thing should be in the README since we can have multiple downloadable BSPs per layer e.g. crownbay vs crownbay-noemgd. I suppose in keeping with the build system you could have separate WebTitle_crownbay and WebTitle_crownbay- noemgd lines. ;-) (and it would be nice if you could get rid of the CamelCaps too) Why not put this info in the machine.conf, where we already have fields meant to be machine parseable e.g. #@TYPE: Machine #@NAME: crownbay #@WEBTITLE: ... Or maybe just use the exisiting #@DESCRIPTION for that... For example in the current way the BSPs are published, this is shown on the YP website for crownbay Intel Atom Processor E660 with Intel Platform Controller Hub EG20T Development Kit Version: 7.0 Denzil Release date: 29 Jun 2012 Type: BSP Download Links: Crown Bay Crown Bay no EMGD Release Notes So there is one BSP list item per h/w with multiple links to different BSP tarballs for the same hardware. If we move the WebTitle in machine file, then we will have multiple items in the BSP list for the same hardware. I am not sure which is better from the downloader's point of view. But this is worth considering for this change. Yeah, on the one hand if we have text that's the same for all BSPs in the layer, it could go in the README for lack of a better common place. But we should consider whether we want to lay things out as the crownbay above, or more like the cedartrail, which has: Intel® Atom™ Processor N2000 and D2000 Series-based Platform (CEDAR TRAIL) with PowerVR Graphics (there's no corresponding -nopvr version available, though I suspect that's an oversight and would have been something like: Intel® Atom™ Processor N2000 and D2000 Series-based Platform (CEDAR TRAIL) with VESA Graphics I'm not sure the field(s) need to map exactly to the page layout, but all the information should be there to allow the page to be generated or laid out by hand without having to ask questions, in either case. Did you have any idea as to how for example to distinguish between the emgd and -noemgd versions (side note: there's nothing in the current entry that tells the user what EMGD even is - should it at least be spelled out in the title, or do we need a separate subtext element to describe that?) I think for crownbay we should add in the title with proprietary IEMGD accelerated graphics drivers, and for crownbay-noemgd we should add with open source VESA graphics drivers And then these can go in the machine.conf files. It will make our list of BSPs bigger, but it will be clearer to people, who want to download a BSP from YP site. Shall we add these title requirements in the BSP standard format, so that other BSP provider's follow the same practice? Nitin Tom + +Compliance: + For consistency with the rest of the README, please remove the colon and clean up the underlining. Will do. Thanks
Re: [yocto] [PATCH 3/6] crownbay README: add WebTitle Compliance information
-Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Sean Liming Sent: Wednesday, October 24, 2012 11:16 AM To: yocto@yoctoproject.org Subject: Re: [yocto] [PATCH 3/6] crownbay README: add WebTitle Compliance information -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Tom Zanussi Sent: Wednesday, October 24, 2012 9:43 AM To: Kamble, Nitin A Cc: yocto@yoctoproject.org; Hart, Darren Subject: Re: [yocto] [PATCH 3/6] crownbay README: add WebTitle Compliance information On Wed, 2012-10-24 at 11:06 -0500, Kamble, Nitin A wrote: -Original Message- From: Zanussi, Tom Sent: Tuesday, October 23, 2012 2:16 PM To: Kamble, Nitin A Cc: yocto@yoctoproject.org; Hart, Darren Subject: Re: [PATCH 3/6] crownbay README: add WebTitle Compliance information On Tue, 2012-10-23 at 13:24 -0700, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com The WebTitle will be used to publish the BSP on the Yocto Project Website. And adding the Yocto Project Compliance information for the 1.3 release. Also specifying all the layers used from meta-intel repository. Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com --- meta-crownbay/README | 13 +++-- 1 files changed, 11 insertions(+), 2 deletions(-) diff --git a/meta-crownbay/README b/meta-crownbay/README index 4bc9f31..3996a94 100644 --- a/meta-crownbay/README +++ b/meta-crownbay/README @@ -2,13 +2,22 @@ This README file contains information on building the meta-crownbay BSP layer, and booting the images contained in the /binary directory. Please see the corresponding sections below for details. -The Crown Bay platform consists of the Intel Atom Z6xx processor, +The Crown Bay platform consists of the Intel Atom E6xx +processor, plus the Intel EG20T Platform Controller Hub (Tunnel Creek + Topcliff). It also supports the E6xx embedded on-chip graphics via the Intel Embedded Media and Graphics Driver (EMGD) 1.14 Driver. +WebTitle: Intel Atom E6xx processor with Intel EG20T Controller +Hub development kit (crownbay) + I'm not sure this kind of thing should be in the README since we can have multiple downloadable BSPs per layer e.g. crownbay vs crownbay-noemgd. I suppose in keeping with the build system you could have separate WebTitle_crownbay and WebTitle_crownbay- noemgd lines. ;-) (and it would be nice if you could get rid of the CamelCaps too) Why not put this info in the machine.conf, where we already have fields meant to be machine parseable e.g. #@TYPE: Machine #@NAME: crownbay #@WEBTITLE: ... Or maybe just use the exisiting #@DESCRIPTION for that... For example in the current way the BSPs are published, this is shown on the YP website for crownbay Intel Atom Processor E660 with Intel Platform Controller Hub EG20T Development Kit Version: 7.0 Denzil Release date: 29 Jun 2012 Type: BSP Download Links: Crown Bay Crown Bay no EMGD Release Notes So there is one BSP list item per h/w with multiple links to different BSP tarballs for the same hardware. If we move the WebTitle in machine file, then we will have multiple items in the BSP list for the same hardware. I am not sure which is better from the downloader's point of view. But this is worth considering for this change. Yeah, on the one hand if we have text that's the same for all BSPs in the layer, it could go in the README for lack of a better common place. But we should consider whether we want to lay things out as the crownbay above, or more like the cedartrail, which has: Intel® Atom™ Processor N2000 and D2000 Series-based Platform (CEDAR TRAIL) with PowerVR Graphics (there's no corresponding -nopvr version available, though I suspect that's an oversight and would have been something like: Intel® Atom™ Processor N2000 and D2000 Series-based Platform (CEDAR TRAIL) with VESA Graphics I'm not sure the field(s) need to map exactly to the page layout, but all the information should be there to allow the page to be generated or laid out by hand without having to ask questions, in either case. Did you have any idea as to how for example to distinguish between the emgd and -noemgd versions (side note: there's nothing in the current entry that tells the user what EMGD even is - should it at least be spelled out in the title, or do we need a separate subtext element to describe that?) Tom I am working with CEDAR trail and Crown Bay-like (SYS940X-ECX) systems. For Crown Bay, it is a little confusing to know which
Re: [yocto] [PATCH 3/6] crownbay README: add WebTitle Compliance information
-The Crown Bay platform consists of the Intel Atom Z6xx processor, +The Crown Bay platform consists of the Intel Atom E6xx processor, plus the Intel EG20T Platform Controller Hub (Tunnel Creek + Topcliff). How can we distinguish this from Queens Bay, which I would describe in exactly the same terms? -- Darren 1st let us understand what are the differences in the crownbay queens bay platforms? If there are not significant differences then we can also look at possibility of combining two BSPs into one. I can add bit more information in the crownbay readme, such as shellbay littlebay boards. And for FRI2 you can talk about the extra M2M devices. And I am not clear how to differentiate crownbay BSP with sys94x BSP. Nitin ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 2/3][meta-intel] meta-intel/common: Add new recipe for libcrypto module.
Hi Kishore,
Will this recipe is being used for multiple BSPs? If not then it can go in
the BSP specific layer.
Thanks,
Nitin
-Original Message-
From: Bodke, Kishore K
Sent: Thursday, October 18, 2012 11:19 AM
To: Zanussi, Tom; Kamble, Nitin A; yocto@yoctoproject.org
Cc: Bodke, Kishore K
Subject: [PATCH 2/3][meta-intel] meta-intel/common: Add new recipe for
libcrypto module.
From: Kishore Bodke kishore.k.bo...@intel.com
This adds a new recipe to include the Intel Quick Assist Technology libcrypto
Memory Management Module.
Signed-off-by: Kishore Bodke kishore.k.bo...@intel.com
---
.../openssl-qat-module/openssl-qat-module.bb | 54
.../openssl-qat-module/openssl_qat_module.patch| 43
2 files changed, 97 insertions(+)
create mode 100644 common/recipes-connectivity/openssl-qat-
module/openssl-qat-module.bb
create mode 100644 common/recipes-connectivity/openssl-qat-
module/openssl-qat-module/openssl_qat_module.patch
diff --git a/common/recipes-connectivity/openssl-qat-module/openssl-qat-
module.bb b/common/recipes-connectivity/openssl-qat-module/openssl-
qat-module.bb
new file mode 100644
index 000..a4fe3c5
--- /dev/null
+++ b/common/recipes-connectivity/openssl-qat-module/openssl-qat-
module.
+++ bb
@@ -0,0 +1,54 @@
+SUMMARY = libcrypto* (OpenSSL*) QAT_MEM Memory Management
Module \ for
+Intel Quick Assist Technology
+DESCRIPTION = This software adds an engine that accelerates some of \
+the libcrypto algorithms via the Intel QuickAssist Technology \
+implemented on Intel Communications Chipset 89xx Series based
platforms.
+
+HOMEPAGE = http://www.openssl.org/;
+SECTION = libs/network
+
+LICENSE = openssl
+LIC_FILES_CHKSUM = file://${WORKDIR}/openssl-
${PV}/LICENSE;md5=f9a8f968107345e0b75aa8c2ecaa7ec8
+
+PV = 1.0.1
+PR = r0
+
+OPENSSL_QAT_VERSION = 0.4.0-012
+
+SRC_URI = http://www.openssl.org/source/openssl-
${PV}.tar.gz;name=openssl \
+ http://downloadmirror.intel.com/19368/eng/libcrypto-openssl-
${PV}-qat.L.${OPENSSL_QAT_VERSION}.tar.gz;name=libcrypto \
+ file://openssl_qat_module.patch
+
+SRC_URI[openssl.md5sum]=134f168bc2a8333f19f81d684841710b
+SRC_URI[openssl.sha256sum]=4d9f0a594a9a89b28e1a04a9504c04104f6508
ee27ad1e0efdd17a7a6dbb
+
+SRC_URI[libcrypto.md5sum] = e4e131fa56d3aa1a52b5bdb9f8fe5a69
+SRC_URI[libcrypto.sha256sum] =
19a80ae6e78548934295d312148e4254c18dabd25e2fd72de5796d8ac15b1cfb
+
+S = ${WORKDIR}/openssl-${PV}/engines/qat_engine/qat_mem
+
+export KERNEL_SOURCE_ROOT = ${STAGING_KERNEL_DIR}
+inherit module
+
+do_patch() {
+ cd ${WORKDIR}/openssl-${PV}
+ patch -p2
+${WORKDIR}/libcrypto-openssl-${PV}-
qat.L.${OPENSSL_QAT_VERSION}.patch
+
+ cd ${WORKDIR}
+ patch -p1 ${WORKDIR}/openssl_qat_module.patch
+}
+
+do_compile() {
+ cd ${S}
+ oe_runmake KERNEL_CC=${KERNEL_CC}
+}
+
+do_install_append() {
+ install -m 0755 -d ${D}${bindir} \
+${D}${includedir}/engines/qat_engine/qat_mem
+
+ install -m 0755 ${S}/qat_mem_test ${D}${bindir}
+ install -m 0750 ${S}/*.h
${D}${includedir}/engines/qat_engine/qat_mem/
+}
+
+FILES_${PN} += ${bindir}/qat_mem_test
diff --git a/common/recipes-connectivity/openssl-qat-module/openssl-qat-
module/openssl_qat_module.patch b/common/recipes-
connectivity/openssl-qat-module/openssl-qat-
module/openssl_qat_module.patch
new file mode 100644
index 000..dfed3c0
--- /dev/null
+++ b/common/recipes-connectivity/openssl-qat-module/openssl-qat-
module/
+++ openssl_qat_module.patch
@@ -0,0 +1,43 @@
+Index:
+openssl-qat-module-1.0.1-r0/openssl-
1.0.1/engines/qat_engine/qat_mem/Ma
+kefile
+=
==
+--- openssl-qat-module-1.0.1-r0.orig/openssl-
1.0.1/engines/qat_engine/qat_mem/Makefile 2012-10-17
13:31:27.932376960 -0700
openssl-qat-module-1.0.1-r0/openssl-
1.0.1/engines/qat_engine/qat_mem/Makefile 2012-10-17
13:35:40.396389410 -0700
+@@ -9,13 +9,9 @@
+ MODULENAME := qat_mem
+ ### should not need to change stuff below ##
+
+-
+-KDIR:= /lib/modules/$(shell uname -r)/build
+-#KDIR := /exports/linux-2.6.12.2/
++KDIR:= $(KERNEL_SOURCE_ROOT)
+ PWD := $(shell pwd)
+-
+-CC := gcc -Wall -imacros /usr/src/kernels/$(shell uname -
r)/include/linux/autoconf.h
+-
++CC := $(KERNEL_CC) -Wall -imacros
$(KERNEL_SOURCE_ROOT)/include/generated/autoconf.h
+ ifeq ($(KERNELRELEASE),)
+ all:$(MODULENAME)_test
+ all:
+@@ -23,20 +19,15 @@
+ else
+ obj-m := $(MODULENAME).o
+ endif
+-
+ $(MODULENAME)_test: $(MODULENAME)_test.c
+ $(CC) -g -o $(MODULENAME)_test $(MODULENAME)_test.c
+-
+-
++modules_install:
++$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules_install
+ load:
+ insmod ./$(MODULENAME).ko
+-
+ unload
Re: [yocto] [PATCH 1/3] [meta-intel] meta-intel/common:Add a new recipe for Zlib qat_mem Module.
Hi Kishore,
Same here, if it is not used by multiple BSPs yet, then it should go in the
BSP specific layer.
Thanks,
Nitin
-Original Message-
From: Bodke, Kishore K
Sent: Thursday, October 18, 2012 11:19 AM
To: Zanussi, Tom; Kamble, Nitin A; yocto@yoctoproject.org
Cc: Bodke, Kishore K
Subject: [PATCH 1/3] [meta-intel] meta-intel/common:Add a new recipe for
Zlib qat_mem Module.
From: Kishore Bodke kishore.k.bo...@intel.com
This adds a new recipe to build the Intel Quick Assist Technology Memory
Management Module for Zlib.
Signed-off-by: Kishore Bodke kishore.k.bo...@intel.com
---
.../zlib-qat-module/zlib-qat-module.bb | 52
.../zlib-qat-module/zlib_qat_module.patch | 43
2 files changed, 95 insertions(+)
create mode 100644 common/recipes-core/zlib-qat-module/zlib-qat-
module.bb
create mode 100644 common/recipes-core/zlib-qat-module/zlib-qat-
module/zlib_qat_module.patch
diff --git a/common/recipes-core/zlib-qat-module/zlib-qat-module.bb
b/common/recipes-core/zlib-qat-module/zlib-qat-module.bb
new file mode 100644
index 000..5ade06e
--- /dev/null
+++ b/common/recipes-core/zlib-qat-module/zlib-qat-module.bb
@@ -0,0 +1,52 @@
+SUMMARY=Zlib QAT_MEM Memory Management Module for Intel Quick
Assist \
+Technology
+DESCRIPTION=This software acelerates the data compression algorithm \
+in the zlib software library via the Intel QuickAssist Technology \
+implemented on Intel Communications Chipset 89xx Series based
platforms.
+
+HOMEPAGE = http://zlib.net/;
+SECTION = libs
+LICENSE = Zlib GPLv2 BSD
+
+LIC_FILES_CHKSUM = file://${WORKDIR}/zlib-
${PV}/zlib.h;beginline=4;endline=23;md5=94d1b5a40dadd127f3351471727e6
6a9 \
+ file://${COMMON_LICENSE_DIR}/GPL-
2.0;md5=801f80980d171dd6425610833a22dbe6 \
+
file://${COMMON_LICENSE_DIR}/BSD;md5=3775480a712fc46a696476
78acb234cb
+PV = 1.2.7
+ZLIB_QAT_VERSION = 0.4.0-011
+
+PR=r0
+
+SRC_URI = http://www.zlib.net/zlib-${PV}.tar.gz;name=zlib \
+ http://downloadmirror.intel.com/20294/eng/zlib-${PV}-
qat.L.${ZLIB_QAT_VERSION}.tar.gz;name=zlib_qat \
+ file://zlib_qat_module.patch
+
+SRC_URI[zlib.md5sum]=60df6a37c56e7c1366cca812414f7b85
+SRC_URI[zlib.sha256sum]=fa9c9c8638efb8cb8ef5e4dd5453e455751e1c530
b1595eed466e1be9b7e26c5
+
+SRC_URI[zlib_qat.md5sum]=88e4140f98d2f9e170bf473f20e1a8d4
+SRC_URI[zlib_qat.sha256sum]=3c360878127f3930e64640ef5a5822719a5059
143326bb4c396645ae37b704a6
+
+S = ${WORKDIR}/zlib-${PV}/contrib/qat/qat_mem
+
+inherit module
+export KERNEL_SOURCE_ROOT = ${STAGING_KERNEL_DIR}
+
+do_patch() {
+ cd ${WORKDIR}/zlib-${PV}
+ patch -p0 ${WORKDIR}/zlib-${PV}-
qat.L.${ZLIB_QAT_VERSION}.patch
+
+ cd ${WORKDIR}
+ patch -p1${WORKDIR}/zlib_qat_module.patch
+}
+
+do_compile(){
+ cd ${S}
+ oe_runmake KERNEL_CC=${KERNEL_CC}
+}
+
+do_install_append() {
+ install -m 0755 -d ${D}${bindir}
+ install -m 0755 ${S}/qat_mem_test ${D}${bindir}
+}
+
+FILES_${PN} += ${bindir}/qat_mem_test
diff --git a/common/recipes-core/zlib-qat-module/zlib-qat-
module/zlib_qat_module.patch b/common/recipes-core/zlib-qat-
module/zlib-qat-module/zlib_qat_module.patch
new file mode 100644
index 000..a30f8b0
--- /dev/null
+++ b/common/recipes-core/zlib-qat-module/zlib-qat-
module/zlib_qat_modul
+++ e.patch
@@ -0,0 +1,43 @@
+Index: zlib-qat-module-1.2.7-r0/zlib-1.2.7/contrib/qat/qat_mem/Makefile
+=
==
+--- zlib-qat-module-1.2.7-r0.orig/zlib-1.2.7/contrib/qat/qat_mem/Makefile
2012-10-16 13:53:10.258938722 -0700
zlib-qat-module-1.2.7-r0/zlib-1.2.7/contrib/qat/qat_mem/Makefile
2012-10-16 13:59:18.174944864 -0700
+@@ -59,13 +59,10 @@
+ #
+ #
+
+#
##
+##
+-
+ MODULENAME := qat_mem
+-KDIR:= /lib/modules/$(shell uname -r)/build
++KDIR:= $(KERNEL_SOURCE_ROOT)
+ PWD := $(shell pwd)
+-
+-CC := gcc -Wall -imacros /usr/src/kernels/$(shell uname -
r)/include/linux/autoconf.h
+-
++CC := $(KERNEL_CC) -Wall -imacros
$(KERNEL_SOURCE_ROOT)/include/generated/autoconf.h
+ ifeq ($(KERNELRELEASE),)
+ all:$(MODULENAME)_test
+ all:
+@@ -73,20 +70,15 @@
+ else
+ obj-m := $(MODULENAME).o
+ endif
+-
++modules_install:
++$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules_install
+ $(MODULENAME)_test: $(MODULENAME)_test.c
+ $(CC) -g -o $(MODULENAME)_test $(MODULENAME)_test.c
+-
+-
+ load:
+ insmod ./$(MODULENAME).ko
+-
+ unload:
+ rmmod $(MODULENAME)
+-
+ test: all
+ ./$(MODULENAME)_test
+-
+ clean:
+ rm -f *.o *.ko Module.symvers modules.order *.mod.c .*.cmd
+$(MODULENAME)_test
+-
--
1.7.9.5
___
yocto mailing
Re: [yocto] [PATCH 1/1] mesa-dri.bbappend: avoid buildtime warnings
Rahul,
FYI, This commit will also avoid similar warnings for cedar-trail build.
Nitin
-Original Message-
From: Kamble, Nitin A
Sent: Thursday, October 18, 2012 5:00 PM
To: yocto@yoctoproject.org; Zanussi, Tom; Hart, Darren
Cc: Kamble, Nitin A
Subject: [PATCH 1/1] mesa-dri.bbappend: avoid buildtime warnings
From: Nitin A Kamble nitin.a.kam...@intel.com
Extend the mesa-dri recipe from oecore to avoid conflict with files generated
by emgd-driver-bin recipe.
This commits avoids these build warning
WARNING: The recipe is trying to install files into a shared area when those
files already exist. Those files are:
/srv/home/nitin/build-test-bsps/build-
crownbay/tmp/sysroots/crownbay/usr/include/KHR/khrplatform.h
/srv/home/nitin/build-test-bsps/build-
crownbay/tmp/sysroots/crownbay/usr/include/EGL/eglplatform.h
/srv/home/nitin/build-test-bsps/build-
crownbay/tmp/sysroots/crownbay/usr/include/EGL/eglext.h
/srv/home/nitin/build-test-bsps/build-
crownbay/tmp/sysroots/crownbay/usr/include/EGL/egl.h
/srv/home/nitin/build-test-bsps/build-
crownbay/tmp/sysroots/crownbay/usr/include/GLES/glplatform.h
/srv/home/nitin/build-test-bsps/build-
crownbay/tmp/sysroots/crownbay/usr/include/GLES/gl.h
/srv/home/nitin/build-test-bsps/build-
crownbay/tmp/sysroots/crownbay/usr/include/GLES/glext.h
/srv/home/nitin/build-test-bsps/build-
crownbay/tmp/sysroots/crownbay/usr/include/GLES2/gl2ext.h
/srv/home/nitin/build-test-bsps/build-
crownbay/tmp/sysroots/crownbay/usr/include/GLES2/gl2.h
/srv/home/nitin/build-test-bsps/build-
crownbay/tmp/sysroots/crownbay/usr/include/GLES2/gl2platform.h
This resolves part of the issue reported on the bug:
[Yocto #3238]
This is a temporary fix, and will be fixed differently after 1.3 release.
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
.../recipes-graphics/mesa/mesa-dri_8.0.4.bbappend |5 +
1 files changed, 5 insertions(+), 0 deletions(-) create mode 100644
common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
diff --git a/common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
b/common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
new file mode 100644
index 000..90e4394
--- /dev/null
+++ b/common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
@@ -0,0 +1,5 @@
+# Temporary avoid warnings of duplicate files providers until #
+mesa-dri emgd-driver-bin recipes are fixed SSTATE_DUPWHITELIST +=
+${STAGING_INCDIR}/KHR ${STAGING_INCDIR}/EGL \
+${STAGING_INCDIR}/GLES ${STAGING_INCDIR}/GLES2
+
--
1.7.3.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCHv4 6/8] mesa-dri.bbappend: avoid conflict with emgd-driver-bin
-Original Message-
From: Hart, Darren
Sent: Monday, October 15, 2012 9:10 AM
To: Kamble, Nitin A
Cc: Zanussi, Tom; yocto@yoctoproject.org
Subject: Re: [PATCHv4 6/8] mesa-dri.bbappend: avoid conflict with emgd-
driver-bin
On 10/11/2012 04:31 PM, nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
Extend the mesa-dri recipe from oecore to avoid conflict with files
generated by emgd-driver-bin recipe.
This extention is needed only when emgd-driver-bin recipe is included
in the target image, so the code is conditional to run only on the
machine with emgd graphics driver.
The emgd binary driver also provides egl, gles1, gles2 library headers.
To avoid conflict disable egl, gles1, gles2 from meta-dri if the BSP
image is bundling the emgd driver.
This commits avoids these build warning
WARNING: The recipe is trying to install files into a shared area when those
files already exist. Those files are:
/srv/home/nitin/build-test-bsps/build-
crownbay/tmp/sysroots/crownbay/usr/include/KHR/khrplatform.h
/srv/home/nitin/build-test-bsps/build-
crownbay/tmp/sysroots/crownbay/usr/include/EGL/eglplatform.h
/srv/home/nitin/build-test-bsps/build-
crownbay/tmp/sysroots/crownbay/usr/include/EGL/eglext.h
/srv/home/nitin/build-test-bsps/build-
crownbay/tmp/sysroots/crownbay/usr/include/EGL/egl.h
/srv/home/nitin/build-test-bsps/build-
crownbay/tmp/sysroots/crownbay/usr/include/GLES/glplatform.h
/srv/home/nitin/build-test-bsps/build-
crownbay/tmp/sysroots/crownbay/usr/include/GLES/gl.h
/srv/home/nitin/build-test-bsps/build-
crownbay/tmp/sysroots/crownbay/usr/include/GLES/glext.h
/srv/home/nitin/build-test-bsps/build-
crownbay/tmp/sysroots/crownbay/usr/include/GLES2/gl2ext.h
/srv/home/nitin/build-test-bsps/build-
crownbay/tmp/sysroots/crownbay/usr/include/GLES2/gl2.h
/srv/home/nitin/build-test-bsps/build-
crownbay/tmp/sysroots/crownbay/u
sr/include/GLES2/gl2platform.h
This resolves part of the issue reported on the bug:
[Yocto #3238]
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
.../recipes-graphics/mesa/mesa-dri_8.0.4.bbappend | 24
1 files changed, 24 insertions(+), 0 deletions(-) create mode 100644
common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
diff --git a/common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
b/common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
new file mode 100644
index 000..6bfa968
--- /dev/null
+++ b/common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
@@ -0,0 +1,24 @@
+
+# The emgd binary driver also provides egl, gles1, gles2 library headers.
+# To avoid conflict disable egl, gles1, gles2 from meta-dri if the
+BSP image # is bundling the emgd driver.
+
+python __anonymous () {
+import re
+xserver = d.getVar('XSERVER', True)
+if 'emgd-driver-bin' in xserver.split(' '):
+extra_oeconf = d.getVar('EXTRA_OECONF', True).split()
+ take_out = [--enable-egl, --enable-gles1, --enable-gles2]
+ put_in = [--disable-egl, --disable-gles1, --disable-gles2]
+pattern = re.compile(--with-egl-platforms)
+new_extra_oeconf = [ ]
+ for i in extra_oeconf:
+if ( i not in take_out ) and ( not pattern.match(i)):
+new_extra_oeconf.append(i)
+for i in put_in:
+new_extra_oeconf.append(i)
+
+d.setVar('EXTRA_OECONF', ' '.join(new_extra_oeconf))
+depends = d.getVar('DEPENDS', True)
+d.setVar('DEPENDS', depends + emgd-driver-bin)
Odd mix of whitespace and tabs above.
Also, I have to agree with Ross. This places very specific knowledge of an
external package in the general purpose recipe. This is opposite of how these
things should be built up.
Whitespace issues can be solved easily. But if this solution is not acceptable,
then I am not sure how to solve the issue. Do we push the issue to 1.4?
Nitin
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCHv4 6/8] mesa-dri.bbappend: avoid conflict with emgd-driver-bin
diff --git a/common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
b/common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
new file mode 100644
index 000..6bfa968
--- /dev/null
+++ b/common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
@@ -0,0 +1,24 @@
+
+# The emgd binary driver also provides egl, gles1, gles2 library
headers.
+# To avoid conflict disable egl, gles1, gles2 from meta-dri if the
+BSP image # is bundling the emgd driver.
+
+python __anonymous () {
+import re
+xserver = d.getVar('XSERVER', True)
+if 'emgd-driver-bin' in xserver.split(' '):
+extra_oeconf = d.getVar('EXTRA_OECONF', True).split()
+ take_out = [--enable-egl, --enable-gles1, --enable-gles2]
+ put_in = [--disable-egl, --disable-gles1, --disable-gles2]
+pattern = re.compile(--with-egl-platforms)
+new_extra_oeconf = [ ]
+ for i in extra_oeconf:
+if ( i not in take_out ) and ( not pattern.match(i)):
+new_extra_oeconf.append(i)
+for i in put_in:
+new_extra_oeconf.append(i)
+
+d.setVar('EXTRA_OECONF', ' '.join(new_extra_oeconf))
+depends = d.getVar('DEPENDS', True)
+d.setVar('DEPENDS', depends + emgd-driver-bin)
Odd mix of whitespace and tabs above.
Also, I have to agree with Ross. This places very specific knowledge
of an external package in the general purpose recipe. This is
opposite of how these things should be built up.
Whitespace issues can be solved easily. But if this solution is not
acceptable, then I am not sure how to solve the issue. Do we push the issue
to 1.4?
Can you define a variable that EXTRA_OECONF includes which can be
manipulated in a bbappend in the meta-intel? This would keep this complex
logic out of the core recipe and move into the place that actually needs it.
If we can modify the recipe in poky, then this method is not needed to achieve
same thing. But because of release we may not be able to do it.
Nitin
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCHv4 6/8] mesa-dri.bbappend: avoid conflict with emgd-driver-bin
-Original Message- From: Burton, Ross [mailto:ross.bur...@intel.com] Sent: Friday, October 12, 2012 2:49 AM To: Kamble, Nitin A Cc: Zanussi, Tom; Hart, Darren; yocto@yoctoproject.org Subject: Re: [yocto] [PATCHv4 6/8] mesa-dri.bbappend: avoid conflict with emgd-driver-bin On 12 October 2012 00:31, nitin.a.kam...@intel.com wrote: Extend the mesa-dri recipe from oecore to avoid conflict with files generated by emgd-driver-bin recipe. The commit message should also say what the high level changes were, in this case The information about high level change is in the next lines in the comment. As seen in the lines bellow here. +# To avoid conflict disable egl, gles1, gles2 from meta-dri if the +BSP image # is bundling the emgd driver. I'm not entirely keen on this level of deep hackery, it looks very fragile. What seems like the hackery here, is simple change to EXTRA_OECONF variable of the mesa-dri recipe. But the way original mesa-dri recipe is written, there is no simpler bitbake way to change EXTRA_OECONF. Is there any difference in the headers installed by emgd and mesa? Yes, there are differences, the EMGD recipe is providing GL implementation at ABI level which has not going in the open source version of mesa-dri. An alternative would be to consider mesa a more canonical source of GL headers for the build, and change EMGD to not install anything to staging. This would mean that emgd wouldn't build-time provide any virtual/libgl packages, just runtime provides so that the image can be built using EMGD and Mesa's libgl. There is a reason EMGD recipe is providing these GL libraries in binary form and not in the source form, I think there is EMGD specific proprietary code in these libraries. I can check with EMGD guys to confirm this. FYI, In ross/xorg I've started re-arranging the packaging of mesa, so that the packages are called libgl-mesa and RPROVIDE libgl. I plan to make the same changes to EMGD once I have the shlib resolution sorted. Looks like this kind of packaging change would not change functionality of both recipes. Cheers, Nitin Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 2/5] crownbay.conf: specify the 8.0.4 version as preferred version of mesa-dri
-Original Message- From: Burton, Ross [mailto:ross.bur...@intel.com] Sent: Thursday, October 11, 2012 9:54 AM To: Kamble, Nitin A Cc: yocto@yoctoproject.org; Zanussi, Tom; Hart, Darren Subject: Re: [yocto] [PATCH 2/5] crownbay.conf: specify the 8.0.4 version as preferred version of mesa-dri On 11 October 2012 00:10, Kamble, Nitin A nitin.a.kam...@intel.com wrote: So far I have tested with glxgears and glxinfo with the 8.0.4 version of mesa-dri. And I did not find any issues. And Tom has been testing the same way so far without any complaints. If there is something which can help things test further, it would be nice to add it to the poky tree; so that it can become part of standard tests, and QA also can use it. A slightly better test than glxgears that is in oe-core is in libclutter-glx-1.0- examples. Run test-interactive test_cairo_flowers in a terminal, you should get flowers falling down the screen. Hi Ross, I am not finding this recipe in the poky master. Nitin (on cdt, this results in a PVR driver error - #3280) Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 2/5] crownbay.conf: specify the 8.0.4 version as preferred version of mesa-dri
-Original Message- From: Burton, Ross [mailto:ross.bur...@intel.com] Sent: Wednesday, October 10, 2012 2:24 AM To: Kamble, Nitin A Cc: yocto@yoctoproject.org; Zanussi, Tom; Hart, Darren Subject: Re: [yocto] [PATCH 2/5] crownbay.conf: specify the 8.0.4 version as preferred version of mesa-dri Hi Nitin, From what I understand, EMGD's Mesa driver will only work correctly with a Mesa that matches exactly the configuration that was used to build EMGD, as the driver interface isn't stable. Have you tested the GL support with more than glxinfo? Ross Hi Ross, I find that emgd driver itself is providing some of the mesa libraries headers. And I could not find a match for those in any of the released mesa sources as well as mesa git repository. So I don't see a way to match mesa code exactly. If such mesa is available in closed source, I am not aware of it either. So far I have tested with glxgears and glxinfo with the 8.0.4 version of mesa-dri. And I did not find any issues. And Tom has been testing the same way so far without any complaints. If there is something which can help things test further, it would be nice to add it to the poky tree; so that it can become part of standard tests, and QA also can use it. Nitin ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCHv2 2/5] crownbay.conf: specify the 8.0.4 version as preferred version of mesa-dri
-Original Message- From: Burton, Ross [mailto:ross.bur...@intel.com] Sent: Wednesday, October 10, 2012 2:25 AM To: Kamble, Nitin A Cc: Zanussi, Tom; Hart, Darren; yocto@yoctoproject.org Subject: Re: [yocto] [PATCHv2 2/5] crownbay.conf: specify the 8.0.4 version as preferred version of mesa-dri On 10 October 2012 02:16, nitin.a.kam...@intel.com wrote: Avoid following warnings while building crownbay BSPs: NOTE: preferred version 7.11 of mesa-dri not available (for item virtual/libgl) NOTE: versions of mesa-dri available: 2:8.0.4 2:8.0.4+git1+c1f4867c89adb1a6b19d66ec8ad146115909f0a7 This is the preferred version in oe-core, so wouldn't it be easier to just drop this preferred version line and avoid this repeating itself in the future? Ross Hi Ross, The reason is we want to know if the version of mesa in oecore has changed or not. EMGD has specific needs of mesa, and in the testing we are not finding any issues with v8.0.4 of mesa. But that may not hold true for future versions of mesa, so we would like to pin the version here so we know that this version works as expected. Nitin ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCHv2 4/5] fishriver BSP retirement
-Original Message- From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] Sent: Wednesday, October 10, 2012 2:07 PM To: Kamble, Nitin A Cc: Zanussi, Tom; Hart, Darren; yocto@yoctoproject.org Subject: Re: [yocto] [PATCHv2 4/5] fishriver BSP retirement On 12-10-09 09:16 PM, nitin.a.kam...@intel.com wrote: From: Nitin A Kamblenitin.a.kam...@intel.com This commit removes fishriver bsp from meta-intel layer. Fish-River-Islnad-2 hardware and BSP has made this Fish-River-Island hardware and BSP absolute. Also we discussed this on the Yocto Execution Tracking Meeting, and to our knowledge no customer is using (cares about) this BSP now. Just so I don't forget, can you send a patch that also removes the kernel meta data for the BSP ? That way I won't recreate the branch for future releases :) Removing the FRI-1 contents from meta branch of v3.4 kernel tree should be ok because it preserves the old commits. But I think we will have to leave the topic branch for fishriver machine as it is. I assume it is ok that the kernel branches stay in the 3.x kernels for the yocto 1.3 release ? I also think that is the right way to handle it. Regards, Nitin Cheers, Bruce Signed-off-by: Nitin A Kamblenitin.a.kam...@intel.com --- MAINTAINERS|4 - meta-fishriver/COPYING.MIT | 17 --- meta-fishriver/README | 114 meta-fishriver/README.sources | 17 --- meta-fishriver/conf/layer.conf | 12 -- meta-fishriver/conf/machine/fishriver.conf | 17 --- .../formfactor/formfactor/fishriver/machconfig |3 - .../recipes-bsp/formfactor/formfactor_0.0.bbappend |3 - .../xserver-xf86-config/fishriver/xorg.conf| 26 - .../xorg-xserver/xserver-xf86-config_0.1.bbappend |1 - .../linux/linux-yocto-rt_3.0.bbappend |8 -- .../linux/linux-yocto-rt_3.2.bbappend |8 -- .../recipes-kernel/linux/linux-yocto_3.0.bbappend |9 -- .../recipes-kernel/linux/linux-yocto_3.2.bbappend |8 -- .../recipes-kernel/linux/linux-yocto_3.4.bbappend |8 -- 15 files changed, 0 insertions(+), 255 deletions(-) delete mode 100644 meta-fishriver/COPYING.MIT delete mode 100644 meta-fishriver/README delete mode 100644 meta-fishriver/README.sources delete mode 100644 meta-fishriver/binary/.gitignore delete mode 100644 meta-fishriver/conf/layer.conf delete mode 100644 meta-fishriver/conf/machine/fishriver.conf delete mode 100644 meta-fishriver/recipes- bsp/formfactor/formfactor/fishriver/machconfig delete mode 100644 meta-fishriver/recipes- bsp/formfactor/formfactor_0.0.bbappend delete mode 100644 meta-fishriver/recipes-graphics/xorg- xserver/xserver-xf86-config/fishriver/xorg.conf delete mode 100644 meta-fishriver/recipes-graphics/xorg- xserver/xserver-xf86-config_0.1.bbappend delete mode 100644 meta-fishriver/recipes-kernel/linux/linux-yocto- rt_3.0.bbappend delete mode 100644 meta-fishriver/recipes-kernel/linux/linux-yocto- rt_3.2.bbappend delete mode 100644 meta-fishriver/recipes-kernel/linux/linux- yocto_3.0.bbappend delete mode 100644 meta-fishriver/recipes-kernel/linux/linux- yocto_3.2.bbappend delete mode 100644 meta-fishriver/recipes-kernel/linux/linux-yocto_3.4.bbappend diff --git a/MAINTAINERS b/MAINTAINERS index 5bcf470..3bf0add 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -56,10 +56,6 @@ EMENLOW M:Tom Zanussitom.zanu...@intel.com F:meta-emenlow/ -FISHRIVER -M: Tom Zanussitom.zanu...@intel.com -F: meta-fishriver/ - FRI2 M:Darren Hartdvh...@linux.intel.com F:meta-fri2/ diff --git a/meta-fishriver/COPYING.MIT b/meta-fishriver/COPYING.MIT deleted file mode 100644 index fb950dc..000 --- a/meta-fishriver/COPYING.MIT +++ /dev/null @@ -1,17 +0,0 @@ -Permission is hereby granted, free of charge, to any person obtaining a copy -of this software and associated documentation files (the Software), to deal -in the Software without restriction, including without limitation the rights -to use, copy, modify, merge, publish, distribute, sublicense, and/or sell -copies of the Software, and to permit persons to whom the Software is -furnished to do so, subject to the following conditions: - -The above copyright notice and this permission notice shall be included in -all copies or substantial portions of the Software. - -THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR -IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, -FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE -AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER -LIABILITY
Re: [yocto] [PATCH 1/5] xf86-video-intel: Bring 2.20.0 version to match released graphics stack
--- /dev/null
+++ b/common/recipes-graphics/xorg-driver/xf86-video-intel_2.20.0.bb
@@ -0,0 +1,26 @@
+require xorg-driver-video.inc
+
+SUMMARY = X.Org X server -- Intel integrated graphics chipsets driver
+
+DESCRIPTION = intel is an Xorg driver for Intel integrated graphics
+\ chipsets. The driver supports depths 8, 15, 16 and 24. On some
+chipsets, \ the driver supports hardware accelerated 3D via the
+Direct Rendering \ Infrastructure (DRI).
+
+LIC_FILES_CHKSUM =
file://COPYING;md5=8730ad58d11c7bbad9a7066d69f7808e
+
+PR = ${INC_PR}.0
+
+DEPENDS += virtual/libx11 drm xf86driproto glproto \
+ virtual/libgl xineramaproto xf86driproto libpciaccess
+
+
+EXTRA_OECONF += --disable-xvmc
I think Ross's version enables xvmc. Any reason to disable it?
I basically took the recipe from oecore, and updated to the desired version.
That way it is very close to what is in oecore, and all the testing of oecore
is on our side.
Is the new method to use PACKAGECONF instead of EXTRA_OECONF now?
Again, this is what I saw in Ross's layer.
Not sure, I will see the differences with Ross's recipe, and test it out here.
Thanks,
Nitin
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] Fix use of PRINC in meta-intel BSPs
Tested this for sugarbay BSP, and did not see any issues with it.
Nitin
-Original Message-
From: Darren Hart [mailto:dvh...@linux.intel.com]
Sent: Tuesday, October 09, 2012 3:53 PM
To: Yocto Project
Cc: Darren Hart; Saul Wold; Zanussi, Tom; Kamble, Nitin A
Subject: [PATCH] Fix use of PRINC in meta-intel BSPs
Replaces all uses of PRINC with the form:
PRINC := ${@int(PRINC) + N}
Where N is the previously assigned value plus one to ensure a monotonically
increasing PRINC value.
Signed-off-by: Darren Hart dvh...@linux.intel.com
CC: Saul Wold s...@linux.intel.com
CC: Tom Zanussi tom.zanu...@intel.com
CC: Nitin Kamble nitin.a.kam...@intel.com
---
.../recipes-bsp/formfactor/formfactor_0.0.bbappend |2 +-
.../recipes-bsp/formfactor/formfactor_0.0.bbappend |2 +-
.../recipes-bsp/formfactor/formfactor_0.0.bbappend |2 +-
.../recipes-bsp/formfactor/formfactor_0.0.bbappend |2 +-
.../recipes-bsp/formfactor/formfactor_0.0.bbappend |2 +-
.../recipes-bsp/formfactor/formfactor_0.0.bbappend |4 ++--
.../recipes-bsp/formfactor/formfactor_0.0.bbappend |2 +-
.../recipes-bsp/formfactor/formfactor_0.0.bbappend |2 +-
.../recipes-bsp/formfactor/formfactor_0.0.bbappend |2 +-
.../recipes-bsp/formfactor/formfactor_0.0.bbappend |2 +-
.../recipes-bsp/formfactor/formfactor_0.0.bbappend |2 +-
.../recipes-bsp/formfactor/formfactor_0.0.bbappend |2 +-
meta-tlk/recipes-core/psplash/psplash_git.bbappend |2 +-
meta-tlk/recipes-kernel/linux/linux-yocto_tlk.inc |2 +-
14 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/meta-cedartrail/recipes-
bsp/formfactor/formfactor_0.0.bbappend b/meta-cedartrail/recipes-
bsp/formfactor/formfactor_0.0.bbappend
index 54da0ff..2a3ee7a 100644
--- a/meta-cedartrail/recipes-bsp/formfactor/formfactor_0.0.bbappend
+++ b/meta-cedartrail/recipes-bsp/formfactor/formfactor_0.0.bbappend
@@ -1,3 +1,3 @@
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
-PRINC = 1
+PRINC := ${@int(PRINC) + 2}
diff --git a/meta-chiefriver/recipes-
bsp/formfactor/formfactor_0.0.bbappend b/meta-chiefriver/recipes-
bsp/formfactor/formfactor_0.0.bbappend
index 54da0ff..2a3ee7a 100644
--- a/meta-chiefriver/recipes-bsp/formfactor/formfactor_0.0.bbappend
+++ b/meta-chiefriver/recipes-bsp/formfactor/formfactor_0.0.bbappend
@@ -1,3 +1,3 @@
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
-PRINC = 1
+PRINC := ${@int(PRINC) + 2}
diff --git a/meta-crownbay/recipes-
bsp/formfactor/formfactor_0.0.bbappend b/meta-crownbay/recipes-
bsp/formfactor/formfactor_0.0.bbappend
index 54da0ff..2a3ee7a 100644
--- a/meta-crownbay/recipes-bsp/formfactor/formfactor_0.0.bbappend
+++ b/meta-crownbay/recipes-bsp/formfactor/formfactor_0.0.bbappend
@@ -1,3 +1,3 @@
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
-PRINC = 1
+PRINC := ${@int(PRINC) + 2}
diff --git a/meta-crystalforest/recipes-
bsp/formfactor/formfactor_0.0.bbappend b/meta-crystalforest/recipes-
bsp/formfactor/formfactor_0.0.bbappend
index 54da0ff..2a3ee7a 100644
--- a/meta-crystalforest/recipes-bsp/formfactor/formfactor_0.0.bbappend
+++ b/meta-crystalforest/recipes-bsp/formfactor/formfactor_0.0.bbappend
@@ -1,3 +1,3 @@
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
-PRINC = 1
+PRINC := ${@int(PRINC) + 2}
diff --git a/meta-emenlow/recipes-
bsp/formfactor/formfactor_0.0.bbappend b/meta-emenlow/recipes-
bsp/formfactor/formfactor_0.0.bbappend
index 54da0ff..2a3ee7a 100644
--- a/meta-emenlow/recipes-bsp/formfactor/formfactor_0.0.bbappend
+++ b/meta-emenlow/recipes-bsp/formfactor/formfactor_0.0.bbappend
@@ -1,3 +1,3 @@
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
-PRINC = 1
+PRINC := ${@int(PRINC) + 2}
diff --git a/meta-fishriver/recipes-bsp/formfactor/formfactor_0.0.bbappend
b/meta-fishriver/recipes-bsp/formfactor/formfactor_0.0.bbappend
index 54da0ff..6644a84 100644
--- a/meta-fishriver/recipes-bsp/formfactor/formfactor_0.0.bbappend
+++ b/meta-fishriver/recipes-bsp/formfactor/formfactor_0.0.bbappend
@@ -1,3 +1,3 @@
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
-
-PRINC = 1
+
+PRINC := ${@int(PRINC) + 2}
diff --git a/meta-fri2/recipes-bsp/formfactor/formfactor_0.0.bbappend
b/meta-fri2/recipes-bsp/formfactor/formfactor_0.0.bbappend
index 54da0ff..2a3ee7a 100644
--- a/meta-fri2/recipes-bsp/formfactor/formfactor_0.0.bbappend
+++ b/meta-fri2/recipes-bsp/formfactor/formfactor_0.0.bbappend
@@ -1,3 +1,3 @@
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
-PRINC = 1
+PRINC := ${@int(PRINC) + 2}
diff --git a/meta-jasperforest/recipes-
bsp/formfactor/formfactor_0.0.bbappend b/meta-jasperforest/recipes-
bsp/formfactor/formfactor_0.0.bbappend
index 54da0ff..2a3ee7a 100644
--- a/meta-jasperforest/recipes-bsp/formfactor/formfactor_0.0.bbappend
+++ b/meta-jasperforest/recipes-bsp/formfactor/formfactor_0.0.bbappend
@@ -1,3 +1,3 @@
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
-PRINC = 1
+PRINC := ${@int(PRINC) + 2}
diff
Re: [yocto] [PATCHv2 4/5] fishriver BSP retirement
Sorry for these typos. I fixed these on the contrib branch. Thanks, Nitin -Original Message- From: Hart, Darren Sent: Tuesday, October 09, 2012 7:42 PM To: Kamble, Nitin A Cc: Zanussi, Tom; yocto@yoctoproject.org Subject: Re: [PATCHv2 4/5] fishriver BSP retirement On 10/09/2012 06:16 PM, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com This commit removes fishriver bsp from meta-intel layer. Fish-River-Islnad-2 hardware and BSP has made this s/Islnad/Island/ Fish-River-Island hardware and BSP absolute. s/absolute/obsolete/ -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCHv2 1/1] crownbay.conf: add kernel parameters for EMGD video acceleration
-Original Message-
From: Hart, Darren
Sent: Thursday, October 04, 2012 3:34 PM
To: Kamble, Nitin A
Cc: Zanussi, Tom; yocto@yoctoproject.org
Subject: Re: [PATCHv2 1/1] crownbay.conf: add kernel parameters for EMGD
video acceleration
On 10/04/2012 03:23 PM, nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
This is recommended in the EMGD User Guide.
My understanding is the emgd kernel driver need to allocate memory
dynamically, and the vmalloc=256MB parameter ensures enough will be
available for the driver.
OK, this explains the change to vmalloc.
Why the change of vga=current and the drop of video=vesafb ?
Darren,
Good catch. I changed this for cleanup, but now I see that it affects the
splash screen. So I will resend the commit by dropping these extra changes.
Thanks,
Nitin
--
Darren
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
meta-crownbay/conf/machine/crownbay.conf |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta-crownbay/conf/machine/crownbay.conf
b/meta-crownbay/conf/machine/crownbay.conf
index 40dbd1d..f02615e 100644
--- a/meta-crownbay/conf/machine/crownbay.conf
+++ b/meta-crownbay/conf/machine/crownbay.conf
@@ -21,7 +21,7 @@ PREFERRED_VERSION_xserver-xorg ?= 1.9.3
PREFERRED_VERSION_mesa-dri ?= 7.11
PREFERRED_VERSION_xf86-input-evdev ?= 2.6.0
-APPEND += video=vesafb vga=0x318
+APPEND += vga=current vmalloc=256MB
VA_FEATURES = ${@bb.utils.contains(LICENSE_FLAGS_WHITELIST, \
commercial, gst-va-intel va-intel, va-intel, d)}
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/1] meta-intel misc commits
-Original Message- From: Hart, Darren Sent: Thursday, October 04, 2012 3:14 PM To: Kamble, Nitin A Cc: Zanussi, Tom; yocto@yoctoproject.org Subject: Re: [PATCH 0/1] meta-intel misc commits I'm familiar with the user-guide and have read through it. What I'm saying is that there should be a technical reason for adding a kernel command line and we should cite it in the commit. How does this improve the current state of things? I have seen once the EMGD kernel driver throwing unable to allocate the memory errors while playing a video file. I guess the issue is scratched only in shortage of memory conditions. Nitin ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/1] Fix X issue on crownbay
Ross, Looking at the bug, I am trying with the latest commits now. When it failed, I looked at the build area, and found that the xorg-xserver package was built fine. I think the issue happened in the with rootfs generation. I haven't found why it was not included in the rootfs. From the bug I thought the issue got resolved in the latest tree HEAD, so I am going to test the latest head on few BSPs, and will dig further if I encounter the issue again. Nitin -Original Message- From: Burton, Ross [mailto:ross.bur...@intel.com] Sent: Wednesday, September 12, 2012 1:43 PM To: Kamble, Nitin A Cc: Zanussi, Tom; Hart, Darren; yocto@yoctoproject.org Subject: Re: [yocto] [PATCH 0/1] Fix X issue on crownbay On 12 September 2012 21:14, Kamble, Nitin A nitin.a.kam...@intel.com wrote: FYI While testing on the fishriver platform, I also find that there is no X log, and looking further found out that xorg executable is not on the image. I think the same thing is also happening on crownbay. There have been transient reports of Xorg missing in the qemu images too -- transient because the reporter said that the next day's autobuilt image had the package installed again. Very odd. In the broken systems you say there is no Xorg binary. Can you confirm that there is no xserver-xorg package too? Can you inspect the build and see if this failed, or if there is some machine configuration disaster which means it doesn't think it needs to install an xserver? Ross FWIW, my qemuarm image from earlier today works. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/1] Fix X issue on crownbay
Thanks Kishore for reporting it. I am trying to get to bottom of this by today or tomorrow. Thanks, Nitin -Original Message- From: Bodke, Kishore K Sent: Wednesday, September 12, 2012 1:57 PM To: Kamble, Nitin A; Zanussi, Tom Cc: Hart, Darren; yocto@yoctoproject.org Subject: RE: [PATCH 0/1] Fix X issue on crownbay -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Kamble, Nitin A Sent: Wednesday, September 12, 2012 1:14 PM To: Zanussi, Tom Cc: Hart, Darren; yocto@yoctoproject.org Subject: Re: [yocto] [PATCH 0/1] Fix X issue on crownbay FYI While testing on the fishriver platform, I also find that there is no X log, and looking further found out that xorg executable is not on the image. I think the same thing is also happening on crownbay. FYI.. I also see the similar issue for Romley. There is no Xlog and X does not comes up. Thanks Kishore. Nitin -Original Message- From: Kamble, Nitin A Sent: Wednesday, September 12, 2012 9:18 AM To: Zanussi, Tom Cc: Hart, Darren; yocto@yoctoproject.org Subject: RE: [PATCH 0/1] Fix X issue on crownbay Hi Tom, Thanks for looking into the matter. I will try to reproduce the issue you are seeing with master. And send another pull request with all the fixes. Regards, Nitin -Original Message- From: Zanussi, Tom Sent: Monday, September 10, 2012 4:34 PM To: Kamble, Nitin A Cc: Hart, Darren; yocto@yoctoproject.org Subject: Re: [PATCH 0/1] Fix X issue on crownbay On Wed, 2012-09-05 at 17:59 -0700, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com The following changes since commit 66b516f3d3a287eecbf8804b2221bfc27e36db63: README: add info explaining meta-tlk layer purpose (2012-09-06 10:36:02 -0500) are available in the git repository at: git://git.yoctoproject.org/meta-intel-contrib nitin/work http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=ni tin /w ork I built and tried this, but it still didn't boot into X, and now there's not even an Xorg.log to look at: root@crownbay:/var/log# ls -al drwxr-xr-x2 root root80 Sep 10 20:15 . drwxrwxrwt7 root root 140 Jan 6 2009 .. -rw-r--r--1 root root 78429 Sep 10 20:17 messages -rw-rw-r--1 root root 4224 Sep 10 20:17 wtmp I assume this is a different X problem related to recent changes in mater. Can you update the bug report with the commits that you tested with so I can verify that your patch at least works? Thanks, Tom Nitin A Kamble (1): emgd-driver-bin: Fix package naming issue .../xorg-xserver/emgd-driver-bin_1.14.bb |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/1] Fix X issue on crownbay
FYI While testing on the fishriver platform, I also find that there is no X log, and looking further found out that xorg executable is not on the image. I think the same thing is also happening on crownbay. Nitin -Original Message- From: Kamble, Nitin A Sent: Wednesday, September 12, 2012 9:18 AM To: Zanussi, Tom Cc: Hart, Darren; yocto@yoctoproject.org Subject: RE: [PATCH 0/1] Fix X issue on crownbay Hi Tom, Thanks for looking into the matter. I will try to reproduce the issue you are seeing with master. And send another pull request with all the fixes. Regards, Nitin -Original Message- From: Zanussi, Tom Sent: Monday, September 10, 2012 4:34 PM To: Kamble, Nitin A Cc: Hart, Darren; yocto@yoctoproject.org Subject: Re: [PATCH 0/1] Fix X issue on crownbay On Wed, 2012-09-05 at 17:59 -0700, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com The following changes since commit 66b516f3d3a287eecbf8804b2221bfc27e36db63: README: add info explaining meta-tlk layer purpose (2012-09-06 10:36:02 -0500) are available in the git repository at: git://git.yoctoproject.org/meta-intel-contrib nitin/work http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=nitin /w ork I built and tried this, but it still didn't boot into X, and now there's not even an Xorg.log to look at: root@crownbay:/var/log# ls -al drwxr-xr-x2 root root80 Sep 10 20:15 . drwxrwxrwt7 root root 140 Jan 6 2009 .. -rw-r--r--1 root root 78429 Sep 10 20:17 messages -rw-rw-r--1 root root 4224 Sep 10 20:17 wtmp I assume this is a different X problem related to recent changes in mater. Can you update the bug report with the commits that you tested with so I can verify that your patch at least works? Thanks, Tom Nitin A Kamble (1): emgd-driver-bin: Fix package naming issue .../xorg-xserver/emgd-driver-bin_1.14.bb |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/1] emgd-driver-bin: Fix package naming issue
-Original Message- From: Burton, Ross [mailto:ross.bur...@intel.com] Sent: Friday, September 07, 2012 2:29 AM To: Kamble, Nitin A Cc: Zanussi, Tom; Hart, Darren; yocto@yoctoproject.org Subject: Re: [yocto] [PATCH 1/1] emgd-driver-bin: Fix package naming issue On 6 September 2012 01:59, nitin.a.kam...@intel.com wrote: emgd-driver-bin is generating rpm package with name libegl1. This name clashes with a package of mesa-dri recipe. This name clash blocks installation of emgd user land binaries in the image. And due to missing emgd user land components X fails start on BSPs like crownbay. Fix this problem by specifying package names in the recipe with the PKG_ vars. Could we name the packages with a -emgd suffix, such as libegl-emgd? I'm going to fix mesa to name it's packages libegl-mesa and so on, so consistency would make everything a lot easier (see my mail to oe-core yesterday about GL). Ross The package generated has lot of other libraries. And IMO the most important in that is emgd-drv. Libegl is one of the many supporting libraries in the package. So to me renaming package to emgd-drv makes more sense than extending the name to libegl-emgd. Nitin ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] CyaSSL Yocto Recipe
And here is bit of information about CyaSSL from their website. http://www.yassl.com/yaSSL/Products-cyassl.html The CyaSSL embedded SSL library is a lightweight SSL library written in ANSI C and targeted for embedded and RTOS environments - primarily because of its small size, speed, and feature set. It is commonly used in standard operating environments as well because of its royalty-free pricing and excellent cross platform support. CyaSSL supports industry standards up to the current TLS 1.2 level, is up to 20 times smaller than OpenSSL, and offers progressive ciphers such as HC-128, RABBIT, and NTRU. User benchmarking and feedback reports dramatically better performance when using CyaSSL over OpenSSL. Thanks, Nitin From: Chris Conlon [mailto:ch...@yassl.com] Sent: Thursday, September 06, 2012 9:07 AM To: yocto@yoctoproject.org Cc: Kamble, Nitin A Subject: CyaSSL Yocto Recipe Hi, As per discussions with a few of the Yocto members, we have put together a Yocto Project recipe for the CyaSSL embedded SSL library. I have attached the recipe here for review and comments. Thanks, Chris Conlon www.yassl.comhttp://www.yassl.com ch...@yassl.commailto:ch...@yassl.com Skype: chris_conlon_07 +1 406 209 0601 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 2/6] crownbay: customize the xorg.conf for the flat panel on the corwnbay kit
-Original Message- From: Darren Hart [mailto:dvh...@linux.intel.com] Sent: Saturday, July 28, 2012 3:27 AM To: Kamble, Nitin A Cc: yocto@yoctoproject.org; bruce.ashfi...@windriver.com; Zanussi, Tom Subject: Re: [yocto] [PATCH 2/6] crownbay: customize the xorg.conf for the flat panel on the corwnbay kit On 07/26/2012 10:31 PM, Kamble, Nitin A wrote: On 07/23/2012 03:06 AM, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com The kit has Auo 800x600 LCD screen. Configuring Xorg for it. I presume the crownbay has additional display options? how does this impact those? This change sets the resolution of the screen to 800x600. And this is applicable to LCD screen on the kit as well as external monitor. I will add a note about it in the log. I presume that without this change it was able to detect the appropriate resolution of the connected monitor, but not of the LCD? If so, this change effectively breaks that autodetection and forces everything to the 800x600 display which is arguably very low-resolution by today's standards. Why should this be the default? When you refer to the kit, what exactly are you referring to? Also, is this a discussion you have already had with Tom? I don't want to contradict what he has said regarding this BSP. EMGD driver on crownbay gives few resolutions as options. By default it tries to set 1366x768 resolution for both LCD and external monitor. The Crownbay kit is a suitcase kind of box, which has builtin LCD screen of resolution 800x600. This LCD screen shows only 800x600 of the default 1366x768 area. So The LCD is not able to show all the screen, and IMO it is a functional issue. For my Dell 1704FPTi monitor which has 1280x1024 native resolution; When connected to the crownbay, X cannot find a working mode for this monitor. But if I set 800x600 in the xorg.conf as this commit does, then both LCD external monitor can show the X screen without any issues. This seems like a bug to me. The driver should be able to probe the display and use the optimal resolution without it being specified in the Xorg.conf. So far as I know we don't specify resolution in any of the meta-intel BSPs: dvhart@envy:~/source/poky/layers/meta-intel [denzil] $ find . -name xorg.conf | xargs grep -i Modes So while I agree the kit screen should work out of the box, the fact that even your dell lcd monitor doesn't work is cause for concern. Is there anything in the Xorg log that indicates why it isn't able to get the EDID data? -- Darren In the xorg log I do not see any useful EDID information. Either these displays do not support EDID, or the EDID support in the EMGD driver is not working well with these devices. And the EMGD driver is closed source. So we can't fix it. So IMO keeping the resolution to 800x600 is the best possible solution for crownbay BSP. Nitin ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/4] emgd-driver-bin: upgrade from 1.10 to 1.14
-Original Message-
From: Zanussi, Tom
Sent: Tuesday, July 31, 2012 1:13 AM
To: Kamble, Nitin A
Cc: yocto@yoctoproject.org; bruce.ashfi...@windriver.com
Subject: Re: [PATCH 1/4] emgd-driver-bin: upgrade from 1.10 to 1.14
On Sun, 2012-07-29 at 07:00 -0700, nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
1.14 is the latest released driver for emgd. This change is tested on
crownbay machine.
Add runtime dependency to libxcb-dri2
Hi Nitin,
When building, I'm seeing this:
NOTE: Resolving any missing task queue dependencies
NOTE: multiple providers are available for runtime libxcb-dri2 (libxcb-
nativesdk, libxcb)
NOTE: consider defining a PREFERRED_PROVIDER entry to match libxcb-dri2
Tom
This is issue with the libxcb recipe. I have sent a fix for that to oecore
mailing list.
Nitin
Otherwise the libxcb-dri2.so is not getting installed, and video
acceleration of emgd does not work. It is dynamic dependency of
emgd_drv_video.so
put files in gstreamer-0.10/.debug directory to the debug package.
It avoids debug files packaging warnings.
add downloadfilename param to SRC_URI
As the url does not have the filename of the tarball, specify it here
so that updated wget bitbake fetcher can save the downloaded file
accordingly.
BTW now EDC has also published another download URL on our request:
http://edc.intel.com/App_Shared/Downloads/LIN_IEMGD_1_14_GOLD_244
3.tgz
And update emgd driver version in the README.
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
...-driver-bin_1.10.bb = emgd-driver-bin_1.14.bb} | 17 +---
-
meta-crownbay/README |8
2 files changed, 13 insertions(+), 12 deletions(-) rename
common/recipes-graphics/xorg-xserver/{emgd-driver-bin_1.10.bb =
emgd-driver-bin_1.14.bb} (88%)
diff --git
a/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.10.bb
b/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.14.bb
similarity index 88%
rename from
common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.10.bb
rename to common/recipes-graphics/xorg-xserver/emgd-driver-
bin_1.14.bb
index 5779e5d..b1ba1b8 100644
--- a/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.10.bb
+++ b/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.14.bb
@@ -1,9 +1,9 @@
-SUMMARY = EMGD 1.10 xserver binaries
-DESCRIPTION = EMGD 1.10 includes some userspace binaries that use
non-free \
+SUMMARY = EMGD 1.14 xserver binaries
+DESCRIPTION = EMGD 1.14 includes some userspace binaries that use
+non-free \
licensing, which are now available via a non-click-through
downloadable \ tarball, and is what this recipe now uses. Since it
is a non-free license, \ -this recipe is marked as
'License_emgd-driver-bin_1.10' and you need to add \ -to
LICENSE_FLAGS_WHITELIST += \License_emgd-driver-bin_1.10\ to your \
+this recipe is marked as 'License_emgd-driver-bin_1.14' and you need
+to add \ to LICENSE_FLAGS_WHITELIST +=
+\License_emgd-driver-bin_1.14\ to your \
local.conf in order to enable it in a build.
LICENSE = Intel-binary-only
LICENSE_FLAGS = license_${PN}_${PV}
@@ -16,17 +16,18 @@ EMGD_VIDEO_PLUGIN_DIR =
../common/video_plugin
LIC_FILES_CHKSUM =
file://${WORKDIR}/${EMGD_LIC_DIR}/License.txt;md5=b54f01caaf8483b3cb
60c0c40f2bf22d
DEPENDS = rpm-native xz-native
+RDEPENDS = libxcb-dri2
-SRC_URI =
https://edc.intel.com/App_Shared/Downloads/LIN_EMGD_1_10_RC_2209.
tgz
+SRC_URI =
https://edc.intel.com/Download.aspx?id=6190;downloadfilename=LIN_IEM
GD_1_14_GOLD_2443.tgz
-SRC_URI[md5sum] = e4a38d9efa0b086ae21b68145c4db4e9
-SRC_URI[sha256sum] =
acea5f0f93a31553553428623c007d7ed0c604cf715fd87dfe075751da4be548
+SRC_URI[md5sum] = 733a7f237ffce21238ce2c9956df4fd6
+SRC_URI[sha256sum] =
bcdc333b5edbda7c746a83ef821ded4a0ca55ead30980e4e3680cdb6469f45a2
# These are closed binaries generated elsewhere so don't check
ldflags INSANE_SKIP_${PN} = ldflags
FILES_${PN} += ${libdir}/dri ${libdir}/gstreamer-0.10
${libdir}/xorg/modules/drivers
-FILES_${PN}-dbg += ${libdir}/xorg/modules/drivers/.debug
${libdir}/dri/.debug
+FILES_${PN}-dbg += ${libdir}/xorg/modules/drivers/.debug
${libdir}/dri/.debug ${libdir}/gstreamer-0.10/.debug
S = ${WORKDIR}/${EMGD_RPM_DIR}
diff --git a/meta-crownbay/README b/meta-crownbay/README index
b56c79a..2521432 100644
--- a/meta-crownbay/README
+++ b/meta-crownbay/README
@@ -6,7 +6,7 @@ The Crown Bay platform consists of the Intel Atom Z6xx
processor, plus the Intel EG20T Platform Controller Hub (Tunnel Creek +
Topcliff).
It also supports the E6xx embedded on-chip graphics via the Intel
-Embedded Media and Graphics Driver (EMGD) 1.10 Driver.
+Embedded Media and Graphics Driver (EMGD) 1.14 Driver.
Dependencies
@@ -63,7 +63,7 @@ common metadata shared between BSPs) e.g.:
The meta
Re: [yocto] [PATCH 2/6] crownbay: customize the xorg.conf for the flat panel on the corwnbay kit
-Original Message- From: Darren Hart [mailto:dvh...@linux.intel.com] Sent: Friday, July 27, 2012 1:41 AM To: Kamble, Nitin A Cc: yocto@yoctoproject.org; bruce.ashfi...@windriver.com; Zanussi, Tom Subject: Re: [yocto] [PATCH 2/6] crownbay: customize the xorg.conf for the flat panel on the corwnbay kit On 07/23/2012 03:06 AM, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com The kit has Auo 800x600 LCD screen. Configuring Xorg for it. I presume the crownbay has additional display options? how does this impact those? This change sets the resolution of the screen to 800x600. And this is applicable to LCD screen on the kit as well as external monitor. I will add a note about it in the log. Thanks, Nitin -- Darren Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com --- .../xserver-xf86-config/crownbay/xorg.conf | 14 ++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86- config/crow nbay/xorg.conf b/meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86- config/crow nbay/xorg.conf index 662f60f..d71173c 100644 --- a/meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86- config/crow nbay/xorg.conf +++ b/meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/ +++ crownbay/xorg.conf @@ -4,12 +4,26 @@ ## DriverVer= ## +# AUO G084SN05 V8 lcd flat panel +Section Monitor +Identifier Monitor0 +VendorName Auo +#HorizSync 33.6 - 48.3 +#VertRefresh 60.0 - 60.0 +Option DPMS +EndSection + Section Screen IdentifierScreen0 DeviceIntelEMGD-0 Monitor Monitor0 + +# for the AUO flat screen SubSectionDisplay +Depth 24 +Modes 800x600 EndSubSection + EndSection # Primary (First/only) display -- Darren Hart Intel Open Source Technology Center Yocto Project - Technical Lead - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 2/6] crownbay: customize the xorg.conf for the flat panel on the corwnbay kit
On 07/23/2012 03:06 AM, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com The kit has Auo 800x600 LCD screen. Configuring Xorg for it. I presume the crownbay has additional display options? how does this impact those? This change sets the resolution of the screen to 800x600. And this is applicable to LCD screen on the kit as well as external monitor. I will add a note about it in the log. I presume that without this change it was able to detect the appropriate resolution of the connected monitor, but not of the LCD? If so, this change effectively breaks that autodetection and forces everything to the 800x600 display which is arguably very low-resolution by today's standards. Why should this be the default? When you refer to the kit, what exactly are you referring to? Also, is this a discussion you have already had with Tom? I don't want to contradict what he has said regarding this BSP. EMGD driver on crownbay gives few resolutions as options. By default it tries to set 1366x768 resolution for both LCD and external monitor. The Crownbay kit is a suitcase kind of box, which has builtin LCD screen of resolution 800x600. This LCD screen shows only 800x600 of the default 1366x768 area. So The LCD is not able to show all the screen, and IMO it is a functional issue. For my Dell 1704FPTi monitor which has 1280x1024 native resolution; When connected to the crownbay, X cannot find a working mode for this monitor. But if I set 800x600 in the xorg.conf as this commit does, then both LCD external monitor can show the X screen without any issues. I guess if a 1366x768 resolution monitor is connected to crownbay, it will show the X screen fine, but I don't have such monitor now. And also I think a BSP should not have such resolution requirement for the attached monitor, and attached LCD screen of the kit work without issues. So the point of this commit is, make default config such that it will work for the LCD screen on the kit as well as any monitor attached. And if someone wants to get better resolution with their external monitor then they need to adjust the xorg.conf accordingly. BTW I did not have much discussion with Tom on this topic. Thanks, Nitin ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/6] emgd-driver-bin: upgrade from 1.10 to 1.14
This commit needs latest poky master to get the bitbake wget fetcher
enhancement needed for the SRC_URI.
Thanks,
Nitin
-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-
boun...@yoctoproject.org] On Behalf Of nitin.a.kam...@intel.com
Sent: Monday, July 23, 2012 3:36 PM
To: yocto@yoctoproject.org; bruce.ashfi...@windriver.com; Zanussi, Tom
Subject: [yocto] [PATCH 1/6] emgd-driver-bin: upgrade from 1.10 to 1.14
From: Nitin A Kamble nitin.a.kam...@intel.com
1.14 is the latest released driver for emgd. This change is tested on crownbay
machine.
Add runtime dependency to libxcb-dri2
Otherwise the libxcb-dri2.so is not getting installed, and video acceleration
of
emgd does not work. It is dynamic dependency of emgd_drv_video.so
emgd-driver-bin: add downloadfilename param to SRC_URI
As the url does not have the filename of the tarball, specify it here so that
updated wget bitbake fetcher can save the downloaded file accordingly.
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
...-driver-bin_1.10.bb = emgd-driver-bin_1.14.bb} | 17 +
1 files changed, 9 insertions(+), 8 deletions(-) rename common/recipes-
graphics/xorg-xserver/{emgd-driver-bin_1.10.bb = emgd-driver-
bin_1.14.bb} (88%)
diff --git a/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.10.bb
b/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.14.bb
similarity index 88%
rename from common/recipes-graphics/xorg-xserver/emgd-driver-
bin_1.10.bb
rename to common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.14.bb
index 5779e5d..b1ba1b8 100644
--- a/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.10.bb
+++ b/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.14.bb
@@ -1,9 +1,9 @@
-SUMMARY = EMGD 1.10 xserver binaries
-DESCRIPTION = EMGD 1.10 includes some userspace binaries that use non-
free \
+SUMMARY = EMGD 1.14 xserver binaries
+DESCRIPTION = EMGD 1.14 includes some userspace binaries that use
+non-free \
licensing, which are now available via a non-click-through downloadable \
tarball, and is what this recipe now uses. Since it is a non-free license, \
-this
recipe is marked as 'License_emgd-driver-bin_1.10' and you need to add \ -to
LICENSE_FLAGS_WHITELIST += \License_emgd-driver-bin_1.10\ to your \
+this recipe is marked as 'License_emgd-driver-bin_1.14' and you need to
+add \ to LICENSE_FLAGS_WHITELIST += \License_emgd-driver-bin_1.14\
to
+your \
local.conf in order to enable it in a build.
LICENSE = Intel-binary-only
LICENSE_FLAGS = license_${PN}_${PV}
@@ -16,17 +16,18 @@ EMGD_VIDEO_PLUGIN_DIR =
../common/video_plugin
LIC_FILES_CHKSUM =
file://${WORKDIR}/${EMGD_LIC_DIR}/License.txt;md5=b54f01caaf8483b3cb
60c0c40f2bf22d
DEPENDS = rpm-native xz-native
+RDEPENDS = libxcb-dri2
-SRC_URI =
https://edc.intel.com/App_Shared/Downloads/LIN_EMGD_1_10_RC_2209.
tgz
+SRC_URI =
https://edc.intel.com/Download.aspx?id=6190;downloadfilename=LIN_IEM
GD_1_14_GOLD_2443.tgz
-SRC_URI[md5sum] = e4a38d9efa0b086ae21b68145c4db4e9
-SRC_URI[sha256sum] =
acea5f0f93a31553553428623c007d7ed0c604cf715fd87dfe075751da4be548
+SRC_URI[md5sum] = 733a7f237ffce21238ce2c9956df4fd6
+SRC_URI[sha256sum] =
bcdc333b5edbda7c746a83ef821ded4a0ca55ead30980e4e3680cdb6469f45a2
# These are closed binaries generated elsewhere so don't check ldflags
INSANE_SKIP_${PN} = ldflags
FILES_${PN} += ${libdir}/dri ${libdir}/gstreamer-0.10
${libdir}/xorg/modules/drivers
-FILES_${PN}-dbg += ${libdir}/xorg/modules/drivers/.debug
${libdir}/dri/.debug
+FILES_${PN}-dbg += ${libdir}/xorg/modules/drivers/.debug
${libdir}/dri/.debug ${libdir}/gstreamer-0.10/.debug
S = ${WORKDIR}/${EMGD_RPM_DIR}
--
1.7.3.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/1] meta: update crownbay.scc for newer emgd driver
-Original Message- From: Zanussi, Tom Sent: Thursday, July 19, 2012 8:57 AM To: Kamble, Nitin A Cc: yocto@yoctoproject.org; bruce.ashfi...@windriver.com Subject: RE: [PATCH 0/1] meta: update crownbay.scc for newer emgd driver On Wed, 2012-07-18 at 19:58 -0700, Kamble, Nitin A wrote: -Original Message- From: Zanussi, Tom Sent: Wednesday, July 18, 2012 7:43 PM To: Kamble, Nitin A Cc: yocto@yoctoproject.org; bruce.ashfi...@windriver.com Subject: Re: [PATCH 0/1] meta: update crownbay.scc for newer emgd driver On Mon, 2012-07-16 at 22:57 -0700, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com This commit changes emgd kernel driver for crownbay bsp to the emgd- 1.14. Nitin, Doesn't switching this over in the kenrnel require emgd-1.14 userspace recipe updates to work? Did I miss those? Tom Tom, I am holding the emgd 1.14 userspace commits until the kernel repository change goes upstream. The kernel recipe will need new SRCREV (with emgd 1.14 kernel parts) for the user level emgd 1.14 parts to work. And that dependency will get satisfied once this commit is in. Yeah, I understand, the crownbay is typically the most complicated update for all of those reasons - simultaneous new kernel version/recipe, new emgd branch, and new emgd userspace recipe all at the same time. In the past I've submitted them all at the same time for simultaneous review and some coordination with Bruce - once the kernel parts are in, the kernel recipe and the userspace parts can then be pulled in along with a simple follow-on patch to update the SRCREVs Bruce give us. The thing is that if Bruce pulls in the patch to switch to emgd-1.14 and only at that point do you post the userspace recipe, and it ends up needing some rework, in the meantime the graphics remain non-functional (I know, they already are, thanks to the package re-ordering patches breaking the current recipe, but hopefully the 1.14 changes will be in and we don't have to worry about it any more.). Does that make sense, and can you just post the userspace and kernel recipe parts before we give Bruce the go-ahead in making the kernel changes? (I'd also like to try it out myself as well...). Tom, Until the crownbay bsp's Linux-yocto kernel recipe's meta SRCREV is updated, these kernel repo changes have no effect in the build process. Right ? So as I see, this commit does not make anything worst (or better). I am sending the userland recipe commits anyway; So that you can also test it out. Thanks, Nitin ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/1] meta: update crownbay.scc for newer emgd driver
-Original Message- From: Zanussi, Tom Sent: Thursday, July 19, 2012 8:27 PM To: Kamble, Nitin A Cc: yocto@yoctoproject.org; bruce.ashfi...@windriver.com Subject: RE: [PATCH 0/1] meta: update crownbay.scc for newer emgd driver On Thu, 2012-07-19 at 07:39 -0700, Kamble, Nitin A wrote: -Original Message- From: Zanussi, Tom Sent: Thursday, July 19, 2012 8:57 AM To: Kamble, Nitin A Cc: yocto@yoctoproject.org; bruce.ashfi...@windriver.com Subject: RE: [PATCH 0/1] meta: update crownbay.scc for newer emgd driver On Wed, 2012-07-18 at 19:58 -0700, Kamble, Nitin A wrote: -Original Message- From: Zanussi, Tom Sent: Wednesday, July 18, 2012 7:43 PM To: Kamble, Nitin A Cc: yocto@yoctoproject.org; bruce.ashfi...@windriver.com Subject: Re: [PATCH 0/1] meta: update crownbay.scc for newer emgd driver On Mon, 2012-07-16 at 22:57 -0700, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com This commit changes emgd kernel driver for crownbay bsp to the emgd- 1.14. Nitin, Doesn't switching this over in the kenrnel require emgd-1.14 userspace recipe updates to work? Did I miss those? Tom Tom, I am holding the emgd 1.14 userspace commits until the kernel repository change goes upstream. The kernel recipe will need new SRCREV (with emgd 1.14 kernel parts) for the user level emgd 1.14 parts to work. And that dependency will get satisfied once this commit is in. Yeah, I understand, the crownbay is typically the most complicated update for all of those reasons - simultaneous new kernel version/recipe, new emgd branch, and new emgd userspace recipe all at the same time. In the past I've submitted them all at the same time for simultaneous review and some coordination with Bruce - once the kernel parts are in, the kernel recipe and the userspace parts can then be pulled in along with a simple follow-on patch to update the SRCREVs Bruce give us. The thing is that if Bruce pulls in the patch to switch to emgd-1.14 and only at that point do you post the userspace recipe, and it ends up needing some rework, in the meantime the graphics remain non-functional (I know, they already are, thanks to the package re-ordering patches breaking the current recipe, but hopefully the 1.14 changes will be in and we don't have to worry about it any more.). Does that make sense, and can you just post the userspace and kernel recipe parts before we give Bruce the go-ahead in making the kernel changes? (I'd also like to try it out myself as well...). Tom, Until the crownbay bsp's Linux-yocto kernel recipe's meta SRCREV is updated, these kernel repo changes have no effect in the build process. Right ? So as I see, this commit does not make anything worst (or better). I am sending the userland recipe commits anyway; So that you can also test it out. Right, but what if we have to update the meta SRCREV for a different reason in the meantime (like we did last week for instance). We're then forced to take the emgd commit as well. I see the issue now. And I don't see a perfect solution to the issue. Because of commits in two different repos there always going to be this kind of a sync issue. The best is pull the commits in both repositories at the same time. Thanks, Nitin In any case, it's your BSP so it's up to you how you want to manage it, I'm just trying to save you and the users some headaches. It always made sense to me to do it all at the same time, all else being equal... Tom Thanks, Nitin ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/1] meta: update crownbay.scc for newer emgd driver
-Original Message- From: Zanussi, Tom Sent: Wednesday, July 18, 2012 7:43 PM To: Kamble, Nitin A Cc: yocto@yoctoproject.org; bruce.ashfi...@windriver.com Subject: Re: [PATCH 0/1] meta: update crownbay.scc for newer emgd driver On Mon, 2012-07-16 at 22:57 -0700, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com This commit changes emgd kernel driver for crownbay bsp to the emgd- 1.14. Nitin, Doesn't switching this over in the kenrnel require emgd-1.14 userspace recipe updates to work? Did I miss those? Tom Tom, I am holding the emgd 1.14 userspace commits until the kernel repository change goes upstream. The kernel recipe will need new SRCREV (with emgd 1.14 kernel parts) for the user level emgd 1.14 parts to work. And that dependency will get satisfied once this commit is in. Nitin ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/1] remove snb rc6 patches from v3.4 kernel repository
Bruce, I think these rc6 patches are still needed for linux-yocto_3.2.bbappend. And they are referenced in the sugarbay bsp 3.2 Yocto kernel as you note above. The commit I sent is for for v3.4 yocto kernel tree. Yes, of course it's for 3.4 .. that's where I merged it :) http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.4/log/?h=meta Are you saying about dropping rc6 patches from the 3.2 kernel tree as well? I was more reminding for any updates to the BSP to 3.4 .. i.e. don't forget to drop it from the recipes when updating, sine it will thrown an error during patching. Cheers, Bruce I see your point now. I have dropped them from 3.4 kernel recipe 1st to avoid patch application errors. Then we realized that these patches are not needed in the v3.4 kernel repository. Nitin ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH x32 Edison 0/2] Fixes for meta-x32 edison branch
-Original Message-
From: Joshua Lock [mailto:joshua.l...@intel.com]
Sent: Tuesday, June 05, 2012 5:46 PM
To: yocto@yoctoproject.org
Cc: Joshua Lock; Kamble, Nitin A
Subject: [PATCH x32 Edison 0/2] Fixes for meta-x32 edison branch
The following patches are required to use the edison branch of meta-x32
with the current edison branch of Poky.
The first change is required because the edison branch updated its openssl
version some time ago for security fixes.
The gmp change is required so that gmp-native can be used by ppl.
Regards,
Joshua
CC: Nitin Kamble nitin.a.kam...@intel.com
The following changes since commit
78a8f65718b7ad7c93103a82026575687271cf5d:
gmp: also built libgmpxx for gmp-native (2011-10-14 10:30:03 -0700)
are available in the git repository at:
git://github.com/incandescant/meta-x32.git josh/edison
https://github.com/incandescant/meta-x32
Joshua Lock (2):
openssl: update bbappend to match version in poky edison
gmp: Fix EXTRA_OECONF for native target
Merged these 2 commits in to Edison branch of the meta-x32 layer.
Nitin
gmp/gmp_5.0.2.bbappend |2 +-
...ssl_0.9.8r.bbappend = openssl_0.9.8s.bbappend} |0
2 files changed, 1 insertions(+), 1 deletions(-) rename
openssl/{openssl_0.9.8r.bbappend = openssl_0.9.8s.bbappend} (100%)
--
1.7.7.6
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 3/3] poky-tiny: avoid eglibc locale packaging
-Original Message- From: Darren Hart [mailto:dvh...@linux.intel.com] Thanks for looking into this Nitin! I'm fine with this fix if it gets things going. I wonder though, I presume omitting something from DISTRO_FEATURES_LIBC is what triggers this bug... could that same omission not be tested to avoid the failure? Seems strange to have to explicitly set PACKAGE_NO_GCONV. Thoughts? Makes sense, I will look into such solution. Nitin ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] yassl recipe in the yocto project
Hi Chris, Here is the recipe we have in yocto-project for openssl projects to be incorporated into embedded Linux distributions. http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-connectivity/openssl Please visit www.yoctoproject.orghttp://www.yoctoproject.org for more information on the Yocto Project. It would be nice to get yassl recipe also in there as an alternative to openssl. Context for others: I came across Chris at ESC, He works for yassl .com which provides GPLv2 ssl solution like openssl which is smaller compared to openssl and targeted for embedded solutions. Thanks, Nitin ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-x32: disagreement between ref manual and README.TXT
-Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Robert P. J. Day Sent: Sunday, March 25, 2012 9:17 AM To: Yocto discussion list Subject: [yocto] meta-x32: disagreement between ref manual and README.TXT poky ref manual reads: As usual, use BitBake to build an image that supports the x32 psABI. Here is an example: $ bitake core-image-sato As usual, run your image using QUEM [sic]: $ runqemu qemux86-64 core-image-sato while the README.TXT file that comes with the experimental/meta-x32 layer reads: build bitbake core-image-minimal-x32 4. boot the image runqemu qemux86-64 core-image-minimal-x32 thoughts? rday Hi Robert, It is not a significant difference. Images with -x32 in their names contain an additional utility named file. Which can let one check the file types of elf binaries. And the absence of this file utility does not affect functionality of x32 images. Thanks, Nitin ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] qemu EFI build failure
Darren, I have reworked the commits to fix issues while building on other distros. Can you check this branch http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=nitin/grub-efi It is working for me on Fedora 14, for which the other grub-efi commit was failing for me. Thanks, Nitin -Original Message- From: Kamble, Nitin A Sent: Thursday, January 12, 2012 2:33 PM To: Kamble, Nitin A; Hart, Darren; Bodke, Kishore K Cc: Ahmad, Josef; yocto@yoctoproject.org Subject: RE: [yocto] qemu EFI build failure Here is the commit: http://git.yoctoproject.org/cgit.cgi/poky- contrib/log/?h=nitin/misc Nitin -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Kamble, Nitin A Sent: Thursday, January 12, 2012 2:32 PM To: Hart, Darren; Bodke, Kishore K Cc: Ahmad, Josef; yocto@yoctoproject.org Subject: Re: [yocto] qemu EFI build failure I just sent a patch to oecore mailing list to fix the grub issue with automake 1.11.2. Thanks, Nitin -Original Message- From: Hart, Darren Sent: Thursday, January 12, 2012 1:39 PM To: Bodke, Kishore K Cc: Ahmad, Josef; yocto@yoctoproject.org; Kamble, Nitin A Subject: Re: [yocto] qemu EFI build failure On 01/12/2012 01:28 PM, Bodke, Kishore K wrote: I have only MACHINE_FEATURES += efi KERNEL_FEATURES_append_cedartrail += cfg/efi-ext.scc. I am not having IMAGE_FSTYPES += live. The live change is just to trigger the live image type which builds grub-efi-native for efi systems. qemux86 needs this added explicitly. -- Darren Thanks Kishore. -Original Message- From: Hart, Darren Sent: Thursday, January 12, 2012 1:20 PM To: Ahmad, Josef Cc: yocto@yoctoproject.org; Bodke, Kishore K; Kamble, Nitin A Subject: Re: [yocto] qemu EFI build failure On 01/12/2012 10:27 AM, Darren Hart wrote: On 01/12/2012 08:19 AM, Josef Ahmad wrote: I tried to build a qemux86 EFI image, by setting: - in my local.conf: IMAGE_FSTYPES += live - in poly/meta/conf/machine/qemux86.conf: MACHINE_FEATURES += efi I haven't tried live images with QEMU. For one thing, they aren't really necessary as you can specify all the boot parameters on the qemu command line. Is there are reason you want to use the live image specifically? Also, in order to properly test EFI in QEMU, you will need to use an EFI BIOS - I believe you're aware of this already - but this isn't currently supported by the runqemu scripts that ship with yocto. The build gave me the following error: I'll do some test builds - it isn't clear to me what is going on here. snip Has anyone encountered the same error? I'm not sure I set up the correct configuration. Also, is there another way to append efi to MACHINE_FEATURES rather than by modifying qemux86.conf? You should be able to do something like: MACHINE_FEATURES_append_qemux86 = efi Note that you will also need to enable the efi support in the kernel, which is done with the KERNEL_FEATURES variable, something like: KERNEL_FEATURES_append_qemux86 = conf/efi-ext.scc Either of these can be set in your local.conf. More accurately: MACHINE_FEATURES_append_qemux86= efi pcbios KERNEL_FEATURES_append_qemux86= cfg/efi-ext.scc IMAGE_FSTYPES += live With these added to local.conf and building for qemux86 I see the same configure failures reported by Kishore and Josef: | ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... | acinclude.m4:363: grub_CHECK_STACK_ARG_PROBE is expanded from... I've discussed in IRC with Nitin and he thinks this may be related to the automake update and is looking into it. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] qemu EFI build failure
I just sent a patch to oecore mailing list to fix the grub issue with automake 1.11.2. Thanks, Nitin -Original Message- From: Hart, Darren Sent: Thursday, January 12, 2012 1:39 PM To: Bodke, Kishore K Cc: Ahmad, Josef; yocto@yoctoproject.org; Kamble, Nitin A Subject: Re: [yocto] qemu EFI build failure On 01/12/2012 01:28 PM, Bodke, Kishore K wrote: I have only MACHINE_FEATURES += efi KERNEL_FEATURES_append_cedartrail += cfg/efi-ext.scc. I am not having IMAGE_FSTYPES += live. The live change is just to trigger the live image type which builds grub-efi-native for efi systems. qemux86 needs this added explicitly. -- Darren Thanks Kishore. -Original Message- From: Hart, Darren Sent: Thursday, January 12, 2012 1:20 PM To: Ahmad, Josef Cc: yocto@yoctoproject.org; Bodke, Kishore K; Kamble, Nitin A Subject: Re: [yocto] qemu EFI build failure On 01/12/2012 10:27 AM, Darren Hart wrote: On 01/12/2012 08:19 AM, Josef Ahmad wrote: I tried to build a qemux86 EFI image, by setting: - in my local.conf: IMAGE_FSTYPES += live - in poly/meta/conf/machine/qemux86.conf: MACHINE_FEATURES += efi I haven't tried live images with QEMU. For one thing, they aren't really necessary as you can specify all the boot parameters on the qemu command line. Is there are reason you want to use the live image specifically? Also, in order to properly test EFI in QEMU, you will need to use an EFI BIOS - I believe you're aware of this already - but this isn't currently supported by the runqemu scripts that ship with yocto. The build gave me the following error: I'll do some test builds - it isn't clear to me what is going on here. snip Has anyone encountered the same error? I'm not sure I set up the correct configuration. Also, is there another way to append efi to MACHINE_FEATURES rather than by modifying qemux86.conf? You should be able to do something like: MACHINE_FEATURES_append_qemux86 = efi Note that you will also need to enable the efi support in the kernel, which is done with the KERNEL_FEATURES variable, something like: KERNEL_FEATURES_append_qemux86 = conf/efi-ext.scc Either of these can be set in your local.conf. More accurately: MACHINE_FEATURES_append_qemux86= efi pcbios KERNEL_FEATURES_append_qemux86= cfg/efi-ext.scc IMAGE_FSTYPES += live With these added to local.conf and building for qemux86 I see the same configure failures reported by Kishore and Josef: | ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... | acinclude.m4:363: grub_CHECK_STACK_ARG_PROBE is expanded from... I've discussed in IRC with Nitin and he thinks this may be related to the automake update and is looking into it. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] qemu EFI build failure
Here is the commit: http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=nitin/misc Nitin -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Kamble, Nitin A Sent: Thursday, January 12, 2012 2:32 PM To: Hart, Darren; Bodke, Kishore K Cc: Ahmad, Josef; yocto@yoctoproject.org Subject: Re: [yocto] qemu EFI build failure I just sent a patch to oecore mailing list to fix the grub issue with automake 1.11.2. Thanks, Nitin -Original Message- From: Hart, Darren Sent: Thursday, January 12, 2012 1:39 PM To: Bodke, Kishore K Cc: Ahmad, Josef; yocto@yoctoproject.org; Kamble, Nitin A Subject: Re: [yocto] qemu EFI build failure On 01/12/2012 01:28 PM, Bodke, Kishore K wrote: I have only MACHINE_FEATURES += efi KERNEL_FEATURES_append_cedartrail += cfg/efi-ext.scc. I am not having IMAGE_FSTYPES += live. The live change is just to trigger the live image type which builds grub-efi-native for efi systems. qemux86 needs this added explicitly. -- Darren Thanks Kishore. -Original Message- From: Hart, Darren Sent: Thursday, January 12, 2012 1:20 PM To: Ahmad, Josef Cc: yocto@yoctoproject.org; Bodke, Kishore K; Kamble, Nitin A Subject: Re: [yocto] qemu EFI build failure On 01/12/2012 10:27 AM, Darren Hart wrote: On 01/12/2012 08:19 AM, Josef Ahmad wrote: I tried to build a qemux86 EFI image, by setting: - in my local.conf: IMAGE_FSTYPES += live - in poly/meta/conf/machine/qemux86.conf: MACHINE_FEATURES += efi I haven't tried live images with QEMU. For one thing, they aren't really necessary as you can specify all the boot parameters on the qemu command line. Is there are reason you want to use the live image specifically? Also, in order to properly test EFI in QEMU, you will need to use an EFI BIOS - I believe you're aware of this already - but this isn't currently supported by the runqemu scripts that ship with yocto. The build gave me the following error: I'll do some test builds - it isn't clear to me what is going on here. snip Has anyone encountered the same error? I'm not sure I set up the correct configuration. Also, is there another way to append efi to MACHINE_FEATURES rather than by modifying qemux86.conf? You should be able to do something like: MACHINE_FEATURES_append_qemux86 = efi Note that you will also need to enable the efi support in the kernel, which is done with the KERNEL_FEATURES variable, something like: KERNEL_FEATURES_append_qemux86 = conf/efi-ext.scc Either of these can be set in your local.conf. More accurately: MACHINE_FEATURES_append_qemux86= efi pcbios KERNEL_FEATURES_append_qemux86= cfg/efi-ext.scc IMAGE_FSTYPES += live With these added to local.conf and building for qemux86 I see the same configure failures reported by Kishore and Josef: | ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... | acinclude.m4:363: grub_CHECK_STACK_ARG_PROBE is expanded from... I've discussed in IRC with Nitin and he thinks this may be related to the automake update and is looking into it. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/1] btrfs: Add a new kernel feature to enable the btrfs support
Hi Bruce, I am seeing that the patch is still not part of the Linux-yocto-3.0 repository. Is there any reason it is being hold? Thanks, Nitin -Original Message- From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] Sent: Tuesday, September 06, 2011 1:30 PM To: Kamble, Nitin A Cc: yocto@yoctoproject.org Subject: Re: [yocto] [PATCH 1/1] btrfs: Add a new kernel feature to enable the btrfs support On 11-09-06 03:56 PM, nitin.a.kam...@intel.com wrote: From: Nitin A Kamblenitin.a.kam...@intel.com Looks good. If we are merging this as config only, I've been putting them in meta/cfg/kernel-cache/cfg/ So I relocated this configuration to that directory. I'll have it pushed out in the next day or so (I'm getting on a plane shortly). Bruce Signed-off-by: Nitin A Kamblenitin.a.kam...@intel.com --- meta/cfg/kernel-cache/features/btrfs/btrfs.cfg |1 + meta/cfg/kernel-cache/features/btrfs/btrfs.scc |1 + 2 files changed, 2 insertions(+), 0 deletions(-) create mode 100644 meta/cfg/kernel-cache/features/btrfs/btrfs.cfg create mode 100644 meta/cfg/kernel-cache/features/btrfs/btrfs.scc diff --git a/meta/cfg/kernel-cache/features/btrfs/btrfs.cfg b/meta/cfg/kernel-cache/features/btrfs/btrfs.cfg new file mode 100644 index 000..605c183 --- /dev/null +++ b/meta/cfg/kernel-cache/features/btrfs/btrfs.cfg @@ -0,0 +1 @@ +CONFIG_BTRFS_FS=y diff --git a/meta/cfg/kernel-cache/features/btrfs/btrfs.scc b/meta/cfg/kernel-cache/features/btrfs/btrfs.scc new file mode 100644 index 000..cf18a2e --- /dev/null +++ b/meta/cfg/kernel-cache/features/btrfs/btrfs.scc @@ -0,0 +1 @@ +kconf non-hardware btrfs.cfg ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/1] btrfs: Add a new kernel feature to enable the btrfs support
Thanks Bruce, BTW we should enable this btrfs feature for linux-yocto-3 kernel. What is the right way to do it? Shall I send a patch for the Linux-yocot-3.0 recipe in the oe-core repository? Thanks, Nitin -Original Message- From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] Sent: Tuesday, September 06, 2011 1:30 PM To: Kamble, Nitin A Cc: yocto@yoctoproject.org Subject: Re: [yocto] [PATCH 1/1] btrfs: Add a new kernel feature to enable the btrfs support On 11-09-06 03:56 PM, nitin.a.kam...@intel.com wrote: From: Nitin A Kamblenitin.a.kam...@intel.com Looks good. If we are merging this as config only, I've been putting them in meta/cfg/kernel-cache/cfg/ So I relocated this configuration to that directory. I'll have it pushed out in the next day or so (I'm getting on a plane shortly). Bruce Signed-off-by: Nitin A Kamblenitin.a.kam...@intel.com --- meta/cfg/kernel-cache/features/btrfs/btrfs.cfg |1 + meta/cfg/kernel-cache/features/btrfs/btrfs.scc |1 + 2 files changed, 2 insertions(+), 0 deletions(-) create mode 100644 meta/cfg/kernel-cache/features/btrfs/btrfs.cfg create mode 100644 meta/cfg/kernel-cache/features/btrfs/btrfs.scc diff --git a/meta/cfg/kernel-cache/features/btrfs/btrfs.cfg b/meta/cfg/kernel-cache/features/btrfs/btrfs.cfg new file mode 100644 index 000..605c183 --- /dev/null +++ b/meta/cfg/kernel-cache/features/btrfs/btrfs.cfg @@ -0,0 +1 @@ +CONFIG_BTRFS_FS=y diff --git a/meta/cfg/kernel-cache/features/btrfs/btrfs.scc b/meta/cfg/kernel-cache/features/btrfs/btrfs.scc new file mode 100644 index 000..cf18a2e --- /dev/null +++ b/meta/cfg/kernel-cache/features/btrfs/btrfs.scc @@ -0,0 +1 @@ +kconf non-hardware btrfs.cfg ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel Panics on armv4t with gcc.4.5.1
Hi Gary, I would look into the 4.5.2 branch and will try to get it to work. BTW there is some workaround Diego Sueiro came up with in his email yday for 4.5.2 gcc. Thanks, Nitin -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Gary Thomas Sent: Wednesday, February 02, 2011 7:29 AM To: yocto@yoctoproject.org Subject: Re: [yocto] Kernel Panics on armv4t with gcc.4.5.1 On 02/02/2011 06:45 AM, Gary Thomas wrote: On 01/31/2011 05:41 PM, Kamble, Nitin A wrote: Diego, Can you try with 4.5.2 gcc from this branch: http://git.pokylinux.org/cgit/cgit.cgi/poky- contrib/log/?h=nitin/khem_gcc_nitin I too am having trouble (OMAP-L138 == armv5te/arm926ejs) Nitin, I tried using your branch, but it failed to build: NOTE: package gcc-cross-intermediate-4.5.2-r3: task do_populate_sysroot: Started ERROR: Error executing a python function in /home/local/poky- contrib/meta/recipes-devtools/gcc/gcc-cross-intermediate_4.5.2.bb: OSError: [Errno 2] No such file or directory: '/home/local/efacec_omap_4.5.2/tmp/work/armv5te-poky-linux- gnueabi/gcc-cross-intermediate-4.5.2-r3/sysroot- destdir///home/local/efacec_omap_4.5.2/tmp/sysroots/cobra- omapl138p78//lib' ERROR: The stack trace of python calls that resulted in this exception/failure was: ERROR: File sstate_task_postfunc, line 10, in module ERROR: ERROR: File sstate_task_postfunc, line 4, in sstate_task_postfunc ERROR: ERROR: File sstate.bbclass, line 17, in sstate_install ERROR: ERROR: File /home/local/poky-contrib/meta/lib/oe/path.py, line 56, in copytree ERROR: names = os.listdir(src) ERROR: ERROR: The code that was being executed was: ERROR: 0006: bb.build.exec_func(intercept, d) ERROR: 0007: sstate_package(shared_state, d) ERROR: 0008: ERROR: 0009: ERROR: *** 0010:sstate_task_postfunc(d) ERROR: 0011: ERROR: (file: 'sstate_task_postfunc', lineno: 10, function: module) ERROR: 0001: ERROR: 0002:def sstate_task_postfunc(d): ERROR: 0003: shared_state = sstate_state_fromvars(d) ERROR: *** 0004: sstate_install(shared_state, d) ERROR: 0005: for intercept in shared_state['interceptfuncs']: ERROR: 0006: bb.build.exec_func(intercept, d) ERROR: 0007: sstate_package(shared_state, d) ERROR: 0008: ERROR: (file: 'sstate_task_postfunc', lineno: 4, function: sstate_task_postfunc) ERROR: Function 'sstate_task_postfunc' failed Any ideas how to fix this? Just to check, I applied the patches from Nitin's contrib tree to poky/master and rebuilt - same results. I used the sequence 5b7e96d852778f1164198040cbd165241ea51e40..HEAD *From:*yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] *On Behalf Of *Diego Sueiro *Sent:* Monday, January 31, 2011 10:53 AM *To:* yocto@yoctoproject.org *Subject:* [yocto] Kernel Panics on armv4t with gcc.4.5.1 Folks, I'm not a kernel and neither a gcc expert developer, and after searching for a solution for the last 2 weeks I've decided to appeal to the list. I'm trying to build a kernel image (2.6.32 and 2.6.30) for mini2440 (armv4t) with Yocto Project (poky master branch) and I'm facing a strange issue. If I compile the kernel with Yocto gcc recipes (gcc 4.5.1) the kernel will panic on init (console printed message is attached for kernel 2.6.30 and 2.6.32). But, if I compile the kernel with meta-oe gcc recipes (gcc 4.5) everything will be ok. Just for your reference these is the gcc recipes which I'm using: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes- devtools/gcc http://git.openembedded.org/cgit.cgi/meta-openembedded/tree/recipes- devtools/gcc I've compiled with and without thumb instructions, but the issue remains. I've tried to apply the patches gcc-armv4-pass-fix-v4bx-to-ld.patch and gcc-arm-volatile-bitfield-fix.patch, but no success. Kind Regards, -- *dS Diego Sueiro /*long live rock 'n roll*/ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel Panics on armv4t with gcc.4.5.1
-Original Message-
From: Gary Thomas [mailto:g...@mlbassoc.com]
Sent: Thursday, February 03, 2011 12:03 PM
To: Darren Hart
Cc: Kamble, Nitin A; yocto@yoctoproject.org
Subject: Re: [yocto] Kernel Panics on armv4t with gcc.4.5.1
On 02/03/2011 11:21 AM, Darren Hart wrote:
On 02/03/2011 09:00 AM, Kamble, Nitin A wrote:
Hi Diego,
Good to know your kernel panic is gone. The 4.5.1 tree is arm
specific
linaro patches, which probably helping you. You can also try the
meta-linaro layer.
http://git.pokylinux.org/cgit/cgit.cgi/meta-linaro/
This has moved:
http://git.pokylinux.org/cgit/cgit.cgi/poky-extras
And Darren is working on updating that layer currently. The gcc from
that layer has linaro arm patches.
I'm running into some build issues during the uprev, but hoping to
have it done ASAP.
To be clear on how to use this - I added the meta-linaro layer to my
poky tree and added these to my MACHINE.conf:
GCCVERSION = 4.5.1.linaro
SDKGCCVERSION = 4.5.1.linaro
When I tried this, I got these errors:
NOTE: preferred version 4.5.1.linaro of gcc-cross not available (for
item virtual/arm-poky-linux-gnueabi-gcc)
NOTE: preferred version 4.5.1.linaro of gcc-runtime not available (for
item virtual/arm-poky-linux-gnueabi-compilerlibs)
NOTE: preferred version 4.5.1.linaro of gcc-cross not available (for
item virtual/arm-poky-linux-gnueabi-g++)
NOTE: preferred version 4.5.1.linaro of gcc-cross-intermediate not
available (for item virtual/arm-poky-linux-gnueabi-gcc-intermediate)
NOTE: preferred version 4.5.1.linaro of gcc-crosssdk not available (for
item virtual/i586-pokysdk-linux-gcc-crosssdk)
NOTE: preferred version 4.5.1.linaro of gcc-runtime-nativesdk not
available (for item virtual/i586-pokysdk-linux-compilerlibs-nativesdk)
NOTE: preferred version 4.5.1.linaro of gcc-cross-initial not available
(for item virtual/arm-poky-linux-gnueabi-gcc-initial)
NOTE: preferred version 4.5.1.linaro of gcc-crosssdk not available (for
item virtual/i586-pokysdk-linux-g++-crosssdk)
NOTE: preferred version 4.5.1.linaro of gcc-crosssdk-intermediate not
available (for item virtual/i586-pokysdk-linux-gcc-intermediate-
crosssdk)
NOTE: preferred version 4.5.1.linaro of gcc-crosssdk-initial not
available (for item virtual/i586-pokysdk-linux-gcc-initial-crosssdk)
What did I miss?
Gary,
It should have worked for you. Only thing I see is the latest drop is at
poky-extras and not meta-linaro.
Thanks,
Nitin
*From:*Diego Sueiro [mailto:diego.sue...@gmail.com]
*Sent:* Tuesday, February 01, 2011 7:34 AM
*To:* Kamble, Nitin A
*Cc:* yocto@yoctoproject.org
*Subject:* Re: [yocto] Kernel Panics on armv4t with gcc.4.5.1
Nitin,
After removing:
echo /* GNU ld script
Use the shared library, but some functions are only in
the static library. */
GROUP ( libgcc_s.so.1 libgcc.a ) ${D}${libdir}/libgcc_s.so
from gcc-package-target.inc and gcc-package-cross.inc, the gcc 4.5.2
was
successfully compiled.
And no kernel panic anymore. :-D
I just want to understand what is wrong with gcc 4.5.1.
Regards,
--
*dS
Diego Sueiro
Administrador do Portal Embarcados
www.embarcados.com.br http://www.embarcados.com.br
/*long live rock 'n roll*/
On Tue, Feb 1, 2011 at 8:40 AM, Diego Sueiro diego.sue...@gmail.com
mailto:diego.sue...@gmail.com wrote:
Nitin,
I got this error:
/home/dev/yocto-repo/build/tmp/sysroots/i686-linux/usr/bin/armv4t-
poky-linux-gnueabi/arm-poky-linux-gnueabi-ld:
/usr/lib/crti.o: Relocations in generic ELF (EM: 3)
/home/dev/yocto-repo/build/tmp/sysroots/i686-linux/usr/bin/armv4t-
poky-linux-gnueabi/arm-poky-linux-gnueabi-ld:
/usr/lib/crti.o: Relocations in generic ELF (EM: 3)
/usr/lib/crti.o: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make[2]: *** [libgcc_s.so] Error 1
make[2]: *** Waiting for unfinished jobs
arm-poky-linux-gnueabi-ranlib libgcc_eh.a
arm-poky-linux-gnueabi-ranlib libgcc.a
make[2]: Leaving directory
`/home/dev/yocto-repo/build/tmp/work/armv4t-poky-linux-gnueabi/gcc-
cross-intermediate-4.5.2-r3/gcc-4.5.2/build.i686-linux.arm-poky-linux-
gnueabi/arm-poky-linux-gnueabi/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory
`/home/dev/yocto-repo/build/tmp/work/armv4t-poky-linux-gnueabi/gcc-
cross-intermediate-4.5.2-r3/gcc-4.5.2/build.i686-linux.arm-poky-linux-
gnueabi'
make: *** [all] Error 2
FATAL: oe_runmake failed
Function 'do_compile' failed (see
/home/dev/yocto-repo/build/tmp/work/armv4t-poky-linux-gnueabi/gcc-
cross-intermediate-4.5.2-r3/temp/log.do_compile.646
for further information)
ERROR: Function 'do_compile' failed (see
/home/dev/yocto-repo/build/tmp/work/armv4t-poky-linux-gnueabi/gcc-
cross-intermediate-4.5.2-r3/temp/log.do_compile.646
for further information)
Regards,
--
*dS
Diego Sueiro
/*long
Re: [yocto] Kernel Panics on armv4t with gcc.4.5.1
Diego, Can you try with 4.5.2 gcc from this branch: http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/log/?h=nitin/khem_gcc_nitin Thanks, Nitin From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Diego Sueiro Sent: Monday, January 31, 2011 10:53 AM To: yocto@yoctoproject.org Subject: [yocto] Kernel Panics on armv4t with gcc.4.5.1 Folks, I'm not a kernel and neither a gcc expert developer, and after searching for a solution for the last 2 weeks I've decided to appeal to the list. I'm trying to build a kernel image (2.6.32 and 2.6.30) for mini2440 (armv4t) with Yocto Project (poky master branch) and I'm facing a strange issue. If I compile the kernel with Yocto gcc recipes (gcc 4.5.1) the kernel will panic on init (console printed message is attached for kernel 2.6.30 and 2.6.32). But, if I compile the kernel with meta-oe gcc recipes (gcc 4.5) everything will be ok. Just for your reference these is the gcc recipes which I'm using: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/gcc http://git.openembedded.org/cgit.cgi/meta-openembedded/tree/recipes-devtools/gcc I've compiled with and without thumb instructions, but the issue remains. I've tried to apply the patches gcc-armv4-pass-fix-v4bx-to-ld.patch and gcc-arm-volatile-bitfield-fix.patch, but no success. Kind Regards, -- *dS Diego Sueiro /*long live rock 'n roll*/ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
