* Kevin Hilman [120810 10:45]:
> Tony,
>
> Please pull the following PM related fixes for v3.6-rc.
>
> One of them is a fix for drivers/cpufreq/omap-cpufreq.c, but it needs to
> go along with the arch/arm change. I'm listed in MAINTAINERS for the
> OMAP CPUfreq driver now, so this should be OK.
On Fri, 10 Aug 2012, Kevin Hilman wrote:
> Under some circumstances, drivers may leave an omap_device enabled due
> to driver programming errors, or due to a failure in the drivers
> probe method.
>
> Using the recently added omap_device driver_status field, we can
> detect conditions where an om
Hi Kevin,
On Fri, 10 Aug 2012, Kevin Hilman wrote:
> Add support for the omap_device layer to keep track of driver bound status.
>
> This will be used to track whether or not a driver is bound in order
> to make intelligent omap_device enable/idle decisions (e.g. ensuring
> omap_devices are idle
On Fri, 10 Aug 2012 11:49:27 -0700 Kevin Hilman wrote:
> Hello,
>
> In doing some automated testing of suspend/resume I noticed that
> repeated attempts to suspend and resume via RTC wakeup fail on
> 3530/Beagle and 3730/Beagle-xM, but work fine on 3430/n900, 3530/Overo,
> 3730/OveroSTORM and 44
Hello,
In doing some automated testing of suspend/resume I noticed that
repeated attempts to suspend and resume via RTC wakeup fail on
3530/Beagle and 3730/Beagle-xM, but work fine on 3430/n900, 3530/Overo,
3730/OveroSTORM and 4430/Panda.
When RTC wakeup fails, a UART wakeup will work, and in the
Use the bus notifier to keep track of driver bound status by adding a
new internal field to struct omap_device: _driver_status.
This will be useful for follow-up patches which need to know whether
or not a driver is bound in order to make intelligent omap_device
enable/idle decisions.
Cc: Paul Wa
Under some circumstances, drivers may leave an omap_device enabled due
to driver programming errors, or due to a failure in the drivers
probe method.
Using the recently added omap_device driver_status field, we can
detect conditions where an omap_device is enabled but has no driver
bound and then
Currently, the omap_device PM domain layer uses the late suspend and
early resume callbacks to ensure devices are in their low power
states.
However, this is attempted even in cases where a driver probe has
failed. If a driver's ->probe() method fails, the driver is likely in
a state where it is
Add support for the omap_device layer to keep track of driver bound status.
This will be used to track whether or not a driver is bound in order
to make intelligent omap_device enable/idle decisions (e.g. ensuring
omap_devices are idled when no driver is present, or driver probe
fails.)
Also, the
Tony,
Please pull the following PM related fixes for v3.6-rc.
One of them is a fix for drivers/cpufreq/omap-cpufreq.c, but it needs to
go along with the arch/arm change. I'm listed in MAINTAINERS for the
OMAP CPUfreq driver now, so this should be OK.
Kevin
The following changes since commit 0d
Hello Vaibhav
On Fri, 10 Aug 2012, Bedia, Vaibhav wrote:
> > Ok. I'll try to do some profiling using a timer to see how much time we
> > spend over here. On AM335x there are 2 such lookups, one for the dma
> > and one for the mcbsp. I could get this done today but will get to it
> > tomorrow. Bas
On Thu, Aug 9, 2012 at 12:13 AM, Andy Gross wrote:
> Removed the unnecessary copy of the memory page addresses when
> programming the DMM/PAT and all support code for the lut copy.
> The original intent was to have this code in place for
> suspend/resume functionality w.r.t. DEVICE_OFF.
>
> Perfor
Hi Jarkko,
On 08/10/2012 04:00 PM, Jarkko Nikula wrote:
> I got some odd current consumption results from Beagle to really compare
> different kernel versions but I was able get sensible results from N900.
I still use my n900 as a main phone so I can not really hack on it :(
> I tested your set
Hi Paul,
[...]
> > > On Wed, Aug 08, 2012 at 19:35:50, Paul Walmsley wrote:
> > >
> > > > It doesn't seem to me that this would necessarily always be an error.
> > > > Suppose some init code to create cpsw devices is running on an
> > > > OMAP3430.
> > > > Then a omap_hwmod_for_each_by_class
gets rid of below messages with CONFIG_DEBUG_PREEMPT enabled
[ 28.832916] debug_smp_processor_id: 18 callbacks suppressed
[ 28.832946] BUG: using smp_processor_id() in preemptible [] code:
modprobe/1763
[ 28.841491] caller is pwrdm_set_next_pwrst+0x54/0x120
Signed-off-by: Roger Qua
On 08/08/2012 02:21 PM, Mark Brown wrote:
> On Wed, Aug 08, 2012 at 12:11:30PM +0300, Peter Ujfalusi wrote:
>
>> The series changes McBSP related files mostly. It would be great if the whole
>> series could go via audio tree (if the patches are OK and it is fine by
>> Tony).
>
> I'm OK with all
Hi Peter
On 08/08/2012 05:00 PM, Peter Ujfalusi wrote:
>> Are you sure it works without any changes to sidetone audio quality or
>> current consumption? What I remember idlemode was broken at least on
>> 3430 and caused bad sidetone audio if autoidle was set and a little bit
>> higher current cons
On 08.10 2012 14:06:38, Timo Kokkonen wrote:
> I should have probably tried this before, but when I enabled lock
> debugging with this driver, I got this:
>
> > [ 663.848083] BUG: sleeping function called from invalid context at
> > kernel/mutex.c:269
> > [ 663.856262] in_atomic(): 1, irqs_disa
I should have probably tried this before, but when I enabled lock
debugging with this driver, I got this:
> [ 663.848083] BUG: sleeping function called from invalid context at
> kernel/mutex.c:269
> [ 663.856262] in_atomic(): 1, irqs_disabled(): 128, pid: 889, name: lircd
> [ 663.863220] 1 loc
The SDI driver currently relies on the omap_dss_device struct to configure the
number of data pairs as specified by the panel. This makes the SDI interface
driver dependent on the omap_dss_device struct.
Make the SDI driver data maintain it's own data lines field. A panel driver
is expected to cal
The DPI driver currently relies on the omap_dss_device struct to configure the
number of data lines as specified by the panel. This makes the DPI interface
driver dependent on the omap_dss_device struct.
Make the DPI driver data maintain it's own data lines field. A panel driver
is expected to cal
The RFBI driver currently relies on the omap_dss_device struct to receive the
desired pixel size of the panel. This makes the RFBI interface driver dependent
on the omap_dss_device struct.
Make the RFBI driver data maintain it's own pixel format field. A panel driver
is expected to call omapdss_rf
The RFBI driver currently relies on the omap_dss_device struct to configure the
number of data lines as specified by the panel. This makes the RFBI interface
driver dependent on the omap_dss_device struct.
Make the RFBI driver data maintain it's own data lines field. A panel driver
is expected to
The DSI driver currently relies on the omap_dss_device struct to receive the
desired pixel format of the panel. This makes the DSI interface driver dependent
on the omap_dss_device struct.
Make the DSI driver data maintain it's own pixel format field. The panel driver
is expected to call omapdss_d
This is a continuation of the work started in the series:
http://marc.info/?l=linux-omap&m=134381744304672&w=2
This makes the panel driver call interface specific functions to configure the
data lines and pixel format requested by the panel.
Configuration of data lines doesn't happen for DSI or
This is the driver for the IR transmitter diode found on the Nokia
N900 (also known as RX51) device. The driver is mostly the same as
found in the original 2.6.28 based kernel that comes with the device.
The following modifications have been made compared to the original
driver version:
- Adopt t
The IR diode on the RX51 is connected to the GPT9. This data is needed
for the IR driver to function.
Signed-off-by: Timo Kokkonen
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-oma
These patches add the support for sending IR remote controller codes
on the Nokia N900 phone. The code is taken from the public N900 kernel
release and modified to work with today's kernel.
The code has been tested with a real Nokia N900 device and confirmed
to work. I can identify only one known
* Konstantin Baydarov [120809 04:00]:
> Hi, Tony.
>
> On 08/08/2012 06:59 PM, Konstantin Baydarov wrote:
> > Yes, omap_type() is called very early , that is why I'm using
> > early_initcall for omap_control_base initialization.
> >
> > Do you mean following?:
> > void __init omap2_set_global
29 matches
Mail list logo
