Hi Benoit,
On Saturday 24 September 2011 01:53 AM, Benoit Cousson wrote:
Re-cycle the original board-generic file to support Device Tree
for every OMAP2+ variants.
Note: Since it is a completely new content in the existing file
I removed the original copyright.
The current approach is an
On OMAP3, in order to enable alpha blending for LCD and TV managers, we needed
to set LCDALPHABLENDERENABLE/TVALPHABLENDERENABLE bits in DISPC_CONFIG. On
OMAP4, alpha blending is always enabled by default, if the above bits are set,
we switch to an OMAP3 compatibility mode where the zorder values
On Tue, 2011-09-20 at 11:18 +0300, Tomi Valkeinen wrote:
Hi Tony,
Here is a bunch of board file patches related to DSS. They have all been sent
for review earlier, and are currently in my tree. Some of them depend on DSS
driver changes, so I'd like to keep them there to avoid compilation
This set includes patches which do the following:
- Fix crash if a we call dssdev-driver-update for a disabled panel.
- Fix the issue of not being able to request for a buffer which is larger than
what we did the last time.
- Fix a small bug in omap_vout_isr()
- Remove some redundant code in
The commit 383e4f69879d11c86ebdd38b3356f6d0690fb4cc makes reqbuf prevent
requesting a larger size buffer than what is allocated at kernel boot during
omap_vout_probe.
The requested size is compared with vout-buffer_size, this isn't correct as
vout-buffer_size is later set to the size requested in
Currently, there is a lot of redundant code is between DPI and VENC panels, this
can be made common by moving out field/interlace specific code to a separate
function called omapvid_handle_interlace_display(). There is no functional
change made.
Signed-off-by: Archit Taneja arc...@ti.com
---
Currently, in omap_vout_isr(), if the panel type is DPI, and if we
get either VSYNC or VSYNC2 interrupts, we proceed ahead to set the
current buffers state to VIDEOBUF_DONE and prepare to display the
next frame in the queue.
On OMAP4, because we have 2 LCD managers, the panel type itself is not
Add support for DSI panels. DSI video mode panels will work directly. For
command mode panels, we will need to trigger updates regularly. This isn't done
by the omap_vout driver currently. It can still be supported if we connect a
framebuffer device to the panel and configure it in auto update
Remove the code in omap_vout_probe() which calls display-driver-update() for
all the displays. This isn't correct because:
- An update in probe doesn't make sense, because we don't have any valid content
to show at this time.
- Calling update for a panel which isn't enabled is not supported by
This is just resend of patches 2-14/14 I posted earlier:
http://marc.info/?l=linux-omapm=131480421332374w=2
Patch 1/14 is already in linux-omap, Acked-by from Peter added and I
took freedom to thank Janusz by adding Tested-by line as he tested the
set on OMAP1.
Jarkko Nikula (13):
omap:
These variables got unused after McBSP was converted to use resource
structures.
Signed-off-by: Jarkko Nikula jarkko.nik...@bitmer.com
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
Tested-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/plat-omap/include/plat/mcbsp.h |7 ---
1
Only OMAP1s are using omap_mcbsp_register_board_cfg after OMAP2+ hwmod
conversion so it can be moved to mach-omap1/mcbsp.c.
Signed-off-by: Jarkko Nikula jarkko.nik...@bitmer.com
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
Tested-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Register access can be made more generic by calculating register address
offsets runtime from common register definitions and by using reg_size and
reg_step variables that are passed via platform data. Common register
definitions are possible since McBSP registers are ordered similarly between
Currently wakeup control code is compiled only when CONFIG_ARCH_OMAP3 is
set even it should be available for CONFIG_ARCH_OMAP4 only builds also.
Fix this by making wakeup control generic so that it is executed whenever
new feature flag has_wakeup in platform data is set. Currently flag is set
for
McBSP transmit and receive configuration control registers must be set up
for OMAP2430 and later. Replace is_omap tests in generic code with a new
feature flag has_ccr in platform data so that there is no need to change
code for any upcoming OMAP version.
Signed-off-by: Jarkko Nikula
Remove CONFIG_ARCH_OMAP3 conditional compilation and cpu_is_omap34xx test
around buffer threshold based transfer and DMA operating mode control. Use
instead the buffer_size in platform data to determine when these sysfs
controls are exposed and when to access related McBSP registers. Rationale
for
Rationale here is to remove one global variable and to make possible to have
variable size McBSP register maps inside SoC.
Signed-off-by: Jarkko Nikula jarkko.nik...@bitmer.com
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
Tested-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
From: Jarkko Nikula jhnik...@gmail.com
Active sidetone requires that McBSP interface clock doesn't idle and there
is no mechanism in hwmod to turn autoidling on/off in runtime. McBSP2 and 3
in OMAP34xx share their interface clock with McBSP sidetone module and
that interface clock must be active
Sidetone resource is already registered for a device so there is no need
for cpu_is_omap34xx() and McBSP port number tests in the driver. We can
cleanup and make the code generic by dropping remaining CONFIG_ARCH_OMAP3
conditional compilations and then using sidetone resource and st_data
variable
This generalizes the omap2_mcbsp1_mux_clkr_src and omap2_mcbsp1_mux_fsr_src
implementation between generic McBSP and OMAP2 specific McBSP code. These
functions are used to select source for CLKR and FSR signals on OMAP2+.
Start generalizing the code by implementing an optional mux_signal function
This generalizes the omap2_mcbsp_set_clks_src implementation between generic
McBSP and OMAP2 specific McBSP code. Currently this function is used to
select either internal fclk or clks pin as a McBSP CLKS source on OMAP2+.
Implement generalization by having an optional set_clk_src function
hardware.h is not needed here and let the definition for struct clk to come
via linux/clk.h.
Signed-off-by: Jarkko Nikula jarkko.nik...@bitmer.com
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
Tested-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/plat-omap/include/plat/mcbsp.h |4
These address definitions are OMAP1 specific can be in single source file.
Signed-off-by: Jarkko Nikula jarkko.nik...@bitmer.com
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
Tested-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/mcbsp.c | 11 +++
Hi Todd,
On Thu, Sep 15, 2011 at 01:37:38PM -0700, Todd Poynor wrote:
On Tue, Sep 06, 2011 at 09:29:30PM +0530, Santosh Shilimkar wrote:
TWL6030 devices have an interrupt line which is connected to
application processor like OMAP. These devices support multiple features
such as MMC card
On 9/26/2011 8:32 AM, Nayak, Rajendra wrote:
Hi Benoit,
On Saturday 24 September 2011 01:53 AM, Benoit Cousson wrote:
Re-cycle the original board-generic file to support Device Tree
for every OMAP2+ variants.
Note: Since it is a completely new content in the existing file
I removed the
-Original Message-
From: Hiremath, Vaibhav
Sent: Tuesday, September 20, 2011 8:02 PM
To: linux-omap@vger.kernel.org
Cc: Hilman, Kevin; p...@pwsan.com; t...@atomide.com; linux-arm-
ker...@lists.infradead.org; Hiremath, Vaibhav
Subject: [PATCH-V3 0/4] Introducing TI's New SoC/board
Samual,
On Monday 26 September 2011 02:20 PM, Samuel Ortiz wrote:
Hi Todd,
On Thu, Sep 15, 2011 at 01:37:38PM -0700, Todd Poynor wrote:
On Tue, Sep 06, 2011 at 09:29:30PM +0530, Santosh Shilimkar wrote:
TWL6030 devices have an interrupt line which is connected to
application processor like
Hi,
To: linux-omap@vger.kernel.org
Cc: linux-...@vger.kernel.org; Balbi, Felipe; t...@atomide.com; B, Ravi;
Cousson, Benoit; Gupta, Ajay Kumar
Subject: [PATCH 1/6 v3] omap: musb: Adding hwmod data for ti81xx
Felipe,
I am planning to send patch 1/6 along with next revision of ti81xx
hwmod
Hi Abhilash,
On Thu, Sep 22, 2011 at 06:59:15PM +0530, Abhilash K V wrote:
The current implementation almost assumes that only
TWL4030/TWL5030/TWl6030 are (or can be) used with the
OMAP processors. This is, however, not true.
This patch removes the automatic selection of the PMIC
from
Adding musb support in am335x EVM board file.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
These three patches are dependent on my patch set on musb support
for ti81xx recently at [1] and am33xx base port patches from
Vaibhav Hiremath at [2].
[1]
Switch on the phy for am335x.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
arch/arm/mach-omap2/omap_phy_internal.c | 15 +--
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
Enabled the flag so that musb_dsps glue file can be used for am335x
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/Kconfig |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index
(Sorry for the late reply, I'm plowing through weeks of backlog...)
On Thursday, September 08, 2011 15:35:00 Deepthy Ravi wrote:
From: Vaibhav Hiremath hvaib...@ti.com
Migrate tvp5146 driver to media controller framework. The
driver registers as a sub-device entity to MC framwork
and
-Original Message-
From: Taneja, Archit
Sent: Thursday, September 22, 2011 11:46 AM
To: Hiremath, Vaibhav
Cc: Valkeinen, Tomi; linux-omap@vger.kernel.org; Semwal, Sumit; linux-
me...@vger.kernel.org
Subject: Re: [PATCH 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in
Hello.
On 26-09-2011 14:03, Ajay Kumar Gupta wrote:
Enabled the flag so that musb_dsps glue file can be used for am335x
Signed-off-by: Ajay Kumar Guptaajay.gu...@ti.com
---
drivers/usb/musb/Kconfig |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git
This set includes patches which do the following:
- Fix crash if a we call dssdev-driver-update for a disabled panel.
- Fix the issue of not being able to request for a buffer which is larger than
what we did the last time.
- Remove some redundant code in omap_vout_isr()
- Add basic support for
The commit 383e4f69879d11c86ebdd38b3356f6d0690fb4cc makes reqbuf prevent
requesting a larger size buffer than what is allocated at kernel boot during
omap_vout_probe.
The requested size is compared with vout-buffer_size, this isn't correct as
vout-buffer_size is later set to the size requested in
Currently, there is a lot of redundant code is between DPI and VENC panels, this
can be made common by moving out field/interlace specific code to a separate
function called omapvid_handle_interlace_display(). There is no functional
change made.
Signed-off-by: Archit Taneja arc...@ti.com
---
Add support for DSI panels. DSI video mode panels will work directly. For
command mode panels, we will need to trigger updates regularly. This isn't done
by the omap_vout driver currently. It can still be supported if we connect a
framebuffer device to the panel and configure it in auto update
Remove the code in omap_vout_probe() which calls display-driver-update() for
all the displays. This isn't correct because:
- An update in probe doesn't make sense, because we don't have any valid content
to show at this time.
- Calling update for a panel which isn't enabled is not supported by
On 9/24/2011 12:58 AM, Tony Lindgren wrote:
* Benoit Coussonb-cous...@ti.com [110923 12:50]:
Used the main OCP node to add bindings with the l3_noc driver.
Remove l3_noc static device creation if DT is populated.
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -16,6
On 9/24/2011 1:08 AM, Tony Lindgren wrote:
* Benoit Coussonb-cous...@ti.com [110923 12:50]:
Re-cycle the original board-generic file to support Device Tree
for every OMAP2+ variants.
Note: Since it is a completely new content in the existing file
I removed the original copyright.
I'd suggest
On 9/24/2011 1:21 AM, Grant Likely wrote:
On Fri, Sep 23, 2011 at 10:23:11PM +0200, Benoit Cousson wrote:
Based on the original omap4-panda.dts file from Manju.
http://www.spinics.net/lists/linux-omap/msg55836.html
Add memory information and a default bootargs to allow
a boot from RAMDISK.
On Sat, Sep 24, 2011 at 12:00 PM, Paul Walmsley p...@pwsan.com wrote:
On Fri, 23 Sep 2011, Munegowda, Keshava wrote:
On Thu, Sep 22, 2011 at 11:31 PM, Paul Walmsley p...@pwsan.com wrote:
But the question arises here , why do we need these ehci and ohci as two
different hwmods containing only
On Sat, Sep 24, 2011 at 12:45 PM, Paul Walmsley p...@pwsan.com wrote:
On Fri, 23 Sep 2011, Munegowda, Keshava wrote:
On Thu, Sep 22, 2011 at 11:31 PM, Paul Walmsley p...@pwsan.com wrote:
On Thu, 22 Sep 2011, Keshava Munegowda wrote:
4. usb_tll_hs hwmod of usbhs with the TLL base address
On Mon, 26 Sep 2011, Munegowda, Keshava wrote:
On Sat, Sep 24, 2011 at 12:45 PM, Paul Walmsley p...@pwsan.com wrote:
On Fri, 23 Sep 2011, Munegowda, Keshava wrote:
On Thu, Sep 22, 2011 at 11:31 PM, Paul Walmsley p...@pwsan.com wrote:
On Thu, 22 Sep 2011, Keshava Munegowda wrote:
Hi Steve,
On Saturday 24 September 2011 15:44:52 Steve Sakoman wrote:
On Tue, Mar 29, 2011 at 8:32 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
I think that Sakari's patches correcty fix the problems he noticed.
However, they won't fix one basic issue, which is that the
* Grant Likely grant.lik...@secretlab.ca [110923 16:14]:
On Fri, Sep 23, 2011 at 04:12:08PM -0700, Tony Lindgren wrote:
* Benoit Cousson b-cous...@ti.com [110923 12:50]:
Still needed to boot until the i2c twl driver is adapted to
device-tree. Otherwise the voltage control code will try
Hi Grant, Tony,
This series is a rework of several series:
[RFC PATCH 00/10] OMAP: Add DT support for early init OMAP4 devices
http://www.spinics.net/lists/linux-omap/msg55977.html
[PATCH 00/13] OMAP4: Add DT support for i2c and twl6030
http://www.spinics.net/lists/linux-omap/msg56524.html
Add a device-tree node for the spinlock.
Remove the static device build code if CONFIG_OF
is set.
Update the hwspinlock driver to use the of_match method.
Add the information in Documentation/devicetree.
Add documentation for the HW spinlock in OMAP4.
Signed-off-by: Benoit Cousson
Adapt the GPIO driver to retrieve information from a DT file.
Note that since the driver is currently under cleanup, some hacks
will have to be removed after.
Add documentation for GPIO properties specific to OMAP.
Remove an un-needed whitespace.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Add the 6 GPIOs controller nodes.
Since the GPIO driver is still under cleanup, a couple of temp
hacks are needed. They will be removed as soon as the driver will
be cleaned.
Remove gpio static device initialisation if DT is populated.
Remove un-needed LF.
Signed-off-by: Benoit Cousson
Add an empty funtion to allow building a file without
adding some #ifdef CONFIG_OF around of APIs.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Grant Likely grant.lik...@secretlab.ca
---
include/linux/irqdomain.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git
Add the DT support for the TI rtc-twl present in the twl4030
and twl6030 devices.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Alessandro Zummo a.zu...@towertech.it
---
Documentation/devicetree/bindings/rtc/twl-rtc.txt | 12
drivers/rtc/rtc-twl.c |
Add initial device-tree support for twl familly chips.
The current version is missing the regulator entries due
to the lack of DT regulator bindings for the moment.
Only the simple sub-modules that do not depend on
platform_data information can be initialized properly.
Add documentation for the
Add i2c controllers nodes into the main ocp bus.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: G, Manjunath Kondaiah manj...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git
Add i2c controllers nodes into the main ocp bus.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: G, Manjunath Kondaiah manj...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git
Update pandaboard dts file with required clock frequencies
for the i2c client devices existing on pandaboard.
Add the twl6030 node in i2c1 controller.
This is the minimal support needed to boot OMAP4 boards
without any crash.
The support for all the features included in this MFD will be
added
Add initial DT support to retrieve the frequency using a
DT attribute instead of the pdata pointer if of_node exist.
Add documentation for omap i2c controller binding.
Based on original patches from Manju and Grant.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Ben Dooks
Update DTS file with required clock frequencies
for the i2c client devices existing on sdp4430.
Add the twl6030 node inside the i2c1 controller node.
This is the minimal support needed to boot OMAP4 boards
without any crash.
The support for all the features included in this MFD will be
added
Add required clock frequencies for the i2c client devices existing
on beagle board.
Add the twl4030 basic description with only the twl_rtc module.
Add the EEPROM node.
Based on original patch from Manju:
http://www.spinics.net/lists/linux-omap/msg55831.html
Signed-off-by: Benoit Cousson
This mainly reverts the commit that was adding the i2c static init.
Since the i2c and twl nodes are now present, there is no need
for the static initialization anymore.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-generic.c |
* DebBarma, Tarun Kanti tarun.ka...@ti.com [110923 01:54]:
Hi Tony,
[...]
I've applied these into dmtimer branch with some changes to simplify
things further. I've also merged it into linux-omap master branch
for further testing.
I'll reply to your patches with the changes I've done.
On 08/22/2011 08:19 AM, Benoit Cousson wrote:
From: Nishanth Menonn...@ti.com
An API which translates a standard hwmod name to corresponding
omap_device is useful for drivers when they need to look up the
device associated with a hwmod name to map back into the device
structure pointers. These
Benoit Cousson b-cous...@ti.com writes:
From: Nishanth Menon n...@ti.com
An API which translates a standard hwmod name to corresponding
platform_device is useful for drivers when they need to look up the
device associated with a hwmod name to map back into the device
structure pointers.
On Mon, Sep 26, 2011 at 10:55 PM, Tony Lindgren t...@atomide.com wrote:
* DebBarma, Tarun Kanti tarun.ka...@ti.com [110923 01:54]:
Hi Tony,
[...]
I've applied these into dmtimer branch with some changes to simplify
things further. I've also merged it into linux-omap master branch
for
DebBarma, Tarun Kanti tarun.ka...@ti.com writes:
Santosh, Kevin,
[...]
After that, pm_runtime_put_sync() is called, which will trigger the
driver's -runtime_suspend callback. The -runtime_suspend() callback
checks bank-mod_usage as well, and if zero, doesn't do anything
(notably, it
hvaib...@ti.com writes:
From: Afzal Mohammed af...@ti.com
This patch updates the common machine specific source files for
support for AM33XX/AM335x with cpu type, macros for identification of
AM33XX/AM335X device.
Signed-off-by: Afzal Mohammed af...@ti.com
Signed-off-by: Vaibhav Hiremath
* Cousson, Benoit b-cous...@ti.com [110926 05:01]:
On 9/24/2011 1:08 AM, Tony Lindgren wrote:
* Benoit Coussonb-cous...@ti.com [110923 12:50]:
Re-cycle the original board-generic file to support Device Tree
for every OMAP2+ variants.
Note: Since it is a completely new content in the existing
* Cousson, Benoit b-cous...@ti.com [110926 04:39]:
On 9/24/2011 12:58 AM, Tony Lindgren wrote:
* Benoit Coussonb-cous...@ti.com [110923 12:50]:
How about just remove omap3_l3_init and omap4_l3_init completely
instead?
There should not be any need for the platform glue code if the
Hi Paul,
On 9/23/2011 1:31 AM, Paul Walmsley wrote:
Hi
On Thu, 22 Sep 2011, Cousson, Benoit wrote:
ADDR_TYPE_RT is mainly use for sysconfig access inside hwmod core today, so
why should we use it in this case?
Just for consistency, since the flag isn't defined to be
SYSCONFIG-specific.
[...]
- Added the debounce clock fix in the end.
Thanks. Glad you found and fixed it.
Rather than add this patch as a fix at the end, I prefer if the problem
is fixed in the original patches that added/created the problem.
Sure. I will put the changes in respective patches.
--
Tarun
[...]
ping
On 09/06/2011 03:31 PM, Kevin Hilman wrote:
Hi Ben,
On 08/23/2011 05:10 PM, Kevin Hilman wrote:
Ben,
Here's one more I2C cleanup series for v3.2.
It applies on top of my for_3.2/i2c-fixes branch just submitted.
Please pull into your tree for linux-next.
I see you pulled the other
Hi Benoit,
Benoit Cousson b-cous...@ti.com writes:
Hi Kevin,
Here are a couple of cleanups on top of your (old) for_3.2/omap_device branch
rebased on top of -rc4 + Tony's cleanup patches.
Since I cannot pull your latest version, I repost the whole series.
I have a (temporary) tree at
Hi Benoit,
Benoit Cousson b-cous...@ti.com writes:
This is the updated version of the initial series that introduced a
notifier in order to create an omap_device from a platform_device bound
to DT node as suggested by Grant.
This series looks good to me.
Barring any final comments (Grant?),
DebBarma, Tarun Kanti tarun.ka...@ti.com writes:
[...]
As pointed out by Kevin, debounce clock was not getting disabled.
In my testing I was somehow grepping CORE power domain instead
of PER power domain and hence missed it. The fix for the debounce
clock issue is at the end of the email.
* Tony Lindgren t...@atomide.com [110923 15:27]:
* Benoit Cousson b-cous...@ti.com [110923 12:50]:
Add SoC specific map_io function to be used by the generic DT
board file. This is an intermediate step before having some
generic DT aware map_io function.
Thanks, I'll apply this into
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
The context lost count is modified in omap_sram_idle() path when
pwrdm_post_transition() is called. But pwrdm_post_transition() is called
only after omap_gpio_resume_after_idle() is called. Correct this so that
There's no longer any need for the board specific
map_io.
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 618216c..45dafe2 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++
Hi Ohad,
Ohad Ben-Cohen o...@wizery.com writes:
Make it possible to set an iommu private archdata before a newly-created
omap device is registered.
Binding iommu client devices with their respective iommu data this way
is needed so the generic IOMMU API can later be used without employing
On Mon, Sep 26, 2011 at 03:01:54PM +0530, Santosh Shilimkar wrote:
Samual,
On Monday 26 September 2011 02:20 PM, Samuel Ortiz wrote:
Hi Todd,
On Thu, Sep 15, 2011 at 01:37:38PM -0700, Todd Poynor wrote:
On Tue, Sep 06, 2011 at 09:29:30PM +0530, Santosh Shilimkar wrote:
TWL6030
DebBarma, Tarun Kanti tarun.ka...@ti.com writes:
[...]
- Added the debounce clock fix in the end.
Thanks. Glad you found and fixed it.
Rather than add this patch as a fix at the end, I prefer if the problem
is fixed in the original patches that added/created the problem.
Sure. I will put
With SoC specific timers, board specific init_irq is
no longer needed. Earlier this was still needed to
initialize the gptimer12 on Beagle based boards.
Also convert board-h4.c to use omap2_init_irq accidentally
did not get converted earlier.
Signed-off-by: Tony Lindgren t...@atomide.com
diff
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
Modify omap_gpio_prepare_for_idle() omap_gpio_resume_after_idle() functions
to handle save context restore context respectively in the OMAP GPIO driver
itself instead of calling these functions from pm specific
* Jarkko Nikula jarkko.nik...@bitmer.com [110926 00:12]:
This is just resend of patches 2-14/14 I posted earlier:
http://marc.info/?l=linux-omapm=131480421332374w=2
Patch 1/14 is already in linux-omap, Acked-by from Peter added and I
took freedom to thank Janusz by adding Tested-by line as
LOCKDEP explicitly sets all irq_desc locks as a single lock-class,
causing possible recursive locking detected when the TWL RTC
driver calls through enable_irq_wake to twl6030_irq_set_wake,
which recursively calls irq_set_irq_wake. Although the
irq_desc and lock are different, LOCKDEP treats
Module IRQs may still be disabled by DPM at the time the TWL6030
ISR runs, causing handle_simple_irq() to silently do nothing.
This may result in missing TWL RTC alarm wakeups, for example,
since the RTC child module ISR is not called to ack the IRQ.
Disable the TWL6030 IRQ during suspend, enable
From: Charulatha V ch...@ti.com
The context lost count is modified in omap_sram_idle() path when
pwrdm_post_transition() is called. But pwrdm_post_transition() is called
only after omap_gpio_resume_after_idle() is called. Correct this so that
context lost count is modified before calling
From: Charulatha V ch...@ti.com
Currently gpio_context array used to save gpio bank's context, is used only for
OMAP3 architecture. Move gpio_context as part of gpio_bank structure so that it
can be specific to each gpio bank and can be used for any OMAP architecture
Signed-off-by: Charulatha V
From: Charulatha V ch...@ti.com
Non-wakeup GPIOs are available only in OMAP2. Avoid cpu_is checks by making
non_wakeup_gpios as part of pdata.
Signed-off-by: Charulatha V ch...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/gpio.c |8
From: Charulatha V ch...@ti.com
Remove cpu-is checks while enabling/disabling OMAP GPIO module during a gpio
request/free.
Signed-off-by: Charulatha V ch...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/gpio.c |2 +
From: Charulatha V ch...@ti.com
In omap3, save/restore context is implemented for GPIO banks 2-6 as GPIO bank1
is in wakeup domain. Instead of identifying bank's power domain by bank id,
use 'loses_context' flag which is filled by pwrdm_can_ever_lose_context()
during dev_init.
For getting the
From: Nishanth Menon n...@ti.com
Setup the interrupt enable registers only after we have configured the
required edge and required configurations, not before, to prevent
spurious events as part of restore routine.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Tarun Kanti DebBarma
From: Nishanth Menon n...@ti.com
GPIO IP revisions such as those used in OMAP4 have a set_dataout
while the previous revisions used a single dataout register.
Depending on what is available restore the dataout settings
to the right register.
Signed-off-by: Nishanth Menon n...@ti.com
This series is continuation of cleanup of OMAP GPIO driver and fixes.
The cleanup include getting rid of cpu_is_* checks wherever possible,
use of gpio_bank list instead of static array, use of unique platform
specific value associated data member to OMAP platforms to avoid
cpu_is_* checks. The
Wakeup enable register offset initialized according to OMAP versions
during device registration. Use this to avoid version checks.
Starting with OMAP4, legacy registers should not be used in combination
with the updated regsiters. Use wkup_en register consistently for
all SoCs wherever applicable.
From: Charulatha V ch...@ti.com
Modify omap_gpio_prepare_for_idle() omap_gpio_resume_after_idle() functions
to handle save context restore context respectively in the OMAP GPIO driver
itself instead of calling these functions from pm specific files.
For this, in gpio_prepare_for_idle(), call
From: Nishanth Menon n...@ti.com
GPIO debounce registers need to be saved and restored for proper functioning
of driver. To save the registers, we cannot cut the clock before the save,
hence move the clk disable after the save.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Tarun Kanti
Context is now saved dynamically in respective functions whenever and
whichever registers are modified. This avoid overhead of saving all
registers context in the runtime suspend callback.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar
By adding level and edge detection register offsets and then initializing them
correctly according to OMAP versions during device registrations we can now
remove
lot of revision checks in these functions.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Signed-off-by: Charulatha V
1 - 100 of 121 matches
Mail list logo
