On Fri, 1 Jul 2011, Benoit Cousson wrote:
> From: Jon Hunter
>
> McASP2, 3 and MMC6 modules are not present in the OMAP4 family.
> Remove the fclk and the clksel related to these nodes.
> Rename the references that were potentially re-used in order nodes.
>
> Remove related macros in prcm heade
* Raphaël Assénat [110705 07:30]:
> On 05/07/11 07:19 AM, Tony Lindgren wrote:
> > * Raphaël Assénat [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
> >> fe
* Paul Walmsley [110705 14:42]:
> On Tue, 5 Jul 2011, Tony Lindgren wrote:
> >
> > Can't we always reset the registered hwmods automatically one at a time when
> > omap_device_build is called?
>
> The experimental series that I wrote, but haven't posted yet, resets each
> IP block during the fi
* Paul Walmsley [110705 18:55]:
> 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
* Paul Walmsley [110705 18:37]:
> 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 devi
On Wednesday 06 July 2011 12:01 AM, Kevin Hilman wrote:
Shubhrajyoti writes:
On Monday 20 June 2011 09:05 PM, Kevin Hilman wrote:
shubhrajy...@ti.com writes:
From: Shubhrajyoti D
Currently the OMAP4 doesnot hit device off still the
driver may have support for it.Adding support for the
same
Restore of context is not done for OMAP4. This patch
adds the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE in the OMAP4
hwmod which activates the restore for OMAP4.
Currently the OMAP4 doesnot hit device off still the
driver may have support for it.
Signed-off-by: Shubhrajyoti D
---
Applies on top of patch
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
Date: Tue, 5 Jul 2011 23:44:32 -0600
Subject: [PATCH] OMAP4: powerdomain data: Fix indentation
MIME-Version: 1.0
Content
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 con
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 PR
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 supp
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
Thanks, this patch has been queued for 3.1 at
git
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 un
On Fri, 1 Jul 2011, Benoit Cousson wrote:
> From: Santosh Shilimkar
>
> 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 desirable. Hence the
> MPU OF
On Fri, 1 Jul 2011, Benoit Cousson wrote:
> From: Santosh Shilimkar
>
> 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 it's clock is
> not r
[...]
>
> > 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'r
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
[..]
>
> > 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 wit
> -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 writes:
> -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
>
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
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 th
Tarun Kanti DebBarma 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 not be used in
comb
On Tue, Jul 5, 2011 at 17:01, Kevin Hilman wrote:
>
> Shubhrajyoti D 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-B
Shubhrajyoti D 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
> Signed-off-by: Shubhrajyoti D
> ---
> Rebased on
Tarun Kanti DebBarma writes:
> From: Charulatha V
>
> 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
Tarun Kanti DebBarma 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 member to OMAP plat
Hi Tony
On Tue, 5 Jul 2011, Tony Lindgren wrote:
> * Paul Walmsley [110705 00:35]:
> > On Mon, 4 Jul 2011, Tony Lindgren wrote:
> > > * Paul Walmsley [110702 21:09]:
> > >
> > > > 3. Merge the lazy/unused hwmod reset code, but disable the unused hwmod
> > > >reset code until the driver ru
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 va
On 7/5/2011 11:35 AM, Kevin Hilman wrote:
Santosh Shilimkar 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 Weitzel
This happened after renaming the clock-nodes some time back.
Looks g
Santosh Shilimkar 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 Weitzel
> This happened after renaming the clock-nodes some time back.
> Looks good to me as a fix though i
Shubhrajyoti writes:
> On Monday 20 June 2011 09:05 PM, Kevin Hilman wrote:
>> shubhrajy...@ti.com writes:
>>
>>> From: Shubhrajyoti D
>>>
>>> Currently the OMAP4 doesnot hit device off still the
>>> driver may have support for it.Adding support for the
>>> same.
>>>
>>> Signed-off-by: Shubhrajyo
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
Julia Lawall writes:
> From: Julia Lawall
>
> 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:
> (http://coccinelle.lip6.fr/)
>
> //
> @r
"S, Venkatraman" writes:
>> From: Kevin Hilman
>> 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 , linux-omap@vger.kernel.org,
>> linux-...@vger.kernel.org, t...@atomide.com, madhu...@ti.com,
>> b-cous
Alan Stern 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.
>>>
>>>Basical
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 eq
> 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 DaV
> 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 */
> >
+ 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 Weitzel
This happened after renaming the clock-nodes some time back.
Looks good to me as a fix though in long run GPMC should be
moved to hwmod to a
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
>
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 an
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
From: Keerthy
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 its clock cleanly u
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 hav
On 05/07/11 07:19 AM, Tony Lindgren wrote:
> * Raphaël Assénat [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 there
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 t
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
>-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.or
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 minim
The gpmc clock on omap44xx is called gpmc_ick not gpmc_ck in
clock44xx_data.c
Signed-off-by: Jan Weitzel
---
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 130034b..34bcd17 100644
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
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 *
* Raphaël Assénat [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 clocks,
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();
* Paul Walmsley [110705 00:35]:
> Hi Tony
>
> On Mon, 4 Jul 2011, Tony Lindgren wrote:
>
> > * Paul Walmsley [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 meant
Just for PRCM chain handler testing purposes. This should be replaced with
a proper implementation.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/serial.c | 71 -
1 files changed, 69 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/se
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
---
arch/arm/plat-omap/omap_device.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/omap_
This is handled automatically by the PRCM chain interrupt mechanism now.
Signed-off-by: Tero Kristo
---
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 34feff4..8b05f14 1006
These are no longer needed as omap_hwmod takes care of multiplexing of pads.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/serial.c | 25 +
1 files changed, 1 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
i
This prevents system hang while attempting to access suspended console. Should
most likely be fixed with proper console locking.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/pm34xx.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/
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
---
arch/arm/mach-omap2/serial.c | 28 +---
drivers/tty/serial/omap-serial.c |8
This is no longer needed as it will be handled within serial driver itself.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/pm34xx.c | 19 ---
1 files changed, 0 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index d8
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
---
arch/arm/mach-omap2/omap_hwmod.c | 19 ++
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 be
From: R, Govindraj
Add API to determine IO-PAD wakeup event status for a given
hwmod dynamic_mux pad.
Signed-off-by: Govindraj.R
---
arch/arm/mach-omap2/mux.c| 30 ++
arch/arm/mach-omap2/mux.h| 13 +++
arch/arm/mach-om
From: R, Govindraj
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
during hwmod idle transit
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 su
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 sepa
> -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
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 smal
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
---
Applies on top of patches from Andy Green
http://www.spinics.net/lists/linux-i2c/msg05632.html
Tested on OMAP4430
arch/arm/mach-omap2/omap_hwmod_44x
Hi Tony
On Mon, 4 Jul 2011, Tony Lindgren wrote:
> * Paul Walmsley [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
> >
On Friday 01 July 2011 04:20 AM, Kevin Hilman wrote:
Shubhrajyoti writes:
On Thursday 30 June 2011 04:53 AM, Kevin Hilman wrote:
Shubhrajyoti D 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
o
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
Signed-off-by: Shubhrajyoti D
---
Rebased on top of the series by Andy Green
http://www
75 matches
Mail list logo
