Currently the fifo depth is set to zero for OMAP4 which disables
the FIFO usage. This patch enables the FIFO usage for I2C transactions
on OMAP4 also.
Tested on omap4430 and 3430.
Reported-By: Nishanth Menon n...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
Rebased on top of the
On Friday 01 July 2011 04:20 AM, Kevin Hilman wrote:
Shubhrajyotishubhrajy...@ti.com writes:
On Thursday 30 June 2011 04:53 AM, Kevin Hilman wrote:
Shubhrajyoti Dshubhrajy...@ti.com writes:
Currently the fifo depth is set to zero for OMAP4 which disables
the FIFO usage. This patch
Hi Tony
On Mon, 4 Jul 2011, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [110702 21:09]:
Here are some options that come to mind:
1. Wait until the driver runtime PM conversion is finished before doing
anything. In the meantime, boards with IP blocks that can't be reset
Currently the OMAP4 doesnot hit device off still the
driver may have support for it.Adding support for the
same.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
Applies on top of patches from Andy Green
http://www.spinics.net/lists/linux-i2c/msg05632.html
Tested on OMAP4430
Hi Samuel,
On Monday 04 July 2011 19:39:35 Samuel Ortiz wrote:
That is fine with me, yes. That's why I ACK the MFD patches for Tony to take
them.
I have changed the series for Tony in my branch for the following comments:
wl6040_is_powered, twl6040_get_rev removal, since these are really small
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Raphaël Assénat
Sent: Tuesday, July 05, 2011 12:59 AM
To: linux-omap@vger.kernel.org
Subject: AM3505/3517 support
Hello,
We have a custom designed based on the
Hi Arnd,
Please pull some fixes from:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
devel-fixes
These are intented for the merge window, there's no rush for
these to go in during the -rc cycle this late. I have one fix
queued for the -rc cycle still that I'll send
Changes compared to previous version:
- rebased on top of latest PM branch
- sparse interrupt numbering in use (thanks Felipe)
- removed duplicate pad mapping as proposed by Kevin
* io pad parsing done now in a support function provided by omap_hwmod
* see patch 4
- using Govindraj's ioring
From: R, Govindraj govindraj.r...@ti.com
Add API to enable IO pad wakeup capability based on mux dynamic pad and
wake_up enable flag available from hwmod_mux initialization.
Use the wakeup_enable flag and enable wakeup capability
for the given pads. Wakeup capability will be enabled/disabled
From: R, Govindraj govindraj.r...@ti.com
Add API to determine IO-PAD wakeup event status for a given
hwmod dynamic_mux pad.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/mux.c| 30 ++
arch/arm/mach-omap2/mux.h
Introduce a chained interrupt handler mechanism for the PRCM
interrupt, so that individual PRCM event can cleanly be handled by
handlers in separate drivers. We do this by introducing PRCM event
names, which are then matched to the particular PRCM interrupt bit
depending on the specific OMAP SoC
OMAP hwmod now provides a service routine to parse pending wakeup events
and to call registered ISR whenever active wakeups are detected. This
routine is called directly from PRCM interrupt handler.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c |
This is no longer needed as it will be handled within serial driver itself.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 19 ---
1 files changed, 0 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c
This patch is just a temporary hack to allow serial to work properly with
the PRCM chain handler. Should be replaced with a proper implementation.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/serial.c | 28 +---
drivers/tty/serial/omap-serial.c
This prevents system hang while attempting to access suspended console. Should
most likely be fixed with proper console locking.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git
These are no longer needed as omap_hwmod takes care of multiplexing of pads.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/serial.c | 25 +
1 files changed, 1 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c
This is handled automatically by the PRCM chain interrupt mechanism now.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index
Prevents a hang when omap_device would want to print something for
serial console device while enabling / disabling its clocks.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/plat-omap/omap_device.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git
Just for PRCM chain handler testing purposes. This should be replaced with
a proper implementation.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/serial.c | 71 -
1 files changed, 69 insertions(+), 2 deletions(-)
diff --git
* Paul Walmsley p...@pwsan.com [110705 00:35]:
Hi Tony
On Mon, 4 Jul 2011, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [110702 21:09]:
Here are some options that come to mind:
1. Wait until the driver runtime PM conversion is finished before doing
anything. In
Hi,
On Tue, Jul 05, 2011 at 01:27:47PM +0300, Tero Kristo wrote:
@@ -854,20 +802,35 @@ static int __init omap3_pm_init(void)
/* XXX prcm_setup_regs needs to be before enabling hw
* supervised mode for powerdomains */
prcm_setup_regs();
+ ret = omap_prcm_irq_init();
+
* Raphaël Assénat r...@8d.com [110704 12:51]:
The am3505 is apparently so similar to the 3430 that it was treated as such
(omap_chip.oc was being set to CHIP_IS_OMAP3430ES3_1). There are however a
few differences that need to be addressed. I have therefore created a new
CHIP_IS and patched
On Tue, 2011-07-05 at 13:18 +0200, Balbi, Felipe wrote:
Hi,
On Tue, Jul 05, 2011 at 01:27:47PM +0300, Tero Kristo wrote:
@@ -854,20 +802,35 @@ static int __init omap3_pm_init(void)
/* XXX prcm_setup_regs needs to be before enabling hw
* supervised mode for powerdomains */
On Tue, Jul 05, 2011 at 02:32:18PM +0300, Tero Kristo wrote:
On Tue, 2011-07-05 at 13:18 +0200, Balbi, Felipe wrote:
Hi,
On Tue, Jul 05, 2011 at 01:27:47PM +0300, Tero Kristo wrote:
@@ -854,20 +802,35 @@ static int __init omap3_pm_init(void)
/* XXX prcm_setup_regs needs to be
The gpmc clock on omap44xx is called gpmc_ick not gpmc_ck in
clock44xx_data.c
Signed-off-by: Jan Weitzel j.weit...@phytec.de
---
arch/arm/mach-omap2/gpmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index
Hi,
On Mon, Jul 04, 2011 at 12:01:24PM -0400, Alan Stern wrote:
On Mon, 4 Jul 2011, Felipe Balbi wrote:
sounds to me like a bug on pm runtime ? If you're calling
pm_runtime_*_sync() family, shouldn't all calls be _sync() too ?
No. This was a deliberate design decision. It minimizes
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Alan Stern
Sent: Monday, July 04, 2011 9:21 PM
To: Partha Basak
Cc: Keshava Munegowda; linux-...@vger.kernel.org; linux-
o...@vger.kernel.org; linux-ker...@vger.kernel.org;
On Tue, 5 Jul 2011, Felipe Balbi wrote:
The real problem here is that you guys are trying to use the runtime PM
framework to carry out activities during system suspend. That won't
work; it's just a bad idea all round. Use the proper callbacks to do
what you want.
then what's the
On Tue, 5 Jul 2011, Partha Basak wrote:
Note that the parent per-se does not have any .suspend .resume
hooked
up.
Why not? That sounds like a big bug.
This was a design decision since the parent needs to be activated only
when at-least one child is insmoded.
If the chidren are
On 05/07/11 07:19 AM, Tony Lindgren wrote:
* Raphaël Assénat r...@8d.com [110704 12:51]:
The am3505 is apparently so similar to the 3430 that it was treated as such
(omap_chip.oc was being set to CHIP_IS_OMAP3430ES3_1). There are however a
few differences that need to be addressed. I have
Hello every one,
I am using an over Fire with an omap3530. I have added a small Lithium backup
battery to the TWL4030 for RTC backup as recommanded by Gumstix.
I have tried to set the time with date command and shutdown the overo and
remove power. After restart the date is not the one that I
From: Keerthy j-keer...@ti.com
Patch adds hwmod entry for 4460 thermal sensor module. Thermal sensor module
is part of Control module sharing its address space and clocked via Bandgap
Functional Clock. Adding a seperate hwmod entry for thermal sensor will
enable thermal sensor driver to manage
Hi,
On Tue, Jul 05, 2011 at 10:17:14AM -0400, Alan Stern wrote:
On Tue, 5 Jul 2011, Felipe Balbi wrote:
The real problem here is that you guys are trying to use the runtime PM
framework to carry out activities during system suspend. That won't
work; it's just a bad idea all round.
Hi Patrick,
On Tue, Jul 05, 2011 at 02:35:12PM +, Gerber Patrick wrote:
I am using an over Fire with an omap3530. I have added a small Lithium
backup battery to the TWL4030 for RTC backup as recommanded by Gumstix.
I have tried to set the time with date command and shutdown the overo and
On Tue, 5 Jul 2011, Felipe Balbi wrote:
Well, of
course runtime PM will conserve power on runtime, but system suspend
should be no different other than an always deepest sleep state
decision.
No, it is significantly different for several reasons. Some of the
most important
+ Benoit
On 7/5/2011 5:19 AM, Jan Weitzel wrote:
The gpmc clock on omap44xx is called gpmc_ick not gpmc_ck in
clock44xx_data.c
Signed-off-by: Jan Weitzelj.weit...@phytec.de
This happened after renaming the clock-nodes some time back.
Looks good to me as a fix though in long run GPMC should be
From: Nori, Sekhar
Sent: Monday, July 04, 2011 10:30 PM
...
https://patchwork.kernel.org/patch/662941/
Yes, I like this idea - much cleaner. For example, the start() method
becomes (pseudo-code):
start()
{
/* bootaddrreg derived from platform data */
bootaddrreg =
From: Nori, Sekhar
Sent: Monday, July 04, 2011 10:35 PM
To: Grosen, Mark; Sergei Shtylyov
...
Since procedure to set the boot address varies across DaVinci
platforms, you could have a callback populated in platform data
which will be implemented differently for original DaVinci and
If an ARM system has multiple cpus in the same socket and the
kernel is booted with maxcpus=1, secondary cpus are possible but
not present due to how platform_smp_prepare_cpus() is called.
Since most typical ARM processors don't actually support physical
hotplug, initialize the present map to be
Alan Stern st...@rowland.harvard.edu writes:
[...]
You have ignored a few very important points:
Firstly, system suspend is supposed to work even when runtime PM is
not configured.
Secondly, the user can disable runtime PM via sysfs at any time.
This shouldn't mess up system suspend.
S, Venkatraman svenk...@ti.com writes:
From: Kevin Hilman khil...@ti.com
Date: Fri, Jul 1, 2011 at 11:24 PM
Subject: Re: [PATCHv4 0/3] OMAP: HSMMC: cleanup and runtime pm
To: c...@laptop.org
Cc: Balaji T K balaj...@ti.com, linux-omap@vger.kernel.org,
linux-...@vger.kernel.org,
Julia Lawall ju...@diku.dk writes:
From: Julia Lawall ju...@diku.dk
At this point, the ioremap has taken place, so the error handling code at
the label err_iounmap should be used rather than returning directly.
The semantic match that finds this problem is as follows:
On Fri, Jul 01, 2011 at 11:09:09PM +0200, Benoit Cousson wrote:
It is mandatory to wait for a module to be in disabled state before
potentially disabling source clock or re-asserting a reset.
omap_hwmod_idle and omap_hwmod_shutdown does not wait for
the module to be fully idle.
Add a
Shubhrajyoti shubhrajy...@ti.com writes:
On Monday 20 June 2011 09:05 PM, Kevin Hilman wrote:
shubhrajy...@ti.com writes:
From: Shubhrajyoti Dshubhrajy...@ti.com
Currently the OMAP4 doesnot hit device off still the
driver may have support for it.Adding support for the
same.
Santosh Shilimkar santosh.shilim...@ti.com writes:
+ Benoit
On 7/5/2011 5:19 AM, Jan Weitzel wrote:
The gpmc clock on omap44xx is called gpmc_ick not gpmc_ck in
clock44xx_data.c
Signed-off-by: Jan Weitzelj.weit...@phytec.de
This happened after renaming the clock-nodes some time back.
On 7/5/2011 11:35 AM, Kevin Hilman wrote:
Santosh Shilimkarsantosh.shilim...@ti.com writes:
+ Benoit
On 7/5/2011 5:19 AM, Jan Weitzel wrote:
The gpmc clock on omap44xx is called gpmc_ick not gpmc_ck in
clock44xx_data.c
Signed-off-by: Jan Weitzelj.weit...@phytec.de
This happened after
Hi Ben,
On Mon, 2011-06-27 at 15:15 -0700, Kevin Hilman wrote:
On Mon, 2011-06-27 at 15:12 -0700, Kevin Hilman wrote:
Ping. I don't see this in linux-next yet.
Are you planning to queue this for v3.1?
Oops, pushed send too soon on this...
As this series touches various data
Hi Tony
On Tue, 5 Jul 2011, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [110705 00:35]:
On Mon, 4 Jul 2011, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [110702 21:09]:
3. Merge the lazy/unused hwmod reset code, but disable the unused hwmod
reset code until
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
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
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
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.
Shubhrajyoti D shubhrajy...@ti.com writes:
Currently the fifo depth is set to zero for OMAP4 which disables
the FIFO usage. This patch enables the FIFO usage for I2C transactions
on OMAP4 also.
Tested on omap4430 and 3430.
Reported-By: Nishanth Menon n...@ti.com
Signed-off-by:
On Tue, Jul 5, 2011 at 17:01, Kevin Hilman khil...@ti.com wrote:
Shubhrajyoti D shubhrajy...@ti.com writes:
Currently the fifo depth is set to zero for OMAP4 which disables
the FIFO usage. This patch enables the FIFO usage for I2C transactions
on OMAP4 also.
Tested on omap4430 and
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
On OMAP4 we are not allowed to access wakeup_set/clear registers.
We are allowed, it is not recommended. Probably makes sense to
reference the TRM here. Basically, these are legacy registers and
starting with OMAP4, the legacy registers should
cc'ing Aaro
On Mon, 4 Jul 2011, Tony Lindgren wrote:
Also related is the gptimer12 on secure omaps as reported by Aaro.
This problem is actually worse. In this case it's not just preventing
reset; we must prevent the kernel from using the device at all. My
understanding is also that it's
On Tue, 5 Jul 2011, Paul Walmsley wrote:
For this case, we probably need some board file function to tell the
hwmod code to disregard a device completely, to tell the kernel to
pretend that the device does not exist.
... and the other problem here is that we currently probe devices via an
-Original Message-
From: Hilman, Kevin
Sent: Wednesday, July 06, 2011 5:22 AM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org; Shilimkar, Santosh; t...@atomide.com;
Varadarajan, Charulatha
Subject: Re: [PATCH v3 09/20] GPIO: OMAP: Use level/edge detect reg
offsets
Tarun
-Original Message-
From: Hilman, Kevin
Sent: Wednesday, July 06, 2011 6:21 AM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org; Shilimkar, Santosh; t...@atomide.com
Subject: Re: [PATCH v3 12/20] GPIO: OMAP: Use wkup_status for all SoCs
Tarun Kanti DebBarma
[..]
On OMAP4 we are not allowed to access wakeup_set/clear registers.
We are allowed, it is not recommended. Probably makes sense to
reference the TRM here. Basically, these are legacy registers and
starting with OMAP4, the legacy registers should not be used in
combination with the
Hi Mark,
On Tue, Jul 05, 2011 at 22:24:21, Grosen, Mark wrote:
From: Nori, Sekhar
Sent: Monday, July 04, 2011 10:35 PM
To: Grosen, Mark; Sergei Shtylyov
...
Since procedure to set the boot address varies across DaVinci
platforms, you could have a callback populated in platform
[...]
Test Details:
- Compile tested for omap1_defconfig and omap2plus_defconfig.
- OMAP1710-H3: Bootup test.
- OMAP2430-SDP, OMAP3430-SDP, OMAP4430-SDP: Functional testing.
Looks like the functional tests need to be expanded to set different
triggering modes, since they're failing
On Fri, 1 Jul 2011, Benoit Cousson wrote:
From: Santosh Shilimkar santosh.shilim...@ti.com
On OMAP4, CPU accesses on unmapped addresses are redirected to GPMC by
L3 interconnect. Because of CPU speculative nature, such accesses are
possible which can lead to indirect access to GPMC and if
On Fri, 1 Jul 2011, Benoit Cousson wrote:
From: Santosh Shilimkar santosh.shilim...@ti.com
On OMAP4430 devices, because of boot ROM code bug, MPU OFF state can't
be attempted independently. When coming out of MPU OFF state, ROM code
disables the clocks of IVAHD, TESLA which is not
Hi
On Thu, 23 Jun 2011, Russell King - ARM Linux wrote:
Do you really want to continue pissing Linus off with churn like this
rather than pressing to get problems fixed _properly_ (eg, getting the
HSMMC driver fixed) ?
Thanks for your comments. We won't queue this patch.
- Paul
--
To
On Thu, 26 May 2011, Vaibhav Bedia wrote:
The call to pwrdm_wait_transition() in clkdm_clk_enable()
is redundant since the function pwrdm_clkdm_state_switch()
which is called next also does the same thing.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Thanks, this patch has been queued
On Fri, 1 Jul 2011, Benoit Cousson wrote:
Since ES2.0, the core ocmram does not support a different state
than the main power domain anymore during both ON and RET power
domain state.
Since PM is not supported at all in ES1.0, update the common
structure.
LOWPOWERSTATECHANGE is supported
On Fri, 1 Jul 2011, Benoit Cousson wrote:
A couple of macros were wrongly changed during the _MOD to _INST
rename done in the following commit:
OMAP4: PRCM: rename _MOD macros to _INST
cdb54c4457d68994da7c2e16907adfbfc130060d
Fix them to their original name.
Some CM and PRM
On Fri, 1 Jul 2011, Benoit Cousson wrote:
The following commit introduced new macros to define an offset
per clock domain in an instance.
commit e4156ee52fe617c2c2d80b5db993ff4bf07d7c3c
OMAP4: CM instances: add clockdomain register offsets
The PRM contains only two clock controls
Hi
I split the indentation changes into the following patch, queued for 3.1
at git://git.pwsan.com/linux-2.6 in the 'prcm_cleanup_a_3.1' branch.
- Paul
From: Benoit Cousson b-cous...@ti.com
Date: Tue, 5 Jul 2011 23:44:32 -0600
Subject: [PATCH] OMAP4: powerdomain data: Fix indentation
68 matches
Mail list logo
