linaro-dev September 2011

linaro-dev@lists.linaro.org

149 participants
200 discussions

Sept 14th struct_clk discussion meetings notes

by Deepak Saxena

A group of us met at Linux Plumber's Conf two weeks ago to discuss struct clk and how we move forward with it. Several of us had a follow up phone call last week, on Wed the 14th, and what follows are meeting notes from this follow up discussion (I've seem to have lost the notepad on which I took notes during the LPC discussion). Attendees: Arnd Bergman Stephen Boyd Mark Brown Thomas Gleixner Shawn Guo Saravana Kannan Nicolas Pitre Mike Turquette Linus Walleij Paul Walmsley - Mike T. - Remove set_parent and upstream clock arbitration - Functionality is limited, but would work for OMAP as is - We can add new features as needed - Shawn - Does not want to block new SoC support due to common clock support not being ready. This is gating mx6 support being merged upstream. - Arnd - Pre-req: Device Tree representation of struct clk before we let these patches in. - Mike T: Can we split the problems. - Arnd: Yes? - Thomas: Is not entirely separate. Current patches are not enough to do actual representation of building blocks. Need more than just the ops pointer structure. Will look into what it would take the current patches and then slowly add changes to building block. - Stephen - Want 1 tree lock instead of a framework lock: + Have 2 trees, 1 fast (1ms), 1 really slow (5ms) - Thomas: Should be trivial to implement - Once the traverse code is fixed, will be hard to change the locking code, so need to get this right. - Thomas: Need a clock tree base with its own lock and put a struct clk tree into that tree base. - Paul W.: How rate propagation would work across bases? - Thomas: Should be doable with proper locking order, and should not be too hard to solve. Non fast path. - Can implement separate root clocks for right now - tglx: separate struct clk from building block devices such as frequency management. - Paul W. - Have multiple root clocks, but only one lock right now - Figure out the scope of the patches to be. Goal: get basic support for common struct clk upstream. Get imx6 upstream w/o common struct clk Has some bugs and races on existing code. set_rate: Can parents be switched at same time? operate under set_rate and set_parent as distinct operations. clk_rate sample implementation: will only work in some limited cases. Need to guarantee that clock is stable. There are lot of hw specific that may not be possible to abstract. Not true: "All parents are equal and should be treated the same" during set_rate. From tglx: Looked at existing stuff and noted that a lot of implementations share concepts... walking a freq table or a divisor table. Paul: Agree, can go into some sort of library code down the road. in-tree vs out-of-tree: what's shipping on most device is quite a bit more hacky and complex than what is currently in mainline. Will need clock notifiers before being able to use on real shipping devices. Much code that calls clk_set_rate() assumes that code will not be changed in the future. Patch 1: good Patch 2: needs a bit more thought Patch 3: no comments yet What do people think about having initial patches to convert to using common clk struct but having sub-arch specific set_rate and get_rate? General consensus: seems like a good idea. - Linus W.: No major comments - Nicolas: Just listening in to understand the issues involved. ACTION ITEMS: - Thomas: will post updated patches by end of the week - Others: Will post initial patches porting their platforms to new patches as follow up. - Deepak: Organize follow up call in two weeks and post to wider audience to attend.

13 years, 3 months

HDMI on Overo with Linaro ALIP

by AJ ONeal

I've got a tobi board with HDMI, I just put in the ALIP image and plugged it into my TV for the first time, but I get nothing (but I'm also plugged in via serial and see that it boots completely). So I try X -configure and I get No devices to configure. Configuration failed. ddxSigGiveUp: Closing log I googled a bit, but I must not have the right terms. It's been years since I've had to configure X. Is there some special setup or a tutorial for this? AJ ONeal

13 years, 3 months

[Activity] Kernel WG Weekly Status report for week ending 2011-09-16

by Mounir Bsaibes

Enclosed please find the link to the Weekly Status report for the kernel working group for the week ending 2011-09-16 == Meeting Minutes == https://wiki.linaro.org/WorkingGroups/Kernel/Meetings/2011-09-12 == Weekly Status Report == https://wiki.linaro.org/WorkingGroups/Kernel/Status/2011-09-15 == Summary == * [i.mx6Q] Posted the first version of I.MX6Q patch series. In addition, suspend support now can work with generic cpu_suspend/resume without needing to flush entire L2 cache. * [Exynos4] Submitted device tree support patches for Exynos4 keypad controller driver * [PL330] Rebased DT patches for pl330 dma controller driver on top of pl330 driver update patches and tested it. * Got 10 platforms to build 97% of time with Randconfig, the randconfig potentially can be used to do all sorts of testing like validation, regression testing, etc.... * Sent RMK a pull request for a huge series eliminating most instances of mach/memory.h * V6/v7 single kernel Thumb-2 undef fixup patches * Arnd pulled patches from various soc maintainers, after finally moving the tree over to git.linaro.org (temporary while git.kernel.org is down). * Arnd published a short article on lwn.net about hexagon and c64x architecture -> http://lwn.net/Articles/457635/ 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>

13 years, 3 months

ioctl ABI considerations for 64b ARM?

by Rob Clark

I don't suppose there are any guidelines from ARM about compatibility between 32bit userspace and 64bit kernel on some hypothetical future version of the ARM architecture? Some hints about what to do or not do could perhaps save some ioctl compat glue later on down the line.. BR, -R ---------- Forwarded message ---------- From: Rob Clark <rob.clark(a)linaro.org> Date: Sun, Sep 18, 2011 at 3:15 PM Subject: Re: [PATCH] RFCv2: omapdrm DRM/KMS driver for TI OMAP platforms To: Thomas Hellstrom <thomas(a)shipmail.org> Cc: Inki Dae <inki.dae(a)samsung.com>, dri-devel(a)lists.freedesktop.org, patches(a)linaro.org On Sun, Sep 18, 2011 at 3:00 PM, Thomas Hellstrom <thomas(a)shipmail.org> wrote: > On 09/18/2011 09:50 PM, Rob Clark wrote: >> >> On Sun, Sep 18, 2011 at 2:36 PM, Thomas Hellstrom<thomas(a)shipmail.org> >> wrote: >> >>> >>> On 09/17/2011 11:32 PM, Rob Clark wrote: >>> >>>> >>>> From: Rob Clark<rob(a)ti.com> >>>> [snip] >>>> >>>> diff --git a/include/drm/omap_drm.h b/include/drm/omap_drm.h >>>> new file mode 100644 >>>> index 0000000..ea0ae8e >>>> --- /dev/null >>>> +++ b/include/drm/omap_drm.h >>>> @@ -0,0 +1,111 @@ >>>> +/* >>>> + * linux/include/drm/omap_drm.h >>>> + * >>>> + * Copyright (C) 2011 Texas Instruments >>>> + * Author: Rob Clark<rob(a)ti.com> >>>> + * >>>> + * This program is free software; you can redistribute it and/or modify >>>> it >>>> + * under the terms of the GNU General Public License version 2 as >>>> published by >>>> + * the Free Software Foundation. >>>> + * >>>> + * This program is distributed in the hope that it will be useful, but >>>> WITHOUT >>>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY >>>> or >>>> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >>>> License >>>> for >>>> + * more details. >>>> + * >>>> + * You should have received a copy of the GNU General Public License >>>> along with >>>> + * this program. If not, see<http://www.gnu.org/licenses/>. >>>> + */ >>>> + >>>> +#ifndef __OMAP_DRM_H__ >>>> +#define __OMAP_DRM_H__ >>>> + >>>> +#include "drm.h" >>>> + >>>> +/* Please note that modifications to all structs defined here are >>>> + * subject to backwards-compatibility constraints. >>>> + */ >>>> + >>>> +#define OMAP_PARAM_CHIPSET_ID 1 /* ie. 0x3430, 0x4430, etc */ >>>> + >>>> +struct drm_omap_param { >>>> + uint64_t param; /* in */ >>>> + uint64_t value; /* in (set_param), out >>>> (get_param) >>>> */ >>>> +}; >>>> + >>>> +struct drm_omap_get_base { >>>> + char plugin_name[64]; /* in */ >>>> + uint32_t ioctl_base; /* out */ >>>> +}; >>>> >>>> >>> >>> What about future ARM 64-bit vs 32-bit structure sizes? On x86 we always >>> take care to make structures appearing in the drm user-space interfaces >>> having sizes that are a multiple of 64-bits, to avoid having to maintain >>> compat code for 32-bit apps running on 64 bit kernels. For the same >>> reasons, structure members with 64 bit alignment requirements on 64-bit >>> systems need to be carefully places. >>> >>> I don't know whether there is or will be a 64-bit ARM, but it might be >>> worth >>> taking into consideration. >>> >> >> There isn't currently any 64-bit ARM, but it is a safe assumption that >> there will be some day.. I guess we'll have enough fun w/ various >> random 32b devices when LPAE arrives w/ the cortex-a15.. >> >> I did try to make sure any uint64_t's were aligned to a 64bit offset, >> but beyond that I confess to not being an expert on how 64 vs 32b >> ioctl compat stuff is handled or what the issues going from 32->64b >> are. If there are some additional considerations that should be taken >> care of, then now is the time. So far I don't have any pointer fields >> in any of the ioctl structs. Beyond that, I'm not entirely sure what >> else needs to be done, but would appreciate any pointers to docs about >> how the compat stuff works. >> >> BR, >> -R >> > > I've actually avoided writing compat ioctl code myself, by trying to make > sure that structures look identical in the 64-bit and 32-bit x86 ABIs, but > the compat code is there to translate pointers and to overcome alignment > incompatibilities. > > A good way to at least try to avoid having to maintain compat code once the > 64-bit ABI shows up is to make sure that 64-bit scalars and embedded > structures are placed on 64-bit boundaries, padding if necessary, and to > make sure (using padding) that struct sizes are always multiples of 64 bits. So far this is true for 64bit scalars.. I'm using stdint types everywhere so there is no chance for fields having different sizes on 64b vs 32b. And the only structs contained within ioctl structs so far are starting at offset==0. Is it necessary to ensure that the ioctl structs themselves (as opposed to structs within those structs) have sizes that are multiple of 64b? The ioctl structs are copied (copy_from_user()/copy_to_user()), which I would have assumed would be sufficient? > But since there is no 64-bit ARM yet, it might be better to rely on using > compat code in the future than on making guesses about alignment > restrictions of the ABI... hmm, it might be nice to get some guidelines from ARM on this, since I really have no idea what a 64b ARM architecture would look like.. BR, -R > /Thomas > > > > > _______________________________________________ > dri-devel mailing list > dri-devel(a)lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >

13 years, 3 months

Export kernel defconfig through android-build

by Zach Pfeffer

I'm writing up some notes on building Android from scratch and replacing the kernel in an Android build from one built locally, and I realized that's it a bit of a chore to extract the kernel config that got used. I thought, it may make sense to provide an way in android-build to control what gets used - which would make finding this information easier since if would one of the configs that gets passed to the build like TARGET_PRODUCT. Thoughts? -- 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

13 years, 3 months

RE: LKML - Battery charge current issue

by Ashish Jangam

> -----Original Message----- > From: Mark Brown [mailto:broonie@opensource.wolfsonmicro.com] > Sent: Monday, September 19, 2011 3:56 PM > To: Ashish Jangam > Subject: Re: LKML - Battery charge current issue > > On Mon, Sep 19, 2011 at 06:26:10AM +0000, Ashish Jangam wrote: > > Questions like this should always be CCed to the list. > > > Some Power Management Controllers has a feature of configuring battery > > charge current for faster battery charging. > > > In the Linux power supply core there is no provision that can help the user > > for configuring battery charge current at "runtime". In current Linux > implementation > > this is done in battery "probe" probably using platform data. > > > Should an additional entry in sysfs be added for configuring battery charge > current > > since most of our clients desire such feature? > > This depends what you're looking to do. The specific currents used > should be configured using platform data, if the user gets these wrong > they can result in physical damage to the system so it's generally > undesirable to have userspace poking at them. The switch from trickle > to fast charge is normally managed automatically, often by hardware. > If there's absolutely no way to figure this out from kernel I guess a > userspace control would be OK but it'd be pretty surprising. Hardware that don't support/have automatic upgrade then, quick battery charge feature will be of no use to end user and especially in smart phone this could be problematic. If sysfs is not a good way of doing this then some alternate mechanism will be very much appreciated.

13 years, 3 months

Origen touchscreen problem

by Angus Ainslie

Hi, For the last few days I've been fighting what I thought was a touchscreen software problem with the Origen. I finally went back to a known good version and it didn't work either. I've figured out what happened to my board I'm just not sure why as there has been no mechanical stress on that connection. One of the connectors has become de-laminated so the signals aren't getting through. I've attached a picture with the area of the fault indicated. Applying pressure to the indicted area re-establishes the connection. Angus -- Angus Ainslie <angus.ainslie(a)linaro.org> Team Lead, Samsung Landing Team

13 years, 3 months

Try Linaro’s 11.09 Toolchain and our 2nd Android Release Candidate Based on It

by Zach Pfeffer

11.09 Release Canidate 2 is out! This is the second 11.09 Android release canidate. Each build has been built with the official Linaro 4.6 toolchain release: https://android-build.linaro.org/builds/~linaro-android/toolchain-4.6-2011.… (we track the tip toolchain which allowed us to release an update nearly co-incident with the toolchain group's official 11.09 release) Builds: https://android-build.linaro.org/builds/~linaro-android/beagle-11.09-releas… (Beagle, Beagle xM) https://android-build.linaro.org/builds/~linaro-android/stage-imx53-11.09-r… https://android-build.linaro.org/builds/~linaro-android/stage-snowball-11.0… https://android-build.linaro.org/builds/~linaro-android/stage-origen-11.09-… https://android-build.linaro.org/builds/~linaro-android/panda-11.09-release… https://android-build.linaro.org/builds/~linaro-android/stage-panda-11.09-r… Enjoy! Original post: http://www.linaro.org/linaro-blog/2011/09/19/try-linaros-11-09-toolchain-an… G+: https://plus.google.com/104422661029399872488/posts/EjKrMN1AGEk -- 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

13 years, 3 months

Linaro Boot up times.

by Sudhangathan B S

Hi Linaro'ers I need to boot Linaro in very short time as my project has a constraint on energy. The normal linaro boot up time is 2 minutes and 15 seconds on my overo fire. I did a little startup tweaks and achieved 2:00 minutes. Is there a way to boot up Linaro in under 40 sec. ?? This could include increasing CPU speeds or more OS tweaks.... Has anybody worked on this(Linaro boot up times) so far..?? Thanks & Regards. --------------------------------- Sudhangathan BS Ph:(+91) 9731-905-205 ---------------------------------

13 years, 3 months

[pm-qa 1/2] fix error in script

by Daniel Lezcano

Prevent a syntax error when running the test which leads to an exception in the script and exiting wildely the loop. The cpuburn stays running in background. Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> --- include/functions.sh | 14 ++++++++++++-- 1 files changed, 12 insertions(+), 2 deletions(-) diff --git a/include/functions.sh b/include/functions.sh index 2cc44b3..f003414 100644 --- a/include/functions.sh +++ b/include/functions.sh @@ -109,8 +109,18 @@ get_governor() { wait_latency() { local cpu=$1 local dirpath=$CPU_PATH/$cpu/cpufreq - local latency=$(cat $dirpath/cpuinfo_transition_latency) - local nrfreq=$(cat $dirpath/scaling_available_frequencies | wc -w) + local latency= + local nrfreq= + + latency=$(cat $dirpath/cpuinfo_transition_latency) + if [ $? != 0 ]; then + return $? + fi + + nrfreq=$(cat $dirpath/scaling_available_frequencies | wc -w) + if [ $? != 0 ]; then + return $? + fi nrfreq=$((nrfreq + 1)) ../utils/nanosleep $(($nrfreq * $latency)) -- 1.7.4.1

13 years, 3 months

← Newer
1
...
7
8
9
10
11
12
13
...
20
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev September 2011