Re: [yocto] RaspberryPi Kernel - sometimes it works, sometimes it doesn't
Hi, On 10/06/12 12:30, Chris Tapp wrote: I've been building the 3.1.9 Raspberry Pi kernel under Denzil using the meta layer at https://github.com/djwillis/meta-raspberrypi. This uses a kernel recipe based on the git repository at https://github.com/raspberrypi/linux/commits/rpi-patches. Some of the kernel commit IDs (e.g. 94fbbc4e3988075abad0d3b32842b82c590324fc) seem to build ok, but they don't always run. As in, if I -c clean and build then sometimes I end up with a bootable image, sometimes I don't. I'm not changing anything else in the build environment. Any ideas what can cause this? I find that -c clean does not work very well, afterward the package gets recompiled but instead of the actual package packages being rebuilt, an earlier version of the packages gets pulled out of sstate into the image. I definitely saw this behaviour with Yocto kernels, but I think happens with other packages as well; I always do -c cleansstate now to avoid this. Tomas ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Is there anyway to get patched source tar file for gcc while building srpm?
bump Added poky and oe-core. anyone? On Thu, Jun 7, 2012 at 8:23 PM, Jegan Chandru pcje...@gmail.com wrote: Hi, Framework - poky-denzil-7.0 arch - x86_64 Is there anyway to get patched source tar file for gcc while building srpm? I have checked the srpms created and found gcc srpms has only the logs_with_scripts tar file and not the patched source. I have configured archive-patched-source in local.conf. Upon checking on archiver.bbclass, noticed not_tarball function is excluding work-shared dir.This dir is used by gcc only for building. I can see the obvious reason here that(correct me if I am wrong) since this source has been used by, say gcc-cross-intermediate, gcc-cross-4.6.3 and gcc-runtime-4.6.3 bb files and you dont want to archive that source. But anyone can tell me the exact reason on why work-shared is being omitted for archiving? Also, I must include that, there are total 40 patches for gcc and all patches getting applied in gcc-4.6.inc. So I think there is no harm in archiving that source. As a try and error, I have created a dummy function for not_tarball and tried to build, but that didnt work! ;( So please anyone shed some light on this matter. It is much appreciated. I need srpm with source for stabilizing and do some testing. Also there is a high chance that I missed something, so feel free to correct me. ;) Thanks, -JC ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RaspberryPi Kernel - sometimes it works, sometimes it doesn't
On 11 Jun 2012, at 08:29, Tomas Frydrych wrote: Hi, On 10/06/12 12:30, Chris Tapp wrote: I've been building the 3.1.9 Raspberry Pi kernel under Denzil using the meta layer at https://github.com/djwillis/meta-raspberrypi. This uses a kernel recipe based on the git repository at https://github.com/raspberrypi/linux/commits/rpi-patches. Some of the kernel commit IDs (e.g. 94fbbc4e3988075abad0d3b32842b82c590324fc) seem to build ok, but they don't always run. As in, if I -c clean and build then sometimes I end up with a bootable image, sometimes I don't. I'm not changing anything else in the build environment. Any ideas what can cause this? I find that -c clean does not work very well, afterward the package gets recompiled but instead of the actual package packages being rebuilt, an earlier version of the packages gets pulled out of sstate into the image. I definitely saw this behaviour with Yocto kernels, but I think happens with other packages as well; I always do -c cleansstate now to avoid this. Yes, I've seen that in the past as well. I should probably have mentioned that I've also tried cleanstate and/or deleting any residual sstate-cache/sstate- files for linux-raspberrypi, etc. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto weekly bug trend charts -- WW23
Hi all, This is the weekly bug trend for WW23. The new submitted vs. fixed bug number is 39 vs. 25. WDD number and Open Bug number increased a lot, as 1103 and 222. Bug status of WW23 could be found on https://wiki.yoctoproject.org/wiki/Yocto_Bug_Trend. Best Regards, Jiajun ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Hob implementation: vanilla or branded?
Thanks, Joshua. Belen On 08/06/2012 17:41, Joshua Lock j...@linux.intel.com wrote: On 08/06/12 07:28, Barros Pena, Belen wrote: Vanilla 5 - branded 0 :) Shane, Dongxiao and Alex: from an implementation point of view, I guess this means eliminating any hardcoded UI-related values (button colours and styles, for example). Joshua: if you have a rough idea of the things that will need to be changed from the work you did before the 1.2 release, please let us know. I have a link to an old article that suggests techniques for getting colours from the GTK+ theme: http://ometer.com/gtk-colors.html It's pretty old but I believe the GTK+2 pieces are still appropriate for Hob. On top of that using gtk.Table is bad, using hard coded sizes for text, widgets, etc. is bad. Pango markup supports proportional font sizes (large, larger) like CSS and I'd suggest those be used. I think we should keep the existing icons, though. What do you think? I'm definitely in favour of that. Cheers, Joshua -- Joshua Lock Yocto Project Intel Open Source Technology Centre - Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Hob implementation: vanilla or branded?
Sounds good: thanks, Ross. Belen On 08/06/2012 21:24, Burton, Ross ross.bur...@intel.com wrote: On 8 June 2012 17:41, Joshua Lock j...@linux.intel.com wrote: Joshua: if you have a rough idea of the things that will need to be changed from the work you did before the 1.2 release, please let us know. I think it's fair that I take over from Joshua as resident GTK+ knowledge base, having written several GNOME applications and more importantly being on the Yocto team. :) Ross - Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] gitignore: add wildcard to match toplevel patch files
On Fri, 2012-06-08 at 12:10 -0400, Paul Gortmaker wrote: To support the basic workflow of trivial patches: git format-patch HEAD~.. ; git send-email --to f...@bar.com 0001-foo.patch We don't want git status reporting on patches lying in the top level dir in this case. Merged to master, thanks. Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RaspberryPi Kernel - sometimes it works, sometimes it doesn't
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/11/2012 12:29 AM, Tomas Frydrych wrote: Hi, On 10/06/12 12:30, Chris Tapp wrote: I've been building the 3.1.9 Raspberry Pi kernel under Denzil using the meta layer at https://github.com/djwillis/meta-raspberrypi. This uses a kernel recipe based on the git repository at https://github.com/raspberrypi/linux/commits/rpi-patches. Some of the kernel commit IDs (e.g. 94fbbc4e3988075abad0d3b32842b82c590324fc) seem to build ok, but they don't always run. As in, if I -c clean and build then sometimes I end up with a bootable image, sometimes I don't. I'm not changing anything else in the build environment. Any ideas what can cause this? I find that -c clean does not work very well, afterward the package gets recompiled but instead of the actual package packages being rebuilt, an earlier version of the packages gets pulled out of sstate into the image. I definitely saw this behaviour with Yocto kernels, but I think happens with other packages as well; I always do -c cleansstate now to avoid this. yes thats the intended behavior if nothing changed that ensues a recompile then it will use precompiled sstate for the package Tomas ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/V+FwACgkQuwUzVZGdMxRlnwCfaIy1wo/G0gEIVbQQe0ImsKPa 2csAoJGhol1N0xrudHfT/c7T97Hoizhf =l1iC -END PGP SIGNATURE- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Web HOB planning discussion
Hi, Here's the link to the wikipage for the design for WebHob that we've been working on here at the London office. https://wiki.yoctoproject.org/wiki/Yocto_1.3_Web_Hob The direct link to the video screencast is here: https://wiki.yoctoproject.org/wiki/images/9/9c/Yocto_webHob.1.9_screencast.0.1.mov -- Jim Kosem Skype: jkosem GTalk: j...@halfman.com Mobile: 07757 559081 Note: I read and reply to email only a couple of times a day. If you need something quicker, please use Skype, GTalk or if its urgent call my mobile.___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Grub installation
On 6/11/2012 5:12 PM, Jürgen Messerer wrote: Hi I have the following problem. I have created with yocto a core-image-minimal for x86 which I could test with qemu. later I added the following lines to conf/local.conf at the end according to the manual chapter 4.2.4: IMAGE_INSTALL_append = bash IMAGE_INSTALL_append = strace IMAGE_INSTALL_append = grub Bash and strace were installed correctly. In the case of grub I couldn’t find the directory /boot/grub. /etc/grub.d is installed also the folder /usr/lib/grub Question 1: Which grub recipe does yocto install from poky-denzil-7.0/meta/recipes-bsp/grub/ I would prefer version 1.99. Questin 2: Will yocto not install a /boot/grub directory? I would appreciate any tips and tricks to install grub correctly in the core-image-minimal Thanks a lot Best regards Juergen ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto Hello, Look for /boot/grub/ in /dev/sda1 It should be there. -- Mihai Lindner ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Grub installation
Dear Mihai, I would expect that grub should be installed in core-image-minimal-qemux86.ext3 Grub couldn't be found when running the image with runqemu. Any other ideas? -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Mihai Lindner Sent: Montag, 11. Juni 2012 16:23 To: yocto@yoctoproject.org Subject: Re: [yocto] Grub installation On 6/11/2012 5:12 PM, Jürgen Messerer wrote: Hi I have the following problem. I have created with yocto a core-image-minimal for x86 which I could test with qemu. later I added the following lines to conf/local.conf at the end according to the manual chapter 4.2.4: IMAGE_INSTALL_append = bash IMAGE_INSTALL_append = strace IMAGE_INSTALL_append = grub Bash and strace were installed correctly. In the case of grub I couldn't find the directory /boot/grub. /etc/grub.d is installed also the folder /usr/lib/grub Question 1: Which grub recipe does yocto install from poky-denzil-7.0/meta/recipes-bsp/grub/ I would prefer version 1.99. Questin 2: Will yocto not install a /boot/grub directory? I would appreciate any tips and tricks to install grub correctly in the core-image-minimal Thanks a lot Best regards Juergen ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto Hello, Look for /boot/grub/ in /dev/sda1 It should be there. -- Mihai Lindner ___ 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/6] meta-intel: remove linux-yocto-2.6.37
On 06/10/2012 08:42 PM, tom.zanu...@intel.com wrote: From: Tom Zanussi tom.zanu...@intel.com Remove 2.6.37 .bbappends to match recent oe-core linux-yocto-2.6.37 removal. For the series: Acked-by: Darren Hart dvh...@linux.intel.com The following changes since commit a2c22fb791eb70b230a5f8169d3580f4f3a4f967: Kishore Bodke (1): meta-cedartrail: update SRCREV are available in the git repository at: git://git.yoctoproject.org/meta-intel.git tzanussi/rm-linux-yocto--2.6.37 http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/log/?h=tzanussi/rm-linux-yocto--2.6.37 Tom Zanussi (6): meta-sugarbay: remove linux-yocto-2.6.37 .bbappend meta-crownbay: remove linux-yocto-2.6.37 .bbappend meta-emenlow: remove linux-yocto-2.6.37 .bbappend meta-fishriver: remove linux-yocto-2.6.37 .bbappend meta-jasperforest: remove linux-yocto-2.6.37 .bbappend meta-n450: remove linux-yocto-2.6.37 .bbappend .../linux/linux-yocto_2.6.37.bbappend | 15 --- .../linux/linux-yocto_2.6.37.bbappend |6 -- .../linux/linux-yocto_2.6.37.bbappend |6 -- .../linux/linux-yocto_2.6.37.bbappend |8 .../linux/linux-yocto_2.6.37.bbappend | 10 -- .../linux/linux-yocto_2.6.37.bbappend |7 --- 6 files changed, 0 insertions(+), 52 deletions(-) delete mode 100644 meta-crownbay/recipes-kernel/linux/linux-yocto_2.6.37.bbappend delete mode 100644 meta-emenlow/recipes-kernel/linux/linux-yocto_2.6.37.bbappend delete mode 100644 meta-fishriver/recipes-kernel/linux/linux-yocto_2.6.37.bbappend delete mode 100644 meta-jasperforest/recipes-kernel/linux/linux-yocto_2.6.37.bbappend delete mode 100644 meta-n450/recipes-kernel/linux/linux-yocto_2.6.37.bbappend delete mode 100644 meta-sugarbay/recipes-kernel/linux/linux-yocto_2.6.37.bbappend -- 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] RaspberryPi Kernel - sometimes it works, sometimes it doesn't
On Monday 11 June 2012 06:53:32 Khem Raj wrote: On 6/11/2012 12:29 AM, Tomas Frydrych wrote: I find that -c clean does not work very well, afterward the package gets recompiled but instead of the actual package packages being rebuilt, an earlier version of the packages gets pulled out of sstate into the image. I definitely saw this behaviour with Yocto kernels, but I think happens with other packages as well; I always do -c cleansstate now to avoid this. yes thats the intended behavior if nothing changed that ensues a recompile then it will use precompiled sstate for the package To clarify, it's designed to be able to determine when the recipe has changed in such a way that it needs to be rebuilt (by building up dependencies between variables and computing a checksum of the value of each one, which ends up in a checksum for each task); if it sees no change then the previous task output will be used from the sstate cache. It's worth noting however that until recently (post-1.2) we did not handle when local files referred to in SRC_URI changed. There also still may be other circumstances under which changes to the recipe or variables which it refers to will not change the sstate checksums; if you come across a situation where you made a change and sstate was re-used when you expected it to be rebuilt, please raise it. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] Correct documentation URL in top-level README file
On Wed, Jun 6, 2012 at 11:05 AM, Robert P. J. Day rpj...@crashcourse.ca wrote: Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca --- even though redirection takes care of this, might as well be accurate. diff --git a/README b/README index 0ab0dbf..06b1ea6 100644 --- a/README +++ b/README @@ -18,7 +18,7 @@ e.g. for the hardware support. Poky is in turn a component of the Yocto Project. The Yocto Project has extensive documentation about the system including a reference manual which can be found at: - http://yoctoproject.org/community/documentation + http://yoctoproject.org/documentation OpenEmbedded-Core is a layer containing the core metadata for current versions of OpenEmbedded. It is distro-less (can build a functional image with -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto Merged into OE-Core Thanks -b -- Elizabeth Flanagan Yocto Project Build and Release ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/1] remove snb rc6 patches from v3.4 kernel repository
From: Nitin A Kamble nitin.a.kam...@intel.com These patches are already part of v3.4 kernel sources. So there is no need to maintain them in the yocto linux 3.4 repository. Thanks, Nitin The following changes since commit 3fd089debe624c642d7b4d9363f853021d1675b2: checkpoint dir: meta (2012-06-06 16:24:42 -0400) 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): rc6: remove rc6 patches for snb .../features/tmp/rc6/rc6-kernel-params.patch | 81 meta/cfg/kernel-cache/features/tmp/rc6/rc6.scc |5 - .../tmp/rc6/snb-disable-rc6p-fix-precedence.patch | 26 -- .../features/tmp/rc6/snb-disable-rc6p.patch| 39 -- .../features/tmp/rc6/snb-enable-rc6.patch | 54 - 5 files changed, 0 insertions(+), 205 deletions(-) delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/rc6-kernel-params.patch delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/rc6.scc delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/snb-disable-rc6p-fix-precedence.patch delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/snb-disable-rc6p.patch delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/snb-enable-rc6.patch -- 1.7.3.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/1] rc6: remove rc6 patches for snb
From: Nitin A Kamble nitin.a.kam...@intel.com The sandybridge rc6 patches are part of the released v3.4 kernel. Hence there is no need to keep these patches in the 3.4 linux yocto kernel repository. Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com --- .../features/tmp/rc6/rc6-kernel-params.patch | 81 meta/cfg/kernel-cache/features/tmp/rc6/rc6.scc |5 - .../tmp/rc6/snb-disable-rc6p-fix-precedence.patch | 26 -- .../features/tmp/rc6/snb-disable-rc6p.patch| 39 -- .../features/tmp/rc6/snb-enable-rc6.patch | 54 - 5 files changed, 0 insertions(+), 205 deletions(-) delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/rc6-kernel-params.patch delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/rc6.scc delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/snb-disable-rc6p-fix-precedence.patch delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/snb-disable-rc6p.patch delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/snb-enable-rc6.patch diff --git a/meta/cfg/kernel-cache/features/tmp/rc6/rc6-kernel-params.patch b/meta/cfg/kernel-cache/features/tmp/rc6/rc6-kernel-params.patch deleted file mode 100644 index f1f7c08..000 --- a/meta/cfg/kernel-cache/features/tmp/rc6/rc6-kernel-params.patch +++ /dev/null @@ -1,81 +0,0 @@ -From 83b7f9ac9126f0532ca34c14e4f0582c565c6b0d Mon Sep 17 00:00:00 2001 -From: Eugeni Dodonov eugeni.dodo...@intel.com -Date: Fri, 23 Mar 2012 11:57:18 -0300 -Subject: [PATCH] drm/i915: allow to select rc6 modes via kernel parameter - -This allows to select which rc6 modes are to be used via kernel parameter, -via a bitmask parameter. E.g.: - -- to enable rc6, i915_enable_rc6=1 -- to enable rc6 and deep rc6, i915_enable_rc6=3 -- to enable rc6 and deepest rc6, use i915_enable_rc6=5 -- to enable rc6, deep and deepest rc6, use i915_enable_rc6=7 - -Please keep in mind that the deepest RC6 state really should NOT be used -by default, as it could potentially worsen the issues with deep RC6. So do -enable it only when you know what you are doing. However, having it around -could help solving possible future rc6-related issues and their debugging -on user machines. - -Note that this changes behavior - previously, value of 1 would enable both -RC6 and deep RC6. Now it should only enable RC6 and deep/deepest RC6 -stages must be enabled manually. - -v2: address Chris Wilson comments and clean up the code. - -References: https://bugs.freedesktop.org/show_bug.cgi?id=42579 -Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -Reviewed-by: Ben Widawsky benjamin.widaw...@intel.com -Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com -Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch -Integrated-by: Tom Zanussi tom.zanu...@intel.com - -Index: linux/drivers/gpu/drm/i915/i915_drv.c -=== linux.orig/drivers/gpu/drm/i915/i915_drv.c 2012-05-24 15:21:16.216263416 -0500 -+++ linux/drivers/gpu/drm/i915/i915_drv.c 2012-05-24 15:21:42.386496572 -0500 -@@ -66,7 +66,11 @@ - int i915_enable_rc6 __read_mostly = -1; - module_param_named(i915_enable_rc6, i915_enable_rc6, int, 0600); - MODULE_PARM_DESC(i915_enable_rc6, -- Enable power-saving render C-state 6 (default: -1 (use per-chip default)); -+ Enable power-saving render C-state 6. -+ Different stages can be selected via bitmask values -+ (0 = disable; 1 = enable rc6; 2 = enable deep rc6; 4 = enable deepest rc6). -+ For example, 3 would enable rc6 and deep rc6, and 7 would enable everything. -+ default: -1 (use per-chip default)); - - int i915_enable_fbc __read_mostly = -1; - module_param_named(i915_enable_fbc, i915_enable_fbc, int, 0600); -Index: linux/drivers/gpu/drm/i915/i915_drv.h -=== linux.orig/drivers/gpu/drm/i915/i915_drv.h 2012-05-24 15:21:23.926268189 -0500 -+++ linux/drivers/gpu/drm/i915/i915_drv.h 2012-05-24 15:21:42.396308725 -0500 -@@ -1003,6 +1003,27 @@ - - #include i915_trace.h - -+/** -+ * RC6 is a special power stage which allows the GPU to enter an very -+ * low-voltage mode when idle, using down to 0V while at this stage. This -+ * stage is entered automatically when the GPU is idle when RC6 support is -+ * enabled, and as soon as new workload arises GPU wakes up automatically as well. -+ * -+ * There are different RC6 modes available in Intel GPU, which differentiate -+ * among each other with the latency required to enter and leave RC6 and -+ * voltage consumed by the GPU in different states. -+ * -+ * The combination of the following flags define which states GPU is allowed -+ * to enter, while RC6 is the normal RC6 state, RC6p is the deep RC6, and -+ * RC6pp is deepest RC6. Their support by hardware varies according to the -+ * GPU, BIOS, chipset and platform. RC6 is usually the
Re: [yocto] [PATCH 0/1] remove snb rc6 patches from v3.4 kernel repository
On 12-06-11 03:38 PM, nitin.a.kam...@intel.com wrote: From: Nitin A Kamblenitin.a.kam...@intel.com These patches are already part of v3.4 kernel sources. So there is no need to maintain them in the yocto linux 3.4 repository. dropped. They obviously weren't reference anyway. I assume you'll be doing an associated meta-intel commit to remove the reference in: ./meta-sugarbay/recipes-kernel/linux/linux-yocto_3.2.bbappend Cheers, Bruce Thanks, Nitin The following changes since commit 3fd089debe624c642d7b4d9363f853021d1675b2: checkpoint dir: meta (2012-06-06 16:24:42 -0400) 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): rc6: remove rc6 patches for snb .../features/tmp/rc6/rc6-kernel-params.patch | 81 meta/cfg/kernel-cache/features/tmp/rc6/rc6.scc |5 - .../tmp/rc6/snb-disable-rc6p-fix-precedence.patch | 26 -- .../features/tmp/rc6/snb-disable-rc6p.patch| 39 -- .../features/tmp/rc6/snb-enable-rc6.patch | 54 - 5 files changed, 0 insertions(+), 205 deletions(-) delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/rc6-kernel-params.patch delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/rc6.scc delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/snb-disable-rc6p-fix-precedence.patch delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/snb-disable-rc6p.patch delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/snb-enable-rc6.patch ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [KERNEL 0/1] remove rc6 patches from meta branch
From: Nitin A Kamble nitin.a.kam...@intel.com These patches are already part of v3.4 kernel sources. So there is no need to maintain them in the yocto linux 3.4 repository. Thanks, Nitin PS: this is resend of earlier pull request with proper email formats. The following changes since commit 3fd089debe624c642d7b4d9363f853021d1675b2: checkpoint dir: meta (2012-06-06 16:24:42 -0400) 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: remove rc6 patches for snb .../features/tmp/rc6/rc6-kernel-params.patch | 81 meta/cfg/kernel-cache/features/tmp/rc6/rc6.scc |5 - .../tmp/rc6/snb-disable-rc6p-fix-precedence.patch | 26 -- .../features/tmp/rc6/snb-disable-rc6p.patch| 39 -- .../features/tmp/rc6/snb-enable-rc6.patch | 54 - 5 files changed, 0 insertions(+), 205 deletions(-) delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/rc6-kernel-params.patch delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/rc6.scc delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/snb-disable-rc6p-fix-precedence.patch delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/snb-disable-rc6p.patch delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/snb-enable-rc6.patch -- 1.7.3.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [KERNEL 1/1] meta: remove rc6 patches for snb
From: Nitin A Kamble nitin.a.kam...@intel.com The sandybridge rc6 patches are part of the released v3.4 kernel. Hence there is no need to keep these patches in the 3.4 linux yocto kernel repository. Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com --- .../features/tmp/rc6/rc6-kernel-params.patch | 81 meta/cfg/kernel-cache/features/tmp/rc6/rc6.scc |5 - .../tmp/rc6/snb-disable-rc6p-fix-precedence.patch | 26 -- .../features/tmp/rc6/snb-disable-rc6p.patch| 39 -- .../features/tmp/rc6/snb-enable-rc6.patch | 54 - 5 files changed, 0 insertions(+), 205 deletions(-) delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/rc6-kernel-params.patch delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/rc6.scc delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/snb-disable-rc6p-fix-precedence.patch delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/snb-disable-rc6p.patch delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/snb-enable-rc6.patch diff --git a/meta/cfg/kernel-cache/features/tmp/rc6/rc6-kernel-params.patch b/meta/cfg/kernel-cache/features/tmp/rc6/rc6-kernel-params.patch deleted file mode 100644 index f1f7c08..000 --- a/meta/cfg/kernel-cache/features/tmp/rc6/rc6-kernel-params.patch +++ /dev/null @@ -1,81 +0,0 @@ -From 83b7f9ac9126f0532ca34c14e4f0582c565c6b0d Mon Sep 17 00:00:00 2001 -From: Eugeni Dodonov eugeni.dodo...@intel.com -Date: Fri, 23 Mar 2012 11:57:18 -0300 -Subject: [PATCH] drm/i915: allow to select rc6 modes via kernel parameter - -This allows to select which rc6 modes are to be used via kernel parameter, -via a bitmask parameter. E.g.: - -- to enable rc6, i915_enable_rc6=1 -- to enable rc6 and deep rc6, i915_enable_rc6=3 -- to enable rc6 and deepest rc6, use i915_enable_rc6=5 -- to enable rc6, deep and deepest rc6, use i915_enable_rc6=7 - -Please keep in mind that the deepest RC6 state really should NOT be used -by default, as it could potentially worsen the issues with deep RC6. So do -enable it only when you know what you are doing. However, having it around -could help solving possible future rc6-related issues and their debugging -on user machines. - -Note that this changes behavior - previously, value of 1 would enable both -RC6 and deep RC6. Now it should only enable RC6 and deep/deepest RC6 -stages must be enabled manually. - -v2: address Chris Wilson comments and clean up the code. - -References: https://bugs.freedesktop.org/show_bug.cgi?id=42579 -Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -Reviewed-by: Ben Widawsky benjamin.widaw...@intel.com -Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com -Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch -Integrated-by: Tom Zanussi tom.zanu...@intel.com - -Index: linux/drivers/gpu/drm/i915/i915_drv.c -=== linux.orig/drivers/gpu/drm/i915/i915_drv.c 2012-05-24 15:21:16.216263416 -0500 -+++ linux/drivers/gpu/drm/i915/i915_drv.c 2012-05-24 15:21:42.386496572 -0500 -@@ -66,7 +66,11 @@ - int i915_enable_rc6 __read_mostly = -1; - module_param_named(i915_enable_rc6, i915_enable_rc6, int, 0600); - MODULE_PARM_DESC(i915_enable_rc6, -- Enable power-saving render C-state 6 (default: -1 (use per-chip default)); -+ Enable power-saving render C-state 6. -+ Different stages can be selected via bitmask values -+ (0 = disable; 1 = enable rc6; 2 = enable deep rc6; 4 = enable deepest rc6). -+ For example, 3 would enable rc6 and deep rc6, and 7 would enable everything. -+ default: -1 (use per-chip default)); - - int i915_enable_fbc __read_mostly = -1; - module_param_named(i915_enable_fbc, i915_enable_fbc, int, 0600); -Index: linux/drivers/gpu/drm/i915/i915_drv.h -=== linux.orig/drivers/gpu/drm/i915/i915_drv.h 2012-05-24 15:21:23.926268189 -0500 -+++ linux/drivers/gpu/drm/i915/i915_drv.h 2012-05-24 15:21:42.396308725 -0500 -@@ -1003,6 +1003,27 @@ - - #include i915_trace.h - -+/** -+ * RC6 is a special power stage which allows the GPU to enter an very -+ * low-voltage mode when idle, using down to 0V while at this stage. This -+ * stage is entered automatically when the GPU is idle when RC6 support is -+ * enabled, and as soon as new workload arises GPU wakes up automatically as well. -+ * -+ * There are different RC6 modes available in Intel GPU, which differentiate -+ * among each other with the latency required to enter and leave RC6 and -+ * voltage consumed by the GPU in different states. -+ * -+ * The combination of the following flags define which states GPU is allowed -+ * to enter, while RC6 is the normal RC6 state, RC6p is the deep RC6, and -+ * RC6pp is deepest RC6. Their support by hardware varies according to the -+ * GPU, BIOS, chipset and platform. RC6 is usually the
[yocto] Agenda: Yocto Project Technical Team Meeting - Tuesday, June 12, 2012 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US Canada).
Agenda: * Opens collection - 5 min (Song) * 1.2.1 update - 5 min (ScottG) * 1.1.2 update - 5 min (Josh/Beth) * Yocto 1.3 status - 10 min (Song/team) * LTSI discussion - 10 min (Sean/Bruce/team) * SWAT team rotation: Jessica - Dexuan * Opens - 5 min * Team sharing - 20 min -Original Appointment- Conference details Conference name: Yocto Technical Team Conference date/start time: Tue Jun 28, 2011 at 10:00 AM Central Daylight Time Participants: 30 Duration: 60 minutes Participant passcode: 49611427 Dial-in number: 1.972.995. US Toll Free number: 1.877.561.6828 BlackBerry users, click this link to join your conference as a chairperson: 1.972.995.x67184230# BlackBerry users, click this link to join your conference as a participant: 1.972.995.x49611427# Depending on where you are dialing from, either your BlackBerry will pause and enter the passcode automatically or you will be prompted to click again to dial the passcode. Local and Global Access Numbers Country Dial-in number Australia: 1800 636 843 Czech Republic: 242 430 350 China (Beijing): From office dial 8-995 or 8784277 Beijing Out of Office dial 5878 4277 China (Shanghai): From office dial 8-995 or 3073322 Shanghai Out of Office dial 2307 3322 China (Shenzen): From office dial 8-995 or 6007877 Shenzen Out of Office dial 2600 7877 China (Other Cities): From IP phone dial 8-995 Other cities - Non IP phone dial 021-23073322 Denmark: 8060 1400 Finland: 09 41333477 France: 0497 275888 Germany: 08161 803232 Holland: 030 2417490 India: BSNL subscribers use 1800 425 9996 (Toll Free) Airtel subscribers use 0008 009 861 212 (Toll Free) From TI Campus use 8995 Others use 2509 9555 (Landline within Bangalore) or 80 2509 9555 (Outside Bangalore) Israel: 09 790 6715 Italy: 039 69061234 (039 is local city code not country code) Japan: From TI Campus use 8 995 Outside TI use 03 4331 3777 Malaysia: From IP phone dial 2643799 From Kuala Lumpur dial 4264 3799 Outside Kuala Lumpur dial (03)4264 3799 Norway: 2 295 8744 Philippines: From Baguio City use 4471177 From Metro Manila area use 8702477 Singapore: From IP phone dial 3894777 Outside TI use 6389 4777 South Korea: From IP phone dial 5606998 From Seoul dial 5606998 Outside Seoul dial (02)5606998 Sweden: 08 58755577 Taiwan: From IP phone dial 1363 From Taipei dial 2241 1363 Outside Taipei dial (02)2241 1363 Turkey: Landline Only dial 0811 288 0001 then enter 877 633 1123 UK: 01604 663003 US: 972 995 or 1877 561 6828 Recurring conferences First scheduled conference: Tue Jun 28, 2011 Recurrence frequency: Weekly - Every 1 week(s) on Tuesday Recurrence ends: End on Fri Jun 22, 2012, 10:40 AM CDT ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [PATCH 1/1] eglibc: remove runtime dependency of perl from eglibc-mtrace
On 06/08/2012 04:02 PM, Darren Hart wrote:
On 06/08/2012 03:23 PM, nitin.a.kam...@intel.com wrote:
From: Nitin A Kamblenitin.a.kam...@intel.com
perl needs eglibc to build.
The presence of runtime dependency of
perl for eglibc-mtrace caused bitbake to build perl before eglibc,
which causes build failure of perl with poky-tiny distro
So is this a circular dependency chain?
perl DEPENDS on eglibc
eglibc (because of eglibc-mtrace) RDEPENDS on perl?
If so, doesn't this solution leave eglibc-mtrace with an incomplete set
of dependencies in it's final package meta-data?
Would the correct solution be to break eglibc-mtrace out into a separate
recipe.
I am not sure if this would be more correct or have the PACKAGES contain
something like ${EGLIBC_PACKAGE_MTRACE}, which could the be over-ridden
by the yocto-tiny distro.
EGLIBC_PACKAGE_MTRACE ?= ${PN}-mtrace
and then change ${PN}-mtrace in the PACKAGES list to
${EGLIBC_PACKAGE_MTRACE}.
This exposes another global, so I am not sure which is better.
Sau!
eglibc-mtrace.bb could then DEPENDS=eglibc and RDEPENDS=perl and
poky-tiny would need to be able to exclude eglibc-mtrace.
This fixes bug: [YOCTO #2523]
Signed-off-by: Nitin A Kamblenitin.a.kam...@intel.com
---
meta/recipes-core/eglibc/eglibc-package.inc |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-core/eglibc/eglibc-package.inc
b/meta/recipes-core/eglibc/eglibc-package.inc
index ce37155..423729a 100644
--- a/meta/recipes-core/eglibc/eglibc-package.inc
+++ b/meta/recipes-core/eglibc/eglibc-package.inc
@@ -55,7 +55,6 @@ FILES_${PN}-dbg += ${libexecdir}/*/.debug
${libdir}/audit/.debug
FILES_catchsegv${PKGSUFFIX} = ${bindir}/catchsegv
RDEPENDS_catchsegv${PKGSUFFIX} = libsegfault
RDEPENDS_${PN}-utils += bash
-RDEPENDS_${PN}-mtrace += perl
FILES_${PN}-pcprofile = ${base_libdir}/libpcprofile.so
FILES_eglibc-thread-db${PKGSUFFIX} = ${base_libdir}/libthread_db.so.*
${base_libdir}/libthread_db-*.so
RPROVIDES_${PN}-dev += libc-dev
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [PATCH 1/1] eglibc: remove runtime dependency of perl from eglibc-mtrace
On 06/11/2012 03:07 PM, Saul Wold wrote:
On 06/08/2012 04:02 PM, Darren Hart wrote:
On 06/08/2012 03:23 PM, nitin.a.kam...@intel.com wrote:
From: Nitin A Kamblenitin.a.kam...@intel.com
perl needs eglibc to build.
The presence of runtime dependency of
perl for eglibc-mtrace caused bitbake to build perl before eglibc,
which causes build failure of perl with poky-tiny distro
So is this a circular dependency chain?
perl DEPENDS on eglibc
eglibc (because of eglibc-mtrace) RDEPENDS on perl?
If so, doesn't this solution leave eglibc-mtrace with an incomplete set
of dependencies in it's final package meta-data?
Would the correct solution be to break eglibc-mtrace out into a separate
recipe.
I am not sure if this would be more correct or have the PACKAGES contain
something like ${EGLIBC_PACKAGE_MTRACE}, which could the be over-ridden
by the yocto-tiny distro.
EGLIBC_PACKAGE_MTRACE ?= ${PN}-mtrace
and then change ${PN}-mtrace in the PACKAGES list to
${EGLIBC_PACKAGE_MTRACE}.
This exposes another global, so I am not sure which is better.
This doesn't seem inconsistent with other solutions to similar sorts of
problems. This is certainly less work and a smaller change.
--
Darren
Sau!
eglibc-mtrace.bb could then DEPENDS=eglibc and RDEPENDS=perl and
poky-tiny would need to be able to exclude eglibc-mtrace.
This fixes bug: [YOCTO #2523]
Signed-off-by: Nitin A Kamblenitin.a.kam...@intel.com
---
meta/recipes-core/eglibc/eglibc-package.inc |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-core/eglibc/eglibc-package.inc
b/meta/recipes-core/eglibc/eglibc-package.inc
index ce37155..423729a 100644
--- a/meta/recipes-core/eglibc/eglibc-package.inc
+++ b/meta/recipes-core/eglibc/eglibc-package.inc
@@ -55,7 +55,6 @@ FILES_${PN}-dbg += ${libexecdir}/*/.debug
${libdir}/audit/.debug
FILES_catchsegv${PKGSUFFIX} = ${bindir}/catchsegv
RDEPENDS_catchsegv${PKGSUFFIX} = libsegfault
RDEPENDS_${PN}-utils += bash
-RDEPENDS_${PN}-mtrace += perl
FILES_${PN}-pcprofile = ${base_libdir}/libpcprofile.so
FILES_eglibc-thread-db${PKGSUFFIX} = ${base_libdir}/libthread_db.so.*
${base_libdir}/libthread_db-*.so
RPROVIDES_${PN}-dev += libc-dev
--
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] [OE-core] [PATCH 1/1] eglibc: remove runtime dependency of perl from eglibc-mtrace
On Mon, Jun 11, 2012 at 3:07 PM, Saul Wold s...@linux.intel.com wrote:
Would the correct solution be to break eglibc-mtrace out into a separate
recipe.
I am not sure if this would be more correct or have the PACKAGES contain
something like ${EGLIBC_PACKAGE_MTRACE}, which could the be over-ridden by
the yocto-tiny distro.
EGLIBC_PACKAGE_MTRACE ?= ${PN}-mtrace
and then change ${PN}-mtrace in the PACKAGES list to
${EGLIBC_PACKAGE_MTRACE}.
This exposes another global, so I am not sure which is better.
there are other tools e.g. memusage etc. which could be built in a
second pass and IMO
we should separate the eglibc-bin into a separate recipe since
everything depends on system libc
its desirable that it should have few dependencies to build it so
builds can be more parallel and
eglibc wont be a bottleneck.
-Khem
___
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
On Mon, Jun 11, 2012 at 7:23 PM, Kamble, Nitin A nitin.a.kam...@intel.com wrote: -Original Message- From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] Sent: Monday, June 11, 2012 1:20 PM To: Kamble, Nitin A Cc: yocto@yoctoproject.org Subject: Re: [yocto] [PATCH 0/1] remove snb rc6 patches from v3.4 kernel repository On 12-06-11 03:38 PM, nitin.a.kam...@intel.com wrote: From: Nitin A Kamblenitin.a.kam...@intel.com These patches are already part of v3.4 kernel sources. So there is no need to maintain them in the yocto linux 3.4 repository. dropped. They obviously weren't reference anyway. I assume you'll be doing an associated meta-intel commit to remove the reference in: ./meta-sugarbay/recipes-kernel/linux/linux-yocto_3.2.bbappend 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 Nitin Cheers, Bruce Thanks, Nitin The following changes since commit 3fd089debe624c642d7b4d9363f853021d1675b2: checkpoint dir: meta (2012-06-06 16:24:42 -0400) 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): rc6: remove rc6 patches for snb .../features/tmp/rc6/rc6-kernel-params.patch | 81 meta/cfg/kernel-cache/features/tmp/rc6/rc6.scc | 5 - .../tmp/rc6/snb-disable-rc6p-fix-precedence.patch | 26 -- .../features/tmp/rc6/snb-disable-rc6p.patch | 39 -- .../features/tmp/rc6/snb-enable-rc6.patch | 54 - 5 files changed, 0 insertions(+), 205 deletions(-) delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/rc6- kernel-params.patch delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/rc6.scc delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/snb- disable-rc6p-fix-precedence.patch delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/snb- disable-rc6p.patch delete mode 100644 meta/cfg/kernel-cache/features/tmp/rc6/snb-enable-rc6.patch ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
