Hi,
On Sun, May 23, 2010 at 01:53:10AM +0200, ext Amit Kucheria wrote:
From 3df714f995b0895e905090760482194233f66a1d Mon Sep 17 00:00:00 2001
Message-Id:
3df714f995b0895e905090760482194233f66a1d.1274570700.git.amit.kuche...@canonical.com
From: Amit Kucheria amit.kuche...@canonical.com
Date:
Hi,
On Mon, May 24, 2010 at 09:07:37AM +0200, ext Gupta, Ajay Kumar wrote:
Attempting to remove usb_nop_xceiv_register() completely will require
someone
with more knowledge of davinci and blackfin archs to comment on what
boards
need the platform_device defined.
NAK..
This is an
On Tue, 25 May 2010 13:21:27 +0100, Jonathan Cameron wrote:
On 05/25/10 13:12, Datta, Shubhrajyoti wrote:
Adds the driver support for the TMP105 temperature sensor device. The
interface is I2C.The driver supports the read of the temperature values.
Still on the wrong list... cc'ing
ps: you really think that adding more and more ifdefs is better than
Amit's patch ??
We can avoid using #ifdefs by introducing '.neednop' flag to board_data.
Here is the patch for this which can be used on top of my earlier patch.
--- cut here ---
diff --git
On Tue, 2010-05-18 at 16:05 +0200, ext Sebastien Jan wrote:
On Tuesday 18 May 2010 11:07:20 Carlos Chinea wrote:
[cut]
+ val |= __raw_readl(omap_ssi-sys +
SSI_MPU_ENABLE_REG(port-num, 0)); + __raw_writel(val,
omap_ssi-sys +
SSI_MPU_ENABLE_REG(port-num, 0)); +
+
Hi
There are now required sound/soc/ patches in mainline and linux-omap to get
basic Nokia N900 audio working.
Patch 1/3 is continuation to earlier set, see
http://marc.info/?l=linux-omapm=127306914008392w=2
IMO, it should go for 2.6.35 as it's kind of fix for unworking audio due
codec being
Proper operation of the tlv320aic3x audio codec requires that reset
sequencing is done in pair with supply voltages when using the regulator
framework. Add the codec reset gpio used in Nokia RX51 to tlv320aic3x
data.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
---
There is REGULATOR_SUPPLY macro available for initializing the struct
regulator_consumer_supply so use it where applicable (all other supplies
than vdds_sdi) as it improves the readability.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
Acked-by: Eduardo Valentin eduardo.valen...@nokia.com
---
With these and upcoming change to tpa6130a2 driver it's possible to add
support for the TPA6130A2 headphone amplifier.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
---
v3:
- No functional changes. Rebased on top of 1/3.
v2:
- Rebased on top of 7b93a0d
- Only Vdd supply added as the CPVSS
On Tue, May 25, 2010 at 05:44:18PM -0700, Tony Lindgren wrote:
So, below is a patch to sanitize the code in arch/arm/plat-omap/fb.c.
The logic in this file is rather convoluted, but essentially:
I've tried the patch below with the patches from your lmb branch
up to this one and I can see
Hi,
I have taken latest Linux Kernel for beagle board (C3).
I tried my image in that board.
But getting omapfb error.
DISPC version 3.0 initialized
omapfb: irq error status 4020
...
I feel this is known issue.
Could you please reply whats need to be done.
Regards,
-S
--
To
From: Hemanth V heman...@ti.com
Date: Fri, 21 May 2010 15:52:03 +0530
Subject: [PATCH] misc: ROHM BH1780GLI Ambient light sensor Driver
This patch adds support for ROHM BH1780GLI Ambient light sensor.
BH1780 supports I2C interface. Driver supports read/update of power state and
read of lux
On 05/26/10 09:30, Hemanth V wrote:
From: Hemanth V heman...@ti.com
Date: Fri, 21 May 2010 15:52:03 +0530
Subject: [PATCH] misc: ROHM BH1780GLI Ambient light sensor Driver
This patch adds support for ROHM BH1780GLI Ambient light sensor.
BH1780 supports I2C interface. Driver supports
On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra pet...@infradead.org wrote:
On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
This of course will lead to a scattering of suspend blockers into any
drivers/subsystems considered useful, which by looking through current
Android
On Wed, 2010-05-26 at 02:41 -0700, Arve Hjønnevåg wrote:
On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra pet...@infradead.org wrote:
On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
This of course will lead to a scattering of suspend blockers into any
drivers/subsystems
On Wed, May 26, 2010 at 2:45 AM, Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2010-05-26 at 02:41 -0700, Arve Hjønnevåg wrote:
On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra pet...@infradead.org wrote:
On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
This of course will
On Mon, May 24, 2010 at 7:05 PM, Ohad Ben-Cohen o...@wizery.com wrote:
Every time the MM application calls proc_map to map
a memory area, remember the details of that mapping,
together with the related page structures.
Whenever a buffer is unmapped, clean up the mapping
information resources.
On Wed, 26 May 2010 11:45:06 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2010-05-26 at 02:41 -0700, Arve Hjønnevåg wrote:
On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra pet...@infradead.org
wrote:
On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
This of
2010/5/26 Peter Zijlstra pet...@infradead.org:
On Wed, 2010-05-26 at 02:41 -0700, Arve Hjønnevåg wrote:
On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra pet...@infradead.org wrote:
On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
This of course will lead to a scattering of suspend
On Wed, 2010-05-26 at 12:02 +0200, Florian Mickler wrote:
The summary is: The device this kernel is running on dosn't want to
(or can) rely on userspace to save power. This is because it is an open
system, without an app-store or the like. Everyone can run what he
wants.
So anything relying
On Wed, 2010-05-26 at 03:06 -0700, Arve Hjønnevåg wrote:
I was not talking about our user-space code. Suspend has to be called
by a running thread, so at least one runqueue is not empty.
But why would you need to suspend if the machine is fully idle?
Is it because you're using broken hardware
On Wed, 26 May 2010 12:08:04 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2010-05-26 at 12:02 +0200, Florian Mickler wrote:
The summary is: The device this kernel is running on dosn't want to
(or can) rely on userspace to save power. This is because it is an open
system,
2010/5/26 Peter Zijlstra pet...@infradead.org:
On Wed, 2010-05-26 at 03:06 -0700, Arve Hjønnevåg wrote:
I was not talking about our user-space code. Suspend has to be called
by a running thread, so at least one runqueue is not empty.
But why would you need to suspend if the machine is fully
On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
and on systems where the
same power state can be used from idle and suspend, we use suspend so
we can stay in the low power state for minutes to hours instead of
milliseconds to seconds.
So don't you think working on making it possible
On Wed, May 26, 2010 at 3:32 AM, Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
and on systems where the
same power state can be used from idle and suspend, we use suspend so
we can stay in the low power state for minutes to hours instead
2010/5/26 Peter Zijlstra pet...@infradead.org:
On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
and on systems where the
same power state can be used from idle and suspend, we use suspend so
we can stay in the low power state for minutes to hours instead of
milliseconds to seconds.
On Wed, 2010-05-26 at 03:40 -0700, Arve Hjønnevåg wrote:
2010/5/26 Peter Zijlstra pet...@infradead.org:
On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
and on systems where the
same power state can be used from idle and suspend, we use suspend so
we can stay in the low power
2010/5/26 Peter Zijlstra pet...@infradead.org:
On Wed, 2010-05-26 at 03:40 -0700, Arve Hjønnevåg wrote:
2010/5/26 Peter Zijlstra pet...@infradead.org:
On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
and on systems where the
same power state can be used from idle and suspend, we
- Original Message -
From: Jonathan Cameron
On 05/26/10 09:30, Hemanth V wrote:
From: Hemanth V heman...@ti.com
Date: Fri, 21 May 2010 15:52:03 +0530
Subject: [PATCH] misc: ROHM BH1780GLI Ambient light sensor Driver
This patch adds support for ROHM BH1780GLI Ambient light sensor.
On Wed, 2010-05-26 at 03:53 -0700, Arve Hjønnevåg wrote:
2010/5/26 Peter Zijlstra pet...@infradead.org:
On Wed, 2010-05-26 at 03:40 -0700, Arve Hjønnevåg wrote:
2010/5/26 Peter Zijlstra pet...@infradead.org:
On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
and on systems
On Wed, May 26, 2010 at 12:02 PM, Florian Mickler flor...@mickler.org wrote:
So why again was this such a great scheme? Go fix your userspace to not
not run when not needed.
Hi Peter!
This was already mentioned in one of these threads.
The summary is: The device this kernel is running on
2010/5/26 Arve Hjønnevåg a...@android.com:
Fixing the actually issue means fixing all user-space code, and
replacing most x86 hardware. I don't think keeping this feature out of
the kernel will significantly accelerate this.
But if this feature gets merged, I bet you'll find another 100
On Wed, May 26, 2010 at 1:37 PM, Florian Mickler flor...@mickler.org wrote:
This is not protection. This is functioning properly in a real world
scenario. Why would the user change the kernel, if the device would be
buggy after that? (Except maybe he is a geek)
Hmm... Why would the user
Hello Everyone,
I am currently working with the linux 2.6.29-omap1 kernel. Right now I
am porting a legacy application code that puts the OMAP 5912 host to
sleep. The host wakes up after 4 secs via an RTC interrupt which is
configured to be the wake-up source. Everything seems to be fine
On Wed, 26 May 2010 14:01:49 +0200
Vitaly Wool vitalyw...@gmail.com wrote:
On Wed, May 26, 2010 at 1:37 PM, Florian Mickler flor...@mickler.org wrote:
This is not protection. This is functioning properly in a real world
scenario. Why would the user change the kernel, if the device would be
I don't think x86 is relevant anyway, it doesn't suspend/resume anywhere
near fast enough for this to be usable.
Yet...
My laptop still takes several seconds to suspend (Lenovo T500), and
resume (aside from some userspace bustage) takes the same amount of
time. That is quick enough for
hi,
On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote:
And if you have two kernels, one with which your device is dead after 1
hour and one with which your device is dead after 10 hours. Which would
you prefer? I mean really... this is ridiculous.
What I find ridiculous is
On Wed, 26 May 2010 15:29:32 +0300
Felipe Balbi felipe.ba...@nokia.com wrote:
hi,
On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote:
And if you have two kernels, one with which your device is dead after 1
hour and one with which your device is dead after 10 hours. Which
Hi,
On Wed, May 26, 2010 at 02:33:23PM +0200, ext Florian Mickler wrote:
But then someone at the user side has to know what he is doing.
I fear, if you target mass market without central distribution
channels, you can not assume that much.
and that's enough to push hacks into the kernel ? I
On Wed, 2010-05-26 at 14:33 +0200, Florian Mickler wrote:
On Wed, 26 May 2010 15:29:32 +0300
Felipe Balbi felipe.ba...@nokia.com wrote:
hi,
On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote:
And if you have two kernels, one with which your device is dead after 1
On Wed, 2010-05-26 at 13:35 +0100, Alan Cox wrote:
This is an area where machines are improving and where the ability to
do stuff like autosuspend, the technology like the OLPC screen and so on
create an incentive for the BIOS and platform people to improve their
bits of it.
But do you think
On Wed, 26 May 2010 15:35:32 +0300
Felipe Balbi felipe.ba...@nokia.com wrote:
Hi,
On Wed, May 26, 2010 at 02:33:23PM +0200, ext Florian Mickler wrote:
But then someone at the user side has to know what he is doing.
I fear, if you target mass market without central distribution
channels,
On Wed, May 26, 2010 at 2:24 PM, Florian Mickler flor...@mickler.org wrote:
Really, what are you getting at? Do you deny that there are programs,
that prevent a device from sleeping? (Just think of the bouncing
cows app)
And if you have two kernels, one with which your device is dead after 1
On Wed, 26 May 2010 14:41:29 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2010-05-26 at 14:33 +0200, Florian Mickler wrote:
On Wed, 26 May 2010 15:29:32 +0300
Felipe Balbi felipe.ba...@nokia.com wrote:
hi,
On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler
On Wed, 2010-05-26 at 14:54 +0200, Florian Mickler wrote:
It really comes down to a policy decision by the distribution maker.
And I don't think kernel upstream should be the one to force one way or
the other.
That's exactly what we always do. If we were not to do so, the kernel
would be a
On Wed, 2010-05-26 at 15:03 +0200, Florian Mickler wrote:
The kernel can not win if it does not try to integrate any use of it.
If we'd integrate every patch that came to lkml, you'd run away
screaming.
We most certainly do not want to integrate _any_ use.
--
To unsubscribe from this list: send
Really, what are you getting at? Do you deny that there are programs,
that prevent a device from sleeping? (Just think of the bouncing
cows app)
And if you have two kernels, one with which your device is dead after 1
hour and one with which your device is dead after 10 hours. Which would
Nonetheless, I really think the kernel needs to allow for the android
way of power saving. It misses out on a big feature and a big user-base
if not.
That seems to me to be conflating models of behaviour and implementations.
This is a _big_ plus for attracting 3rd party programs. (And of
On Wed, 26 May 2010 14:55:31 +0200
Vitaly Wool vitalyw...@gmail.com wrote:
On Wed, May 26, 2010 at 2:24 PM, Florian Mickler flor...@mickler.org wrote:
Really, what are you getting at? Do you deny that there are programs,
that prevent a device from sleeping? (Just think of the bouncing
On Wed, 26 May 2010 15:07:27 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2010-05-26 at 15:03 +0200, Florian Mickler wrote:
The kernel can not win if it does not try to integrate any use of it.
If we'd integrate every patch that came to lkml, you'd run away
screaming.
We
On Wed, 26 May 2010 14:19:42 +0100
Alan Cox a...@lxorguk.ukuu.org.uk wrote:
This is a _big_ plus for attracting 3rd party programs. (And of course
the thing you don't like).
You would do better to concentrate on technical issues that the
assignment of malicious intent to other parties.
Alan,
On Wed, 26 May 2010, Alan Cox wrote:
Really, what are you getting at? Do you deny that there are programs,
that prevent a device from sleeping? (Just think of the bouncing
cows app)
And if you have two kernels, one with which your device is dead after 1
hour and one with which
ARM: OMAP3LOGIC: Adding SDMMC support
Add low-level initialization for hsmmc controller for
LogicPD's OMAP 3530 LV SOM and OMAP 35x Torpedo board.
Signed-off-by: Jacob Tanenbaum jacob.tanenb...@logicpd.com
---
Adding LogicPD OMAP3 board support
Adding support for LogicPD's OMAP 3530 LV SOM and
OMAP 35x Torpedo board.
Signed-off-by: Jacob Tanenbaum jacob.tanenb...@logicpd.com
---
arch/arm/configs/omap3_logic_defconfig | 990
* Russell King - ARM Linux li...@arm.linux.org.uk [100526 00:45]:
On Tue, May 25, 2010 at 05:44:18PM -0700, Tony Lindgren wrote:
After applying the next patch in your lmb branch ARM: OMAP: Convert
to use -reserve method to reserve boot time memory tux still works
on 5912osk, but not on
On Wed, 26 May 2010, Florian Mickler wrote:
I don't think that the in-kernel suspend block is a bad idea.
You could probably use the suspend-blockers unconditionally in the
suspend framework to indicate if a suspend is possible or not.
That's not how it works. Drivers aren't supposed to
On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
I'm not saying that your argument is not valid. But why don't you look
at suspend blockers as a contract between userspace and kernelspace? An
Opt-In to the current guarantees the kernel provides in the non-suspend
case.
That's
On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
If you don't want to suspend while
looking at the bouncing-cow, you have to take a suspend blocker and
make yourself a user-visible power-eater, or don't do
echo opportunistic /sys/power/policy
How about we don't merge that junk
Alan Cox a...@lxorguk.ukuu.org.uk writes:
[1] Note I disagree with Kevin here on static/dynamic power management.
There are IMHO two types of PM but they are 'user invoked' and
'automatic'. Static simply means it's not been made fast enough yet but
its just a policy divide dependant on the
Hi,
On Wed, May 26, 2010 at 03:46:55PM +0200, Thomas Gleixner wrote:
Really, what are you getting at? Do you deny that there are programs,
that prevent a device from sleeping? (Just think of the bouncing
cows app)
And if you have two kernels, one with which your device is dead
I'm not saying that your argument is not valid. But why don't you look
at suspend blockers as a contract between userspace and kernelspace? An
Opt-In to the current guarantees the kernel provides in the non-suspend
case.
It is a contract - but not the right one. You are removing autonomy from
On Wed, 26 May 2010 17:15:47 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
I'm not saying that your argument is not valid. But why don't you look
at suspend blockers as a contract between userspace and kernelspace? An
Opt-In to
On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote:
On Wed, 26 May 2010 17:15:47 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
I'm not saying that your argument is not valid. But why don't you look
at suspend blockers
On Wed, 26 May 2010 17:45:00 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote:
On Wed, 26 May 2010 17:15:47 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
I'm not
On Wed, 26 May 2010 17:47:35 +0200
Florian Mickler flor...@mickler.org wrote:
On Wed, 26 May 2010 17:45:00 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote:
On Wed, 26 May 2010 17:15:47 +0200
Peter Zijlstra pet...@infradead.org
From: Julia Lawall ju...@diku.dk
Add a mutex_unlock missing on the error paths. The use of the mutex is
balanced elsewhere in the file.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@@
expression E1;
@@
* mutex_lock(E1,...);
+... when != E1
Florian,
On Wed, 26 May 2010, Florian Mickler wrote:
On the other hand, applications can say, they don't need that much
power and userspace guaranties and not take a suspend blocker.
This is an option which they currently don't have.
Wrong. A well coded power aware application is very well
The power efficiency of a mobile device is depending on a sane overall
software stack and not on the ability to mitigate crappy software in
some obscure way which is prone to malfunction and disappoint users.
Even if you believe the kernel should be containing junk the model that
works and is
On Wed, 26 May 2010 19:02:04 +0100
Alan Cox a...@lxorguk.ukuu.org.uk wrote:
The power efficiency of a mobile device is depending on a sane overall
software stack and not on the ability to mitigate crappy software in
some obscure way which is prone to malfunction and disappoint users.
On Wed, May 26, 2010 at 9:56 PM, Florian Mickler flor...@mickler.org wrote:
Your approach definitely sounds better than the current solution.
What about mapping suspend blocker functionality later on, when this
interface exists, on to this new approach and deprecating it?
What about coming
On Wed, May 26, 2010 at 05:13:24PM +0530, DebBarma, Tarun Kanti wrote:
1) With the existing implementation I am not able to correctly
write/read {d0-d15} but not the {d16-d31} set
2) With my changes I am able to write/read correctly.
The reason this happens is simple. In vfp_get_double(),
On Wed, May 26, 2010 at 02:53:16PM +0200, Peter Zijlstra wrote:
On Wed, 2010-05-26 at 13:35 +0100, Alan Cox wrote:
This is an area where machines are improving and where the ability to
do stuff like autosuspend, the technology like the OLPC screen and so on
create an incentive for the BIOS
Thanks Eric, David,
[..]
- if (skb_shinfo(skb)-nr_frags) {
+ if (skb_shinfo(skb)-nr_frags skb_has_frags(skb)) {
int i;
for (i = 0; i skb_shinfo(skb)-nr_frags; i++)
Le mercredi 26 mai 2010 à 15:19 -0500, Arce, Abraham a écrit :
By increasing the allocation length of our rx skbuff the corruption issue is
fixed... I have increased it by 2... Were we writing outside our boundaries
of skb data?
Please let me know about this approach...
diff --git
suspend blockers are completely backwards as they basically disable
the kernels ability to do resource management.
I don't think this is a defect in the approach but the point of it.
I think it's both. It's the point of it, and that itself is a defect. Its
designed wrongly.
drivers code
On Wed, May 26, 2010 at 6:16 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Really, what are you getting at? Do you deny that there are programs,
that prevent a device from sleeping? (Just think of the bouncing
cows app)
And if you have two kernels, one with which your device is dead after 1
Govindraj.R govindraj.r...@ti.com writes:
This patch adds driver support for OMAP3/4 high speed UART.
The driver is made separate from 8250 driver as we cannot
over load 8250 driver with omap platform specific configuration for
features like DMA, it makes easier to implement features like
2010/5/26 Peter Zijlstra pet...@infradead.org:
On Wed, 2010-05-26 at 03:53 -0700, Arve Hjønnevåg wrote:
2010/5/26 Peter Zijlstra pet...@infradead.org:
On Wed, 2010-05-26 at 03:40 -0700, Arve Hjønnevåg wrote:
2010/5/26 Peter Zijlstra pet...@infradead.org:
On Wed, 2010-05-26 at 03:25 -0700,
On OMAP24xx, the polarity for the IDLEST bits is opposite of OMAP3.
The mask used to check this was using the bit position instead of the
bit mask.
This patch fixes the problem by using the bit mask instead of the bit
field.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
Found when
This series on top of my pm-wip/uart branch fixes up various issues
with UART hwmods for 24xx as well as IDLEST issues after Benoit's
fixes/cleanup series.
Tested on OMAP3 (omap3evm) and OMAP2 (n810/2420).
Note that for OMAP2, this recently posted patch is required as well:
[PATCH] OMAP24xx:
fold into OMAP3 hwmod patch
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index f88bfff..5bf8690 100644
---
Since these hwmods do not have IDLEST, set the HWMOD_NO_IDLEST flag,
otherwise _enable() will fail due to failing _wait_target_ready().
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |9 ++---
PRCM bits for UART3 are in PRCM reg id 2 (CM_IDLEST2_CORE, etc.)
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index c1618a5..682eecd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++
On Wed, 26 May 2010 15:30:58 -0700
Arve Hjønnevåg a...@android.com wrote:
On Wed, May 26, 2010 at 6:16 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Really, what are you getting at? Do you deny that there are programs,
that prevent a device from sleeping? (Just think of the bouncing
cows
2010/5/26 Alan Cox a...@lxorguk.ukuu.org.uk:
On Wed, 26 May 2010 15:30:58 -0700
Arve Hjønnevåg a...@android.com wrote:
On Wed, May 26, 2010 at 6:16 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Really, what are you getting at? Do you deny that there are programs,
that prevent a device from
Russell,
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Thursday, May 27, 2010 1:40 AM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH] ARM:VFPv3:enable {d16-d31} access
On
On Wed, 26 May 2010 22:03:37 +0200
Vitaly Wool vitalyw...@gmail.com wrote:
On Wed, May 26, 2010 at 9:56 PM, Florian Mickler flor...@mickler.org wrote:
Your approach definitely sounds better than the current solution.
What about mapping suspend blocker functionality later on, when this
On Wed, 26 May 2010 23:09:43 +0100
Alan Cox a...@lxorguk.ukuu.org.uk wrote:
We now have suggestions how to do the job properly so the right thing is
probably to go and explore those suggestions not merge crap.
Merging crap won't help anyway. The rest of the kernel community can
still simply
89 matches
Mail list logo
