On Thu, Aug 9, 2012 at 10:26 PM, Rob Clark rob.cl...@linaro.org wrote:
On Thu, Aug 9, 2012 at 12:14 AM, Andy Gross andy.gr...@ti.com wrote:
Fix the following sparse warnings:
drivers/staging/omapdrm/omap_dmm_tiler.c:123:13:
warning: symbol 'omap_dmm_irq_handler' was not declared.
On Thu, Aug 9, 2012 at 8:28 PM, Kevin Hilman khil...@ti.com wrote:
DebBarma, Tarun Kanti tarun.ka...@ti.com writes:
On Wed, Aug 8, 2012 at 10:40 PM, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
Add *remove* callback so that necessary cleanup operations
* Peter Ujfalusi peter.ujfal...@ti.com [120808 02:42]:
Remove the use of set_hs_extmute callback and let the codec driver to
handle the extmute GPIO.
Acked-by: Tony Lindgren t...@atomide.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
* Peter Ujfalusi peter.ujfal...@ti.com [120808 02:54]:
Since several OMAP3 based boards will be using the unified simple audio
driver it is better to not have duplicated code in the board files for this
purpose.
Board files can call omap_twl4030_audio_init(); to set up the needed device
for
* Peter Ujfalusi peter.ujfal...@ti.com [120808 02:54]:
These boards have similar audio setup and they can all use the same driver
for audio support if it is enabled in the kernel config.
After the naming changes suggested by Igor:
Acked-by: Tony Lindgren t...@atomide.com
--
To unsubscribe from
* Mark Brown broo...@opensource.wolfsonmicro.com [120808 06:27]:
On Wed, Aug 08, 2012 at 12:54:06PM +0300, Peter Ujfalusi wrote:
Changes under arch/arm/mach-omap2/ are trivial, I don't expect merge issues
later. If it is OK for the maintainers I would like this to go via audio
tree
On Fri, Aug 10, 2012 at 11:38 AM, DebBarma, Tarun Kanti
tarun.ka...@ti.com wrote:
On Thu, Aug 9, 2012 at 8:28 PM, Kevin Hilman khil...@ti.com wrote:
DebBarma, Tarun Kanti tarun.ka...@ti.com writes:
On Wed, Aug 8, 2012 at 10:40 PM, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma
* Konstantin Baydarov kbaida...@dev.rtsoft.ru [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
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
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 timo.t.kokko...@iki.fi
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff
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
This is a continuation of the work started in the series:
http://marc.info/?l=linux-omapm=134381744304672w=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
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
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
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 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
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
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 lock
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_disabled():
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 consumption
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 the
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
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() that doesn't
On Thu, Aug 9, 2012 at 12:13 AM, Andy Gross andy.gr...@ti.com 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.
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. Based on
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
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,
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
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
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
On Fri, 10 Aug 2012 11:49:27 -0700 Kevin Hilman khil...@ti.com 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,
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
32 matches
Mail list logo
