Re: [RFC PATCH 0/2] thermal: Add generic cpu cooling devices according to thermal framework
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. > Any comments on these patches? I submitted them quite long back. Regards, Amit D > > 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
Re: Android 11.12 on pandaboard
Thanks for all your responses. We will try it as soon as possible :) So this tells me that the build determines which resolution it has, this can not be changed through any setting. Is this right? With kind regards, Ion Aalbers On 19 January 2012 08:30, Vishal Bhoj wrote: > I guess the right build for you to use is the tracking-panda build which > has Wifi and onboard audio playback support also. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Android 11.12 on pandaboard
On 01/19/2012 03:37 PM, Somebody in the thread at some point said: > Thanks for all your responses. > We will try it as soon as possible :) > > So this tells me that the build determines which resolution it has, this > can not be changed through any setting. Is this right? You can try messing with dss kernel commandlines but I dunno you get anywhere good. Fracture in video status reflects fracture in TI approach to how the work is done. There's an upstream effort to get definitive mainline support in, and separately there's customer support based approach from TI that is mainly targeted at Android / Omapzoom. The code quality is best in mainline but support is incomplete, especially about multihead. In OZ and OZ-ish kernels, filter for what goes in is not as aggressive as mainline, enablement is better but basis is always an old release. That means, the old, working 3.0 code diverges from what got into mainline for later releases and can't be brought on easily unless treated as alien code like SGX. Linaro TI LT kernel is trying to be a third approach, while worshipping mainline HEAD above all, so we have recent development basis, we glue on whatever missing pieces we can scavenge from wherever, keeping them up to date with Linus HEAD with to goal of being a highly enabled "fake upstream" with the missing pieces integrated. In your case that boils down to: Jassi added code to come out on HDMI connector at 1080p via EDID on our kernel, AOSP omap 3.0-based kernel doesn't have that support. -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
[Fwd: Versatile Express hwpack changes]
Hi folks, The way Versatile Express hardware packs are to be delivered is set to change. Currently, both Platform and the ARM Landing Team (Tixy and me) generate hwpacks for Versatile Express A9. In future, only the ARM Landing Team will be generating hardware packs for the Versatile Express platforms. The LT have a some great features to roll out in the coming months, such as UEFI, Device Tree, A5 and A15 CoreTile support. It makes sense for Linaro to only support one variant of the hardware pack and gives the Landing Team more control over feature deployment. You can find our hardware pack in the current Linaro releases, via http://www.linaro.org/downloads in the Developer and Community Builds section and/or via releases.linaro.org. For example, you'll find the current LT hwpack here: http://releases.linaro.org/11.12/ubuntu/oneiric-hwpacks/hwpack_linaro-lt-vexpress-a9_20111219-1_armel_supported.tar.gz Regards, Ryan ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Meeting Minutes: Discussion on STM framework proposal (17 January 2012)
Arvind, Thanks for taking and publishing the notes from our discussion. The following are additional notes for the STM metadata discussion: STM Framework Spec version .4 uses the STP 2.0 Mark packets for driver generated binary messages primarily for broadcasting context changes (process id) on an STM channel. So no plan to use Mark packets for metadata. We are currently using a dedicated channel for metadata (for processing hw generated STM messages), which worked out very efficiently for our decoder. Since we would use a dedicated channel for metadata, I don't see any reason not to simply use the basic byte-stream message format to broadcast metadata. For broadcasting metadata into an ETB, there is a solution Michael and I talked about last week that I forgot to mention during our discussion. We can simply store the metadata in a debugfs file when routing to the ETB. We may need to use some other switch to determine this since routing through the first level of trace funnel may be all we should handle from the STM drivers. Would also need an interface (another debugfs file) that allows user mode libraries to hand off metadata to the driver. We also touched a bit on the possibility of metadata providing a descriptor for binary data allowing for generic decoding beyond simple string data. This may be a good solution for decoding tracepoints since they broadcast binary data on a dedicated channel. Adding sw message metadata would mean that a STM channel would have to be dedicated to a specific data type, which is something OST headers avoid. Other than additions to the spec for metadata support I don't recall anything in our discussion that would cause me to modify the STM Framework spec. I have started implementation so would like to get feedback on the .4 spec as soon as possible. Thanks, Doug From: Arvind Chauhan [mailto:arvind.chau...@arm.com] Sent: Wednesday, January 18, 2012 6:51 AM To: Deao, Douglas; Ian Spray; Robin Randhawa; John Horley; Al Grant; Ashwin Namjoshi Subject: Meeting Minutes: Discussion on STM framework proposal (17 January 2012) Minutes - Discussion on STM framework proposal Present: Linaro: Deao Douglas; ARM: Ian Spray, John Horley, Robin Randhawa, Al Grant, Aswhin Namjoshi, Arvind Chauhan Local Decode * Doug mentioned about a requirement for local decode, where some customers want to capture data in ETB and decode locally. oUse cases: Power and Bus profiling - (hardware messages) oEasier to explain to customers in terms of use cases than about STM details - they look at it as just another driver to get trace data out * Ian provided views on ETB decode being not an optimal option Trace Ecosystem * Discussion on how rest of Coresight world fits together, in terms of configuring other sub-systems like funnel, replicators to get trace data out reliably oDoug mentioned that current view is to have these modules sit side-by-side together in a system - STM specifics taken care of by STM Framework driver, like so by respective drivers. These various drivers may not be interacting a lot beyond init * Question: Is it part of Linaro's remit to look at overall Coresight components (not just STM)? o Answer from Doug: Not particularly. * Ian emphasized the point that it's very important to address overall trace ecosystem view beyond STM framework driver and testing oAt least getting the high level overview written down will help in guiding how everything fits together oDoug is open to considering this aspect. * Question: Can ARM put some thoughts together, maybe expand initial section of STM framework driver spec to cover overall trace flow? oThis may lead to future blueprints, increased scope. oIan to see if some text can be put together Validation Platform * Local decode setup: STM framework driver + OMAP Plugins + Standalone decoder + User mode library to configure ETB + OMAP4 Platform, OMAP5 in future oPandaboard can be an option Roadmap * Doug mentioned that though most of their customer/tools are for local decode, 'agrees that there does exist valid case for transferring trace data to host machine/tools for processing * Roadmap mentions about LTTng etc. - so not just limited to local decode Metadata channel * Question: Any plans of reserved block of channels for metadata? Ver 0.4 of STM Framework spec doesn't give any details on metadata channel. oDoug mentioned that it's not included in current spec - looking at using mark packet - were not in favor of metadata transport, as OST headers were supported that describes data for TI's decoders o Don't see a strong need for broadcasting metadata for software messages - have found it useful lately for hardware messages oChallenge to determine
Fwd: Re: Latest kernel build information for snowball
FYI - see below. Mathieu. Original Message Subject: Re: Latest kernel build information for snowball Date: Thu, 19 Jan 2012 13:53:26 -0700 From: Mathieu Poirier To: us...@igloocommunity.org Sharad and friends, I have updated the build instructions. You will find the latest and greatest here: https://wiki.linaro.org/Platform/Android/snowballAcceleratedGraphics I also included a section that indicates how to find the exact SHA of a kernel for a given build number. As usual question, complaint and rants can be sent to me via email or openly in #igloo. Mathieu. On 12-01-19 05:56 AM, Sharad Srivastava wrote: > Hi, > > I would like to build the latest stable kernel release for snowball, for > which I am trying to gather some information such as; > > 1. Location of the git repository for the latest source code . > > 2. The tag to use to check out the code. > > 3. The .config file to use for building the kernel source code. > > regards, > sharad. > > > > > ___ > users mailing list > us...@igloocommunity.org > http://igloocommunity.org/cgi-bin/mailman/listinfo/users ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
SMP Improvement on Android
Team, The TI SMP team is interested in our work improving SMP on Android. They may be able to come to Connect and hack on things with us. We need to get the relevant patches that have been hanging around integrated into some builds, get some benchmark and correctness test into LAVA and send everything back up to AOSP. Interested people should subscribe to: https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-define-and-run-smp-tests The connect session will be: https://blueprints.launchpad.net/linaro-android/+spec/linaro-platforms-q112-android-smp-on-android This is going to rock! -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
LAVA maintenance 2012-01-19 23:00 UTC COMPLETE
Dear LAVA users, We have finished the planned maintenance. The lab was down for approximately: 23 minutes (we did not estimate the downtime before). We have installed the 2012.01 release from this .pybundle file [1]. It contains the following software packages [2] We did encounter some problems in the upgrade procedure which will be addressed in the subsequent release [3, 4] [1]: https://launchpad.net/lava-project/+milestone/2012.01 [2]: http://bazaar.launchpad.net/~linaro-validation/lava-deployment-tool/trunk/view/head:/requirements/requirements-2012.01.txt [3]: https://bugs.launchpad.net/lava-deployment-tool/+bug/918944 [4]: TBD -- The Validation Team. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: LAVA maintenance 2012-01-19 23:00 UTC COMPLETE
On Thu, 19 Jan 2012 23:25:33 +0100, Zygmunt Krynicki wrote: > Dear LAVA users, > > We have finished the planned maintenance. > > The lab was down for approximately: 23 minutes (we did not estimate > the downtime before). > We have installed the 2012.01 release from this .pybundle file [1]. It > contains the following software packages [2] > We did encounter some problems in the upgrade procedure which will be > addressed in the subsequent release [3, 4] > > [1]: https://launchpad.net/lava-project/+milestone/2012.01 > [2]: > http://bazaar.launchpad.net/~linaro-validation/lava-deployment-tool/trunk/view/head:/requirements/requirements-2012.01.txt > [3]: https://bugs.launchpad.net/lava-deployment-tool/+bug/918944 > [4]: TBD https://bugs.launchpad.net/lava-deployment-tool/+bug/918955 Cheers, mwh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
