linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

[ACTIVITY] Power Management WG Weekly Status report week ending 2011-09-02

by Mounir Bsaibes

Enclosed please find the link to the Meeting Minutes & Weekly Status report for the Power Management working group for the week ending 2011-08-26. == Meeting Minutes == https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2011-08-31 == Weekly Status Report == https://wiki.linaro.org/WorkingGroups/PowerManagement/Status/2011-09-01 == Summary == * Made hotplug power measurements on st-e u8500 platform * mp3 playback test showed between 7 to 8% power improvement * cpuhotplug - For Linux idle case, no visible improvement as power is already very low * Finished GPIO support in power debug. * linaro-pm-qa integration with LAVA went well, we should start seeing a daily test of power management suite * Published git tree containing common Samsung save and restore code * Preparing thermal framework for upstreaming and preparing slides for Plumbers conference * Started to work on integration of thermal with OMAP4460 power management * Re-writing cpuidle driver * Started design work on struct clk, created some notes and design points for discussion at LPC * Rebased PMWG kernel git tree to 3.1-rc4 Best regards, Mounir -- Mounir Bsaibes Project Manager Follow Linaro.org: facebook.com/pages/Linaro/155974581091106 http://twitter.com/#!/linaroorg http://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>

14 years, 10 months

Please register for Linaro Connect Q4.11

by Stephen Doel

Hi All, As a reminder, please register and organise your attendance at Linaro Connect Q4.11 as soon as possible. In particular: · if you're going to need a visa you should register now so we can get the process going with your respective embassy · if you need internal company approvals for attendance, make sure its underway - and let me know if you need any additional supporting information · if you are a Canonical secondee to Linaro, you should register to Linaro Connect (not UDS) The hotel registration and booking details are now here: http://connect.linaro.org/events/event/linaro-connect-q411/ Schedule information should be following in the next couple of weeks, I'll send an update when they are available. Thx Stephen Doel Chief Operating Officer T: +44 1223 45 00 23 │ M: +44 77 66 014 247 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook <http://www.facebook.com/pages/Linaro/155974581091106> | Twitter <http://twitter.com/#!/linaroorg> | Blog <http://www.linaro.org/linaro-blog/>

14 years, 10 months

[ACTIVITY] OCTO status - wk 36 (20110829-20110902)

by Ilias Biris

Status: https://wiki.linaro.org/OfficeofCTO/WeeklyReport Last Meeting minutes: https://wiki.linaro.org/OfficeofCTO/2011-08-30 Not much to report as many were either on vacation or just returning from vac. Highlights: ARMHF: build farm setup for the Freescale quickstart boards used. Build farm is now ready - just waiting to be fit in a machine room at ARM. On the Debian hardfp build: mono/armhf has been uploaded. chromium-browser fails checking why, building both qtwebkit/webkitgtk+ now manually. Konstantinos also reported that he needs to get some 180 packages to be built to reach past the 90% mark Boot architecture: meetings scheduled to restart on the week after LPC. Best, -- Ilias Biris ilias.biris(a)linaro.org Project Manager, Linaro M: +358504839608, IRC: ibiris Skype: ilias_biris Linaro.org│ Open source software for ARM SoCs

14 years, 10 months

[NOTES] Linaro Release Meeting 2011-09-01

by Fathi Boudra

Enclosed, please find a link to the agenda, notes and actions from the Linaro Release Weekly meeting held on September 1st in #linaro-meeting on irc.freenode.net at 16:00 UTC. == Meeting Minutes == http://wiki.linaro.org/Cycles/WeeklyReleaseMeeting/2011-09-01 == Meeting Log == http://irclogs.linaro.org/meeting-logs/linaro-meeting/2011/linaro-meeting.2… == Previous actions items == * fabo to sync with pfalcon/asac to get more space for android builders - DONE RT#87 opened, space extended to 30G. RT#90 opened, quote of additional hard drives INPROGRESS. == Agenda == * Current focus: the list of components delivered for this cycle is up-to-date - INPROGRESS the milestone pages for this cycle are created - DONE the blueprints are targeted to this cycle - INPROGRESS the blueprints have a headline and an acceptance criteria - INPROGRESS REMINDER: the headlines should be worded nicely to figure on the release notes/announcement highlights and minimize re-wording. * Toolchain WG release date Dev Platform and Android would like to have the toolchain released 2 weeks before Linaro release. 3rd Thursday vs last Thursday: delay varies. Sometime it's a week, sometime it's 2 weeks. * Release dashboard available on the wiki: http://wiki.linaro.org/Cycles/1109/Release/Dashboard * Next week: - call for testing on Monday (using form, lava-qatracker will be used as soon as available). - release response team setup. == Image status == * disk space issues raised for Ubuntu and Android builders. It's planned to add additional hard drives for both. See also RT#86, RT#87 and RT#90. == Bugs == * http://bugs.launchpad.net/bugs/709245 High ARM SMP scheduler performance bug => Tracked by jcrigby * http://bugs.launchpad.net/bugs/732912 High omapdss DISPC error: GFX_FIFO_UNDERFLOW => Tracked by mounir/doanac; fixed according to doanac * http://bugs.launchpad.net/bugs/753878 High Ubuntu image - icons and parts of screen disappear with Origen => Assigned to rsalveti * http://bugs.launchpad.net/bugs/754254 High imx51 randomly truncates serial input at 31 characters => Waiting for springz * http://bugs.launchpad.net/bugs/788746 High Ethernet is not enabled be default => Assigned to mpoirier * http://bugs.launchpad.net/bugs/807230 High ADB requires new userland setup w/ linux-linaro-android 3.0-2011.07 => Assigned to vishal * http://bugs.launchpad.net/bugs/816491 High System crashes when display attempts to sleep => Waiting for agreen * http://bugs.launchpad.net/bugs/816638 High Pulseaudio consumes 100% of the cpu when trying to play a sound with natty's linaro LEB and 3.0.0-1402-linaro-lt-omap => Assigned to rsalveti, kan_hu is helping * http://bugs.launchpad.net/bugs/823313 High Android LEB fails to mount system and user partition interminttently => Assigned to philang * http://bugs.launchpad.net/bugs/829220 Critical linaro-media-create fails for snowball_emmc => Fixed but trigger another issue, mpoirier to comment * http://bugs.launchpad.net/bugs/832356 High LT-Panda 11.07/08 lacks device tree support => Assigned to rsalveti * http://bugs.launchpad.net/bugs/832397 High add Origen support to linaro-android-media-create => Fix committed but not released == Action items == * mounir to open the discussion with michael hope about toolchain release date. * james_w/pfalcon/fabo to follow-up closely on disk space issues, quote of hardrive. == People present == fabo pfefferz rsalveti james_w mounir plars ibiris doanac mpoirier tgall_foo uahmad -- Fathi Boudra Linaro Release Manager | Platform Project Manager Linaro.org | Open source software for ARM SoCs

14 years, 10 months

[ACTIVITY] Graphics WG status report - wk34.2011 (20110822-20110826)

by Ilias Biris

Status: https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/WeeklyReport Last meeting minutes: https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2011-08-24 Highlights: Milestones for 1109 deliverables: - https://launchpad.net/unity-gles/+milestone/2011.09 - https://launchpad.net/glcompbench/+milestone/2011.09 - https://launchpad.net/linaro-graphics-misc/+milestone/2011.09 - https://launchpad.net/glmark2/+milestone/2011.09 - https://launchpad.net/glproxy/+milestone/2011.09 - https://launchpad.net/linaro-mm-sig/+milestone/2011.09 (memory management work) Today (31Aug) we will discuss how to make available the unity/nux on 1109. I will update the milestone page once the decision is taken. Also note the development on MM: Jesse is preparing a GIT tree to contain the patches available, including components from the Video-Multimedia side (eg OMAP DRM driver (maybe others too), xf86-video-omap open source xorg driver). The tree can be made available as a meta-pkg for the Linaro main release in September (add-on "use at own risk" since all this is work still in progress and not upstreamed completely). Details on the tree and how to use it will come during September. BR, -- Ilias Biris ilias.biris(a)linaro.org Project Manager, Linaro M: +358504839608, IRC: ibiris Skype: ilias_biris Linaro.org│ Open source software for ARM SoCs

14 years, 10 months

[Request] Can Linaro-dev not send duplicate mail to recipients?

by John Stultz

So being on vacation for a few days and checking my mail and have found an explosion of emails. Unfortunately most of them are duplicates. It seems the linaro-dev list isn't configed to avoid mailing folks who are already recipients of the email. So if you're on linaro-dev and you're also To/CC'ed in the email, you get it twice (three times if your other work email was CC'ed as well, but that cannot be helped). Is this something that can be easily resolved? I really don't know much about maillist servers, but I do know I've not had this issue on other mailing lists. So it should be possible. Thoughts? (but don't CC me! :) -john

14 years, 10 months

[PATCH 0/3] Extend SDHCI support for Origen board

by Tushar Behera

Patch 1: It fixes the incorrect card detection type. Patch 2: It enables secondary MMC port. Patch 3: It extends support of 8-bit bus width The patches are rebased to for-next branch of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git Tushar Behera (3): ARM: EXYNOS4: Fix sdhci card detection for ORIGEN ARM: EXYNOS4: Add support for secondary MMC port on ORIGEN ARM: EXYNOS4: Add support for 8-bit bus width in SDHCI for ORIGEN arch/arm/mach-exynos4/Kconfig | 1 + arch/arm/mach-exynos4/mach-origen.c | 19 ++++++++++++++++--- 2 files changed, 17 insertions(+), 3 deletions(-) -- 1.7.4.1

14 years, 10 months

11.07 oprofile on panda busted?

by Tom Gall

Hi all, Say has anyone else run oprofile on recent builds on panda? By recent I mean say anything since 11.07? Reason for asking is I'm seeing basically a very very small number of samples being recorded... as in there's no way this is right. Log: root@linaro-desktop:/home/linaro/ltj-1.1.90-d# opcontrol --reset Signalling daemon... done root@linaro-desktop:/home/linaro/ltj-1.1.90-d# opcontrol --start Profiler running. root@linaro-desktop:/home/linaro/ltj-1.1.90-d# ./djpeg ~linaro/Saturn.jpg > /dev/null Decoding took 1216 ms root@linaro-desktop:/home/linaro/ltj-1.1.90-d# ./djpeg ~linaro/Saturn.jpg > /dev/null Decoding took 1206 ms root@linaro-desktop:/home/linaro/ltj-1.1.90-d# root@linaro-desktop:/home/linaro/ltj-1.1.90-d# ./djpeg ~linaro/Saturn.jpg > /dev/null Decoding took 1207 ms root@linaro-desktop:/home/linaro/ltj-1.1.90-d# ./djpeg ~linaro/Saturn.jpg > /dev/null Decoding took 1212 ms root@linaro-desktop:/home/linaro/ltj-1.1.90-d# opcontrol --stop Stopping profiling. root@linaro-desktop:/home/linaro/ltj-1.1.90-d# opreport -l ./djpeg Overflow stats not available CPU: CPU with timer interrupt, speed 0 MHz (estimated) Profiling through timer interrupt samples % symbol name 1 100.000 put_pixel_rows I'll pull the latest and retry still, this I think is the11.07 ubuntu-desktop LEB release for panda (or pretty close) uname -a Linux linaro-desktop 3.0.0-1001-linaro-omap #1~ppa~natty-Ubuntu SMP PREEMPT Mon Jul 25 22:44:36 UTC 2011 armv7l armv7l armv7l GNU/Linux Thanks! -- Regards, Tom "We want great men who, when fortune frowns will not be discouraged." - Colonel Henry Knox 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

14 years, 10 months

Re: [PATCH] RFCv2: video support for dri2 (Rob Clark)

by Christian König

Hi Rob, > + flipping between multiple back buffers, perhaps not in order (to > handle video formats with B-frames) Oh, yes please. The closed source drivers seems to do this also all the time, and I never really understood why DRI is limiting the buffers to the OGL attachment points. ... > Current solutions use the GPU to do a scaled/colorconvert into a DRI2 > buffer from the client context. The goal of this protocol change is > to push the decision to use overlay or GPU blit to the xorg driver. You left one corner case out, HDMI allows for the framebuffer to be in YUV 4:4:4 format. So it is possible to send YUV data to the display (usually a TV) without color conversion at all, but I think with the current state of X we are years away from that. ... > In many cases, an overlay will avoid several passes through memory > (blit/scale/colorconvert to DRI back-buffer on client side, blit to > front and fake-front, and then whatever compositing is done by the > window manager). On the other hand, overlays can often be handled > directly by the scanout engine in the display hardware, with the GPU > switched off. Actually AMD has thrown out the hardware support for overlay with the R7xx (or was it evergreen?) series, because they got support for turning shader pipes off separately and figured out that it use less power to turn off all shaders except one and then use this one for color conversion and scaling, compared to having a distinct hardware block doing the job. But there are tendencies to get a distinct color conversion block back again. ... > Note: video is not exactly the same as 3d, there are a number of other > things to consider (scaling, colorconvert, multi-planar formats). But > on the other hand the principle is similar (direct rendering from hw > video codecs). And a lot infrastructure of connection, authentication, > is same. So there are two options, either extend DRI2 or add a new > protocol which duplicates some parts. I'd like to consider extending > DRI2 first, but if people think the requirements for video are too > much different from 3d, then I could split this into a new protocol. If you ask me extending things seems the better way to do this. .. > @@ -184,6 +185,11 @@ DRI2ATTACHMENT { DRI2BufferFrontLeft > These values describe various attachment points for DRI2 > buffers. > > + In the case of video driver (DRI2DriverXV) the attachment, > + other than DRI2BufferFrontLeft, just indicates buffer > + number and has no other special significance. There is no > + automatic maintenance of DRI2BufferFakeFrontLeft. I think that will created compatibility problems with existing implementations, because the DDX side doesn't know if it's talking to a video or 3D client side. ... > + The "XV_OSD" attribute specifies the XID of a pixmap containing > + ARGB data to be non-destructively overlayed over the video. This > + could be used to implement subtiles, on-screen-menus, etc. Why an XID? I'm not 100% sure about it, but using a DRI buffer name directly here seems to be the better alternative. > > Are you targeting/limiting this to a particular API (or the customary > > limitations of overlay HW)? I ask because VDPAU allows clients to pass > > in an arbitrary colour conversion matrix rather than color > > standard/hue/sat/bri/con, so it wouldn't be possible to use this in > > that context. > > Ideally it would something that could be used either from > device-dependent VDPAU or VAAPI driver back-end, or something that > could be used in a generic way, for example GStreamer sink element > that could be used with software codecs. AFAIK DRI mostly isn't a device driver dependent protocol, and the client side doesn't necessary know to which hardware it is talking, just look at how gallium 3D is working, talking with X over the DRI protocol is part of the driver independent state tracker, and NOT part of the driver itself. So having this driver independent is just a must have, and not optional. > Well, this is the goal anyways. There is one slight other > complication for use in a generic way.. it would need to be a bit > better defined what the buffer 'name' is, so that the client side > would know how to interpret it, mmap it if needed. But I think there > is a solution brewing: > http://lists.linaro.org/pipermail/linaro-mm-sig/2011-August/000509.html That's indeed true, but currently it is the only parameter that must be interpreted in a driver dependent fashion. And I really think it should stay that way. > As far as color conversion matrix... well, the attribute system can > have arbitrary device-dependent attributes. In the VDPAU case, I > suppose the implementation on the client side knows which xorg driver > it is talking to, and could introduce it's own attributes. Perhaps a > bit awkward for communicating a matrix, but you could in theory have > 4*3 different attributes (ie. XV_M00, XV_M01, ... XV_M23) for each > entry in the matrix. Yes, but you should define that clearly in the protocol, we also need something to make the client side know what is supported: individual values or matrix or both? > > Also in general, their compositing API is a lot more > > flexible and allows for a background + multiple layers, rather than > > just a single layer. I suppose you could pre-flatten the layers into a > > single one, but the background would be problematic. > > Yeah, pre-flatten into a single layer, I think. I mean, we *could* > push that to xorg driver side too, but I was trying to not make things > overly complicated in the protocol. > > I'm not sure I caught the issue about background.. or are you > thinking about video w/ AYUV? Is there any hw out there that supports > overlays w/ YUV that has an alpha channel? If this is enough of a > weird edge case, maybe it is ok to fall back in these cases to the old > way of doing the blending on the client side and just looking like a > 3d app to the xorg side. (I suspect in this sort of case you'd end up > falling back to the GPU on the xorg side otherwise.) But I'm always > interested to hear any other suggestions. VDPAU indeed defines two YUVA formats you can use, but currently I haven't seen anybody using the background picture functionality so far, because there are just not so much YUVA videos around. Christian.

14 years, 10 months

Preliminary wiki starting page for i.MX53 QuickStart board

by Eric Miao

https://wiki.linaro.org/Boards/MX53QuickStart Sorry guys, although been pushed and pinged several times by various people we are finally able to come up with a preliminary starting page for i.MX53 QuickStart board. It's currently very simple, and hopefully we'll get it more detailed in the future. Feedback is welcome! Thanks - eric

14 years, 10 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev