On Sat, Feb 12, 2011 at 7:06 PM, Amit Daniel Kachhap
wrote:
> Enabling the macro CONFIG_PM_DEBUG is causing compilation error as all PM
> components
> are included which is not in mainline for samsung V310 platform, therefore,
> this patch
> removes the dependency on macro CONFIG_PM_DEBUG for cl
Enabling the macro CONFIG_PM_DEBUG is causing compilation error as all PM
components
are included which is not in mainline for samsung V310 platform, therefore,
this patch
removes the dependency on macro CONFIG_PM_DEBUG for clock debugging through
debugfs
interface.
Signed-off-by: Amit Daniel K
I'm investigating the powerdebug tool on all platforms for which there
is a Linaro image.
Can anyone with boards imx51, lt-s5pv310, overo and vexpress provide
access for a short period of time?
___
linaro-dev mailing list
linaro-dev@lists.linaro.or
Steve,
Forwarding to linaro-dev since this might be of general interest.
Here is an experimental version of a thermal manager that allows us to
take appropriate actions in case of overheating. Since temperature
changes relatively slowly, the implementation is in userspace. If
you're interested in
Greetings,
Enclosed you'll find a link to the agenda, minutes and actions from the
Linaro kernel working group weekly meeting of Feb 07, 2011.
https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Meetings/2011-02-07
=== Summary ===
* Redesigned flash remapper and started implementing UBD
Greetings,
Enclosed you'll find a link to the agenda, minutes and actions from the
Linaro toolchain working group weekly meetings of Feb 07 & Feb 09, 2011.
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2011-02-07
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2011-02-09
On Wed, Feb 09, 2011 at 05:31:07PM +0100, Arnd Bergmann wrote:
> Ok. This sounds like a lot of upfront work indeed, to make KMS more
> generic, though I think a number of driver would benefit from it
> eventually. It could be something for the Linaro graphics working
> group to look at in the follo
Hi,
This is a message sent out once per week to call on our community to
help test the Linaro evaluation builds we produce. If you have supported
hardware, as found on:
http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/
please help our initiative by testing:
Headless:
http://snapshots.
On 10 February 2011 05:41, David Gilbert wrote:
> On 10 February 2011 13:14, Mirsad Vojnikovic
> wrote:
> >
> >
> > On 10 February 2011 04:30, David Gilbert
> wrote:
>
> >> OK, there were a few cases I was thinking here:
> >> 1) A batch of new machines arrives in the data centre; they are
> >
On 10 February 2011 13:14, Mirsad Vojnikovic
wrote:
>
>
> On 10 February 2011 04:30, David Gilbert wrote:
>> OK, there were a few cases I was thinking here:
>> 1) A batch of new machines arrives in the data centre; they are
>> apparently
>> identical - you want to run a benchmark on them all a
On 10 February 2011 04:30, David Gilbert wrote:
> On 10 February 2011 12:19, Mirsad Vojnikovic
> wrote:
> > That I wrote:
>
> >> I'd like to add as user stories:
> >> Dave wants to rerun a test on a particular machine to see if a
> >> failure is machine specific.
> >
> > An initial idea we h
On 10 February 2011 12:19, Mirsad Vojnikovic
wrote:
That I wrote:
>> I'd like to add as user stories:
>> Dave wants to rerun a test on a particular machine to see if a
>> failure is machine specific.
>
> An initial idea we had was to run jobs based on machine type, i.e.
> BeagleBoard, not on a
On 7 February 2011 02:05, David Gilbert wrote:
> On 4 February 2011 21:53, Paul Larson wrote:
> >
> > Hi Mirsad, I'm looking at the recent edits to
> > https://wiki.linaro.org/Platform/Validation/Specs/ValidationSchedulerand
> > wanted to start a thread to discuss. Would love to hear thoughts f
On 4 February 2011 13:53, Paul Larson wrote:
>
> Hi Mirsad, I'm looking at the recent edits to
> https://wiki.linaro.org/Platform/Validation/Specs/ValidationScheduler and
> wanted to start a thread to discuss. Would love to hear thoughts from
> others as well.
>
> We could probably use some more
On Thu, Feb 10, 2011, Wookey wrote:
> Loic Minier in October last year, to libtool list
> http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/7626
> (response: yes that seems to be a bug, no time to fix now, does sysroot
> option fix it? 'Not for me' said lool)
FTR, I just tried libtool.git, and
> Regarding using V4L to communicate with DSPs/other processors: that too
> could be something for Linaro to pick up: experiment with it for one
> particular
> board, see what (if anything) is needed to make this work. I expect it to be
> pretty easy, but again, nobody has actually done the initia
On Thursday, February 10, 2011 08:17:31 Linus Walleij wrote:
> Thanks for the help Harald, much appreciated.
>
> On Wed, Feb 9, 2011 at 8:44 PM, Harald Gustafsson
> wrote:
>
> > OMX main purpose is to handle multimedia hardware and offer an
> > interface to that HW that looks identical indenpend
[This was also posted to debian-devel but I got the linaro addesss
wrong: http://lists.debian.org/debian-devel/2011/02/msg00196.html]
Libtool is intended to make library linking 'just work' whatever the
details of your build mechanisms are.
However in Debian/Ubuntu cross-building it seems to go
> Ah I think there is a misunderstanding here, damn these TLA:s.
>
> STM in U8500 == ST-Ericsson System Trace Module
> STM in coresight == ARM System Trace Macrocell
Right... I've just nearly died laughing... ;-)
We could have discussed technical details for a looong time then :-)
Thanks for be
On Thursday 10 February 2011 08:17:31 Linus Walleij wrote:
>
> > OMX main purpose is to handle multimedia hardware and offer an
> > interface to that HW that looks identical indenpendent of the vendor
> > delivering that hardware, much like the v4l2 or USB subsystems tries to
> > do. And yes optim
20 matches
Mail list logo
