> -Original Message-
> From: Kevin Hilman [mailto:khil...@ti.com]
> Sent: Thursday, March 03, 2011 5:16 AM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH 00/17] omap4: pm: suspend, hotplug and cpuilde
> support
>
> Santos
On Thu, 03 Mar 2011 06:22:36 +0530
Nishanth Menon wrote:
> Kevin Hilman wrote, on 03/03/2011 06:18 AM:
> > Nishanth Menon writes:
> >> Looks like a nice cleanup to me.
> >>
> >> if the motivation of patch 1/3 is to do this cleanup, I am altogether
> >> for it (lesser code == lesser bugs ;) ). bt
Hi,
On Wed, 2011-03-02 at 23:29 -0600, K, Mythri P wrote:
> Hi Tomi,
> I just rechecked the TRM.
> The TRM description of the bit is VENC_HDMI_switch , Wouldnt it be
> appropriate to have the same
> name for the enum and the variables as suggested by you.
Please don't top-post when posting to mai
Hi Benoît,
On Tue, 1 Mar 2011, Cousson, Benoit wrote:
> So to conclude, I will drop the #3 and just push #1 and #2.
>
> #1 is fine with addition of the WARN.
We should probably drop this one now that _setup() is allowed to be called
on hwmods that have already been setup (commit 48d54f3f).
>
Hi Tomi,
I just rechecked the TRM.
The TRM description of the bit is VENC_HDMI_switch , Wouldnt it be
appropriate to have the same
name for the enum and the variables as suggested by you.
Thanks and regards,
Mythri.
On Thu, Mar 3, 2011 at 9:57 AM, K, Mythri P wrote:
> Hi Tomi,
>
> On Tue, Mar 1,
Hi,
>-Original Message-
>From: Govindraj [mailto:govindraj...@gmail.com]
>Sent: Wednesday, March 02, 2011 3:37 PM
>To: Sricharan R
>Cc: Govindraj.R; linux-omap@vger.kernel.org;
linux-ser...@vger.kernel.org;
>linux-arm-ker...@lists.infradead.org; Jon Hunter; Tony Lindgren; Benoit
>Cousson; K
Hi Tomi,
I have checked for static functions :) .
Ok i will revisit the global variables to either move it to hdmi
struct or make it const.
Thanks and regards,
Mythri.
On Tue, Mar 1, 2011 at 11:07 PM, Tomi Valkeinen wrote:
> On Tue, 2011-03-01 at 08:16 -0600, K, Mythri P wrote:
>> Adding the hdm
On Tue, Mar 1, 2011 at 10:41 PM, Tomi Valkeinen wrote:
> On Tue, 2011-03-01 at 08:16 -0600, K, Mythri P wrote:
>> The panel driver(hdmi_omap4_panel.c) in dss file acts as a controller
>> to manage the enable and disable requests and synchronize audio and video.
>> Also the header file to export th
Hi Tomi,
On Tue, Mar 1, 2011 at 10:31 PM, Tomi Valkeinen wrote:
> On Tue, 2011-03-01 at 08:16 -0600, K, Mythri P wrote:
>> Adding changes to set gamma table bit for TV interface and function to select
>> between VENC and HDMI.
>>
>> Signed-off-by: Mythri P K
>> ---
>> drivers/video/omap2/dss/di
On Wed, Mar 2, 2011 at 7:44 PM, Tony Lindgren wrote:
> * Armando Uribe [110302 13:54]:
>> From: Hari Kanigeri
>>
>> omap4 interrupt disable bits is different. On rx kfifo full, the mbox rx
>> interrupts wasn't getting disabled, and this is causing the rcm stress tests
>> to hang.
>>
>> Signed-of
* Armando Uribe [110302 13:54]:
> From: Hari Kanigeri
>
> omap4 interrupt disable bits is different. On rx kfifo full, the mbox rx
> interrupts wasn't getting disabled, and this is causing the rcm stress tests
> to hang.
>
> Signed-off-by: Hari Kanigeri
> Signed-off-by: Armando Uribe
> Signed
* Kevin Hilman [110302 13:14]:
> Kishore Kadiyala writes:
>
> > Adding hwmod data for hsmmc device on OMAP2430/OMAP3/OMAP4.
> > Adapting the omap_hsmmc driver to hwmod framework.
>
> Looks OK to me.
>
> Reviewed-by: Kevin Hilman
Sorry just missed it, got it all merged into omap-for-linus alr
* Michael Buesch [110302 08:09]:
> Make the WDT driver fully preemptible.
> This is required in order to apply a locking fix to retu_write_reg.
> It also improves power management by using round_relative_jiffies().
Thanks, seems to stay running, so applying all your remaining patches
to the cbus
Kevin Hilman wrote, on 03/03/2011 06:30 AM:
Nishanth Menon writes:
- Please Cc linux-arm-kernel for patches intended for mainline. Because
of this, I didn't (yet) queue the ones I said I would queue.
done that with v2 which I had happened to have posted yesterday :(:
http://marc.info/?l
Kevin Hilman wrote, on 03/03/2011 06:29 AM:
Nishanth Menon writes:
Kevin Hilman wrote, on 03/03/2011 05:45 AM:
Nishanth Menon writes:
We will enable and disable interrupt on a need basis in the class
driver. we need to keep the irq disabled by default else the
forceupdate or vcbypass even
Hi Santosh,
Santosh Shilimkar writes:
> The series does below fixes to the omap3 low power code.
> 1. Use supported ARMv7 instructions instead of the legacy ones
> 2. Fix the MMU on sequence
> 3. Fix the cache flush scenario when only L1 lost.
> 4. Remove all un-necessary
Kevin Hilman wrote, on 03/03/2011 06:27 AM:
Nishanth Menon writes:
Kevin Hilman wrote, on 03/03/2011 05:38 AM:
Nishanth Menon writes:
Certain class drivers such as class 1.5 drivers, will need specific
notification that they have to be started up or stopped independent
of smart reflex ope
* Ilkka Koskinen [110225 00:48]:
Adding for the merge window with updated description
"Add support for vibra".
Tony
> Signed-off-by: Ilkka Koskinen
> ---
> arch/arm/mach-omap2/board-rx51-peripherals.c |9 +
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/arch/
* Guy Eilam [110224 22:52]:
> Added the KIM (Kernel initialization module for the
> Shared Transport driver) device entry in the board file
>
> Only the Blutooth enable GPIO is set for now
Adding for the merge window.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap"
Nishanth Menon writes:
>>
>> - Please Cc linux-arm-kernel for patches intended for mainline. Because
>>of this, I didn't (yet) queue the ones I said I would queue.
> done that with v2 which I had happened to have posted yesterday :(:
> http://marc.info/?l=linux-omap&m=129906334611444&w=2
Do
* Rajendra Nayak [110224 04:54]:
> On the OMAP3430LDP board, the ads7846 touchscreen controller
> is powered by VAUX1 regulator (supplying 3.0v).
> Fix this mapping in the board file, and hence prevent
> the ads7846 driver init to fail with the below error..
>
> ads7846 spi1.0: unable to get regu
Nishanth Menon writes:
> Kevin Hilman wrote, on 03/03/2011 05:45 AM:
>> Nishanth Menon writes:
>>
>>> We will enable and disable interrupt on a need basis in the class
>>> driver. we need to keep the irq disabled by default else the
>>> forceupdate or vcbypass events could trigger events that we
Nishanth Menon writes:
> Kevin Hilman wrote, on 03/03/2011 05:38 AM:
>> Nishanth Menon writes:
>>
>>> Certain class drivers such as class 1.5 drivers, will need specific
>>> notification that they have to be started up or stopped independent
>>> of smart reflex operation. They also may need priv
Nishanth Menon writes:
[...]
>
> Does the following sound any better?:
Yes, thanks.
> Blindly setting a 1.2v setting in the initial structure may not even
> match the default voltages stored in the voltage table which are
> supported for the domain. For example, OMAP3430 core domain does not
>
Kevin Hilman wrote, on 03/03/2011 06:18 AM:
Nishanth Menon writes:
Jarkko Nikula wrote, on 03/02/2011 09:27 PM:
sr_start_vddautocomp and sr_stop_autocomp functions can be reused from
omap_sr_enable, omap_sr_disable and omap_sr_disable_reset_volt and by
adding one additional argument sr_stop_a
Nishanth Menon writes:
> Jarkko Nikula wrote, on 03/02/2011 09:27 PM:
>> sr_start_vddautocomp and sr_stop_autocomp functions can be reused from
>> omap_sr_enable, omap_sr_disable and omap_sr_disable_reset_volt and by
>> adding one additional argument sr_stop_autocomp.
>>
>> Signed-off-by: Jarkko
Kevin Hilman wrote, on 03/03/2011 05:47 AM:
[..]
diff --git a/arch/arm/plat-omap/include/plat/smartreflex.h
b/arch/arm/plat-omap/include/plat/smartreflex.h
index 8b6ecd9..ff07d1e 100644
--- a/arch/arm/plat-omap/include/plat/smartreflex.h
+++ b/arch/arm/plat-omap/include/plat/smartreflex.h
@@ -
Kevin Hilman wrote, on 03/03/2011 05:41 AM:
Nishanth Menon writes:
Request the handler irq such that there is no nesting for calls.
the notifiers are not expected to be nested, further the interrupt
events for status change should be handled prior to the next event
else there is a risk of loos
Hi Jean,
jean.pi...@newoldbits.com writes:
> From: Jean Pihet
>
> The patch adds the new power management trace points for
> the OMAP architecture.
There are some other core clock/powerdomain changes queued for 2.6.39
ahead of this that conflict with your patch.
Could you rebase this against m
Kevin Hilman wrote, on 03/03/2011 05:18 AM:
Nishanth Menon writes:
OMAP3 smartreflex irqs in hwmod structures with the same naming as
present in OMAP4. Without these IRQs being registered, SmartReflex
driver will be unable to get the irq numbers to handle notifications
Signed-off-by: Nishanth
Kevin Hilman wrote, on 03/03/2011 05:38 AM:
Nishanth Menon writes:
Certain class drivers such as class 1.5 drivers, will need specific
notification that they have to be started up or stopped independent
of smart reflex operation. They also may need private data to be
used for operations of the
Kevin Hilman wrote, on 03/03/2011 06:03 AM:
- Please capitalize acronyms throughout the
subjects/comments/changelogs. This series tends to mix lower-case and
upper case acronyms
Ack. thanks for catching it.
- Please Cc linux-arm-kernel for patches intended for mainline. Because
of
Kevin Hilman wrote, on 03/03/2011 05:22 AM:
"Menon, Nishanth" writes:
On Wed, Feb 23, 2011 at 14:29, Vishwanath Sripathy wrote:
-Original Message-
From: Menon, Nishanth [mailto:n...@ti.com]
Sent: Wednesday, February 23, 2011 1:48 PM
To: Vishwanath Sripathy
Cc: linux-omap; Tony Lindgr
Hi Nishanth,
Nishanth Menon writes:
> Hi,
> This series intends to introduce SmartReflex AVS Class 1.5 support which
> is now the recommended AVS class for usage in OMAP3630, OMAP4 an potentially
> in later generation of silicon as well. Smartreflex class 1.5 is a software
> controlled hardware
Shweta Gulati writes:
> From: Thara Gopinath
>
> Voltage control on TWL can be done using VMODE/I2C1/I2C_SR.
> Since almost all platforms use I2C_SR on omap3, omap3_twl_init by
> default expects that OMAP's I2C_SR is plugged in to TWL's I2C
> and calls omap3_twl_set_sr_bit. On platforms where I2
Kevin Hilman wrote, on 03/03/2011 05:45 AM:
Nishanth Menon writes:
We will enable and disable interrupt on a need basis in the class
driver. we need to keep the irq disabled by default else the
forceupdate or vcbypass events could trigger events that we dont
need/expect to handle.
It's not c
Nishanth Menon writes:
> At times with bad SR configurations especially during silicon bringups,
> we could get continuous spurious interrupts which end up hanging the
> platform in the form of an ISR call for status bits that are
> automatically enabled by the h/w without any s/w clearing option
Nishanth Menon writes:
> SmartReflex IP v1 and v2 have different registers and offsets.
> Currently, we pass the status as is to the class driver. However,
> since we dont pass the version of the underlying SR hardware
> to the Class driver, it will not be unable to make consistent
> sense of the
Nishanth Menon writes:
> We will enable and disable interrupt on a need basis in the class
> driver. we need to keep the irq disabled by default else the
> forceupdate or vcbypass events could trigger events that we dont
> need/expect to handle.
It's not clear from the patch where the IRQ is re-
Nishanth Menon writes:
> Request the handler irq such that there is no nesting for calls.
> the notifiers are not expected to be nested, further the interrupt
> events for status change should be handled prior to the next event
> else there is a risk of loosing events.
>
> Signed-off-by: Nishanth
Nishanth Menon writes:
> Error label case seems to have a 2 tab indentation when just 1 is
> necessary.
>
> Signed-off-by: Nishanth Menon
Thanks, queueing for 2.6.39 after capitalizing OMAP and SR in subject.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the
Nishanth Menon writes:
> Certain class drivers such as class 1.5 drivers, will need specific
> notification that they have to be started up or stopped independent
> of smart reflex operation. They also may need private data to be
> used for operations of their own, provide the same.
>
> Signed-of
Nishanth Menon writes:
> Interrupt notification mechanism of SmartReflex can be used by the
> choice of implementation of the class driver. For example, Class 2 and
> Class 1.5 of SmartReflex can both use the interrupt notification to
> identify the transition of voltage or other events.
>
> Henc
"Menon, Nishanth" writes:
> On Wed, Feb 23, 2011 at 14:29, Vishwanath Sripathy
> wrote:
>>> -Original Message-
>>> From: Menon, Nishanth [mailto:n...@ti.com]
>>> Sent: Wednesday, February 23, 2011 1:48 PM
>>> To: Vishwanath Sripathy
>>> Cc: linux-omap; Tony Lindgren; Kevin Hilman
>>> Su
Nishanth Menon writes:
> OMAP3 smartreflex irqs in hwmod structures with the same naming as
> present in OMAP4. Without these IRQs being registered, SmartReflex
> driver will be unable to get the irq numbers to handle notifications
>
> Signed-off-by: Nishanth Menon
minor: IRQ is an acronym, ple
Santosh Shilimkar writes:
> This series adds OMAP4 suspend and cpuidle support till MPU subsystem
> (MPUSS) off-mode. The suspend on SMP machines uses cpu-hotplug
> infrastructure to take down the non-boot CPUs. We put secondary
> CPU(CPU1 in OMAP4) to OFF state via cpu-hotplug.
> In cpuidle too
Santosh Shilimkar writes:
> The SGI(Software Generated Interrupts) are not wakeup capable from
> low power states. This is known limitation on OMAP4 and needs to be
> worked around by using software forced clockdomain wake-up. CPU0 forces
> the CPU1 clockdomain to software force wakeup. After the
Santosh Shilimkar writes:
> Only MPU OFF and RET is controllable. CORE state is blocked
> at ON state till the CORE RET support is added.
-ECONFUSED
None of the C-states currently have CORE != ON:
./cpuidle44xx.c:219:omap4_power_states[OMAP4_STATE_C1].core_state =
PWRDM_POWER_ON;
./cpui
Santosh Shilimkar writes:
> This patch adds MPUSS low power states in cpuidle.
>
> C1 - CPU0 ON + CPU1 ON/OFF + MPU ON + CORE ON
> C2 - CPU0 ON + CPU1 OFF + MPU ON + CORE ON
> C3 - CPU0 OFF + CPU1 OFF + MPU CSWR + CORE ON
> C4 - CPU0 OFF + CPU1 OFF + MPU OFF + CORE ON
>
>
Santosh Shilimkar writes:
> From: Rajendra Nayak
>
> The patch adds a basic CPUidle driver for OMAP4. Just
> one C state is registered for both CPU cores which
> does a wfi.
s/wfi/WFI/
> Signed-off-by: Rajendra Nayak
> Signed-off-by: Santosh Shilimkar
> Reviewed-by: Kevin Hilman
Mostly min
Santosh Shilimkar writes:
> This patch adds configurable wakeup timer support in suspend. Also
> for statistics pm counter support is added.
>
> Signed-off-by: Santosh Shilimkar
> Reviewed-by: Kevin Hilman
> ---
> arch/arm/mach-omap2/omap4-mpuss-lowpower.c |8
> arch/arm/mach-omap
Santosh Shilimkar writes:
> This patch adds MPUSS(MPU Sub System) RET and OFF mode support
> to suspend path. For both MPUSS RET and OFF support, CPUs are
> programmed to OFF state.
>
> Only MPUSS RET and OFF supported at this point of time. CORE RET
> will be added subsequently.
>
> Signed-off-b
Santosh Shilimkar writes:
> When MPUSS hits off-mode e, L2 cache is lost. This patch adds L2X0
> necessary maintenance operations and context restoration in the
> low power code.
>
> Signed-off-by: Santosh Shilimkar
> Reviewed-by: Kevin Hilman
> ---
> arch/arm/mach-omap2/omap4-mpuss-lowpower.c
Santosh Shilimkar writes:
> WakeupGen is lost only when device hits off-mode. Though the register
> context is retained in MPUSS OFF/OSWR state, hardware recommondation is
> to save/restore WakeupGen along with GIC to have consistent interrupt
> state at both the blocks. The ROM code restore mech
Santosh Shilimkar writes:
> On OMAP4 when attempting MPU off-mode or OSWR, the GIC context is
> lost. This patch adds GIC context save and restore support.
>
> The context save is done by software and restore is done by
> ROM code from predefined SAR locations where the context suppose
s/suppose
Santosh Shilimkar writes:
> The SGI(Software Generated Interrupts) are not wakeup capable from
> low power states. This is known limitation on OMAP4 and needs to be
> worked around by using software forced clockdomain wake-up. CPU0 forces
> the CPU1 clockdomain to software force wakeup. After the
Santosh Shilimkar writes:
> Initialise hardware supervised mode for all clockdomains if it's
> supported. Initiate sleep transition for other clockdomains,
> if they are not being used.
>
> Signed-off-by: Santosh Shilimkar
> Signed-off-by: Rajendra Nayak
> Reviewed-by: Kevin Hilman
> ---
> ar
Santosh Shilimkar writes:
> This patch adds the CPU0 and CPU1 off mode support. CPUX close switch
s/CPUX/CPUx/
> retention (CSWR) is not supported by hardware design.
>
> The CPUx OFF mode isn't supported on OMAP4430 ES1.0
>
> CPUx sleep code is common for hotplug, suspend and cpuilde.
s/cpuil
Santosh Shilimkar writes:
> The scu base address needs to be accessed in cpu hotplug
> for power management. Hence export the same
As with previous patch, rather than export the base address itself, it
should export a helper function to get the base address
Kevin
> Signed-off-by: Santosh Shili
From: Hari Kanigeri
omap4 interrupt disable bits is different. On rx kfifo full, the mbox rx
interrupts wasn't getting disabled, and this is causing the rcm stress tests
to hang.
Signed-off-by: Hari Kanigeri
Signed-off-by: Armando Uribe
Signed-off-by: Fernando Guzman Lugo
---
arch/arm/mach-o
Santosh Shilimkar writes:
> This patch adds SAR RAM support on OMAP4430. SAR RAM used to save
> and restore the HW context in low power modes.
>
> Signed-off-by: Santosh Shilimkar
> Reviewed-by: Kevin Hilman
> ---
> arch/arm/mach-omap2/omap4-common.c | 25 -
>
Hi Santosh,
Santosh Shilimkar writes:
> This patch adds OMAP WakeupGen support. The WakeupGen unit is responsible
> for generating wakeup event from the incoming interrupts and enable bits.
> The WakeupGen is implemented in MPU Always-On power domain. During normal
> operation, WakeupGen deliver
Kishore Kadiyala writes:
> Adding hwmod data for hsmmc device on OMAP2430/OMAP3/OMAP4.
> Adapting the omap_hsmmc driver to hwmod framework.
Looks OK to me.
Reviewed-by: Kevin Hilman
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majo
Vishwanath Sripathy writes:
> Kevin,
>
>> -Original Message-
>> From: Kevin Hilman [mailto:khil...@ti.com]
>> Sent: Wednesday, March 02, 2011 2:32 AM
>> To: Vishwanath BS
>> Cc: linux-omap@vger.kernel.org; patc...@linaro.org
>> Subject: Re: [PATCH 1/3] OMAP3 PM: Deny clock gating only for
Balaji,
On Mon, 7 Feb 2011, Paul Walmsley wrote:
> On Wed, 19 Jan 2011, Paul Walmsley wrote:
>
> > On Wed, 19 Jan 2011, Paul Walmsley wrote:
> >
> > > On Wed, 19 Jan 2011, Krishnamoorthy, Balaji T wrote:
> > >
> > > > in ES1, timeouts were observed only with RTC.
> > > > I2C burst access to IR
* Michael Buesch [110228 12:43]:
>
> The hwmod code performs a soft-reset on the GPIO
> module. The first GPIO module carries the MIPID
> "nreset" line, which is toggled due to the hwmod soft reset.
> This resets Blizzard and breaks it, because
> it assumes the LCD was left in the state that the
* Govindraj [110302 02:05]:
>
> +static struct omap_device_pad default_serial1_pads[] __initdata = {
> + {
> + .name = "uart2_rx.uart2_rx",
> + .flags = OMAP_DEVICE_PAD_REMUX |
> > OMAP_DEVICE_PAD_WAKEUP,
> + .enable = OMAP_MUX_MOD
Either OMAP_MMC_STAT_CARD_ERR or OMAP_MMC_STAT_END_OF_CMD might
fire if there is no host->cmd pointer.
Check for a valid host->cmd pointer before calling mmc_omap_cmd_done().
Signed-off-by: Michael Buesch
Acked-by: Tony Lindgren
---
Fixes
[3.814483] Unable to handle kernel NULL pointer de
* Michael Buesch [110227 03:36]:
> Either OMAP_MMC_STAT_CARD_ERR or OMAP_MMC_STAT_END_OF_CMD might
> fire if there is no host->cmd pointer.
> Check for a valid host->cmd pointer before calling mmc_omap_cmd_done().
>
> Signed-off-by: Michael Buesch
Can you please resend this to the MMC list?
Ac
* Premi, Sanjeev [110226 00:27]:
> > -Original Message-
> > From: Tony Lindgren [mailto:t...@atomide.com]
> > Sent: Friday, February 25, 2011 11:47 PM
> > To: Premi, Sanjeev
> > Cc: linux-omap@vger.kernel.org
> > Subject: Re: [PATCH] omap2plus: Remove auto selection on PMICs
> >
> > * San
> On 2/28/2011 3:31 AM, Paul Walmsley wrote:
> >Tony, I guess the omap-for-linus branch will probably need to get rebuilt
> >to drop that patch, once this series is merged...
Let's rather apply a fix or revert instead than start messing with
omap-for-linus. That branch is supposed to be a stable b
Sergei Shtylyov wrote, on 03/02/2011 11:09 PM:
I wrote:
Request the handler irq such that there is no nesting for calls.
the notifiers are not expected to be nested, further the interrupt
events for status change should be handled prior to the next event
else there is a risk of loosing events.
I wrote:
Request the handler irq such that there is no nesting for calls.
the notifiers are not expected to be nested, further the interrupt
events for status change should be handled prior to the next event
else there is a risk of loosing events.
Signed-off-by: Nishanth Menon
---
arch/arm/
* Tomi Valkeinen [110228 22:27]:
> On Mon, 2011-02-28 at 19:39 -0600, Tony Lindgren wrote:
> > * Tomi Valkeinen [110228 07:07]:
> > >
> > > Well, it's a bit ugly, but I'm fine with it. It's for the old omapfb,
> > > which hopefully nobody uses anymore (right =), and there's no simple way
> > > t
Hi Samuel,
* Samuel Ortiz [110302 06:32]:
> Hi Ilkka,
>
> On Wed, Mar 02, 2011 at 03:24:04PM +0200, Ilkka Koskinen wrote:
> > This series of patches removes duplicate audio_mclk fields from
> > twl4030_codec driver.
> >
> > The patches have been compiled on sound-2.6/for-2.6.39 branch.
> > I ha
> -Original Message-
> From: Kevin Hilman [mailto:khil...@ti.com]
> Sent: Wednesday, March 02, 2011 3:15 AM
> To: Vishwanath BS
> Cc: linux-omap@vger.kernel.org; patc...@linaro.org
> Subject: Re: [PATCH 3/3] OMAP36xx PM: Updated C state latencies for
> OMAP3630
>
> Vishwanath BS writes:
>
Sergei Shtylyov wrote, on 03/02/2011 07:08 PM:
Hello.
On 02-03-2011 13:55, Nishanth Menon wrote:
Request the handler irq such that there is no nesting for calls.
the notifiers are not expected to be nested, further the interrupt
events for status change should be handled prior to the next even
Kevin,
> -Original Message-
> From: Kevin Hilman [mailto:khil...@ti.com]
> Sent: Wednesday, March 02, 2011 2:32 AM
> To: Vishwanath BS
> Cc: linux-omap@vger.kernel.org; patc...@linaro.org
> Subject: Re: [PATCH 1/3] OMAP3 PM: Deny clock gating only for safe
> state
>
> Vishwanath BS writes
Sergei Shtylyov wrote, on 03/02/2011 07:15 PM:
[...]
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 49a04ea..d62da3d 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -209,8 +209,16 @@ static irqreturn_t sr_interrup
Jarkko Nikula wrote, on 03/02/2011 09:27 PM:
sr_start_vddautocomp and sr_stop_autocomp functions can be reused from
omap_sr_enable, omap_sr_disable and omap_sr_disable_reset_volt and by
adding one additional argument sr_stop_autocomp.
Signed-off-by: Jarkko Nikula
---
arch/arm/mach-omap2/smartr
Jarkko Nikula wrote, on 03/02/2011 09:27 PM:
Currently it is possible to enable multiple times the smartreflex class
driver from userspace via ../smartreflex/autocomp debugfs entry. Fix this
by checking the autocomp_active state in sr_start_vddautocomp.
Signed-off-by: Jarkko Nikula
---
Not known
Tony,
Kevin Hilman writes:
> Here's a final batch of PM fixes for the 2.6.38-rc cycle.
I just noticed that a couple of these were already queued in your last
pull request to Linus.
Here's an updated pull request based on .38-rc7.
Kevin
The following changes since commit dd9c1549edef02290edce
David,
On Wed, Mar 2, 2011 at 5:58 AM, David Cohen wrote:
> Hi,
>
> On Tue, Mar 1, 2011 at 9:46 PM, Fernando Guzman Lugo
> wrote:
>> From: Ramesh Gupta
>
> No patch body description at all?
> Can we get at least something here?
My apologies, I will be sending an updated patch
with description.
Hi Santosh,
On Wed, Mar 2, 2011 at 6:48 AM, Santosh Shilimkar
wrote:
> Hello,
>> -Original Message-
>> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
>> ow...@vger.kernel.org] On Behalf Of Fernando Guzman Lugo
>> Sent: Wednesday, March 02, 2011 1:17 AM
>> To: hiroshi.d...@noki
This removes nonstandard interfaces from the WDT driver.
/dev/watchdog should be used to access the watchdog, only.
It removes the sysfs interface.
It also removes the "counter_param" module parameter, which
currently is broken anyway (doesn't work, because the value
is overridden right away).
Si
An unsigned int pointer must not be casted to an unsigned
long pointer before use. Convert the bitfield to unsigned long
to fix this.
Also use clear_bit() in the release path.
Signed-off-by: Michael Buesch
---
Index: linux-2.6.38-rc6/drivers/cbus/retu-wdt.c
=
Make the WDT driver fully preemptible.
This is required in order to apply a locking fix to retu_write_reg.
It also improves power management by using round_relative_jiffies().
Signed-off-by: Michael Buesch
---
Tony, thanks for the report on this issue.
You may apply the locking fix on to of thi
sr_start_vddautocomp and sr_stop_autocomp functions can be reused from
omap_sr_enable, omap_sr_disable and omap_sr_disable_reset_volt and by
adding one additional argument sr_stop_autocomp.
Signed-off-by: Jarkko Nikula
---
arch/arm/mach-omap2/smartreflex.c | 41 ++--
This is mostly preparation for another patch that takes these functions into
use from omap_sr_enable and omap_sr_disable.
Signed-off-by: Jarkko Nikula
---
arch/arm/mach-omap2/smartreflex.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/smartref
Currently it is possible to enable multiple times the smartreflex class
driver from userspace via ../smartreflex/autocomp debugfs entry. Fix this
by checking the autocomp_active state in sr_start_vddautocomp.
Signed-off-by: Jarkko Nikula
---
Not known to cause any problems at the moment with clas
Hi
I found a minor issue from smartreflex that it allows to enable multiple times
smartreflex class driver from userspace. Then two cleanups.
Nishant: I think this will conflict with your class 1.5 set. I think my
1/3 is worth to fix now and for 2-3/3 I don't have any particular priority.
I can r
"Menon, Nishanth" writes:
> On Wed, Feb 16, 2011 at 11:48, Shweta Gulati wrote:
>> All OMAP4 boards support OPP-Turbo (800M) and OPP-Nitro (1G).
> s/All OMAP4/Almost all/ - there are a minority of boards that use
> OMAP4430-800 device instead of the OMAP4430-1000 device.
> Also please use the fu
Hi Ilkka,
On Wed, Mar 02, 2011 at 03:24:06PM +0200, Ilkka Koskinen wrote:
> audio_mclk can be queried from mfd driver. Therefore, it is not
> needed in twl4030_codec_audio_data or in twl4030_codec_vibra_data
> anymore.
>
> Signed-off-by: Ilkka Koskinen
Acked-by: Samuel Ortiz
Cheers,
Samuel.
-
Hi Ilkka,
On Wed, Mar 02, 2011 at 03:24:04PM +0200, Ilkka Koskinen wrote:
> This series of patches removes duplicate audio_mclk fields from
> twl4030_codec driver.
>
> The patches have been compiled on sound-2.6/for-2.6.39 branch.
> I haven't tested them on any target board though.
I'm fine with
On Wed, Mar 02, 2011 at 04:57:46PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the usb tree got a conflict in
> drivers/usb/musb/musb_core.h between commit
> 59b479e0985f0b795d68331d6443a7f89c47768d ("omap: Start using
> CONFIG_SOC_OMAP") from the omap tree and commit
Hello.
On 02-03-2011 13:55, Nishanth Menon wrote:
At times with bad SR configurations especially during silicon bringups,
we could get continuous spurious interrupts which end up hanging the
platform in the form of an ISR call for status bits that are
automatically enabled by the h/w without an
Hello.
On 02-03-2011 13:55, Nishanth Menon wrote:
Request the handler irq such that there is no nesting for calls.
the notifiers are not expected to be nested, further the interrupt
events for status change should be handled prior to the next event
else there is a risk of loosing events.
Sig
On Wed, Mar 02, 2011 at 03:24:04PM +0200, Ilkka Koskinen wrote:
> Ilkka Koskinen (2):
> omap: Remove unnecessary twl4030_codec_audio settings from board
> files
> mfd: twl4030_codec: Remove unused and duplicate audio_mclk fields
Acked-by: Mark Brown
--
To unsubscribe from this list: send
Workaround for TWL5030 Silicon Errata 27 & 28:
27 - VDD1, VDD2, may have glitches when their output value is updated.
28 - VDD1 and / or VDD2 DCDC clock may stop working when internal clock
is switched from internal to external.
Errata 27:
If the DCDC regula
Added api to get the TWL5030 Si version from the IDCODE register.
It is used for enabling the workaround for TWL errata 27.
Signed-off-by: Lesly A M
Cc: Nishanth Menon
Cc: David Derrick
Cc: Samuel Ortiz
---
drivers/mfd/twl-core.c | 61 +++
includ
1 - 100 of 146 matches
Mail list logo
