Re: [RFC PATCH 0/2] thermal: Add generic cpu cooling devices according to thermal framework
Hi Zach/Ricardo, All the thermal Kconfigs are enabled in https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/Kconfig. Thanks, Amit D On 10 January 2012 23:55, Amit Kucheria wrote: > Amit, could you please add the required Kconfig options that need to > be enabled to > https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/Kconfig > under Exynos->Thermal? > > Zach and Ricardo will then ensure that their kernels have those > Kconfig options enabled. > > /Amit > > On Wed, Dec 14, 2011 at 6:54 PM, Amit Kachhap > wrote: > > Hi Nicolas, > > > > Please pull my samsung thermal implementation work from git repository > > (git://git.linaro.org/people/amitdanielk/linux.git thermal_cpu_cooling). > > Some of the patches are under review and some are in mainline in 3.2 rc* > > version. > > It is all based on the tip of your tree. > > > > The patches are added since commit id > > 971be11492b1e248798f7078592b1fa0dfbf3534 > > > > Thanks, > > Amit Daniel > > > > > > On 14 December 2011 20:11, Amit Kachhap wrote: > >> > >> Hi Nicolas, > >> > >> Is it possible for you to add these 2 patches for this month release? I > am > >> not able to give you the git link as there is seems some problem with > the > >> linaro git server. > >> Also I attached the patches in case required. > >> > >> Thanks, > >> Amit Daniel > >> > >> > >> On 13 December 2011 20:43, Amit Daniel Kachhap > > >> wrote: > >> > PATCH 1) [thermal: Add a new trip type to use cooling device instance > >> > number] > >> > This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE which passes > >> > cooling device instance number and may be helpful for cpufreq cooling > >> > devices > >> > to take the correct cooling action. > >> > > >> > PATCH 2) [thermal: Add generic cpu cooling implementation] > >> > This patch adds generic cpu cooling low level implementation through > >> > frequency > >> > clipping and cpu hotplug. In future, other cpu related cooling devices > >> > may be > >> > added here. An ACPI version of this already > >> > exists(drivers/acpi/processor_thermal.c). > >> > But this will be useful for platforms like ARM using the generic > thermal > >> > interface > >> > along with the generic cpu cooling devices. The cooling device > >> > registration API's > >> > return cooling device pointers which can be easily binded with the > >> > thermal zone > >> > trip points. > >> > > >> > > >> > Amit Daniel Kachhap (2): > >> > thermal: Add a new trip type to use cooling device instance number > >> > thermal: Add generic cpu cooling implementation > >> > > >> > Documentation/thermal/cpu-cooling-api.txt | 52 + > >> > Documentation/thermal/sysfs-api.txt |4 +- > >> > drivers/thermal/Kconfig | 11 + > >> > drivers/thermal/Makefile |1 + > >> > drivers/thermal/cpu_cooling.c | 302 > >> > + > >> > drivers/thermal/thermal_sys.c | 27 +++- > >> > include/linux/cpu_cooling.h | 45 + > >> > include/linux/thermal.h |1 + > >> > 8 files changed, 440 insertions(+), 3 deletions(-) > >> > create mode 100644 Documentation/thermal/cpu-cooling-api.txt > >> > create mode 100644 drivers/thermal/cpu_cooling.c > >> > create mode 100644 include/linux/cpu_cooling.h > >> > > >> > > > > > > ___ > > linaro-dev mailing list > > linaro-dev@lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/linaro-dev > > > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Monthly Release Thoughts
On 01/11/2012 03:34 AM, Somebody in the thread at some point said: Hi - I had some thoughts and a suggestion this morning about the monthly release cycle that I'd like to share. Perhaps I'll get booed off the stage, perhaps not. I'm sure it can be improved on. There is a great deal of stress around what blueprints fit into what monthly release boundary. For deliveries like the LEB that combine the fruits of our Linaro labors this makes great sense. Outside of the process for LEB creation and release, I'd like to suggest it's less than efficient and creates a bit of stress as we have the monthly rush to make the release dates. PMs and TLs continually have to be watching for what will and what won't be making dates that fit with the LEB. This passes on the stress to the engineering team, causes some late night hack-a-thons which in turn I believe caused us to rush software what was less than ready to be included in a LEB. I'm sure we all have examples we could point to. It seems there's some confusion here. The WGs/LTs deliveries aren't tight to LEB monthly releases, you have your own goals. It's fine to skip a monthly release (like many have done) or provide a snapshot of your current work (like LTs have done). I think there is confusion inside Linaro about what these releases are. What you're saying is correct, but it doesn't always reflect what's happening on the ground. For LT the 'beat' we work to is kernel cycle and as you say monthly release is something downstream of what we are anyway doing for us, it should just be a staging post for what popped out of our sausage machine recently. However people responsible for making the releases feel under pressure to maximize what's in there for a deadline that's not inherently meaningful, when at times when we may be dedicated to having to do something else do to lack of sync with our underlying 'beat'. At its worst, the drama of having a release leads to a false sense of urgency and bad decisions that are not in Linaro's overall interest. However outside of that process, for the WGs and such, we should go to a process based on continuous integration. All the chain should be based on continuous integration, including our builds. That's the goal we're aiming and working on. I completely agree about CI approach will lead to best results in medium and long term and we should be all about that, not wasting time polishing the coprolite of old releases - especially someone else's old releases. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Errors in work item definitions
On Tue, 10 Jan 2012 08:21:10 +0100, Mattias Backman wrote: > On Mon, Jan 9, 2012 at 2:45 PM, Tony Mansson wrote: > > Hi Guys. > > > > I get a lot of spam from launchpad whenever the format of a blueprint is not > > OK. > > > > Below is an example. Please don't use colons (as e.g. in an URL) inside work > > item definitions. There is a low-IQ parser somewhere that gets confused by > > that. > > I believe that is a problem only when you leave out the work item > state. That is, if you always add ": TODO" to your new work items > you'll be ok. I will just say again that if you want to avoid formatting issues in work items, my greasemonkey work item editor can be a help: http://voices.canonical.com/michael.hudson/2011/09/01/announcing-the-workitem-editor-greasemonkey-script/ (only works in ff/chrome/chromium, as you'd expect) Cheers, mwh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Monthly Release Thoughts
Hi Tom, On 10 January 2012 19:14, Tom Gall wrote: > Hi All, > > I had some thoughts and a suggestion this morning about the monthly > release cycle that I'd like to share. Perhaps I'll get booed off the > stage, perhaps not. I'm sure it can be improved on. > > There is a great deal of stress around what blueprints fit into what > monthly release boundary. For deliveries like the LEB that combine the > fruits of our Linaro labors this makes great sense. > > Outside of the process for LEB creation and release, I'd like to > suggest it's less than efficient and creates a bit of stress as we > have the monthly rush to make the release dates. PMs and TLs > continually have to be watching for what will and what won't be making > dates that fit with the LEB. This passes on the stress to the > engineering team, causes some late night hack-a-thons which in turn I > believe caused us to rush software what was less than ready to be > included in a LEB. I'm sure we all have examples we could point to. It seems there's some confusion here. The WGs/LTs deliveries aren't tight to LEB monthly releases, you have your own goals. It's fine to skip a monthly release (like many have done) or provide a snapshot of your current work (like LTs have done). monthly releases != monthly planning. It doesn't prevent that PMs/TLs should know what will make the targeted delivery, independently of the release. I'd like to believe that the hack-a-thons/rush is done to meet your own planned date and not the LEB release date. > To address this I'd like to suggest the following. > > The production of the LEB and related builds should continue to be on > a monthly release cycle. > > However outside of that process, for the WGs and such, we should go to > a process based on continuous integration. All the chain should be based on continuous integration, including our builds. That's the goal we're aiming and working on. > As work groups, landing teams and so on, we commit to the LEB process > that we have some set of blueprints IN QUEUE, meaning they are being > worked on right now. When they go complete if they are LEB bound, they > are delivered to the staging overlay. Items in the staging overlay are > candidates for promotion to the overlay. When an item in the staging > overlay is judged as being ready (bugs are at least triaged and deemed > to not be blocking) it is promoted into the overlay from which daily > builds are made and the monthly release is made. > > Packages in the staging overlay are the subject of functional test.IE > Does it work? Packages in the overlay are the subject of integration > test. IE Does it break the system? The picture is pretty clear and has been discussed at last Connect: https://blueprints.launchpad.net/linaro-project-management/+spec/linaro-general-release-process-improvements-lcq4.11 See "The road to Continuous Integration" > Work Groups, Landing Teams will also commit to having a priority list > of blueprints and bugs that are being addressed or will be addressed. > This keeps the release process and management team aware of what is > coming and when. The # of completed work items per week (or other > counts) can also help the management team measure forward momentum and > progress. In which way is it different from current workflow? AFAICS the only difference is LTs, as things stand today they don't use blueprint but rally for their project management. > In some respects it's subtle process tweek. But I feel shifting part > of linaro to a continuous integration / ship when ready model makes > sense. In the work groups we are more connected upstream as we stay > tune with upstream release boundaries but still want to showcase > results in the monthly LEBs. Likewise focus on the LEB continues > with higher quality software. It does shift the goal of creating great > software by date X, to creating great software and ship when it's > ready. The goal is to create great software and ship it upstream, when it's ready. Though we do project management, planning, estimate deliveries, and it isn't tight to LEB monthly releases. The monthly releases are provided to showcase our results, and is also a playground for our improvements. If you don't have anything to show at the end of a cycle, or aren't interested to test your improvements in a real world environment, just skip it. Re-stating, my initial comment: it seems there's some confusion. > Perhaps this would be a good discussion for 1Q12LC. I think we want to talk about the monthly planning. > -- > Regards, > Tom > > "Where's the kaboom!? There was supposed to be an earth-shattering > kaboom!" Marvin Martian > Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs > w) tom.gall att linaro.org > w) tom_gall att vnet.ibm.com > h) tom_gall att mac.com Cheers, -- Fathi Boudra Linaro Release Manager | Validation Project Manager Linaro.org | Open source software for ARM SoCs ___ linar
Status reporting
Hello Android Team. Tomorrows meeting page: https://wiki.linaro.org/Platform/Android/Meetings/2012-01-11 is now open for status reporting. BR, Tony ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Notes from Platform - Working Group Sync January 10, 2012
Power Management Item: = One of the roadmap cards the PMWG is working on is the thermal management card. http://status.linaro.org/card/PMWG2011-THERMAL-MANAGEMENT.html One of the acceptance criteria for this item is: Thermal management should be validated on an Android image; a suggestion is to run the system on the highest OPP, and use that to trigger the thermal transition. Per Amit D., This topic has been discussed with Samsung landing team, they will pick these patches for hwpack and android release. I want to make sure this happens and the patches make it to an Android image that we can test with on Samsung platform. Android Agenda Items === 1. Single kernel? 2. Benchmarks-to-toolchain-group work 3. Developer tools 4. MM help with Video Conferencing 5. GFX help GLMark2 6. PM on all Android targets 7. How else can Android help you? Notes: - * Single Kernel status unknown. * Valgrind +2 * MM help with video conferencing? * How can Android better help you * MM? Panda Audio enablement, Vishal question, what’s the plan for the rest, AI for Zach to send plan. * GFX? Wiki pages are helpful. Some kind of dev guide. PoC list for Android issues. * Toolchain: Valgrind, auto-benchmarks, PoC lists, getting going * PM: Power Tutor, stalled out, Zach to pick back up , Amit can you, once CPU idle, pick i up support * KWG: ??? Dev Platform Agenda Items: === 1. Deliverables that might affect Ubuntu 2. How to make sure PM is properly integrated at the Ubuntu targets 3. MM and work needed to improve XBMC and Ubuntu TV (qtmobility) 4. GFX planning for 12.01 and work with Unity 3D 5. Anything missing at the Dev Platform (images, tools) that might be interesting for other WGs? Notes: - * Michael is fine with the current sysroot produced by Marcin, and plan to keep validating it by hand once they are available. Maybe a discussion should happen at Connect to see if this can be automate. * Please send Ubuntu input to Ricardo. * Still not sure if Ubuntu is properly using power management (as the LT is maintaining the tree and config set), Amit will take a look and see if anything is missing. * Point to MM working group, XBMC and Ubuntu TV, can the MM WG help? Ravi is. Kan Hu - XBMC still need a person for Ubuntu TV. * Mark and Alexandros is working on Unity-3D upstreaming. Fighting against time. They are the correct PoC for Unity-3D upstreaming for this month and through Connect. * Ricardo, are there any other tools that people need in Ubuntu? Jesse, images are fairly good. Validation Agenda Items: 1. There was some recent discussion with mmwg about audio e2e testing, and whether we should be testing this over hdmi for boards that default to hdmi, or whether all boards should start with a test to simply cover the jack loopback. 2. Kernel WG testsuite progress? Notes: - * End-to-end audio test. Need to handle HDMI audio test. Audio loop-back over jack is one test case and HDMI audio loop-back is a seperate test. Need HDMI test in the next 3-4 months. * Need to get audio test into LAVA. * Tom to work on Android and other higher level tests Housekeeping: === The quality of voice really sucks. Any suggestions for a public platform, or should we move back to #linaro-meeting? - Mumble seems to work better, as you can see where the noise is coming and mute the person (but people generally have issues with mumble). - Google Hangout? Would probably work fine too (it’s the only good thing of google+ ;-) There are quite a few conflicts with this time slot, we need to reschedule. I (dzin) will try to find a more appropriate time slot. Apologies and please bear with me. == = Action Items: = == Amit will send out CONFIG options to check and a test we can run by hand for http://status.linaro.org/card/PMWG2011-THERMAL-MANAGEMENT.html. Ideally this would be part of the pm test case available at LAVA. Besides config enablement, would be good to check with LTs if they are including the needed patches and so on. Zach to spin up a thread about feeding raw data to the toolchain grouphttp://status.linaro.org/card/PMWG2011-THERMAL-MANAGEMENT.html Zach to send an email to KWG. Ricardo to spin up a BP for remaining XBMC and Ubuntu TV work (2 different BPs to target 2 people) Zach to meet with Benjamin. Tony to talk to Alexandros about GLMark2 integration work, Zach to get a thread going. David to send out a summary to linaro-dev and linaro-android. -- David Zinman Linaro Release Manager | Project Manager Linaro.org | Open source software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 0/2] thermal: Add generic cpu cooling devices according to thermal framework
Amit, could you please add the required Kconfig options that need to be enabled to https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/Kconfig under Exynos->Thermal? Zach and Ricardo will then ensure that their kernels have those Kconfig options enabled. /Amit On Wed, Dec 14, 2011 at 6:54 PM, Amit Kachhap wrote: > Hi Nicolas, > > Please pull my samsung thermal implementation work from git repository > (git://git.linaro.org/people/amitdanielk/linux.git thermal_cpu_cooling). > Some of the patches are under review and some are in mainline in 3.2 rc* > version. > It is all based on the tip of your tree. > > The patches are added since commit id > 971be11492b1e248798f7078592b1fa0dfbf3534 > > Thanks, > Amit Daniel > > > On 14 December 2011 20:11, Amit Kachhap wrote: >> >> Hi Nicolas, >> >> Is it possible for you to add these 2 patches for this month release? I am >> not able to give you the git link as there is seems some problem with the >> linaro git server. >> Also I attached the patches in case required. >> >> Thanks, >> Amit Daniel >> >> >> On 13 December 2011 20:43, Amit Daniel Kachhap >> wrote: >> > PATCH 1) [thermal: Add a new trip type to use cooling device instance >> > number] >> > This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE which passes >> > cooling device instance number and may be helpful for cpufreq cooling >> > devices >> > to take the correct cooling action. >> > >> > PATCH 2) [thermal: Add generic cpu cooling implementation] >> > This patch adds generic cpu cooling low level implementation through >> > frequency >> > clipping and cpu hotplug. In future, other cpu related cooling devices >> > may be >> > added here. An ACPI version of this already >> > exists(drivers/acpi/processor_thermal.c). >> > But this will be useful for platforms like ARM using the generic thermal >> > interface >> > along with the generic cpu cooling devices. The cooling device >> > registration API's >> > return cooling device pointers which can be easily binded with the >> > thermal zone >> > trip points. >> > >> > >> > Amit Daniel Kachhap (2): >> > thermal: Add a new trip type to use cooling device instance number >> > thermal: Add generic cpu cooling implementation >> > >> > Documentation/thermal/cpu-cooling-api.txt | 52 + >> > Documentation/thermal/sysfs-api.txt | 4 +- >> > drivers/thermal/Kconfig | 11 + >> > drivers/thermal/Makefile | 1 + >> > drivers/thermal/cpu_cooling.c | 302 >> > + >> > drivers/thermal/thermal_sys.c | 27 +++- >> > include/linux/cpu_cooling.h | 45 + >> > include/linux/thermal.h | 1 + >> > 8 files changed, 440 insertions(+), 3 deletions(-) >> > create mode 100644 Documentation/thermal/cpu-cooling-api.txt >> > create mode 100644 drivers/thermal/cpu_cooling.c >> > create mode 100644 include/linux/cpu_cooling.h >> > >> > > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Monthly Release Thoughts
Hi All, I had some thoughts and a suggestion this morning about the monthly release cycle that I'd like to share. Perhaps I'll get booed off the stage, perhaps not. I'm sure it can be improved on. There is a great deal of stress around what blueprints fit into what monthly release boundary. For deliveries like the LEB that combine the fruits of our Linaro labors this makes great sense. Outside of the process for LEB creation and release, I'd like to suggest it's less than efficient and creates a bit of stress as we have the monthly rush to make the release dates. PMs and TLs continually have to be watching for what will and what won't be making dates that fit with the LEB. This passes on the stress to the engineering team, causes some late night hack-a-thons which in turn I believe caused us to rush software what was less than ready to be included in a LEB. I'm sure we all have examples we could point to. To address this I'd like to suggest the following. The production of the LEB and related builds should continue to be on a monthly release cycle. However outside of that process, for the WGs and such, we should go to a process based on continuous integration. As work groups, landing teams and so on, we commit to the LEB process that we have some set of blueprints IN QUEUE, meaning they are being worked on right now. When they go complete if they are LEB bound, they are delivered to the staging overlay. Items in the staging overlay are candidates for promotion to the overlay. When an item in the staging overlay is judged as being ready (bugs are at least triaged and deemed to not be blocking) it is promoted into the overlay from which daily builds are made and the monthly release is made. Packages in the staging overlay are the subject of functional test.IE Does it work? Packages in the overlay are the subject of integration test. IE Does it break the system? Work Groups, Landing Teams will also commit to having a priority list of blueprints and bugs that are being addressed or will be addressed. This keeps the release process and management team aware of what is coming and when. The # of completed work items per week (or other counts) can also help the management team measure forward momentum and progress. In some respects it's subtle process tweek. But I feel shifting part of linaro to a continuous integration / ship when ready model makes sense. In the work groups we are more connected upstream as we stay tune with upstream release boundaries but still want to showcase results in the monthly LEBs. Likewise focus on the LEB continues with higher quality software. It does shift the goal of creating great software by date X, to creating great software and ship when it's ready. Perhaps this would be a good discussion for 1Q12LC. -- Regards, Tom "Where's the kaboom!? There was supposed to be an earth-shattering kaboom!" Marvin Martian Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: DD and Resize2fs
On Tue, Jan 10, 2012 at 05:29:25PM +0100, Adrien Ferré wrote: > Just tried a linaro nano distrib for beagleboards. I used the dd > tool to copy bit per bit the system to the sdcard but I now have a > 500 Mb system on a 8 Gb sd card. First thing to do is to resize the > rootfs partition. I guess one answer is if you don't want a fixed image size, it's probably going to be best to use linaro-media-create, which lets you decide exactly what you want. -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
DD and Resize2fs
Hi, Just tried a linaro nano distrib for beagleboards. I used the dd tool to copy bit per bit the system to the sdcard but I now have a 500 Mb system on a 8 Gb sd card. First thing to do is to resize the rootfs partition. I'd like to know if it's possible to merge those 2 steps into one? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ACTIVITY] Multimedia WG weekly status report - wk01.2012 (20120102-20120106)
On Tue, Jan 10, 2012 at 8:56 AM, Christian Robottom Reis wrote: > On Tue, Jan 10, 2012 at 08:54:56AM -0600, Tom Gall wrote: >> On Tue, Jan 10, 2012 at 8:15 AM, Christian Robottom Reis >> wrote: >> > On Tue, Jan 10, 2012 at 11:00:29AM +0200, Ilias Biris wrote: >> >> On 09/01/12 17:40, Christian Robottom Reis wrote: >> >> >> for Realvideo that's going upstream into libav. >> >> > Is there a mailing list post or commit? >> >> >> >> For realvideo the last release in 11.12 went upstream - >> >> repo: git://git.libav.org/libav.git >> >> hash: a1e98f198e9db4e5ddfc2f777014179d3d7bc4d2 >> >> >> >> This was incorporated in the last monthly Linaro release. I expect the >> >> same will happen in 12.01 >> > >> > Oh, so we are including in the Ubuntu LEB a trunk build of libav now? Do >> > we do the same for Android (or does Android not use libav)? >> >> A correction is in order. >> >> No we did not ship an upstream development version of libav. The patch >> was shipped upstream and accepted. It was discussed and decided in >> this instance we will pick up the functionality in our libav when the >> next version of libav is released. > > Okay, that makes sense. Should we have a PPA with release and maybe even > pre-release versions available for testing? Yes it would be possible to put something into overlay-staging. > And as I asked above does Android use libav? Sorry missed the question, wasn't avoiding it. No. libav is LGPL. 'nuff said. > -- > Christian Robottom Reis, Engineering VP > Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 > Linaro.org: Open Source Software for ARM SoCs -- Regards, Tom "Where's the kaboom!? There was supposed to be an earth-shattering kaboom!" Marvin Martian Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [GIT PULL] essential u-boot patches for imx6 sabrelite
Thanks Eric, I'll get these into 2012.1. On Tue, Jan 10, 2012 at 2:09 AM, Eric Miao wrote: > The following changes since commit cba9a894fdb1cb49b60fcd1d1d6919cbd7995dd5: > > Prepare v2011.12 (2011-12-23 20:25:35 +0100) > > are available in the git repository at: > git://git.linaro.org/bsp/freescale/u-boot-linaro.git lt-imx6 > > Dirk Behme (1): > i.mx: i.mx6q: add the initial support for i.mx6q Sabre Lite board > > Eric Miao (2): > i.mx6q: mx6qsabrelite: Change default mmcdev and boot command > net/eth.c: fix eth_write_hwaddr() to use dev->enetaddr as fall back > > Fabio Estevam (1): > sdhc_boot: Introduce CONFIG_FSL_FIXED_MMC_LOCATION option > > Jason Chen (1): > i.mx: i.mx6q: add aisp tz init for Off-Platform Peripheral > > Jason Liu (5): > i.mx: fsl_esdhc: add the i.mx6q support > i.mx: i.mx6q: Add the enet clock function > fec: add the i.mx6q enet driver support > i.mx6q: arm2: Add the enet function support > i.mx6q: mx6qsabrelite: Add the ethernet function support > > MAINTAINERS | 1 + > arch/arm/cpu/armv7/mx6/clock.c | 5 + > arch/arm/cpu/armv7/mx6/soc.c | 10 + > board/freescale/common/Makefile | 2 +- > board/freescale/common/sdhc_boot.c | 2 + > board/freescale/mx6qarm2/mx6qarm2.c | 90 + > board/freescale/mx6qsabrelite/Makefile | 42 > board/freescale/mx6qsabrelite/imximage.cfg | 170 > board/freescale/mx6qsabrelite/mx6qsabrelite.c | 259 > + > boards.cfg | 1 + > drivers/mmc/fsl_esdhc.c | 12 +- > drivers/net/fec_mxc.c | 10 + > drivers/net/fec_mxc.h | 7 +- > include/configs/MPC8536DS.h | 1 + > include/configs/P1010RDB.h | 1 + > include/configs/P1_P2_RDB.h | 1 + > include/configs/P2020COME.h | 1 + > include/configs/P2020DS.h | 1 + > include/configs/P2041RDB.h | 1 + > include/configs/corenet_ds.h | 1 + > include/configs/mx6qarm2.h | 13 +- > include/configs/mx6qsabrelite.h | 171 > include/configs/p1_p2_rdb_pc.h | 1 + > net/eth.c | 3 +- > 24 files changed, 797 insertions(+), 9 deletions(-) > create mode 100644 board/freescale/mx6qsabrelite/Makefile > create mode 100644 board/freescale/mx6qsabrelite/imximage.cfg > create mode 100644 board/freescale/mx6qsabrelite/mx6qsabrelite.c > create mode 100644 include/configs/mx6qsabrelite.h ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ACTIVITY] Multimedia WG weekly status report - wk01.2012 (20120102-20120106)
On Tue, Jan 10, 2012 at 08:54:56AM -0600, Tom Gall wrote: > On Tue, Jan 10, 2012 at 8:15 AM, Christian Robottom Reis > wrote: > > On Tue, Jan 10, 2012 at 11:00:29AM +0200, Ilias Biris wrote: > >> On 09/01/12 17:40, Christian Robottom Reis wrote: > >> >> for Realvideo that's going upstream into libav. > >> > Is there a mailing list post or commit? > >> > >> For realvideo the last release in 11.12 went upstream - > >> repo: git://git.libav.org/libav.git > >> hash: a1e98f198e9db4e5ddfc2f777014179d3d7bc4d2 > >> > >> This was incorporated in the last monthly Linaro release. I expect the > >> same will happen in 12.01 > > > > Oh, so we are including in the Ubuntu LEB a trunk build of libav now? Do > > we do the same for Android (or does Android not use libav)? > > A correction is in order. > > No we did not ship an upstream development version of libav. The patch > was shipped upstream and accepted. It was discussed and decided in > this instance we will pick up the functionality in our libav when the > next version of libav is released. Okay, that makes sense. Should we have a PPA with release and maybe even pre-release versions available for testing? And as I asked above does Android use libav? -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ACTIVITY] Multimedia WG weekly status report - wk01.2012 (20120102-20120106)
On Tue, Jan 10, 2012 at 8:15 AM, Christian Robottom Reis wrote: > On Tue, Jan 10, 2012 at 11:00:29AM +0200, Ilias Biris wrote: >> On 09/01/12 17:40, Christian Robottom Reis wrote: >> >> for Realvideo that's going upstream into libav. >> > Is there a mailing list post or commit? >> >> For realvideo the last release in 11.12 went upstream - >> repo: git://git.libav.org/libav.git >> hash: a1e98f198e9db4e5ddfc2f777014179d3d7bc4d2 >> >> This was incorporated in the last monthly Linaro release. I expect the >> same will happen in 12.01 > > Oh, so we are including in the Ubuntu LEB a trunk build of libav now? Do > we do the same for Android (or does Android not use libav)? A correction is in order. No we did not ship an upstream development version of libav. The patch was shipped upstream and accepted. It was discussed and decided in this instance we will pick up the functionality in our libav when the next version of libav is released. >> For speex, the releases are happening via the LP project - >> https://launchpad.net/linaro-multimedia-speex. The NEON optimisation >> patches (not contributed by Linaro) are supposed to be merged upstream >> but afaik have not yet been merged - which is why we helped release >> tarballs for our LEBs for now. > > Makes sense -- thanks! > -- > Christian Robottom Reis, Engineering VP > Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 > Linaro.org: Open Source Software for ARM SoCs -- Regards, Tom "Where's the kaboom!? There was supposed to be an earth-shattering kaboom!" Marvin Martian Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ACTIVITY] Multimedia WG weekly status report - wk01.2012 (20120102-20120106)
On Tue, Jan 10, 2012 at 11:00:29AM +0200, Ilias Biris wrote: > On 09/01/12 17:40, Christian Robottom Reis wrote: > >> for Realvideo that's going upstream into libav. > > Is there a mailing list post or commit? > > For realvideo the last release in 11.12 went upstream - > repo: git://git.libav.org/libav.git > hash: a1e98f198e9db4e5ddfc2f777014179d3d7bc4d2 > > This was incorporated in the last monthly Linaro release. I expect the > same will happen in 12.01 Oh, so we are including in the Ubuntu LEB a trunk build of libav now? Do we do the same for Android (or does Android not use libav)? > For speex, the releases are happening via the LP project - > https://launchpad.net/linaro-multimedia-speex. The NEON optimisation > patches (not contributed by Linaro) are supposed to be merged upstream > but afaik have not yet been merged - which is why we helped release > tarballs for our LEBs for now. Makes sense -- thanks! -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [U-Boot] [PATCH v2 0/4] Add SMDK5250 board support
Hi HeungJun, On 10 January 2012 14:50, HeungJun, Kim wrote: > Hi Chander Kashyap, > > I'm going to share the status of size. > > The case of assemble code: > text data bss dec hex filename > 1929 20 12 1961 7a9 board/samsung/trats/libtrats.o > 912 0 0 912 390 board/samsung/trats/lowlevel_init.o > 1017 20 12 1049 419 board/samsung/trats/trats.o > > The case of C code: > text data bss dec hex filename > 1845 20 4 1869 74d board/samsung/trats/libtrats.o > 1845 20 4 1869 74d board/samsung/trats/trats.o > > Although the pre-version patch has been optimized to current version, > and so it might be the factor, but the size is decreased. > Thanks for sharing the statistics. > Thank you. > > Regards, > Heungjun Kim > > > >> -Original Message- >> From: linaro-dev-boun...@lists.linaro.org [mailto:linaro-dev- >> boun...@lists.linaro.org] On Behalf Of Chander Kashyap >> Sent: Tuesday, January 10, 2012 12:58 PM >> To: Simon Glass >> Cc: linaro-dev@lists.linaro.org; bj...@samsung.com; patc...@linaro.org; >> mk7.k...@samsung.com; u-b...@lists.denx.de; sams...@lists.linaro.org >> Subject: Re: [U-Boot] [PATCH v2 0/4] Add SMDK5250 board support >> >> Dear Simon, >> >> On 9 January 2012 23:25, Simon Glass wrote: >> > Hi Chander, >> > >> > On Sun, Jan 8, 2012 at 10:40 PM, Chander Kashyap >> > wrote: >> >> This patchset add support for Samsung's SMDK5250 board based on >> >> EXYNOS5250 based SoC. It also adds support for MMC SPL booting. >> >> >> >> The porting is done by Samsung engineers at HQ in System LSI Team. >> >> I am contributing in upstreaming the code for the board. >> >> >> >> Based upon discussions following patches are dropped in this version: >> >> Exynos: Add CONFIG_EXYNOS4 Macro to EXYNOS4 based boards >> >> Exynos: Clock.c: Replace exynos4 prefix with exynos >> >> >> >> SMDK5250: enable device tree support is squashed with >> >> EXYNOS: Add SMDK5250 board support >> >> >> >> Chander Kashyap (4): >> >> Exynos: Clock.c: Use CONFIG_SYS_CLK_FREQ macro >> >> ARM: EXYNOS: Add support for Exynos5 based SoCs >> >> EXYNOS: Add SMDK5250 board support >> >> EXYNOS: SMDK5250: Add MMC SPL support >> >> >> >> MAINTAINERS | 1 + >> >> arch/arm/cpu/armv7/exynos/clock.c | 215 +- >> >> arch/arm/include/asm/arch-exynos/clock.h | 326 ++ >> >> arch/arm/include/asm/arch-exynos/cpu.h | 53 ++- >> >> arch/arm/include/asm/arch-exynos/gpio.h | 32 ++ >> >> board/samsung/smdk5250/Makefile | 64 +++ >> >> board/samsung/smdk5250/lowlevel_init.S | 528 > ++ >> >> board/samsung/smdk5250/mem_setup.S | 600 >> + >> > >> > Are you planning to reimplement most of these two files in C as per >> > Wolfgang's comments on the TRATS board, or is that a separate issue? >> Not as of now. We have 14K for spl. Using C style it might not fit into >> that. >> > >> > Regards, >> > Simon >> > >> >> board/samsung/smdk5250/mmc_boot.c | 58 +++ >> >> board/samsung/smdk5250/smdk5250.c | 125 + >> >> board/samsung/smdk5250/smdk5250_setup.h | 589 >> >> >> board/samsung/smdk5250/tools/mkexynos_image.c | 117 + >> >> boards.cfg | 1 + >> >> include/configs/s5pc210_universal.h | 1 + >> >> include/configs/smdk5250.h | 188 >> >> 15 files changed, 2878 insertions(+), 20 deletions(-) >> >> create mode 100644 board/samsung/smdk5250/Makefile >> >> create mode 100644 board/samsung/smdk5250/lowlevel_init.S >> >> create mode 100644 board/samsung/smdk5250/mem_setup.S >> >> create mode 100644 board/samsung/smdk5250/mmc_boot.c >> >> create mode 100644 board/samsung/smdk5250/smdk5250.c >> >> create mode 100644 board/samsung/smdk5250/smdk5250_setup.h >> >> create mode 100644 board/samsung/smdk5250/tools/mkexynos_image.c >> >> create mode 100644 include/configs/smdk5250.h >> >> >> >> -- >> >> 1.7.5.4 >> >> >> >> ___ >> >> U-Boot mailing list >> >> u-b...@lists.denx.de >> >> http://lists.denx.de/mailman/listinfo/u-boot >> >> >> >> -- >> with warm regards, >> Chander Kashyap >> >> ___ >> linaro-dev mailing list >> linaro-dev@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-dev > -- with warm regards, Chander Kashyap ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [U-Boot] [PATCH v2 0/4] Add SMDK5250 board support
Dear Wolfgang Denk, On 10 January 2012 11:05, Wolfgang Denk wrote: > Dear Chander Kashyap, > > In message > you > wrote: >> >> > Are you planning to reimplement most of these two files in C as per >> > Wolfgang's comments on the TRATS board, or is that a separate issue? >> Not as of now. We have 14K for spl. Using C style it might not fit into >> that. > > What makes you think that C coude would be that much larger? Made wrong assumption. It will fit into spl size restrictions. > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > The human race is a race of cowards; and I am not only marching in > that procession but carrying a banner. - Mark Twain -- with warm regards, Chander Kashyap ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [U-Boot] [PATCH v2 0/4] Add SMDK5250 board support
Hi Kyungmin Park, On 10 January 2012 10:42, Kyungmin Park wrote: > On 1/10/12, Chander Kashyap wrote: >> Dear Simon, >> >> On 9 January 2012 23:25, Simon Glass wrote: >>> Hi Chander, >>> >>> On Sun, Jan 8, 2012 at 10:40 PM, Chander Kashyap >>> wrote: This patchset add support for Samsung's SMDK5250 board based on EXYNOS5250 based SoC. It also adds support for MMC SPL booting. The porting is done by Samsung engineers at HQ in System LSI Team. I am contributing in upstreaming the code for the board. Based upon discussions following patches are dropped in this version: Exynos: Add CONFIG_EXYNOS4 Macro to EXYNOS4 based boards Exynos: Clock.c: Replace exynos4 prefix with exynos SMDK5250: enable device tree support is squashed with EXYNOS: Add SMDK5250 board support Chander Kashyap (4): Exynos: Clock.c: Use CONFIG_SYS_CLK_FREQ macro ARM: EXYNOS: Add support for Exynos5 based SoCs EXYNOS: Add SMDK5250 board support EXYNOS: SMDK5250: Add MMC SPL support MAINTAINERS | 1 + arch/arm/cpu/armv7/exynos/clock.c | 215 +- arch/arm/include/asm/arch-exynos/clock.h | 326 ++ arch/arm/include/asm/arch-exynos/cpu.h | 53 ++- arch/arm/include/asm/arch-exynos/gpio.h | 32 ++ board/samsung/smdk5250/Makefile | 64 +++ board/samsung/smdk5250/lowlevel_init.S | 528 ++ board/samsung/smdk5250/mem_setup.S | 600 + >>> >>> Are you planning to reimplement most of these two files in C as per >>> Wolfgang's comments on the TRATS board, or is that a separate issue? >> Not as of now. We have 14K for spl. Using C style it might not fit into >> that. > In case of trats implemented by C. it's not big. and I think it can > fit SPL size limitation. Yes true. I assumed wrongly. > > Thank you, > Kyungmin Park >>> >>> Regards, >>> Simon >>> board/samsung/smdk5250/mmc_boot.c | 58 +++ board/samsung/smdk5250/smdk5250.c | 125 + board/samsung/smdk5250/smdk5250_setup.h | 589 board/samsung/smdk5250/tools/mkexynos_image.c | 117 + boards.cfg | 1 + include/configs/s5pc210_universal.h | 1 + include/configs/smdk5250.h | 188 15 files changed, 2878 insertions(+), 20 deletions(-) create mode 100644 board/samsung/smdk5250/Makefile create mode 100644 board/samsung/smdk5250/lowlevel_init.S create mode 100644 board/samsung/smdk5250/mem_setup.S create mode 100644 board/samsung/smdk5250/mmc_boot.c create mode 100644 board/samsung/smdk5250/smdk5250.c create mode 100644 board/samsung/smdk5250/smdk5250_setup.h create mode 100644 board/samsung/smdk5250/tools/mkexynos_image.c create mode 100644 include/configs/smdk5250.h -- 1.7.5.4 ___ U-Boot mailing list u-b...@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot >> >> >> >> -- >> with warm regards, >> Chander Kashyap >> >> ___ >> linaro-dev mailing list >> linaro-dev@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-dev >> -- with warm regards, Chander Kashyap ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Errors in work item definitions
On 10 January 2012 11:50, Tony Mansson wrote: > Hm, not according to the documentation: > > "The start is indicated by a line "Work items:" (anywhere in the > whiteboard), then exactly one line for each work item, and finally an > empty line to end the work item list. Each work item is one line with > the description, then a colon, and the status, and optionally has an > assignee prefix (which should be the Launchpad account name) in square > brackets" > > Is the supervision run done 1:1 with the mails? If I try a fix and > half an hour later gets the same error message again, I tend to > conclude that the fix didn't work. After being spammed (like many others, including me), you can check if someone else has fixed it (see blueprints notification). > Currently I get complaints from this BP on the line marked as TODO, > but all the lines marked DONE are accepted. They all contain URLs. It > is confusing. > > OK -> [pundiramit] Test > https://android-build.linaro.org/builds/~linaro-android/staging-vexpress-a9/#build=47: > DONE > NOK -> [pfefferz] Test > https://android-build.linaro.org/builds/~linaro-android/panda/#build=463: > TODO In the meantime, I fixed it. The TODO status was missing previously. > OK -> [pfefferz] > https://android-build.linaro.org/builds/~linaro-android/staging-origen/#build=130: > DONE > > complaint: > [ERROR] invalid state > "//android-build.linaro.org/builds/~linaro-android/panda/#build=463" > for work item "Test https" > > /Tony > > On 10 January 2012 08:21, Mattias Backman wrote: >> >> On Mon, Jan 9, 2012 at 2:45 PM, Tony Mansson wrote: >> > Hi Guys. >> > >> > I get a lot of spam from launchpad whenever the format of a blueprint is >> > not >> > OK. >> > >> > Below is an example. Please don't use colons (as e.g. in an URL) inside >> > work >> > item definitions. There is a low-IQ parser somewhere that gets confused by >> > that. >> >> I believe that is a problem only when you leave out the work item >> state. That is, if you always add ": TODO" to your new work items >> you'll be ok. >> >> > >> > BR, >> > Tony >> > >> > >> > -- Forwarded message -- >> > From: Launchpad work item tracker >> > >> > Date: 9 January 2012 13:37 >> > Subject: Errors in work item definitions >> > To: tony.mans...@linaro.org >> > >> > >> > https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-12.01-release >> > [ERROR] invalid state >> > "//android-build.linaro.org/builds/~linaro-android/tracking-panda/#build=139" >> > for work item "https" >> > https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-12.01-release >> > [ERROR] invalid state >> > "//android-build.linaro.org/builds/~linaro-android/staging-imx53/#build=142" >> > for work item "https" >> > https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-12.01-release >> > [ERROR] invalid state >> > "//android-build.linaro.org/builds/~linaro-android/landing-panda/#build=15" >> > for work item "https" >> > https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-12.01-release >> > [ERROR] invalid state >> > "//android-build.linaro.org/builds/~linaro-android/landing-snowball/#build=113" >> > for work item "https" >> > https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-12.01-release >> > [ERROR] invalid state >> > "//android-build.linaro.org/builds/~linaro-android/staging-panda/#build=184" >> > for work item "https" >> > https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-12.01-release >> > [ERROR] invalid state >> > "//android-build.linaro.org/builds/~linaro-android/staging-snowball/#build=154" >> > for work item "https" >> > >> > >> > ___ >> > linaro-dev mailing list >> > linaro-dev@lists.linaro.org >> > http://lists.linaro.org/mailman/listinfo/linaro-dev >> > > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev -- Fathi Boudra Linaro Release Manager | Validation Project Manager Linaro.org | Open source software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [Linaro-mm-sig] [PATCH] cma: fix limit adjustment in dma_declare_contiguous()
Hello,
On Monday, January 09, 2012 9:53 PM Mans Rullgard wrote:
> The upper limit needs to be rounded down to a multiple of the
> alignment, not up.
>
> Signed-off-by: Mans Rullgard
Thanks for spotting this issue! I will add this change to the next version of
CMA patches.
> ---
> drivers/base/dma-contiguous.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
> index 924c052..e10120f 100644
> --- a/drivers/base/dma-contiguous.c
> +++ b/drivers/base/dma-contiguous.c
> @@ -256,7 +256,7 @@ int __init dma_declare_contiguous(struct device *dev,
> unsigned long size,
> alignment = PAGE_SIZE << max(MAX_ORDER, pageblock_order);
> base = ALIGN(base, alignment);
> size = ALIGN(size, alignment);
> - limit = ALIGN(limit, alignment);
> + limit &= ~(alignment - 1);
>
> /* Reserve memory */
> if (base) {
> --
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Errors in work item definitions
Hm, not according to the documentation: "The start is indicated by a line "Work items:" (anywhere in the whiteboard), then exactly one line for each work item, and finally an empty line to end the work item list. Each work item is one line with the description, then a colon, and the status, and optionally has an assignee prefix (which should be the Launchpad account name) in square brackets" Is the supervision run done 1:1 with the mails? If I try a fix and half an hour later gets the same error message again, I tend to conclude that the fix didn't work. Currently I get complaints from this BP on the line marked as TODO, but all the lines marked DONE are accepted. They all contain URLs. It is confusing. OK -> [pundiramit] Test https://android-build.linaro.org/builds/~linaro-android/staging-vexpress-a9/#build=47: DONE NOK -> [pfefferz] Test https://android-build.linaro.org/builds/~linaro-android/panda/#build=463: TODO OK -> [pfefferz] https://android-build.linaro.org/builds/~linaro-android/staging-origen/#build=130: DONE complaint: [ERROR] invalid state "//android-build.linaro.org/builds/~linaro-android/panda/#build=463" for work item "Test https" /Tony On 10 January 2012 08:21, Mattias Backman wrote: > > On Mon, Jan 9, 2012 at 2:45 PM, Tony Mansson wrote: > > Hi Guys. > > > > I get a lot of spam from launchpad whenever the format of a blueprint is not > > OK. > > > > Below is an example. Please don't use colons (as e.g. in an URL) inside work > > item definitions. There is a low-IQ parser somewhere that gets confused by > > that. > > I believe that is a problem only when you leave out the work item > state. That is, if you always add ": TODO" to your new work items > you'll be ok. > > > > > BR, > > Tony > > > > > > -- Forwarded message -- > > From: Launchpad work item tracker > > > > Date: 9 January 2012 13:37 > > Subject: Errors in work item definitions > > To: tony.mans...@linaro.org > > > > > > https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-12.01-release > > [ERROR] invalid state > > "//android-build.linaro.org/builds/~linaro-android/tracking-panda/#build=139" > > for work item "https" > > https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-12.01-release > > [ERROR] invalid state > > "//android-build.linaro.org/builds/~linaro-android/staging-imx53/#build=142" > > for work item "https" > > https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-12.01-release > > [ERROR] invalid state > > "//android-build.linaro.org/builds/~linaro-android/landing-panda/#build=15" > > for work item "https" > > https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-12.01-release > > [ERROR] invalid state > > "//android-build.linaro.org/builds/~linaro-android/landing-snowball/#build=113" > > for work item "https" > > https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-12.01-release > > [ERROR] invalid state > > "//android-build.linaro.org/builds/~linaro-android/staging-panda/#build=184" > > for work item "https" > > https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-12.01-release > > [ERROR] invalid state > > "//android-build.linaro.org/builds/~linaro-android/staging-snowball/#build=154" > > for work item "https" > > > > > > ___ > > linaro-dev mailing list > > linaro-dev@lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/linaro-dev > > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [U-Boot] [PATCH v2 0/4] Add SMDK5250 board support
Hi Chander Kashyap, I'm going to share the status of size. The case of assemble code: textdata bss dec hex filename 1929 20 121961 7a9 board/samsung/trats/libtrats.o 912 0 0 912 390 board/samsung/trats/lowlevel_init.o 1017 20 121049 419 board/samsung/trats/trats.o The case of C code: textdata bss dec hex filename 1845 20 41869 74d board/samsung/trats/libtrats.o 1845 20 41869 74d board/samsung/trats/trats.o Although the pre-version patch has been optimized to current version, and so it might be the factor, but the size is decreased. Thank you. Regards, Heungjun Kim > -Original Message- > From: linaro-dev-boun...@lists.linaro.org [mailto:linaro-dev- > boun...@lists.linaro.org] On Behalf Of Chander Kashyap > Sent: Tuesday, January 10, 2012 12:58 PM > To: Simon Glass > Cc: linaro-dev@lists.linaro.org; bj...@samsung.com; patc...@linaro.org; > mk7.k...@samsung.com; u-b...@lists.denx.de; sams...@lists.linaro.org > Subject: Re: [U-Boot] [PATCH v2 0/4] Add SMDK5250 board support > > Dear Simon, > > On 9 January 2012 23:25, Simon Glass wrote: > > Hi Chander, > > > > On Sun, Jan 8, 2012 at 10:40 PM, Chander Kashyap > > wrote: > >> This patchset add support for Samsung's SMDK5250 board based on > >> EXYNOS5250 based SoC. It also adds support for MMC SPL booting. > >> > >> The porting is done by Samsung engineers at HQ in System LSI Team. > >> I am contributing in upstreaming the code for the board. > >> > >> Based upon discussions following patches are dropped in this version: > >> Exynos: Add CONFIG_EXYNOS4 Macro to EXYNOS4 based boards > >> Exynos: Clock.c: Replace exynos4 prefix with exynos > >> > >> SMDK5250: enable device tree support is squashed with > >> EXYNOS: Add SMDK5250 board support > >> > >> Chander Kashyap (4): > >> Exynos: Clock.c: Use CONFIG_SYS_CLK_FREQ macro > >> ARM: EXYNOS: Add support for Exynos5 based SoCs > >> EXYNOS: Add SMDK5250 board support > >> EXYNOS: SMDK5250: Add MMC SPL support > >> > >> MAINTAINERS | 1 + > >> arch/arm/cpu/armv7/exynos/clock.c | 215 +- > >> arch/arm/include/asm/arch-exynos/clock.h | 326 ++ > >> arch/arm/include/asm/arch-exynos/cpu.h | 53 ++- > >> arch/arm/include/asm/arch-exynos/gpio.h | 32 ++ > >> board/samsung/smdk5250/Makefile | 64 +++ > >> board/samsung/smdk5250/lowlevel_init.S | 528 ++ > >> board/samsung/smdk5250/mem_setup.S | 600 > + > > > > Are you planning to reimplement most of these two files in C as per > > Wolfgang's comments on the TRATS board, or is that a separate issue? > Not as of now. We have 14K for spl. Using C style it might not fit into that. > > > > Regards, > > Simon > > > >> board/samsung/smdk5250/mmc_boot.c | 58 +++ > >> board/samsung/smdk5250/smdk5250.c | 125 + > >> board/samsung/smdk5250/smdk5250_setup.h | 589 > > >> board/samsung/smdk5250/tools/mkexynos_image.c | 117 + > >> boards.cfg | 1 + > >> include/configs/s5pc210_universal.h | 1 + > >> include/configs/smdk5250.h | 188 > >> 15 files changed, 2878 insertions(+), 20 deletions(-) > >> create mode 100644 board/samsung/smdk5250/Makefile > >> create mode 100644 board/samsung/smdk5250/lowlevel_init.S > >> create mode 100644 board/samsung/smdk5250/mem_setup.S > >> create mode 100644 board/samsung/smdk5250/mmc_boot.c > >> create mode 100644 board/samsung/smdk5250/smdk5250.c > >> create mode 100644 board/samsung/smdk5250/smdk5250_setup.h > >> create mode 100644 board/samsung/smdk5250/tools/mkexynos_image.c > >> create mode 100644 include/configs/smdk5250.h > >> > >> -- > >> 1.7.5.4 > >> > >> ___ > >> U-Boot mailing list > >> u-b...@lists.denx.de > >> http://lists.denx.de/mailman/listinfo/u-boot > > > > -- > with warm regards, > Chander Kashyap > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[GIT PULL] essential u-boot patches for imx6 sabrelite
The following changes since commit cba9a894fdb1cb49b60fcd1d1d6919cbd7995dd5: Prepare v2011.12 (2011-12-23 20:25:35 +0100) are available in the git repository at: git://git.linaro.org/bsp/freescale/u-boot-linaro.git lt-imx6 Dirk Behme (1): i.mx: i.mx6q: add the initial support for i.mx6q Sabre Lite board Eric Miao (2): i.mx6q: mx6qsabrelite: Change default mmcdev and boot command net/eth.c: fix eth_write_hwaddr() to use dev->enetaddr as fall back Fabio Estevam (1): sdhc_boot: Introduce CONFIG_FSL_FIXED_MMC_LOCATION option Jason Chen (1): i.mx: i.mx6q: add aisp tz init for Off-Platform Peripheral Jason Liu (5): i.mx: fsl_esdhc: add the i.mx6q support i.mx: i.mx6q: Add the enet clock function fec: add the i.mx6q enet driver support i.mx6q: arm2: Add the enet function support i.mx6q: mx6qsabrelite: Add the ethernet function support MAINTAINERS |1 + arch/arm/cpu/armv7/mx6/clock.c|5 + arch/arm/cpu/armv7/mx6/soc.c | 10 + board/freescale/common/Makefile |2 +- board/freescale/common/sdhc_boot.c|2 + board/freescale/mx6qarm2/mx6qarm2.c | 90 + board/freescale/mx6qsabrelite/Makefile| 42 board/freescale/mx6qsabrelite/imximage.cfg| 170 board/freescale/mx6qsabrelite/mx6qsabrelite.c | 259 + boards.cfg|1 + drivers/mmc/fsl_esdhc.c | 12 +- drivers/net/fec_mxc.c | 10 + drivers/net/fec_mxc.h |7 +- include/configs/MPC8536DS.h |1 + include/configs/P1010RDB.h|1 + include/configs/P1_P2_RDB.h |1 + include/configs/P2020COME.h |1 + include/configs/P2020DS.h |1 + include/configs/P2041RDB.h|1 + include/configs/corenet_ds.h |1 + include/configs/mx6qarm2.h| 13 +- include/configs/mx6qsabrelite.h | 171 include/configs/p1_p2_rdb_pc.h|1 + net/eth.c |3 +- 24 files changed, 797 insertions(+), 9 deletions(-) create mode 100644 board/freescale/mx6qsabrelite/Makefile create mode 100644 board/freescale/mx6qsabrelite/imximage.cfg create mode 100644 board/freescale/mx6qsabrelite/mx6qsabrelite.c create mode 100644 include/configs/mx6qsabrelite.h ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ACTIVITY] Multimedia WG weekly status report - wk01.2012 (20120102-20120106)
Hi Kiko! On 09/01/12 17:40, Christian Robottom Reis wrote: >> for Realvideo that's going upstream into libav. > Is there a mailing list post or commit? For realvideo the last release in 11.12 went upstream - repo: git://git.libav.org/libav.git hash: a1e98f198e9db4e5ddfc2f777014179d3d7bc4d2 This was incorporated in the last monthly Linaro release. I expect the same will happen in 12.01 For speex, the releases are happening via the LP project - https://launchpad.net/linaro-multimedia-speex. The NEON optimisation patches (not contributed by Linaro) are supposed to be merged upstream but afaik have not yet been merged - which is why we helped release tarballs for our LEBs for now. As for the link you requested, I usually leave the links in the full dashboard (which is mentioned first in the report message). I will add the links also from now on in the email report also. thanks, -- Ilias Biris ilias.bi...@linaro.org Project Manager, Linaro M: +358504839608, IRC: ibiris Skype: ilias_biris Linaro.org│ Open source software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
