On 9/25/2012 7:34 AM, Rajagopal Venkat wrote:
>> On 09/24/2012 06:28 AM, Rajagopal Venkat wrote:
>>>
>>> This patch adds following minor changes to prepare powertop
>>> to support Android platform.
>>>
>>> - Add missing HAVE_CONFIG_H conditional check.
>>> - remove un-used ethtool_cmd_speed_set and
On 9/25/2012 7:34 AM, Rajagopal Venkat wrote:
>> On 09/24/2012 06:28 AM, Rajagopal Venkat wrote:
>>>
>>> This patch adds following minor changes to prepare powertop
>>> to support Android platform.
>>>
>>> - Add missing HAVE_CONFIG_H conditional check.
>>> - remove un-used ethtool_cmd_speed_set and
On 24 September 2012 21:27, Chris Ferron wrote:
> On 09/24/2012 06:28 AM, Rajagopal Venkat wrote:
>>
>> This patch adds following minor changes to prepare powertop
>> to support Android platform.
>>
>> - Add missing HAVE_CONFIG_H conditional check.
>> - remove un-used ethtool_cmd_speed_set and eth
With the tegra3 and the big.LITTLE [1] new architectures, several cpus
with different characteristics (latencies and states) can co-exists on the
system.
The cpuidle framework has the limitation of handling only identical cpus.
This patch removes this limitation by introducing the multiple driver
We want to support different cpuidle drivers co-existing together.
In this case we should move the refcount to the cpuidle_driver
structure to handle several drivers at a time.
Signed-off-by: Daniel Lezcano
---
drivers/cpuidle/driver.c | 13 -
include/linux/cpuidle.h |1 +
2 f
The discussion about having different cpus on the system with
different latencies bring us to a first attemp by adding a
pointer in the cpuidle_device to the states array.
But as Rafael suggested, it would make more sense to create a
driver per cpu [1].
This patch adds support for multiple cpuidl
The code checks if the driver is already set without taking the lock,
but, right after, it takes the lock to assign the variable.
If it is safe to check the variable without lock, then it is safe to
assign it without lock. If it is unsafe to assign without a lock, then
it is unsafe to check it wit
This patch is a preparation for the multiple drivers support.
As the next patch will introduce the multiple drivers with the Kconfig
option and we want to keep the code clean and understandable, this patch
defines a set of functions for encapsulating some common parts and split
what should be done
Email client got the best of me again. Sorry, Robert, for sending this to you
twice. First, a note on my earlier situation:
I just had one end-to-end build finish successfully, but it
caused htop (a completely independent process) to die. Says it gave me
a core dump. Without a kernel core dump thi
Alexander Sack writes:
> On Mon, Sep 24, 2012 at 12:48 PM, Dave Pigott wrote:
>> Unfortunately, not as easy as it sounds. We'd have to actually change the
>> dispatcher to intercept submissions to vexpress, and then re-route them to
>> vexpress-a9, because we can'\t have two device instances tal
On Mon, Sep 24, 2012 at 12:14 PM, Ash Charles wrote:
> On Fri, Sep 21, 2012 at 2:48 PM, Robert Nelson
> wrote:
>> For omap34/35xx class hardware definitely turn on
>> CONFIG_ARM_ERRATA_430973=y
>>
>> When using a mix of arm/thumb application binaries on this core.
> Thanks Robert. Do you kn
On Fri, Sep 21, 2012 at 2:48 PM, Robert Nelson wrote:
> For omap34/35xx class hardware definitely turn on
> CONFIG_ARM_ERRATA_430973=y
>
> When using a mix of arm/thumb application binaries on this core.
Thanks Robert. Do you know of any references for these errata beyond
just the kernel conf
On 09/24/2012 06:28 AM, Rajagopal Venkat wrote:
This patch adds following minor changes to prepare powertop
to support Android platform.
- Add missing HAVE_CONFIG_H conditional check.
- remove un-used ethtool_cmd_speed_set and ethtool_cmd_speed
functions.
- Minimize dependency on exception handl
This patch adds following minor changes to prepare powertop
to support Android platform.
- Add missing HAVE_CONFIG_H conditional check.
- remove un-used ethtool_cmd_speed_set and ethtool_cmd_speed
functions.
- Minimize dependency on exception handling in catch blocks.
These changes will not affec
This patch adds stubs for features that are not supported
by Andriod. An header file which defines all stubs is
included only for Android builds.
Signed-off-by: Rajagopal Venkat
---
Android.mk | 33 ++-
src/android_stubs.h | 65 +++
Hi Ajay,
I don't believe the Linaro release for i.MX53 ever included the
hardware acceleration support required to play an HDMI video. If
the LTIB release included those kernel drivers, then that would be
a better place to start for this project.
HTH,
Matt
On 09/24/2012 12:42 AM, Ajay Kaushik wr
This weekend a test rebuild of quantal quetzal did start for the amd64, i386 and
armhf architectures. The test rebuild is now finished for the main and
restricted components, and continues with the universe and multiverse
components.
Results can be seen at
http://people.ubuntuwire.org/~wgrant/reb
On Mon, Sep 24, 2012 at 12:48 PM, Dave Pigott wrote:
> Unfortunately, not as easy as it sounds. We'd have to actually change the
> dispatcher to intercept submissions to vexpress, and then re-route them to
> vexpress-a9, because we can'\t have two device instances talking to the same
> device. I'l
Unfortunately, not as easy as it sounds. We'd have to actually change the
dispatcher to intercept submissions to vexpress, and then re-route them to
vexpress-a9, because we can'\t have two device instances talking to the same
device. I'll look into it, but it would be quite a nasty bodge.
Dave
Hi, I am new to i.Mx53 QSB, would appreciate if you can provide head up to get started. I have downloaded and installed ubuntu desktop as per "Ubuntu 11.10 64-bit host i.MX53 START_R LTIB 11.09.01 Installation", but now got confused as I came across an article where as in we can use the image provi
could we keep deprecated backward compatibility mapping on LAVA side for a
while?
On Sep 24, 2012 10:01 AM, "Paul Sokolovsky"
wrote:
> Hello,
>
> On Mon, 24 Sep 2012 08:30:34 +0100
> Dave Pigott wrote:
>
> > Hi All,
> >
> > I notice that there are still some jobs being submitted to LAVA with
> >
Hello,
On Mon, 24 Sep 2012 08:30:34 +0100
Dave Pigott wrote:
> Hi All,
>
> I notice that there are still some jobs being submitted to LAVA with
> the device-type "vexpress". This device type is now deprecated and
> has been replaced by the more specific device type vexpress-a9. The
> jobs seem
Hi All,
I notice that there are still some jobs being submitted to LAVA with the
device-type "vexpress". This device type is now deprecated and has been
replaced by the more specific device type vexpress-a9. The jobs seem to be
coming from CI and Android. Could someone amend these submissions?
23 matches
Mail list logo
