Here is my workaround for now. I brought forward the dt support from 3.0.
git://git.linaro.org/ubuntu/linux-linaro-precise.git
001947f dt: Linux dt usage model documentation
b5f9d90 arm/dt: vexpress: add basic DT platform matching support
b2b9f46 arm/dt: Add basic devicetree support to IGEPv2 and
On Thu, Oct 20, 2011 at 7:44 PM, Nicolas Pitre wrote:
> On Thu, 20 Oct 2011, John Rigby wrote:
>
>> This tree seems to be missing per board dt support so booting with a
>> device tree doesn't seem to work. Need something like for example
>> this commit that added it for panda in the 3.0 tree:
>>
On Thu, 20 Oct 2011, John Rigby wrote:
> This tree seems to be missing per board dt support so booting with a
> device tree doesn't seem to work. Need something like for example
> this commit that added it for panda in the 3.0 tree:
>
> commit d24e9a194c2ed4ca56b8f4e7d96038cd3af3fda8
> Author: G
Enclosed please find the link to the Weekly Status report
for the kernel working group for the week ending 2011-10-21
== Meeting Minutes ==
https://wiki.linaro.org/WorkingGroups/Kernel/Meetings/2011-10-17
== Weekly Status Report ==
https://wiki.linaro.org/WorkingGroups/Kernel/Status/2011-10-20
On Thu, 20 Oct 2011, Nicolas Pitre wrote:
> On Thu, 20 Oct 2011, john stultz wrote:
>
> > On Thu, 2011-10-20 at 03:11 -0700, Deepak Saxena wrote:
> > > The Linaro Kernel Working Group (KWG) is excited to announce the
> > > availability our October 2011 development snapshot:
> > >
> > > linux-lin
On Thu, 20 Oct 2011, john stultz wrote:
> On Thu, 2011-10-20 at 03:11 -0700, Deepak Saxena wrote:
> > The Linaro Kernel Working Group (KWG) is excited to announce the
> > availability our October 2011 development snapshot:
> >
> > linux-linaro-3.1-2011.10-1
> >
> > As the word "snapshot" implies
On Thu, 2011-10-20 at 03:11 -0700, Deepak Saxena wrote:
> The Linaro Kernel Working Group (KWG) is excited to announce the
> availability our October 2011 development snapshot:
>
> linux-linaro-3.1-2011.10-1
>
> As the word "snapshot" implies, these are meant as development kernels
> and have not
This tree seems to be missing per board dt support so booting with a
device tree doesn't seem to work. Need something like for example
this commit that added it for panda in the 3.0 tree:
commit d24e9a194c2ed4ca56b8f4e7d96038cd3af3fda8
Author: Grant Likely
Date: Tue Jul 5 23:42:31 2011 -0600
On 20 October 2011 23:22, Michael Hope wrote:
> On Fri, Oct 21, 2011 at 11:16 AM, Mans Rullgard
> wrote:
>> On 20 October 2011 23:07, Michael Hope wrote:
>>> On Fri, Oct 21, 2011 at 7:48 AM, James Tunnicliffe
>>> wrote:
This isn't exactly overflowing with up to date numbers, but...
>>
On 20 October 2011 23:22, Michael Hope wrote:
> On Fri, Oct 21, 2011 at 11:16 AM, Mans Rullgard
> wrote:
>> On 20 October 2011 23:07, Michael Hope wrote:
>>> On Fri, Oct 21, 2011 at 7:48 AM, James Tunnicliffe
>>> wrote:
This isn't exactly overflowing with up to date numbers, but...
>>
On Fri, Oct 21, 2011 at 11:16 AM, Mans Rullgard
wrote:
> On 20 October 2011 23:07, Michael Hope wrote:
>> On Fri, Oct 21, 2011 at 7:48 AM, James Tunnicliffe
>> wrote:
>>> This isn't exactly overflowing with up to date numbers, but...
>>>
>>> http://elinux.org/images/8/8a/Experiment_with_Linux_an
On 20 October 2011 23:07, Michael Hope wrote:
> On Fri, Oct 21, 2011 at 7:48 AM, James Tunnicliffe
> wrote:
>> This isn't exactly overflowing with up to date numbers, but...
>>
>> http://elinux.org/images/8/8a/Experiment_with_Linux_and_ARM_Thumb-2_ISA.pdf
>>
>> Slides 14 and 15 say that across EE
On Fri, Oct 21, 2011 at 7:48 AM, James Tunnicliffe
wrote:
> This isn't exactly overflowing with up to date numbers, but...
>
> http://elinux.org/images/8/8a/Experiment_with_Linux_and_ARM_Thumb-2_ISA.pdf
>
> Slides 14 and 15 say that across EEMBC Thumb-2 gives 98% of the
> performance of ARM 32 bit
On Thu, 20 Oct 2011, Amit Kachhap wrote:
> Hi Nicolas,
>
> This is a request to pull L2 retention cpuidle implementation from
> git://git.linaro.org/people/amitdanielk/linux.git (branch-
> samsung_cpuidle_l2_retention)
>
> The top 5 patches on this refers to the work and this is heavily based
>
And also the first Working Group to have a new roadmap card moved into Accepted!
On Thu, Oct 20, 2011 at 2:08 PM, Mounir Bsaibes
wrote:
> Enclosed please find the link to the Weekly Status report
> for the Power Management working group for the week ending 2011-10-20
>
> == Meeting Minutes ==
>
Enclosed please find the link to the Weekly Status report
for the Power Management working group for the week ending 2011-10-20
== Meeting Minutes ==
https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2011-10-19
== Weekly Status Report ==
https://wiki.linaro.org/WorkingGroups/PowerM
On 20 October 2011 18:27, Christian Robottom Reis wrote:
> - Do we know how much better Thumb-2 actually is, in practice? It's
> easy for us to confirm this on Android; what do the numbers and
> feel of the system tell us?
I did some tests comparing Libav built for ARM and Thumb-2.
This isn't exactly overflowing with up to date numbers, but...
http://elinux.org/images/8/8a/Experiment_with_Linux_and_ARM_Thumb-2_ISA.pdf
Slides 14 and 15 say that across EEMBC Thumb-2 gives 98% of the
performance of ARM 32 bit instructions (assume performance optimised)
and binaries are 26% sma
Linus Walleij wrote at Thursday, October 20, 2011 4:25 AM:
> On Thu, Oct 20, 2011 at 1:04 AM, Stephen Warren wrote:
...
> >> + * @PIN_CONFIG_BIAS_HIGH_IMPEDANCE: the pin will be set to a high
> >> impedance
> >> + * mode, also know as "third-state" (tristate) or "high-Z" or
> >> "floating".
>
Linus Walleij wrote at Thursday, October 20, 2011 7:44 AM:
> On Thu, Oct 20, 2011 at 4:45 AM, Shawn Guo wrote:
>
> > We should not require device driver to call these APIs directly. There
> > are so many pinctrl subsystem internal details left to its users.
>
> As explained I already have drive
So its basically like Sunday ;)
As a point of interest here's how I cut the builds.
I boot each tip:
~linaro-android/staging-origen
~linaro-android/staging-panda
~linaro-android/staging-imx53
~linaro-android/staging-snowball
~linaro-android/landing-snowball
~linaro-android/tracking-panda
~linar
Hi Christian,
I'm currently working on Origen WIFI and USB Ethernet topics with Samsung
landing team.
WIFI works now, but not stable enough. You can find the detailed information
at this link:
https://bugs.launchpad.net/linaro-android/+bug/851006
USB Ethernet adapter "basically works", because
Hi Kiko,
These are all excellent questions and I for one would be keen to see a position
on this.
How would it be captured and the output published?
Ta
Sent from yet another ARM powered device
On 20 Oct 2011, at 18:30, "Christian Robottom Reis" wrote:
> Hello there,
>
>Coming back from
Hello there,
Coming back from Asia I've been putting a lot of thought about how
we can make sure we spend our engineering cycles on the work that is
most valuable to the current Linaro members, and part of that means
reassessing assumptions that we've carried since our foundation.
The first p
Shawn Guo wrote at Wednesday, October 19, 2011 8:32 PM:
> On Wed, Oct 19, 2011 at 06:21:14PM +0200, Linus Walleij wrote:
...
> > +int pin_config_group(struct pinctrl_dev *pctldev, const char *pin_group,
> > +enum pin_config_param param, unsigned long data)
...
> > +enum pin_config_p
On Thu, Oct 20, 2011 at 01:15:01PM +0200, Tony Mansson wrote:
> * libjpeg-turbo has been benchmarked against the original Android
> libjpeg implementation. https://wiki.linaro.org/TomGall/LibJpegTurbo
This is now impressive enough that I think it's time for us to start
promoting this in the Andro
On Wed, Oct 19, 2011 at 09:19:49AM +0300, Fathi Boudra wrote:
> linaro-media-create/linaro-android-media-create command line options are now
> using dashes to separate words instead of underscores.
Woot, nice catch fixing it before I even complained! Thanks guys,
--
Christian Robottom Reis, Engin
Howdy,
The project managers are working on a few interesting sessions for
Connect. If you are interested please subscribe and attend the
sessions.
1) Mapping Upstream Development to Blueprints, Work Items, Roadmaps, etc.
https://blueprints.launchpad.net/linaro/+spec/linaro-general-upstream-proc
On Thu, Oct 20, 2011 at 04:43:30PM +0200, Linus Walleij wrote:
> On Thu, Oct 20, 2011 at 4:18 PM, Mark Brown
> > The other question is if it's worth bouncing through too much of an
> > abstraction layer when both ends of the API are fixed.
> If drivers doing pinctrl are used in more than one SoC
On Thu, Oct 20, 2011 at 4:18 PM, Mark Brown
wrote:
> On Thu, Oct 20, 2011 at 04:04:47PM +0200, Linus Walleij wrote:
>> I think (and of course this may be completely wrong, but it's my
>> working hypthesis) that the things that software wants to do to
>> pins are:
>
> The other question is if it's
On Thu, Oct 20, 2011 at 04:04:47PM +0200, Linus Walleij wrote:
> I think (and of course this may be completely wrong, but it's my
> working hypthesis) that the things that software wants to do to
> pins are:
The other question is if it's worth bouncing through too much of an
abstraction layer whe
On Thu, Oct 20, 2011 at 3:10 PM, Shawn Guo wrote:
>> without the common definition from PIN_CONFIG_PULL to
>> PIN_CONFIG_USER, many platforms will need to definite them repeatedly.
>> that is what we hate.
>>
> I prefer to completely leave the encoding of this 'u32 param' to pinctrl
> drivers, s
On Thu, Oct 20, 2011 at 11:17 AM, Barry Song <21cn...@gmail.com> wrote:
> [Shawn]
>> I like Stephen's idea about having 'u32 param' and let pinctrl drivers
>> to encode/decode this u32 for their pinctrl controller. It makes
>> people's life much easier.
>
> A multifunctional API is actually a bad
On Thu, Oct 20, 2011 at 4:45 AM, Shawn Guo wrote:
> There
> are so many pinctrl subsystem internal details left to its users.
The idea is indeed to provide facilities to help with setting up
default configuration
for pins like we set up default pinmux maps. It's not been coded yet though,
atlea
On Thu, Oct 20, 2011 at 4:45 AM, Shawn Guo wrote:
> We should not require device driver to call these APIs directly. There
> are so many pinctrl subsystem internal details left to its users.
As explained I already have drivers that need to do this. OK they
are out-of-tree, but they do exist.
F
On Thu, Oct 20, 2011 at 05:17:08PM +0800, Barry Song wrote:
> >> +enum pin_config_param {
> >> + PIN_CONFIG_BIAS_UNKNOWN,
> >> + PIN_CONFIG_BIAS_FLOAT,
> >> + PIN_CONFIG_BIAS_HIGH_IMPEDANCE,
> >> + PIN_CONFIG_BIAS_PULL_UP,
> >> + PIN_CONFIG_BIAS_PULL_DOWN,
> >> + PIN_CONFIG_
Key Points for wider discussion
===
* The gerrit review bot has been deployed. Changes submitted and
approved in Gerrit get built in Android Build, then verified in LAVA,
with resulting status propagated back to Gerrit.
* All strict-aliasing violations in 2.3.5 have be
On Thu, Oct 20, 2011 at 1:04 AM, Stephen Warren wrote:
>> +/**
>> + * enum pin_config_param - possible pin configuration parameters
>> + * @PIN_CONFIG_BIAS_UNKNOWN: this bias mode is not known to us
>
> I'm not sure what use that would be; shouldn't we remove that, and add
> new PIN_CONFIG_BIAS_*
The Linaro Kernel Working Group (KWG) is excited to announce the
availability our October 2011 development snapshot:
linux-linaro-3.1-2011.10-1
As the word "snapshot" implies, these are meant as development kernels
and have not been fully validated. You should expect issues and to help
us deliver
On Thu, Oct 20, 2011 at 11:46 AM, Barry Song <21cn...@gmail.com> wrote:
> 2011/10/20 Stephen Warren :
>> A pin controller's pin definitions are used both during pinctrl_register()
>> and pinctrl_unregister(). The latter happens outside of __init/__devinit
>> time, and hence it is unsafe to mark th
On Thu, Oct 20, 2011 at 12:19 AM, Stephen Warren wrote:
> Instead, store a pointer to the currently assigned function.
>
> This allows us to delete the mux_requested variable from pin_desc; a pin
> is requested if its currently assigned function is non-NULL.
>
> When a pin is requested as a GPIO
2011/10/20 Stephen Warren :
> A pin controller's pin definitions are used both during pinctrl_register()
> and pinctrl_unregister(). The latter happens outside of __init/__devinit
> time, and hence it is unsafe to mark the pin array as __refdata.
Thanks.
Acked-by: Barry Song
missed this when por
On Thu, Oct 20, 2011 at 12:19 AM, Stephen Warren wrote:
> A pin controller's names array is no longer marked __refdata. Hence, we
> can avoid copying a pin's name into the descriptor when registering it.
> Instead, just point at the string supplied in the pin array.
>
> This both simplifies and s
On Thu, Oct 20, 2011 at 12:19 AM, Stephen Warren wrote:
> A pin controller's pin definitions are used both during pinctrl_register()
> and pinctrl_unregister(). The latter happens outside of __init/__devinit
> time, and hence it is unsafe to mark the pin array as __refdata.
>
> Signed-off-by: Ste
On Thu, Oct 20, 2011 at 12:19 AM, Stephen Warren wrote:
> get_group_pins() "returns" a pointer to an array of const objects, through
> a pointer parameter. Fix the prototype so what's pointed at by the returned
> pointer is const, rather than the function parameter being const.
>
> This also allo
http://www.maxtrack.com.br/produtos/produto.php?cod=1
FYI.
BTW,Does Android/Kernel can support High real-time feature?
B.R
Tommy
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Tue, Oct 18, 2011 at 8:02 PM, Stephen Warren wrote:
> [Me]
>> 1) The need to configure per-pin "stuff" like biasing, driving,
>> load capacitance ... whatever
I sent of a proposal for this so we get somewhere...
>> 2) The need to handle state transitions of pinmux settings.
Still uncertain
2011/10/20 Shawn Guo :
>> #ifdef CONFIG_DEBUG_FS
>>
>> static int pinctrl_pins_show(struct seq_file *s, void *what)
>> diff --git a/include/linux/pinctrl/pinctrl.h
>> b/include/linux/pinctrl/pinctrl.h
>> index 4f8d208..189c047 100644
>> --- a/include/linux/pinctrl/pinctrl.h
>> +++ b/include/linu
Adding the SHAID for the commits.
1)c3d9c1725dfdb595d6054a123222faff81b2d06b
2)1126792e47c4282fa9d9e491c18e7f6b933ca642
3)ece51a25086cfabd291b9122552dcefb70145620
4)d162be5c4a29161d727bb71bfcb27f1fdc1a3b0e
5)2ddd7157a90d8c0ad05cdb7a60fdfb7101eaebc2
Thanks,
Amit Daniel
Linaro PMWG member
On 20 O
Hi Nicolas,
This is a request to pull L2 retention cpuidle implementation from
git://git.linaro.org/people/amitdanielk/linux.git (branch-
samsung_cpuidle_l2_retention)
The top 5 patches on this refers to the work and this is heavily based
on Russell's rmk-next tree. So if it is possible to take t
50 matches
Mail list logo
