RE: [PATCH 00/17] omap4: pm: suspend, hotplug and cpuilde support
> -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 > > 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, low power states are attempted only when the > > CPU1 is put to OFF state via cpu-hotplug because of hardware > > constraints. > > Minor nit on patch subjects: both OMAP and PM are acronyms, please > capitalize. > Will Fix that. > Also, can you rebase this on Paul's integration-2.6.39 branch? > There > are several things in this series that conflict with changes there. > I did that already and found issues around static dependencies. Rajendra and myself are sorting those out. Will address the comments on this series and post v2. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] omap3+: sr: Reuse sr_[start|stop]_vddautocomp functions
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 ;) ). btw, this should not impact > >> class1.5 either - core sr.c sequencing has not been modified in sr1.5 > >> :) > >> Heh, no any hidded motivation here. I was just blind to see your 12/18 and I found the issue and cleanup possibilities at the same time and decided to put them into same RFC set :-) > > Nishanth, > > > > I'd prefer if you handle these. You can add them to the fixup/cleanup > > part of your SR1.5 series. > > ok will pull this in as part of sr1.5 series if no further review comments. > Ok, that's fine to me (though your set has the priority as I didn't notice the 12/18). -- Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/8] OMAP4 : DSS2 : HDMI: HDMI specific display controller and dss change.
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 mailing lists. Yes, it's a good rule of thumb to have similar naming with the TRM. However, we shouldn't follow TRM blindly, and also TRM can be changed. In this case we already have a bunch of functions to configure the clock muxes, like void dss_select_dispc_clk_source(enum dss_clk_source clk_src) Also, a function name like dss_select_hdmi_venc doesn't really tell anything about what it does. Even if you know the architecture of DSS HW, you can't deduce what the function does. And usually when you are pondering about the clocking configuration, you look at the DSS clock tree figure (fig 10-4), or the DSS clock sources table 10-3. And in this case I believe the naming in those figures and tables are much better than the name of the bit we are setting. Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] OMAP2+ hwmod fixes
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). > #2 does return an error but does not print anything, but since each call > (_init_main_clk, _init_interface_clks, _init_opt_clks) does report > some pr_warn in case of error, this is fine. #2 looks fine to me. - Paul
Re: [PATCH v2 2/8] OMAP4 : DSS2 : HDMI: HDMI specific display controller and dss change.
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, 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/dispc.c | 5 +
>>> drivers/video/omap2/dss/dss.c | 5 +
>>> drivers/video/omap2/dss/dss.h | 7 +++
>>> 3 files changed, 17 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/video/omap2/dss/dispc.c
>>> b/drivers/video/omap2/dss/dispc.c
>>> index 69e1e9d..cf385f8 100644
>>> --- a/drivers/video/omap2/dss/dispc.c
>>> +++ b/drivers/video/omap2/dss/dispc.c
>>> @@ -1224,6 +1224,11 @@ void dispc_enable_zorder(enum omap_plane plane, bool
>>> enable)
>>> dispc_write_reg(dispc_reg_att[plane], val);
>>> }
>>>
>>> +void dispc_enable_gamma_table(bool enable)
>>> +{
>>> + REG_FLD_MOD(DISPC_CONFIG, enable, 9, 9);
>>> +}
>>
>> I would separate the gamma function out from this patch. These two
>> things are not related in any way.
>>
>> And I'm not quite happy with this partial gamma implementation, as only
>> the enable function is implemented. At the minimum, put BUG_ON(enable);
>> there, and a comment that this can currently only be used to disable
>> gamma support.
> I shall separate these out.
>>
>>> +
>>> static void _dispc_set_vid_color_conv(enum omap_plane plane, bool enable)
>>> {
>>> u32 val;
>>> diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
>>> index 99de4e1..ca76e68 100644
>>> --- a/drivers/video/omap2/dss/dss.c
>>> +++ b/drivers/video/omap2/dss/dss.c
>>> @@ -559,6 +559,11 @@ void dss_set_dac_pwrdn_bgz(bool enable)
>>> REG_FLD_MOD(DSS_CONTROL, enable, 5, 5); /* DAC Power-Down Control */
>>> }
>>>
>>> +void dss_select_hdmi_venc(enum dss_hdmi_venc_select hdmi)
>>> +{
>>> + REG_FLD_MOD(DSS_CONTROL, hdmi, 15, 15); /* 0x1 for HDMI, 0x0 VENC */
>>
>> That comment is not needed, but you could put "VENC_HDMI_SWITCH" there
>> in the comments.
>>
>>> +}
>>> +
>>> static int dss_init(bool skip_init)
>>> {
>>> int r;
>>> diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
>>> index b6f27fe..5b5b90c 100644
>>> --- a/drivers/video/omap2/dss/dss.h
>>> +++ b/drivers/video/omap2/dss/dss.h
>>> @@ -123,6 +123,11 @@ enum dss_clk_source {
>>> DSS_SRC_DSS1_ALWON_FCLK,
>>> };
>>>
>>> +enum dss_hdmi_venc_select {
>>> + DSS_VENC_SELECT, /* Select VENC */
>>> + DSS_HDMI_SELECT, /* Select HDMI */
>>> +};
>>
>> If the integer value of the enum is important, like in this case, you
>> need to define the value: DSS_VENC_SELECT = 0.
>>
>> Also, the comments are not needed, they just say the same thing as the
>> enum itself.
>>
>> And only now I realized that this is a clock source switch. The enum and
>> the function should be named appropriately, for example enum
>> dss_tv_clk_out_source. And the sources are TV_CLK and HDMI_M_PCLK, so
>> the the enum values should use those as part of their name.
>>
> ok i shall name them appropriately.
>> Tomi
>>
>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 6/7] OMAP: Serial: Allow UART parameters to be configured from board file
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; Kevin Hilman; Paul Walmsley; Rajendra Nayak; Deepak Kattungal
>Subject: Re: [PATCH 6/7] OMAP: Serial: Allow UART parameters to be
>configured from board file
>
>On Wed, Mar 2, 2011 at 1:49 PM, Sricharan R wrote:
>> Hi,
>>>-Original Message-
>>>From: Govindraj [mailto:govindraj...@gmail.com]
>>>Sent: Wednesday, March 02, 2011 1:11 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; Kevin Hilman; Paul Walmsley; Rajendra Nayak; Deepak Kattungal
>>>Subject: Re: [PATCH 6/7] OMAP: Serial: Allow UART parameters to be
>>>configured from board file
>>>
>>>On Wed, Mar 2, 2011 at 12:46 AM, Sricharan R
wrote:
Hi,
>diff --git a/arch/arm/mach-omap2/serial.c
>> b/arch/arm/mach-omap2/serial.c
>index 755f4aa..530e9e3 100644
>--- a/arch/arm/mach-omap2/serial.c
>+++ b/arch/arm/mach-omap2/serial.c
>@@ -44,6 +44,15 @@
>
> static int omap_uart_con_id __initdata = -1;
>
>+static struct omap_uart_port_info omap_serial_default_info[] = {
>+ {
>+ .dma_enabled = 0,
>+ .dma_rx_buf_size = DEFAULT_RXDMA_BUFSIZE,
>+ .dma_rx_timeout = DEFAULT_RXDMA_TIMEOUT,
>+ .idle_timeout = DEFAULT_IDLE_TIMEOUT,
>+ },
>+};
>+
> static int uart_idle_hwmod(struct omap_device *od)
> {
> omap_hwmod_idle(od->hwmods[0]);
>@@ -66,6 +75,54 @@ static struct omap_device_pm_latency
omap_uart_latency[]
>= {
> },
> };
>
>+#ifdef CONFIG_OMAP_MUX
>+static struct omap_device_pad default_serial0_pads[] __initdata = {
>+ {
>+ .name = "uart1_rx.uart1_rx",
>+ .flags = OMAP_DEVICE_PAD_REMUX |
>> OMAP_DEVICE_PAD_WAKEUP,
>+ .enable = OMAP_MUX_MODE0,
>+ },
>+};
>+
>+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_MODE0,
>+ },
>+};
>+
>+static struct omap_device_pad default_serial2_pads[] __initdata = {
>+ {
>+ .name = "uart3_rx_irrx.uart3_rx_irrx",
>+ .flags = OMAP_DEVICE_PAD_REMUX |
>> OMAP_DEVICE_PAD_WAKEUP,
>+ .enable = OMAP_MUX_MODE0,
>+ },
>+};
>+
>+static struct omap_device_pad default_omap36xx_serial3_pads[]
>> __initdata
=
>{
>+ {
>+ .name = "gpmc_wait3.uart4_rx",
>+ .flags = OMAP_DEVICE_PAD_REMUX |
>> OMAP_DEVICE_PAD_WAKEUP,
>+ .enable = OMAP_MUX_MODE2,
>+ },
>+};
>+
>+static struct omap_device_pad default_omap4_serial3_pads[]
__initdata
>> =
{
>+ {
>+ .name = "uart4_rx.uart4_rx",
>+ .flags = OMAP_DEVICE_PAD_REMUX |
>> OMAP_DEVICE_PAD_WAKEUP,
>+ .enable = OMAP_MUX_MODE0,
>+ },
>+};
Here only the UART RX pins are muxed, so what about the cts, rts, tx
>>>pins?
>>>
>>>The intention here is to enable wakeup capabilities for uart rx pad.
>>>
>>>AFAIK most of the boards are currently dependent on bootloader for
>>>uart-muxing if any board is not dependent on bootloader then we
>>>can use omap_serial_init_port along with board_mux_info from board.
>>>
>> Yes. The idea is to be independent of the bootloaders for mux settings.
>>
>>>Prior to this change uart wakeup is based on rx_pad and we were
>> populating
>>>offset and using omap_ctrl api's to read/write which is cleaned up now.
>>>Most of boards are dependent on uart-rx wakeup to avoid breaking any
>>>board support we
>>>are using omap_serial_init by filling default values, which provides
>>>us with same
>>>environment but with right approach towards handling mux data with a
>>>handshake with
>>>hwmod framework.
>>>
>> Now, in this change only the RX pin is configured. So if some board
uses
>> omap_serial_init then only the RX is going to be configured.
>> How will they configure the rest of the pins?
>
>
>They should call omap_serial_init_port to configure each individual uart
>with
>mux_info filled and not use omap_serial_init.
>
>If any board is not dependent for mux from u-boot then they use above
said
>init_port func.
>
>
>> They cannot call omap_serial_init_port after this just to configure the
>> rest of the mux pins( cts, rts, tx).
>
>No. You need to use either omap_serial_init_port or omap_serial_init
>you cannot call b
Re: [PATCH v2 4/8] OMAP4 : DSS2 : HDMI: HDMI driver addition in the DSS drivers interface
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 hdmi interface driver(hdmi.c) to the dss driver. >> It configures the audio and video portion of HDMI in the >> display header file to be accessed by the panels. > > Check once more if the private functions and variables are marked as > static. > > The edid variables should be in the hdmi struct. The constant data > arrays should be const. > > hdmi_power_on() leaves clocks on in case of error. > > Tomi > > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/8] OMAP4 : DSS2 : HDMI: HDMI panel driver addition in the DSS
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 the hdmi registers is added in the >> plat-omap , so that it can be accessed by audio driver. > > Could you review the description. The panel driver is not in "dss file" > and there's no header in this patch. > > The locking is broken in this patch. You cannot return from the function > while holding the lock. I shall fix the lock and describe appropriately. > > Tomi > > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/8] OMAP4 : DSS2 : HDMI: HDMI specific display controller and dss change.
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/dispc.c | 5 +
>> drivers/video/omap2/dss/dss.c | 5 +
>> drivers/video/omap2/dss/dss.h | 7 +++
>> 3 files changed, 17 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/video/omap2/dss/dispc.c
>> b/drivers/video/omap2/dss/dispc.c
>> index 69e1e9d..cf385f8 100644
>> --- a/drivers/video/omap2/dss/dispc.c
>> +++ b/drivers/video/omap2/dss/dispc.c
>> @@ -1224,6 +1224,11 @@ void dispc_enable_zorder(enum omap_plane plane, bool
>> enable)
>> dispc_write_reg(dispc_reg_att[plane], val);
>> }
>>
>> +void dispc_enable_gamma_table(bool enable)
>> +{
>> + REG_FLD_MOD(DISPC_CONFIG, enable, 9, 9);
>> +}
>
> I would separate the gamma function out from this patch. These two
> things are not related in any way.
>
> And I'm not quite happy with this partial gamma implementation, as only
> the enable function is implemented. At the minimum, put BUG_ON(enable);
> there, and a comment that this can currently only be used to disable
> gamma support.
I shall separate these out.
>
>> +
>> static void _dispc_set_vid_color_conv(enum omap_plane plane, bool enable)
>> {
>> u32 val;
>> diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
>> index 99de4e1..ca76e68 100644
>> --- a/drivers/video/omap2/dss/dss.c
>> +++ b/drivers/video/omap2/dss/dss.c
>> @@ -559,6 +559,11 @@ void dss_set_dac_pwrdn_bgz(bool enable)
>> REG_FLD_MOD(DSS_CONTROL, enable, 5, 5); /* DAC Power-Down Control */
>> }
>>
>> +void dss_select_hdmi_venc(enum dss_hdmi_venc_select hdmi)
>> +{
>> + REG_FLD_MOD(DSS_CONTROL, hdmi, 15, 15); /* 0x1 for HDMI, 0x0 VENC */
>
> That comment is not needed, but you could put "VENC_HDMI_SWITCH" there
> in the comments.
>
>> +}
>> +
>> static int dss_init(bool skip_init)
>> {
>> int r;
>> diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
>> index b6f27fe..5b5b90c 100644
>> --- a/drivers/video/omap2/dss/dss.h
>> +++ b/drivers/video/omap2/dss/dss.h
>> @@ -123,6 +123,11 @@ enum dss_clk_source {
>> DSS_SRC_DSS1_ALWON_FCLK,
>> };
>>
>> +enum dss_hdmi_venc_select {
>> + DSS_VENC_SELECT, /* Select VENC */
>> + DSS_HDMI_SELECT, /* Select HDMI */
>> +};
>
> If the integer value of the enum is important, like in this case, you
> need to define the value: DSS_VENC_SELECT = 0.
>
> Also, the comments are not needed, they just say the same thing as the
> enum itself.
>
> And only now I realized that this is a clock source switch. The enum and
> the function should be named appropriately, for example enum
> dss_tv_clk_out_source. And the sources are TV_CLK and HDMI_M_PCLK, so
> the the enum values should use those as part of their name.
>
ok i shall name them appropriately.
> Tomi
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] omap:mailbox: resolve hang issue
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-off-by: Hari Kanigeri
>> Signed-off-by: Armando Uribe
>> Signed-off-by: Fernando Guzman Lugo
>
> Should we merge this as a fix for the 2.6.38 still?
yeah, if it can still be merged in 2.6.38 because it is a fix it would be great.
Regards,
Fernando.
>
> Tony
>
>> ---
>> arch/arm/mach-omap2/mailbox.c | 10 ++
>> 1 files changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
>> index 394413d..011ca50 100644
>> --- a/arch/arm/mach-omap2/mailbox.c
>> +++ b/arch/arm/mach-omap2/mailbox.c
>> @@ -193,10 +193,12 @@ static void omap2_mbox_disable_irq(struct omap_mbox
>> *mbox,
>> omap_mbox_type_t irq)
>> {
>> struct omap_mbox2_priv *p = mbox->priv;
>> - u32 l, bit = (irq == IRQ_TX) ? p->notfull_bit : p->newmsg_bit;
>> - l = mbox_read_reg(p->irqdisable);
>> - l &= ~bit;
>> - mbox_write_reg(l, p->irqdisable);
>> + u32 bit = (irq == IRQ_TX) ? p->notfull_bit : p->newmsg_bit;
>> +
>> + if (!cpu_is_omap44xx())
>> + bit = mbox_read_reg(p->irqdisable) & ~bit;
>> +
>> + mbox_write_reg(bit, p->irqdisable);
>> }
>>
>> static void omap2_mbox_ack_irq(struct omap_mbox *mbox,
>> --
>> 1.7.0.4
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] omap:mailbox: resolve hang issue
* 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-off-by: Fernando Guzman Lugo
Should we merge this as a fix for the 2.6.38 still?
Tony
> ---
> arch/arm/mach-omap2/mailbox.c | 10 ++
> 1 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
> index 394413d..011ca50 100644
> --- a/arch/arm/mach-omap2/mailbox.c
> +++ b/arch/arm/mach-omap2/mailbox.c
> @@ -193,10 +193,12 @@ static void omap2_mbox_disable_irq(struct omap_mbox
> *mbox,
> omap_mbox_type_t irq)
> {
> struct omap_mbox2_priv *p = mbox->priv;
> - u32 l, bit = (irq == IRQ_TX) ? p->notfull_bit : p->newmsg_bit;
> - l = mbox_read_reg(p->irqdisable);
> - l &= ~bit;
> - mbox_write_reg(l, p->irqdisable);
> + u32 bit = (irq == IRQ_TX) ? p->notfull_bit : p->newmsg_bit;
> +
> + if (!cpu_is_omap44xx())
> + bit = mbox_read_reg(p->irqdisable) & ~bit;
> +
> + mbox_write_reg(bit, p->irqdisable);
> }
>
> static void omap2_mbox_ack_irq(struct omap_mbox *mbox,
> --
> 1.7.0.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/8] OMAP: HSMMC: hwmod adaptation
* 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 already and rather not start messing with it any longer. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cbus-retu-wdt: Make the watchdog driver fully preemptible
* 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 branch. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/19] OMAP3+: introduce SR class 1.5
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=linux-omap&m=129906334611444&w=2 Doh, sorry. My backlog is deep enough that I hadn't seen your v2 yet. :/ nothing lost ;).. I guess we can skip it for the moment and look at v3 later this week.. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/19] omap3+: sr: disable interrupt by default
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 events could trigger events that we dont need/expect to handle. It's not clear from the patch where the IRQ is re-enabled. For example, without knowing better, I would expect a corresponding change to the Class 3 driver to enable/disable the IRQ as needed. Why would that be? a) class 3 driver does not request for any notifiers b) class 3 does'nt need interrupts. c) each class driver can choose to enable when it needs it - class3 does'nt. is it fine if I add a "this is a preperation for class drivers such as class 2 and class 1.5 which would need to use interrupts" in commit message? Yes, also stating/summarizing that existing class driver (e.g. class 3) does not use interrupts would be helpful. Ack. will do in v3. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] omap3: pm: Fixes for low power code
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 context save registers > 5. Disable C-bit before cache clean > 6. Use set_cr() exported API instead of custom one. Look like good cleanups, thanks. > It's generated against mainline and tested with OMAP3630 ZOOM3. > 1. Renetion and off-mode mode in suspend - ok. > 2. Retention in idle - ok Testing this series along with other PM changes queued up for mainline (my pm-core branch), this doesn't work for me on 3630/Zoom3 (but works fine on 3430/n900.) Here's what I did using omap2plus_defconfig + enabling CPUidle First tested suspend: echo 4 > /debug/pm_debug/wakeup_timer_seconds echo mem > /sys/power/state then, setup UART idle/wakeup: echo 5 > /sys/devices/platform/omap/omap_uart.0/sleep_timeout echo 5 > /sys/devices/platform/omap/omap_uart.1/sleep_timeout echo 5 > /sys/devices/platform/omap/omap_uart.2/sleep_timeout echo 5 > /sys/devices/platform/omap/omap_uart.3/sleep_timeout echo enabled > /sys/devices/platform/serial8250.0/tty/ttyS0/power/wakeup then enabled idle: echo 1 > /debug/pm_debug/sleep_while_idle As soon as I do this, it hangs. Without your series, it's working fine for me. Only after merging your series it hangs. Kevin > The following changes since commit 85e2efbb1db9a18d218006706d6e4fbeb0216213: > Linus Torvalds (1): > Linux 2.6.38-rc5 > > Santosh Shilimkar (6): > omap3: pm: Use amrv7 supported instructions instead of legacy cp15 > ones > omap3: pm: Fix the mmu on sequence in the asm code > omap3: pm: Allow the cache clean when L1 is lost. > omap3: pm: Remove un-necessary cp15 registers form low power cpu > context > omap3: pm: Clear the SCTLR C bit in asm code to prevent data cache > allocation > omap3: pm: Use exported set_cr() instead of a custom one. > > arch/arm/mach-omap2/pm34xx.c|7 +- > arch/arm/mach-omap2/sleep34xx.S | 223 > ++- > 2 files changed, 78 insertions(+), 152 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/19] omap3+: sr: introduce class init,deinit and priv data
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 operation. They also may need private data to be
used for operations of their own, provide the same.
Signed-off-by: Nishanth Menon
Basic principle looks fine, but some naming comments below...
k, thx.
[...]
diff --git a/arch/arm/plat-omap/include/plat/smartreflex.h
b/arch/arm/plat-omap/include/plat/smartreflex.h
index 6568c88..8b6ecd9 100644
--- a/arch/arm/plat-omap/include/plat/smartreflex.h
+++ b/arch/arm/plat-omap/include/plat/smartreflex.h
@@ -167,6 +167,8 @@ struct omap_sr_pmic_data {
*
* @enable: API to enable a particular class smaartreflex.
* @disable: API to disable a particular class smartreflex.
+ * @class_init:API to do class specific initialization
(optional)
+ * @class_deinit: API to do class specific initialization (optional)
The 'class_' prefix here is not needed.
ack.
The changelog uses 'start' and 'stop' instead of init& deinit. I
prefer those names to [de]init.
Would'nt start and stop cause confusion when mixed with existing
enable/disable? does enable/start actually start the SR? intent here
with init/deinit is to do class specific initialization or
deinitialization.
Well, one way or another, make the changelog consistent with the
function names.
To me though, start/stop has more meaning. They are called from
sr_[start|stop]_vddautocomp, so using start/stop is consistent there.
Also, init is usually something done once (and doesn't have a de-init
counterpart) but here we're talking about something done for each
sr_[start|stop]_vddautocomp()
fair enough - unless there are other dissenting voices, will switch to
start/stop for the api name and add documentation in code to explain the
need.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: rx51: Add support for vibra
* 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/arm/mach-omap2/board-rx51-peripherals.c
> b/arch/arm/mach-omap2/board-rx51-peripherals.c
> index e75e240..dcd98fa 100644
> --- a/arch/arm/mach-omap2/board-rx51-peripherals.c
> +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
> @@ -699,6 +699,14 @@ static struct twl4030_power_data rx51_t2scripts_data
> __initdata = {
> .resource_config = twl4030_rconfig,
> };
>
> +struct twl4030_codec_vibra_data rx51_vibra_data __initdata = {
> + .coexist= 0,
> +};
> +
> +struct twl4030_codec_data rx51_codec_data __initdata = {
> + .audio_mclk = 2600,
> + .vibra = &rx51_vibra_data,
> +};
>
> static struct twl4030_platform_data rx51_twldata __initdata = {
> .irq_base = TWL4030_IRQ_BASE,
> @@ -710,6 +718,7 @@ static struct twl4030_platform_data rx51_twldata
> __initdata = {
> .madc = &rx51_madc_data,
> .usb= &rx51_usb_data,
> .power = &rx51_t2scripts_data,
> + .codec = &rx51_codec_data,
>
> .vaux1 = &rx51_vaux1,
> .vaux2 = &rx51_vaux2,
> --
> 1.7.0.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: panda: Add TI-ST driver support
* 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" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/19] OMAP3+: introduce SR class 1.5
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 Doh, sorry. My backlog is deep enough that I hadn't seen your v2 yet. :/ Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ldp: Fix regulator mapping for ads7846 TS controller
* 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 regulator: -19 Applying for the merge window. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/19] omap3+: sr: disable interrupt by default
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 dont >>> need/expect to handle. >> >> It's not clear from the patch where the IRQ is re-enabled. For example, >> without knowing better, I would expect a corresponding change to the >> Class 3 driver to enable/disable the IRQ as needed. > > Why would that be? > a) class 3 driver does not request for any notifiers > b) class 3 does'nt need interrupts. > c) each class driver can choose to enable when it needs it - class3 does'nt. > > is it fine if I add a "this is a preperation for class drivers such as > class 2 and class 1.5 which would need to use interrupts" in commit > message? Yes, also stating/summarizing that existing class driver (e.g. class 3) does not use interrupts would be helpful. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/19] omap3+: sr: introduce class init,deinit and priv data
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 private data to be
>>> used for operations of their own, provide the same.
>>>
>>> Signed-off-by: Nishanth Menon
>>
>> Basic principle looks fine, but some naming comments below...
> k, thx.
>
>>
>> [...]
>>
>>> diff --git a/arch/arm/plat-omap/include/plat/smartreflex.h
>>> b/arch/arm/plat-omap/include/plat/smartreflex.h
>>> index 6568c88..8b6ecd9 100644
>>> --- a/arch/arm/plat-omap/include/plat/smartreflex.h
>>> +++ b/arch/arm/plat-omap/include/plat/smartreflex.h
>>> @@ -167,6 +167,8 @@ struct omap_sr_pmic_data {
>>>*
>>>* @enable: API to enable a particular class smaartreflex.
>>>* @disable: API to disable a particular class smartreflex.
>>> + * @class_init:API to do class specific initialization
>>> (optional)
>>> + * @class_deinit: API to do class specific initialization (optional)
>>
>> The 'class_' prefix here is not needed.
> ack.
>
>>
>> The changelog uses 'start' and 'stop' instead of init& deinit. I
>> prefer those names to [de]init.
>
> Would'nt start and stop cause confusion when mixed with existing
> enable/disable? does enable/start actually start the SR? intent here
> with init/deinit is to do class specific initialization or
> deinitialization.
Well, one way or another, make the changelog consistent with the
function names.
To me though, start/stop has more meaning. They are called from
sr_[start|stop]_vddautocomp, so using start/stop is consistent there.
Also, init is usually something done once (and doesn't have a de-init
counterpart) but here we're talking about something done for each
sr_[start|stop]_vddautocomp()
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/19] omap3+: voltage: remove initial voltage
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 > use 1.2v and ends up generating a warning on the first transition. > > Further, since omap2_set_init_voltage is called as part of the pm > framework's initialization sequence to configure the voltage required > for the current OPP, the call does(and has to) setup the system > voltage(curr_volt as a result) using the right mechanisms appropriate > for the system at that point of time. This also overrides > initialization we are currently doing in voltage.c making it > redundant. So remove the wrong and useless initialization. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] omap3+: sr: Reuse sr_[start|stop]_vddautocomp functions
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_autocomp.
Signed-off-by: Jarkko Nikula
---
arch/arm/mach-omap2/smartreflex.c | 41 ++--
1 files changed, 7 insertions(+), 34 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 11741d8..7e6002f 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -227,7 +227,7 @@ static void sr_start_vddautocomp(struct omap_sr *sr)
sr->autocomp_active = true;
}
-static void sr_stop_vddautocomp(struct omap_sr *sr)
+static void sr_stop_vddautocomp(struct omap_sr *sr, int is_volt_reset)
{
if (!sr->autocomp_active)
return;
@@ -239,7 +239,7 @@ static void sr_stop_vddautocomp(struct omap_sr *sr)
return;
}
- if (!sr_class->disable(sr->voltdm, 1))
+ if (!sr_class->disable(sr->voltdm, is_volt_reset))
sr->autocomp_active = false;
}
@@ -681,16 +681,7 @@ void omap_sr_enable(struct voltagedomain *voltdm)
return;
}
- if (!sr->autocomp_active)
- return;
-
- if (!sr_class || !(sr_class->enable) || !(sr_class->configure)) {
- dev_warn(&sr->pdev->dev, "%s: smartreflex class driver not"
- "registered\n", __func__);
- return;
- }
-
- sr_class->enable(voltdm);
+ sr_start_vddautocomp(sr);
}
/**
@@ -714,16 +705,7 @@ void omap_sr_disable(struct voltagedomain *voltdm)
return;
}
- if (!sr->autocomp_active)
- return;
-
- if (!sr_class || !(sr_class->disable)) {
- dev_warn(&sr->pdev->dev, "%s: smartreflex class driver not"
- "registered\n", __func__);
- return;
- }
-
- sr_class->disable(voltdm, 0);
+ sr_stop_vddautocomp(sr, 0);
}
/**
@@ -747,16 +729,7 @@ void omap_sr_disable_reset_volt(struct voltagedomain
*voltdm)
return;
}
- if (!sr->autocomp_active)
- return;
-
- if (!sr_class || !(sr_class->disable)) {
- dev_warn(&sr->pdev->dev, "%s: smartreflex class driver not"
- "registered\n", __func__);
- return;
- }
-
- sr_class->disable(voltdm, 1);
+ sr_stop_vddautocomp(sr, 1);
}
/**
@@ -809,7 +782,7 @@ static int omap_sr_autocomp_store(void *data, u64 val)
}
if (!val)
- sr_stop_vddautocomp(sr_info);
+ sr_stop_vddautocomp(sr_info, 1);
else
sr_start_vddautocomp(sr_info);
@@ -976,7 +949,7 @@ static int __devexit omap_sr_remove(struct platform_device
*pdev)
}
if (sr_info->autocomp_active)
- sr_stop_vddautocomp(sr_info);
+ sr_stop_vddautocomp(sr_info, 1);
list_del(&sr_info->node);
iounmap(sr_info->base);
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 ;) ). btw, this should not impact
class1.5 either - core sr.c sequencing has not been modified in sr1.5
:)
Depending on Kevin's views, either you or I or both of us can rebase
depending on whose ever series gets pulled in first.. (either should
be a very minimal effort).
Nishanth,
I'd prefer if you handle these. You can add them to the fixup/cleanup
part of your SR1.5 series.
ok will pull this in as part of sr1.5 series if no further review comments.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] omap3+: sr: Reuse sr_[start|stop]_vddautocomp functions
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 Nikula
>> ---
>> arch/arm/mach-omap2/smartreflex.c | 41
>> ++--
>> 1 files changed, 7 insertions(+), 34 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/smartreflex.c
>> b/arch/arm/mach-omap2/smartreflex.c
>> index 11741d8..7e6002f 100644
>> --- a/arch/arm/mach-omap2/smartreflex.c
>> +++ b/arch/arm/mach-omap2/smartreflex.c
>> @@ -227,7 +227,7 @@ static void sr_start_vddautocomp(struct omap_sr *sr)
>> sr->autocomp_active = true;
>> }
>>
>> -static void sr_stop_vddautocomp(struct omap_sr *sr)
>> +static void sr_stop_vddautocomp(struct omap_sr *sr, int is_volt_reset)
>> {
>> if (!sr->autocomp_active)
>> return;
>> @@ -239,7 +239,7 @@ static void sr_stop_vddautocomp(struct omap_sr *sr)
>> return;
>> }
>>
>> -if (!sr_class->disable(sr->voltdm, 1))
>> +if (!sr_class->disable(sr->voltdm, is_volt_reset))
>> sr->autocomp_active = false;
>> }
>>
>> @@ -681,16 +681,7 @@ void omap_sr_enable(struct voltagedomain *voltdm)
>> return;
>> }
>>
>> -if (!sr->autocomp_active)
>> -return;
>> -
>> -if (!sr_class || !(sr_class->enable) || !(sr_class->configure)) {
>> -dev_warn(&sr->pdev->dev, "%s: smartreflex class driver not"
>> -"registered\n", __func__);
>> -return;
>> -}
>> -
>> -sr_class->enable(voltdm);
>> +sr_start_vddautocomp(sr);
>> }
>>
>> /**
>> @@ -714,16 +705,7 @@ void omap_sr_disable(struct voltagedomain *voltdm)
>> return;
>> }
>>
>> -if (!sr->autocomp_active)
>> -return;
>> -
>> -if (!sr_class || !(sr_class->disable)) {
>> -dev_warn(&sr->pdev->dev, "%s: smartreflex class driver not"
>> -"registered\n", __func__);
>> -return;
>> -}
>> -
>> -sr_class->disable(voltdm, 0);
>> +sr_stop_vddautocomp(sr, 0);
>> }
>>
>> /**
>> @@ -747,16 +729,7 @@ void omap_sr_disable_reset_volt(struct voltagedomain
>> *voltdm)
>> return;
>> }
>>
>> -if (!sr->autocomp_active)
>> -return;
>> -
>> -if (!sr_class || !(sr_class->disable)) {
>> -dev_warn(&sr->pdev->dev, "%s: smartreflex class driver not"
>> -"registered\n", __func__);
>> -return;
>> -}
>> -
>> -sr_class->disable(voltdm, 1);
>> +sr_stop_vddautocomp(sr, 1);
>> }
>>
>> /**
>> @@ -809,7 +782,7 @@ static int omap_sr_autocomp_store(void *data, u64 val)
>> }
>>
>> if (!val)
>> -sr_stop_vddautocomp(sr_info);
>> +sr_stop_vddautocomp(sr_info, 1);
>> else
>> sr_start_vddautocomp(sr_info);
>>
>> @@ -976,7 +949,7 @@ static int __devexit omap_sr_remove(struct
>> platform_device *pdev)
>> }
>>
>> if (sr_info->autocomp_active)
>> -sr_stop_vddautocomp(sr_info);
>> +sr_stop_vddautocomp(sr_info, 1);
>>
>> list_del(&sr_info->node);
>> iounmap(sr_info->base);
>
> 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 ;) ). btw, this should not impact
> class1.5 either - core sr.c sequencing has not been modified in sr1.5
> :)
>
> Depending on Kevin's views, either you or I or both of us can rebase
> depending on whose ever series gets pulled in first.. (either should
> be a very minimal effort).
Nishanth,
I'd prefer if you handle these. You can add them to the fixup/cleanup
part of your SR1.5 series.
Thanks,
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/19] omap3+: sr: introduce notifiers flags
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 @@ -141,6 +141,12 @@ #define OMAP3430_SR_ERRWEIGHT 0x04 #define OMAP3430_SR_ERRMAXLIMIT 0x02 +/* Smart reflex notifiers for class drivers to use */ +#define SR_NOTIFY_MCUACCUM (0x1<< 0) +#define SR_NOTIFY_MCUVALID (0x1<< 1) +#define SR_NOTIFY_MCUBOUND (0x1<< 2) +#define SR_NOTIFY_MCUDISACK(0x1<< 3) + Please use BIT(x) Ack. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/19] omap3+: sr: call handler with interrupt disabled
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 loosing events. Signed-off-by: Nishanth Menon IRQs disabled interrupt handlers are soon to disappear in the kernel. This kind of thing should be handled using locking, most likely IRQs disabled spinlocks. http://marc.info/?t=129906354500012&r=1&w=2 Ack.. painfully made clear in l-a as well.. dropping this :( Kevin --- arch/arm/mach-omap2/smartreflex.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c index 1fe8b95..7931fcd 100644 --- a/arch/arm/mach-omap2/smartreflex.c +++ b/arch/arm/mach-omap2/smartreflex.c @@ -278,7 +278,7 @@ static int sr_late_init(struct omap_sr *sr_info) goto error; } ret = request_irq(sr_info->irq, sr_interrupt, - 0, name, (void *)sr_info); + IRQF_DISABLED, name, (void *)sr_info); if (ret) goto error; } -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] perf: add OMAP support for the new power events
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 my pm-core branch where these other
changes are queued?
Thanks,
Kevin
> The trace points are for:
> - default idle handler. Since the cpuidle framework is
> instrumented in the generic way there is no need to
> add trace points in the OMAP specific cpuidle handler;
> - cpufreq (DVFS),
> - SoC clocks changes (enable, disable, set_rate),
> - power domain states: the desired target state and -if different-
> the actually hit state.
>
> Because of the generic nature of the changes, OMAP3 and OMAP4 are supported.
>
> Tested on OMAP3 with suspend/resume, cpuidle, basic DVFS.
>
> Signed-off-by: Jean Pihet
> ---
> arch/arm/mach-omap2/clock.c |8 +++-
> arch/arm/mach-omap2/pm34xx.c |7 +++
> arch/arm/mach-omap2/powerdomain.c | 26 +++---
> 3 files changed, 37 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
> index 2a2f152..72af75d 100644
> --- a/arch/arm/mach-omap2/clock.c
> +++ b/arch/arm/mach-omap2/clock.c
> @@ -22,7 +22,9 @@
> #include
> #include
> #include
> +#include
>
> +#include
> #include
> #include "clockdomain.h"
> #include
> @@ -261,6 +263,7 @@ void omap2_clk_disable(struct clk *clk)
>
> pr_debug("clock: %s: disabling in hardware\n", clk->name);
>
> + trace_clock_disable(clk->name, 0, smp_processor_id());
> clk->ops->disable(clk);
>
> if (clk->clkdm)
> @@ -312,6 +315,7 @@ int omap2_clk_enable(struct clk *clk)
> }
> }
>
> + trace_clock_enable(clk->name, 1, smp_processor_id());
> ret = clk->ops->enable(clk);
> if (ret) {
> WARN(1, "clock: %s: could not enable: %d\n", clk->name, ret);
> @@ -349,8 +353,10 @@ int omap2_clk_set_rate(struct clk *clk, unsigned long
> rate)
> pr_debug("clock: set_rate for clock %s to rate %ld\n", clk->name, rate);
>
> /* dpll_ck, core_ck, virt_prcm_set; plus all clksel clocks */
> - if (clk->set_rate)
> + if (clk->set_rate) {
> + trace_clock_set_rate(clk->name, rate, smp_processor_id());
> ret = clk->set_rate(clk, rate);
> + }
>
> return ret;
> }
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index 2f864e4..d1cc3f4 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include "clockdomain.h"
> @@ -519,8 +520,14 @@ static void omap3_pm_idle(void)
> if (omap_irq_pending() || need_resched())
> goto out;
>
> + trace_power_start(POWER_CSTATE, 1, smp_processor_id());
> + trace_cpu_idle(1, smp_processor_id());
> +
> omap_sram_idle();
>
> + trace_power_end(smp_processor_id());
> + trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
> +
> out:
> local_fiq_enable();
> local_irq_enable();
> diff --git a/arch/arm/mach-omap2/powerdomain.c
> b/arch/arm/mach-omap2/powerdomain.c
> index eaed0df..1495eed 100644
> --- a/arch/arm/mach-omap2/powerdomain.c
> +++ b/arch/arm/mach-omap2/powerdomain.c
> @@ -19,12 +19,15 @@
> #include
> #include
> #include
> +#include
> +
> #include "cm2xxx_3xxx.h"
> #include "prcm44xx.h"
> #include "cm44xx.h"
> #include "prm2xxx_3xxx.h"
> #include "prm44xx.h"
>
> +#include
> #include
> #include "powerdomain.h"
> #include "clockdomain.h"
> @@ -32,6 +35,8 @@
>
> #include "pm.h"
>
> +#define PWRDM_TRACE_STATES_FLAG (1<<31)
> +
> enum {
> PWRDM_STATE_NOW = 0,
> PWRDM_STATE_PREV,
> @@ -130,8 +135,7 @@ static void _update_logic_membank_counters(struct
> powerdomain *pwrdm)
> static int _pwrdm_state_switch(struct powerdomain *pwrdm, int flag)
> {
>
> - int prev;
> - int state;
> + int prev, state, trace_state = 0;
>
> if (pwrdm == NULL)
> return -EINVAL;
> @@ -148,6 +152,17 @@ static int _pwrdm_state_switch(struct powerdomain
> *pwrdm, int flag)
> pwrdm->state_counter[prev]++;
> if (prev == PWRDM_POWER_RET)
> _update_logic_membank_counters(pwrdm);
> + /*
> + * If the power domain did not hit the desired state,
> + * generate a trace event with both the desired and hit states
> + */
> + if (state != prev) {
> + trace_state = (PWRDM_TRACE_STATES_FLAG |
> +((state & OMAP_POWERSTATE_MASK) << 8) |
> +((prev & OMAP_POWERSTATE_MASK) << 0));
> + trace_power_domain_target(pwrdm->name, trace_state,
> +
Re: [PATCH 01/19] omap3: hwmod: add smartreflex irqs
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 Menon minor: IRQ is an acronym, please capitalize consistenly throughout. I know we haven't been too consitent about this but OMAP is also an acronym, please capitialize (c.f. $SUBJECT). This goes for the whole series. here and elsewhere - will do with v3.. thanks for catching.. Otherwise patch looks fine. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/19] omap3+: sr: introduce class init,deinit and priv data
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 their own, provide the same.
Signed-off-by: Nishanth Menon
Basic principle looks fine, but some naming comments below...
k, thx.
[...]
diff --git a/arch/arm/plat-omap/include/plat/smartreflex.h
b/arch/arm/plat-omap/include/plat/smartreflex.h
index 6568c88..8b6ecd9 100644
--- a/arch/arm/plat-omap/include/plat/smartreflex.h
+++ b/arch/arm/plat-omap/include/plat/smartreflex.h
@@ -167,6 +167,8 @@ struct omap_sr_pmic_data {
*
* @enable: API to enable a particular class smaartreflex.
* @disable: API to disable a particular class smartreflex.
+ * @class_init:API to do class specific initialization
(optional)
+ * @class_deinit: API to do class specific initialization (optional)
The 'class_' prefix here is not needed.
ack.
The changelog uses 'start' and 'stop' instead of init& deinit. I
prefer those names to [de]init.
Would'nt start and stop cause confusion when mixed with existing
enable/disable? does enable/start actually start the SR? intent here
with init/deinit is to do class specific initialization or deinitialization.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/19] OMAP3+: introduce SR class 1.5
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 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 - Please rebase this on top of my pm-core branch (or Paul's integration-2.6.39 branch if you prefer.) There are some important voltage related re-organization happening there that affects your code. ok. will do that and integrate comments from v1 and v2 for v3.. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/19] omap3+: voltage: remove initial voltage
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 Lindgren; Kevin Hilman Subject: Re: [PATCH 03/19] omap3+: voltage: remove initial voltage Wed, Feb 23, 2011 at 12:24, Vishwanath Sripathy wrote: -Original Message- From: Nishanth Menon [mailto:n...@ti.com] Sent: Sunday, February 20, 2011 10:42 AM To: Vishwanath Sripathy Cc: linux-omap; Tony Lindgren; Kevin Hilman Subject: Re: [PATCH 03/19] omap3+: voltage: remove initial voltage Vishwanath Sripathy wrote, on 02/19/2011 06:54 PM: [..] omap2_set_init_voltage should setup the curr_volt based on which OPP the system is functioning at. 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 use 1.2v and ends up generating a warning on the first transition. [..] diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach- omap2/voltage.c index 12be525..280ee12 100644 --- a/arch/arm/mach-omap2/voltage.c +++ b/arch/arm/mach-omap2/voltage.c [..] /* Generic voltage parameters */ - vdd->curr_volt = 120; Where do you update this parameter upon initialization? Shouldn't you read the VP register and find the actual current voltage and update this param? The sequence is as follows: a) omapx_vdd_data configure is called as part of sr init sequence. And the curr_volt with this patch is not updated at this stage. b) somewhere down in the boot sequence, pm.c's omap2_set_init_voltage starts up. This looks up the current clk frequency from clock layer of the parent device for the domain, picks up the nominal voltages stored in the opp layer, then does a omap_voltage_scale_vdd to that voltage. In omap_voltage_scale_vdd, The current voltage is merely picked off the vp (in _pre_volt_scale). the last step it does is to setup vdd->curr_volt. This can then be used by dvfs layer etc to make appropriate decisions. So, No, I dont think I need to update it here, it should happen as part of the pm init sequence. Could you explain what problem do you foresee by doing this? What if omap_voltage_scale_vdd fails when called from omap2_set_init_voltage? Or omap2_set_init_voltage returns error even before calling omap_voltage_scale_vdd because it could not find the matching voltage for the frequency set by bootloader? Your assumption that curr_volt is always set by omap2_set_init_voltage need not be true always. set_init_voltage's job is to set the initial voltage. if it is incapable of doing it, I say fix that instead of hacking in some random number as curr_volt. I never said to use random numbers. All I suggested was that instead of relying on some others function's behavior, read the VP register to fill in the right values. If set_init_voltage succeeds, it will anyway update with right voltage. OK, lets take this argument for a moment. Q: which voltage to set as curr_volt? a) what if the update was done over vcbypass by bootloader? Cannot trust the vp register for the value. b) what if the voltage was updated over i2c1 to the PMIC by bootloader? cant trust vp register again. c) use some number like 1.2v - which we are aligned is wrong. in short, what should we do for a accurate curr_volt? vp register may not be correct, instead, the right steps to do: find my current freq, check the OPP table for the voltage needed, setup the voltage for it, update curr_volt for it. this is trust worthy, rest are not. This is what set_init_voltage does, replicating that logic in voltage.c makes no sense again to me. Agreed. Please update the changelog with a summary of how curr_volt is properly updated so it's clear that you're not removing something that isn't updated elsewhere. Does the following sound any better?: 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 use 1.2v and ends up generating a warning on the first transition. Further, since omap2_set_init_voltage is called as part of the pm framework's initialization sequence to configure the voltage required for the current OPP, the call does(and has to) setup the system voltage(curr_volt as a result) using the right mechanisms appropriate for the system at that point of time. This also overrides initialization we are currently doing in voltage.c making it redundant. So remove the wrong and useless initialization. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordom
Re: [PATCH 00/19] OMAP3+: introduce SR class 1.5
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 calibration mechanism designed to improve dvfs latencies > and system performance as well as helping bring in additional benefits to the > system from h/w perspective. The corresponding patch has details on this class > and the implementation as well. In addition to some specific comments given on individual patches, I a couple of general, nit-picky comments: - Please capitalize acronyms throughout the subjects/comments/changelogs. This series tends to mix lower-case and upper case acronyms - 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. - Please rebase this on top of my pm-core branch (or Paul's integration-2.6.39 branch if you prefer.) There are some important voltage related re-organization happening there that affects your code. Kevin > The series eventually results in OMAP343x based platforms using class3 and > OMAP3630, OMAP4 platforms using class1.5 automatically without modifications > or additions to board files. > > This series is Based on: > a) k.org 2.6.38-rc5 (b2.6.38-rc5) > b) The following branches Kevin Hilman's tree: (pm-base) > 'pm/for_2.6.38/pm-fixes', 'pm/for_2.6.39/pm-misc' and 'pm/pm-wip/cpufreq' > http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=summary > c) sr-fixes: (sr-baseline) > http://marc.info/?l=linux-omap&m=129783708019505&w=2 > http://marc.info/?l=linux-omap&m=129679846322563&w=2 > > This series is also available at: > git://gitorious.org/linux-omap-nm-sr/linux-omap-sr.git > Branch: sr-1.5-v1 > > Note: There is also a branch sr-dvfs-1.5 in my tree which contains the test > version of code which is based off Vishwa's DVFS series which is currently > being revamped. it may need few handtweaking for testing (esp selecting class > at menuconfig level or by commenting out appropriate late_init). > > The series contains a bunch of bugfixes and improvements needed to introduce > Smartreflex class 1.5. > Nishanth Menon (19): > omap3: hwmod: add smartreflex irqs > omap3630: hwmod: sr: enable for higher ES > omap3+: voltage: remove initial voltage > omap3+: voltage: remove spurious pr_notice for debugfs > omap3+: voltage: use IS_ERR_OR_NULL > omap3+: voltage: use volt_data pointer instead values > omap3+: voltage: add transdone apis > omap3+: sr: make notify independent of class > omap3+: sr: introduce class init,deinit and priv data > omap3+: sr: fix cosmetic indentation > omap3+: sr: call handler with interrupt disabled > omap3+: sr: disable interrupt by default > omap3+: sr: enable/disable SR only on need > omap3+: sr: introduce notifiers flags > omap3+: sr: introduce notifier_control > omap3+: sr: disable spamming interrupts > omap3+: sr: make enable path use volt_data pointer > omap3630+: sr: add support for class 1.5 > omap3430: sr: class3: restrict cpu to run on > > arch/arm/mach-omap2/Makefile |1 + > arch/arm/mach-omap2/omap_hwmod_3xxx_data.c| 25 +- > arch/arm/mach-omap2/pm.c |3 +- > arch/arm/mach-omap2/smartreflex-class1p5.c| 556 > + > arch/arm/mach-omap2/smartreflex-class3.c | 21 +- > arch/arm/mach-omap2/smartreflex.c | 249 ++-- > arch/arm/mach-omap2/voltage.c | 236 --- > arch/arm/plat-omap/Kconfig| 17 + > arch/arm/plat-omap/include/plat/smartreflex.h | 42 ++- > arch/arm/plat-omap/include/plat/voltage.h | 36 ++- > 10 files changed, 1062 insertions(+), 124 deletions(-) > create mode 100644 arch/arm/mach-omap2/smartreflex-class1p5.c > > Testing performed: > - basic boot tests on SDP3630 and SDP3430 - with bare series > - Detailed dvfs tests with Viswha's series on SDP3430 and SDP3630 > - OMAP4 was'nt supported yet by dvfs series, so very restricted tests. > - Build tests with and without each of SR classes, SMARTREFLEX enabled. > > Test Script: http://pastebin.mozilla.org/1080985 > > I request any additional tests on Panda, BeagleXM, EVM platforms that folks > may have. please feel free to comment and provide tested-by/Acked-by feedback > before I take this ahead including l-a. > > Regards, > Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4] OMAP3: PM: Set/clear T2 bit for Smartreflex on TWL
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 I2C_SR is not connected,
> the board files are expected to call omap3_twl_set_sr_bit(false) to
> ensure that I2C_SR path is not set for voltage control and prevent
> the default behavior of omap3_twl_init.
>
> Signed-off-by: Nishanth Menon
> Signed-off-by: Thara Gopinath
> Signed-off-by: Shweta Gulati
> Cc: linux-arm-ker...@lists.infradead.org
queueing this one for 2.6.39 (branch: for_2.6.39/pm-misc)
Kevin
> ---
> This patch is based on LO PM Branch and Smartreflex has been
> tested on OMAP3430 SDP, OMAP3630 SDP and boot tested on
> OMAP2430 SDP.
>
> arch/arm/mach-omap2/omap_twl.c | 60
>
> arch/arm/mach-omap2/pm.h |1 +
> 2 files changed, 61 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
> index 00e1d2b..b341c36 100644
> --- a/arch/arm/mach-omap2/omap_twl.c
> +++ b/arch/arm/mach-omap2/omap_twl.c
> @@ -59,8 +59,15 @@
>
> static bool is_offset_valid;
> static u8 smps_offset;
> +/*
> + * Flag to ensure Smartreflex bit in TWL
> + * being cleared in board file is not overwritten.
> + */
> +static bool __initdata twl_sr_enable_autoinit;
>
> +#define TWL4030_DCDC_GLOBAL_CFG0x06
> #define REG_SMPS_OFFSET 0xE0
> +#define SMARTREFLEX_ENABLE BIT(3)
>
> static unsigned long twl4030_vsel_to_uv(const u8 vsel)
> {
> @@ -269,6 +276,18 @@ int __init omap3_twl_init(void)
> omap3_core_volt_info.vp_vddmax = OMAP3630_VP2_VLIMITTO_VDDMAX;
> }
>
> + /*
> + * The smartreflex bit on twl4030 specifies if the setting of voltage
> + * is done over the I2C_SR path. Since this setting is independent of
> + * the actual usage of smartreflex AVS module, we enable TWL SR bit
> + * by default irrespective of whether smartreflex AVS module is enabled
> + * on the OMAP side or not. This is because without this bit enabled,
> + * the voltage scaling through vp forceupdate/bypass mechanism of
> + * voltage scaling will not function on TWL over I2C_SR.
> + */
> + if (!twl_sr_enable_autoinit)
> + omap3_twl_set_sr_bit(true);
> +
> voltdm = omap_voltage_domain_lookup("mpu");
> omap_voltage_register_pmic(voltdm, &omap3_mpu_volt_info);
>
> @@ -277,3 +296,44 @@ int __init omap3_twl_init(void)
>
> return 0;
> }
> +
> +/**
> + * omap3_twl_set_sr_bit() - Set/Clear SR bit on TWL
> + * @enable: enable SR mode in twl or not
> + *
> + * If 'enable' is true, enables Smartreflex bit on TWL 4030 to make sure
> + * voltage scaling through OMAP SR works. Else, the smartreflex bit
> + * on twl4030 is cleared as there are platforms which use OMAP3 and T2 but
> + * use Synchronized Scaling Hardware Strategy (ENABLE_VMODE=1) and Direct
> + * Strategy Software Scaling Mode (ENABLE_VMODE=0), for setting the voltages,
> + * in those scenarios this bit is to be cleared (enable = false).
> + *
> + * Returns 0 on sucess, error is returned if I2C read/write fails.
> + */
> +int __init omap3_twl_set_sr_bit(bool enable)
> +{
> + u8 temp;
> + int ret;
> + if (twl_sr_enable_autoinit)
> + pr_warning("%s: unexpected multiple calls\n", __func__);
> +
> + ret = twl_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, &temp,
> + TWL4030_DCDC_GLOBAL_CFG);
> + if (ret)
> + goto err;
> +
> + if (enable)
> + temp |= SMARTREFLEX_ENABLE;
> + else
> + temp &= ~SMARTREFLEX_ENABLE;
> +
> + ret = twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, temp,
> + TWL4030_DCDC_GLOBAL_CFG);
> + if (!ret) {
> + twl_sr_enable_autoinit = true;
> + return 0;
> + }
> +err:
> + pr_err("%s: Error access to TWL4030 (%d)\n", __func__, ret);
> + return ret;
> +}
> diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
> index 39580e6..797bfd1 100644
> --- a/arch/arm/mach-omap2/pm.h
> +++ b/arch/arm/mach-omap2/pm.h
> @@ -127,6 +127,7 @@ static inline void omap_enable_smartreflex_on_init(void)
> {}
> #ifdef CONFIG_TWL4030_CORE
> extern int omap3_twl_init(void);
> extern int omap4_twl_init(void);
> +extern int omap3_twl_set_sr_bit(bool enable);
> #else
> static inline int omap3_twl_init(void)
> {
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/19] omap3+: sr: disable interrupt by default
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 clear from the patch where the IRQ is re-enabled. For example, without knowing better, I would expect a corresponding change to the Class 3 driver to enable/disable the IRQ as needed. Why would that be? a) class 3 driver does not request for any notifiers b) class 3 does'nt need interrupts. c) each class driver can choose to enable when it needs it - class3 does'nt. is it fine if I add a "this is a preperation for class drivers such as class 2 and class 1.5 which would need to use interrupts" in commit message? Kevin Signed-off-by: Nishanth Menon --- arch/arm/mach-omap2/smartreflex.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c index 7931fcd..9c61ab0 100644 --- a/arch/arm/mach-omap2/smartreflex.c +++ b/arch/arm/mach-omap2/smartreflex.c @@ -281,6 +281,7 @@ static int sr_late_init(struct omap_sr *sr_info) IRQF_DISABLED, name, (void *)sr_info); if (ret) goto error; + disable_irq(sr_info->irq); } if (pdata&& pdata->enable_on_init) -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 16/19] omap3+: sr: disable spamming interrupts
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.
>
> If we detect scenarios where isr was called without the corresponding
minor: please capitalize ISR consistently throughout.
> notification bit being set, instead of hanging up the system,
> we will disable interrupt after noting the event in the system log
> to try and keep system sanity and allow developer to debug and fix
> the condition.
>
> Signed-off-by: Nishanth Menon
otherwise, patch looks fine.
Kevin
> ---
> arch/arm/mach-omap2/smartreflex.c | 12 ++--
> 1 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/smartreflex.c
> b/arch/arm/mach-omap2/smartreflex.c
> index ad23b8d..0301186 100644
> --- a/arch/arm/mach-omap2/smartreflex.c
> +++ b/arch/arm/mach-omap2/smartreflex.c
> @@ -209,8 +209,16 @@ static irqreturn_t sr_interrupt(int irq, void *data)
> value = irqstat_to_notifier_v2(status);
> }
>
> - if (sr_class->notify)
> - sr_class->notify(sr_info->voltdm, value);
> + /* Attempt some resemblence of recovery! */
> + if (!value) {
> + dev_err(&sr_info->pdev->dev, "%s: Spurious interrupt!"
> + "status = 0x%08x. Disabling to prevent spamming!!\n",
> + __func__, status);
> + disable_irq_nosync(sr_info->irq);
> + } else {
> + if (sr_class->notify)
> + sr_class->notify(sr_info->voltdm, value);
> + }
>
> return IRQ_HANDLED;
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/19] omap3+: sr: introduce notifiers flags
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 status bits coming over to it. > > A class driver should be able to function without dependency > on the exact IP version it is actually running on. We hence > introduce our own translation in s/w level for a generic > notification flag. > > As part of this change, we will now call the notifier iff we get > a match with the notifier flags that the class driver requested. > > Signed-off-by: Nishanth Menon Looks fine, minor comment below... [...] > 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 > @@ -141,6 +141,12 @@ > #define OMAP3430_SR_ERRWEIGHT0x04 > #define OMAP3430_SR_ERRMAXLIMIT 0x02 > > +/* Smart reflex notifiers for class drivers to use */ > +#define SR_NOTIFY_MCUACCUM (0x1 << 0) > +#define SR_NOTIFY_MCUVALID (0x1 << 1) > +#define SR_NOTIFY_MCUBOUND (0x1 << 2) > +#define SR_NOTIFY_MCUDISACK(0x1 << 3) > + Please use BIT(x) Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/19] omap3+: sr: disable interrupt by default
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-enabled. For example, without knowing better, I would expect a corresponding change to the Class 3 driver to enable/disable the IRQ as needed. Kevin > Signed-off-by: Nishanth Menon > --- > arch/arm/mach-omap2/smartreflex.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/mach-omap2/smartreflex.c > b/arch/arm/mach-omap2/smartreflex.c > index 7931fcd..9c61ab0 100644 > --- a/arch/arm/mach-omap2/smartreflex.c > +++ b/arch/arm/mach-omap2/smartreflex.c > @@ -281,6 +281,7 @@ static int sr_late_init(struct omap_sr *sr_info) > IRQF_DISABLED, name, (void *)sr_info); > if (ret) > goto error; > + disable_irq(sr_info->irq); > } > > if (pdata && pdata->enable_on_init) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/19] omap3+: sr: call handler with interrupt disabled
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 Menon IRQs disabled interrupt handlers are soon to disappear in the kernel. This kind of thing should be handled using locking, most likely IRQs disabled spinlocks. Kevin > --- > arch/arm/mach-omap2/smartreflex.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/mach-omap2/smartreflex.c > b/arch/arm/mach-omap2/smartreflex.c > index 1fe8b95..7931fcd 100644 > --- a/arch/arm/mach-omap2/smartreflex.c > +++ b/arch/arm/mach-omap2/smartreflex.c > @@ -278,7 +278,7 @@ static int sr_late_init(struct omap_sr *sr_info) > goto error; > } > ret = request_irq(sr_info->irq, sr_interrupt, > - 0, name, (void *)sr_info); > + IRQF_DISABLED, name, (void *)sr_info); > if (ret) > goto error; > } -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/19] omap3+: sr: fix cosmetic indentation
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 body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/19] omap3+: sr: introduce class init,deinit and priv data
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-off-by: Nishanth Menon
Basic principle looks fine, but some naming comments below...
[...]
> diff --git a/arch/arm/plat-omap/include/plat/smartreflex.h
> b/arch/arm/plat-omap/include/plat/smartreflex.h
> index 6568c88..8b6ecd9 100644
> --- a/arch/arm/plat-omap/include/plat/smartreflex.h
> +++ b/arch/arm/plat-omap/include/plat/smartreflex.h
> @@ -167,6 +167,8 @@ struct omap_sr_pmic_data {
> *
> * @enable: API to enable a particular class smaartreflex.
> * @disable: API to disable a particular class smartreflex.
> + * @class_init: API to do class specific initialization
> (optional)
> + * @class_deinit:API to do class specific initialization (optional)
The 'class_' prefix here is not needed.
The changelog uses 'start' and 'stop' instead of init & deinit. I
prefer those names to [de]init.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/19] omap3+: sr: make notify independent of class
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.
>
> Hence, the actual class does not matter for notifier. Let the class
> driver's handling decide how it should be used. smartreflex driver
> should provide just the primitives.
>
> Signed-off-by: Nishanth Menon
Thanks, queueing for 2.6.39 after capitalizing OMAP & SR in subject.
Kevin
> ---
> arch/arm/mach-omap2/smartreflex.c |6 ++
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/smartreflex.c
> b/arch/arm/mach-omap2/smartreflex.c
> index eba90a4..6f0c7d0 100644
> --- a/arch/arm/mach-omap2/smartreflex.c
> +++ b/arch/arm/mach-omap2/smartreflex.c
> @@ -142,7 +142,7 @@ static irqreturn_t sr_interrupt(int irq, void *data)
> sr_write_reg(sr_info, IRQSTATUS, status);
> }
>
> - if (sr_class->class_type == SR_CLASS2 && sr_class->notify)
> + if (sr_class->notify)
> sr_class->notify(sr_info->voltdm, status);
>
> return IRQ_HANDLED;
> @@ -257,9 +257,7 @@ static int sr_late_init(struct omap_sr *sr_info)
> struct resource *mem;
> int ret = 0;
>
> - if (sr_class->class_type == SR_CLASS2 &&
> - sr_class->notify_flags && sr_info->irq) {
> -
> + if (sr_class->notify && sr_class->notify_flags && sr_info->irq) {
> name = kasprintf(GFP_KERNEL, "sr_%s", sr_info->voltdm->name);
> if (name == NULL) {
> ret = -ENOMEM;
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/19] omap3+: voltage: remove initial voltage
"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 >>> Subject: Re: [PATCH 03/19] omap3+: voltage: remove initial voltage >>> >>> Wed, Feb 23, 2011 at 12:24, Vishwanath Sripathy >>> wrote: >>> >> -Original Message- >>> >> From: Nishanth Menon [mailto:n...@ti.com] >>> >> Sent: Sunday, February 20, 2011 10:42 AM >>> >> To: Vishwanath Sripathy >>> >> Cc: linux-omap; Tony Lindgren; Kevin Hilman >>> >> Subject: Re: [PATCH 03/19] omap3+: voltage: remove initial voltage >>> >> >>> >> Vishwanath Sripathy wrote, on 02/19/2011 06:54 PM: >>> >> [..] >>> >> >> omap2_set_init_voltage should setup the curr_volt based on >>> which >>> >> OPP >>> >> >> the system is functioning at. 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 use 1.2v and ends >>> up >>> >> >> generating a warning on the first transition. >>> >> >> >>> >> [..] >>> >> >> diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach- >>> >> >> omap2/voltage.c >>> >> >> index 12be525..280ee12 100644 >>> >> >> --- a/arch/arm/mach-omap2/voltage.c >>> >> >> +++ b/arch/arm/mach-omap2/voltage.c >>> >> [..] >>> >> >> /* Generic voltage parameters */ >>> >> >> - vdd->curr_volt = 120; >>> >> > Where do you update this parameter upon initialization? Shouldn't >>> you >>> >> read >>> >> > the VP register and find the actual current voltage and update this >>> >> param? >>> >> >>> >> The sequence is as follows: >>> >> a) omapx_vdd_data configure is called as part of sr init sequence. >>> >> And the curr_volt with this patch is not updated at this stage. >>> >> b) somewhere down in the boot sequence, pm.c's >>> >> omap2_set_init_voltage >>> >> starts up. This looks up the current clk frequency from clock layer >> of >>> >> the parent device for the domain, picks up the nominal voltages >>> stored >>> >> in the opp layer, then does a omap_voltage_scale_vdd to that >>> voltage. In >>> >> omap_voltage_scale_vdd, The current voltage is merely picked off >>> the vp >>> >> (in _pre_volt_scale). the last step it does is to setup >> vdd->curr_volt. >>> >> This can then be used by dvfs layer etc to make appropriate >>> decisions. >>> >> >>> >> So, No, I dont think I need to update it here, it should happen as >>> part >>> >> of the pm init sequence. >>> >> >>> >> Could you explain what problem do you foresee by doing this? >>> > What if omap_voltage_scale_vdd fails when called from >>> > omap2_set_init_voltage? Or omap2_set_init_voltage returns error >>> even >>> > before calling omap_voltage_scale_vdd because it could not find the >>> > matching voltage for the frequency set by bootloader? >>> > >>> > Your assumption that curr_volt is always set by >>> omap2_set_init_voltage >>> > need not be true always. >>> >>> set_init_voltage's job is to set the initial voltage. if it is >>> incapable of doing it, I say fix that instead of hacking in some >>> random number as curr_volt. >> I never said to use random numbers. All I suggested was that instead of >> relying on some others function's behavior, read the VP register to fill >> in the right values. If set_init_voltage succeeds, it will anyway update >> with right voltage. > OK, lets take this argument for a moment. > Q: which voltage to set as curr_volt? > a) what if the update was done over vcbypass by bootloader? Cannot > trust the vp register for the value. > b) what if the voltage was updated over i2c1 to the PMIC by > bootloader? cant trust vp register again. > c) use some number like 1.2v - which we are aligned is wrong. > > in short, what should we do for a accurate curr_volt? vp register may > not be correct, instead, the right steps to do: > find my current freq, check the OPP table for the voltage needed, > setup the voltage for it, update curr_volt for it. this is trust > worthy, rest are not. > > This is what set_init_voltage does, replicating that logic in > voltage.c makes no sense again to me. Agreed. Please update the changelog with a summary of how curr_volt is properly updated so it's clear that you're not removing something that isn't updated elsewhere. Thanks, Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/19] omap3: hwmod: add smartreflex irqs
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, please capitalize consistenly throughout.
I know we haven't been too consitent about this but OMAP is also an
acronym, please capitialize (c.f. $SUBJECT). This goes for the whole
series.
Otherwise patch looks fine.
Kevin
> ---
> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 17 +
> 1 files changed, 17 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> index 8d81813..ea1f49a 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> @@ -265,6 +265,15 @@ static struct omap_hwmod_ocp_if omap3_l4_core__i2c3 = {
> .user = OCP_USER_MPU | OCP_USER_SDMA,
> };
>
> +
> +static struct omap_hwmod_irq_info omap3_smartreflex_mpu_irqs[] = {
> + {.name = "sr1_irq", .irq = 18},
> +};
> +
> +static struct omap_hwmod_irq_info omap3_smartreflex_core_irqs[] = {
> + {.name = "sr2_irq", .irq = 19},
> +};
> +
> /* L4 CORE -> SR1 interface */
> static struct omap_hwmod_addr_space omap3_sr1_addr_space[] = {
> {
> @@ -1289,6 +1298,8 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
> CHIP_IS_OMAP3430ES3_0 |
> CHIP_IS_OMAP3430ES3_1),
> .flags = HWMOD_SET_DEFAULT_CLOCKACT,
> + .mpu_irqs = omap3_smartreflex_mpu_irqs,
> + .mpu_irqs_cnt = ARRAY_SIZE(omap3_smartreflex_mpu_irqs),
> };
>
> static struct omap_hwmod omap36xx_sr1_hwmod = {
> @@ -1308,6 +1319,8 @@ static struct omap_hwmod omap36xx_sr1_hwmod = {
> .slaves = omap3_sr1_slaves,
> .slaves_cnt = ARRAY_SIZE(omap3_sr1_slaves),
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1),
> + .mpu_irqs = omap3_smartreflex_mpu_irqs,
> + .mpu_irqs_cnt = ARRAY_SIZE(omap3_smartreflex_mpu_irqs),
> };
>
> /* SR2 */
> @@ -1335,6 +1348,8 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
> CHIP_IS_OMAP3430ES3_0 |
> CHIP_IS_OMAP3430ES3_1),
> .flags = HWMOD_SET_DEFAULT_CLOCKACT,
> + .mpu_irqs = omap3_smartreflex_core_irqs,
> + .mpu_irqs_cnt = ARRAY_SIZE(omap3_smartreflex_core_irqs),
> };
>
> static struct omap_hwmod omap36xx_sr2_hwmod = {
> @@ -1354,6 +1369,8 @@ static struct omap_hwmod omap36xx_sr2_hwmod = {
> .slaves = omap3_sr2_slaves,
> .slaves_cnt = ARRAY_SIZE(omap3_sr2_slaves),
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1),
> + .mpu_irqs = omap3_smartreflex_core_irqs,
> + .mpu_irqs_cnt = ARRAY_SIZE(omap3_smartreflex_core_irqs),
> };
>
> static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/17] omap4: pm: suspend, hotplug and cpuilde support
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, low power states are attempted only when the > CPU1 is put to OFF state via cpu-hotplug because of hardware > constraints. Minor nit on patch subjects: both OMAP and PM are acronyms, please capitalize. Also, can you rebase this on Paul's integration-2.6.39 branch? There are several things in this series that conflict with changes there. Thanks, Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/17] omap4: pm: CPU1 wakeup workaround form Low power modes
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 wakeup, CPU1 > restores its clockdomain hardware supervised mode. > > More details can be found in OMAP4430 TRM - Version J > Section : > 4.3.4.2 Power States of CPU0 and CPU1 > > Signed-off-by: Santosh Shilimkar > Reviewed-by: Kevin Hilman One other thing... in subject: s/form/from/ Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 16/17] omap4: cpuidle: Allow debugfs control through enable_off_mode
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;
./cpuidle44xx.c:240:omap4_power_states[OMAP4_STATE_C2].core_state =
PWRDM_POWER_ON;
./cpuidle44xx.c:262:omap4_power_states[OMAP4_STATE_C3].core_state =
PWRDM_POWER_ON;
./cpuidle44xx.c:284:omap4_power_states[OMAP4_STATE_C4].core_state =
PWRDM_POWER_ON;
> Signed-off-by: Santosh Shilimkar
> Reviewed-by: Kevin Hilman
> ---
> arch/arm/mach-omap2/cpuidle44xx.c | 30 ++
> arch/arm/mach-omap2/pm.h |1 +
> arch/arm/mach-omap2/pm44xx.c |4
> 3 files changed, 35 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
> b/arch/arm/mach-omap2/cpuidle44xx.c
> index e887eb5..4207862 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -170,6 +170,31 @@ static int omap4_enter_idle_bm(struct cpuidle_device
> *dev,
> }
>
> /**
> + * omap4_cpuidle_update_states() - Update the cpuidle states
> + * @mpu_deepest_state: Enable states upto and including this for mpu domain
> + * @core_deepest_state: Enable states upto and including this for core domain
> + *
> + * This goes through the list of states available and enables and disables
> the
> + * validity of C states based on deepest state that can be achieved for the
> + * variable domain
> + */
> +void omap4_cpuidle_update_states(u32 mpu_deepest_state, u32
> core_deepest_state)
> +{
> + int i;
> +
> + for (i = OMAP4_STATE_C1; i < OMAP4_MAX_STATES; i++) {
> + struct omap4_processor_cx *cx = &omap4_power_states[i];
> +
> + if ((cx->mpu_state >= mpu_deepest_state) &&
> + (cx->core_state >= core_deepest_state)) {
> + cx->valid = 1;
> + } else {
> + cx->valid = 0;
> + }
> + }
> +}
Also, as mentioned in a previous patch, for OMAP4 I'd like to move away
from this approach to updating the states and rather use the ->prepare
hook along with the ignore flag.
> +/**
> * omap4_init_power_states - Initialises the OMAP4 specific C states.
> *
> */
> @@ -325,6 +350,11 @@ int __init omap4_idle_init(void)
> }
> }
>
> + if (enable_off_mode)
> + omap4_cpuidle_update_states(PWRDM_POWER_OFF, PWRDM_POWER_OFF);
> + else
> + omap4_cpuidle_update_states(PWRDM_POWER_RET, PWRDM_POWER_RET);
> +
> return 0;
> }
> #else
> diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
> index ce848b0..4df89d1 100644
> --- a/arch/arm/mach-omap2/pm.h
> +++ b/arch/arm/mach-omap2/pm.h
> @@ -77,6 +77,7 @@ extern u32 sleep_while_idle;
>
> #if defined(CONFIG_CPU_IDLE)
> extern void omap3_cpuidle_update_states(u32, u32);
> +extern void omap4_cpuidle_update_states(u32, u32);
> #endif
>
> #if defined(CONFIG_PM_DEBUG) && defined(CONFIG_DEBUG_FS)
> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
> index 628242d..6244ab2 100644
> --- a/arch/arm/mach-omap2/pm44xx.c
> +++ b/arch/arm/mach-omap2/pm44xx.c
> @@ -183,6 +183,10 @@ void omap4_pm_off_mode_enable(int enable)
> else
> state = PWRDM_POWER_RET;
>
> +#ifdef CONFIG_CPU_IDLE
> + omap4_cpuidle_update_states(state, PWRDM_POWER_ON);
> +#endif
> +
> list_for_each_entry(pwrst, &pwrst_list, node) {
> /* FIXME: Remove this check when core retention is supported */
> if (!strcmp(pwrst->pwrdm->name, "mpu_pwrdm")) {
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/17] omap4: cpuidle: Add MPUSS RET OFF states
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
>
> MPU OSWR isn't supported yet. To support OSWR, power domain context
> registers needs to be managed which are not supported yet. A patch
> to address this was submitted but it's not ready for merge yet because
> it was not addressing all OMAP4 power domain context registers.
> More info on this issue:
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg38667.html
>
> OMAP4 powerdomain INACTIVE support is also dropped because of inconsistency
> of it with OMAP3. More information on this thread.
> http://www.spinics.net/lists/linux-omap/msg45370.html
>
> CORE low power states and associated latencies will be updated as part
> along with chip retention support.
>
> On OMAP4 because of hardware constraints, no low power states are
> targeted when both CPUs are online and in SMP mode. The low power
> states are attempted only when secondary CPU gets offline to OFF
> through hotplug infrastructure.
>
> Thanks to Nicole Chalhoub for doing exhaustive
> C-state latency profiling.
>
> Signed-off-by: Rajendra Nayak
> Signed-off-by: Santosh Shilimkar
> Reviewed-by: Kevin Hilman
> ---
> arch/arm/mach-omap2/cpuidle44xx.c | 190
> ++---
> 1 files changed, 176 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
> b/arch/arm/mach-omap2/cpuidle44xx.c
> index 6c3c69d..aa1584e 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -3,6 +3,7 @@
> *
> * Copyright (C) 2011 Texas Instruments, Inc.
> * Rajendra Nayak
> + * Santosh Shilimkar
> *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License version 2 as
> @@ -17,12 +18,21 @@
> #include
>
> #include "pm.h"
> +#include "prm.h"
>
> #ifdef CONFIG_CPU_IDLE
>
> -#define OMAP4_MAX_STATES 1
> -/* C1 - CPUx wfi + MPU inactive + CORE inactive */
> +#define CPUIDLE_FLAG_CHECK_BM0x1 /* use omap4_enter_idle_bm() */
> +#define OMAP4_MAX_STATES 4
> +
> +/* C1 - CPU0 ON + CPU1 ON/OFF + MPU ON + CORE ON */
> #define OMAP4_STATE_C1 0
> +/* C2 - CPU0 ON + CPU1 OFF + MPU ON + CORE ON */
> +#define OMAP4_STATE_C2 1
> +/* C3 - CPU0 OFF + CPU1 OFF + MPU CSWR + CORE ON */
> +#define OMAP4_STATE_C3 2
> +/* C4 - CPU0 OFF + CPU1 OFF + MPU OFF + CORE ON */
> +#define OMAP4_STATE_C4 3
>
> struct omap4_processor_cx {
> u8 valid;
> @@ -32,19 +42,44 @@ struct omap4_processor_cx {
> u32 cpu0_state;
> u32 cpu1_state;
> u32 mpu_state;
> + u32 mpu_logic_state;
> u32 core_state;
> + u32 core_logic_state;
> u32 threshold;
> u32 flags;
> + const char *desc;
> };
>
> -struct omap4_processor_cx omap4_power_states[OMAP4_MAX_STATES];
> -struct omap4_processor_cx current_cx_state;
> +static struct omap4_processor_cx omap4_power_states[OMAP4_MAX_STATES];
> +static struct powerdomain *mpu_pd, *cpu1_pd, *core_pd;
>
> +/*
> + * FIXME: Full latenecy numbers needs to be updated as part of
> + * cpuidle CORE retention support.
> + * Currently only MPUSS latency numbers are added based on
> + * measurements done internally. The numbers for MPUSS are
> + * not board dependent and hence set directly here instead of
> + * passing it from board files.
> + */
> static struct cpuidle_params cpuidle_params_table[] = {
> - /* C1 */
> - {1, 2, 2, 5},
> + /* C1 - CPU0 WFI + CPU1 ON/OFF + MPU ON + CORE ON */
Above comments say 'CPU0 ON' intead of WFI. Make this consistent.
Also, according to the code, CPU1 is always programmed to OFF.
That being the case, what's the difference between C1 and C2?
> + {1, 2, 2, 5},
> + /* C2 - CPU0 ON + CPU1 OFF + MPU ON + CORE ON */
> + {1, 140,160,300},
> + /* C3 - CPU0 OFF + CPU1 OFF + MPU CSWR + CORE ON */
> + {1, 200,300,700},
> + /* C4 - CPU0 OFF + CPU1 OFF + MPU OFF + CORE ON */
> + {1, 1400, 600,5000},
> };
>
> +DEFINE_PER_CPU(struct cpuidle_device, omap4_idle_dev);
> +
> +static int omap4_idle_bm_check(void)
The 'bm' terminology here is from legacy x86-based CPUidle code (for
bus-master.) Let's just call this 'activity' check.
> +{
> + /* FIXME: Populate this with CORE retention support */
> + return 0;
> +}
How about just leaving this function out altogether until it's needed.
Also leave out the #define CPUIDLE_FLAG_CHECK_BM for now.
I think we may be able to do OMAP4 a little smarter than we've done
OMAP3 using the ->prepare hook of struct cpuidle_device, and get rid of
this 'bm' check. More on that below...
> /**
> * oma
Re: [PATCH 13/17] omap4: cpuidle: Basic CPUidle support
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 minor nits below...
> ---
> arch/arm/mach-omap2/Makefile |3 +-
> arch/arm/mach-omap2/cpuidle44xx.c | 165
> +
> arch/arm/mach-omap2/pm.h |1 +
> arch/arm/mach-omap2/pm44xx.c |2 +
> 4 files changed, 170 insertions(+), 1 deletions(-)
> create mode 100644 arch/arm/mach-omap2/cpuidle44xx.c
>
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index 5d94f7e..2b4fe44 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -64,7 +64,8 @@ obj-$(CONFIG_ARCH_OMAP2)+= sleep24xx.o pm_bus.o
> voltage.o
> obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o voltage.o \
> cpuidle34xx.o pm_bus.o
> obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o voltage.o pm_bus.o \
> -omap4-mpuss-lowpower.o sleep44xx.o
> +omap4-mpuss-lowpower.o sleep44xx.o \
> +cpuidle44xx.o
> obj-$(CONFIG_PM_DEBUG) += pm-debug.o
> obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o
> obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3)+= smartreflex-class3.o
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
> b/arch/arm/mach-omap2/cpuidle44xx.c
> new file mode 100644
> index 000..6c3c69d
> --- /dev/null
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -0,0 +1,165 @@
> +/*
> + * OMAP4 CPU IDLE Routines
s/IDLE/idle/
> + *
> + * Copyright (C) 2011 Texas Instruments, Inc.
> + * Rajendra Nayak
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +
> +#include
> +
> +#include
> +
> +#include "pm.h"
> +
> +#ifdef CONFIG_CPU_IDLE
> +
> +#define OMAP4_MAX_STATES 1
> +/* C1 - CPUx wfi + MPU inactive + CORE inactive */
s/wfi/WFI/
> +#define OMAP4_STATE_C1 0
> +
> +struct omap4_processor_cx {
> + u8 valid;
> + u8 type;
> + u32 sleep_latency;
> + u32 wakeup_latency;
> + u32 cpu0_state;
> + u32 cpu1_state;
> + u32 mpu_state;
> + u32 core_state;
> + u32 threshold;
> + u32 flags;
> +};
> +
> +struct omap4_processor_cx omap4_power_states[OMAP4_MAX_STATES];
> +struct omap4_processor_cx current_cx_state;
> +
> +static struct cpuidle_params cpuidle_params_table[] = {
> + /* C1 */
> + {1, 2, 2, 5},
> +};
> +
> +/**
> + * omap4_enter_idle - Programs OMAP4 to enter the specified state
> + * @dev: cpuidle device
> + * @state: The target state to be programmed
> + *
> + * Called from the CPUidle framework to program the device to the
> + * specified low power state selected by the governor.
> + * Returns the amount of time spent in the low power state.
> + */
> +static int omap4_enter_idle(struct cpuidle_device *dev,
> + struct cpuidle_state *state)
> +{
> + struct timespec ts_preidle, ts_postidle, ts_idle;
> +
> + /* Used to keep track of the total time in idle */
> + getnstimeofday(&ts_preidle);
> +
> + local_irq_disable();
> + local_fiq_disable();
> +
> + cpu_do_idle();
> +
> + getnstimeofday(&ts_postidle);
> + ts_idle = timespec_sub(ts_postidle, ts_preidle);
> +
> + local_irq_enable();
> + local_fiq_enable();
> +
> + return ts_idle.tv_nsec / NSEC_PER_USEC + ts_idle.tv_sec * USEC_PER_SEC;
> +}
> +
> +DEFINE_PER_CPU(struct cpuidle_device, omap4_idle_dev);
> +
> +/**
> + * omap4_init_power_states - Initialises the OMAP4 specific C states.
> + *
> + * Below is the desciption of each C state.
> + * C1 : CPUx wfi + MPU inative + Core inactive
> + */
> +void omap_init_power_states(void)
> +{
> + /* C1 . CPUx wfi + MPU inactive + Core inactive */
> + omap4_power_states[OMAP4_STATE_C1].valid =
> + cpuidle_params_table[OMAP4_STATE_C1].valid;
> + omap4_power_states[OMAP4_STATE_C1].type = OMAP4_STATE_C1;
> + omap4_power_states[OMAP4_STATE_C1].sleep_latency =
> + cpuidle_params_table[OMAP4_STATE_C1].sleep_latency;
> + omap4_power_states[OMAP4_STATE_C1].wakeup_latency =
> + cpuidle_params_table[OMAP4_STATE_C1].wake_latency;
> + omap4_power_states[OMAP4_STATE_C1].threshold =
> + cpuidle_params_table[OMAP4_STATE_C1].threshold;
> + omap4_power_states[OMAP4_STATE_C1].mpu_state = PWRDM_POWER_ON;
> + omap4_power_states[OMAP4_STATE_C1].core_state = PWRDM_POWER_ON;
> + omap4_power_states[OMAP4_STATE_C1].flags = CPUIDLE_FLAG_TIME_
Re: [PATCH 12/17] omap4: pm-debug: Add wakeup timer and debug counters
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-omap2/pm-debug.c |6 --
> arch/arm/mach-omap2/pm44xx.c |5 +
> 3 files changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap4-mpuss-lowpower.c
> b/arch/arm/mach-omap2/omap4-mpuss-lowpower.c
> index ab2e101..5e0141e 100644
> --- a/arch/arm/mach-omap2/omap4-mpuss-lowpower.c
> +++ b/arch/arm/mach-omap2/omap4-mpuss-lowpower.c
> @@ -287,6 +287,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
> power_state)
> if (cpu)
> goto cpu_prepare;
>
> +#ifdef CONFIG_PM_DEBUG
> + pwrdm_pre_transition();
> +#endif
Why the #ifdef?
> /*
>* Check MPUSS next state and save GIC if needed
>* GIC lost during MPU OFF and OSWR
> @@ -332,6 +336,10 @@ cpu_prepare:
> gic_dist_set(CPU0_ID, 1);
> }
>
> +#ifdef CONFIG_PM_DEBUG
> + pwrdm_post_transition();
> +#endif
> +
> ret:
> return 0;
> }
> diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
> index 9b46b3e..7d6dd5b 100644
> --- a/arch/arm/mach-omap2/pm-debug.c
> +++ b/arch/arm/mach-omap2/pm-debug.c
> @@ -606,9 +606,11 @@ static int __init pm_dbg_init(void)
> if (pm_dbg_init_done)
> return 0;
>
> - if (cpu_is_omap34xx())
> + if (cpu_is_omap34xx()) {
> pm_dbg_reg_modules = omap3_pm_reg_modules;
> - else {
> + } else if (cpu_is_omap44xx()) {
> + /* Allow pm_dbg_init on OMAP4. */
Doing this will cause crashes if the 'registers/*' debugfs file is
accessed.
Since there are no 'reg_modules' created, you should also prevent the
creation of the 'registers' debugfs entries.
Kevin
> + } else {
> printk(KERN_ERR "%s: only OMAP3 supported\n", __func__);
> return -ENODEV;
> }
> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
> index f527e33..8e57b42 100644
> --- a/arch/arm/mach-omap2/pm44xx.c
> +++ b/arch/arm/mach-omap2/pm44xx.c
> @@ -42,6 +42,11 @@ static int omap4_pm_suspend(void)
> int state, ret = 0;
> u32 cpu_id = smp_processor_id();
>
> + /* Wakeup timer from suspend */
> + if (wakeup_timer_seconds || wakeup_timer_milliseconds)
> + omap2_pm_wakeup_on_timer(wakeup_timer_seconds,
> + wakeup_timer_milliseconds);
> +
> /* Save current powerdomain state */
> list_for_each_entry(pwrst, &pwrst_list, node) {
> pwrst->saved_state = pwrdm_read_next_pwrst(pwrst->pwrdm);
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/17] omap4: suspend: Add MPUSS RET and OFF support
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-by: Santosh Shilimkar
> Reviewed-by: Kevin Hilman
> ---
> arch/arm/mach-omap2/omap4-mpuss-lowpower.c |8 ++-
> arch/arm/mach-omap2/pm-debug.c |2 +
> arch/arm/mach-omap2/pm.h |1 +
> arch/arm/mach-omap2/pm44xx.c | 88
> ++--
> 4 files changed, 93 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap4-mpuss-lowpower.c
> b/arch/arm/mach-omap2/omap4-mpuss-lowpower.c
> index bff768f..ab2e101 100644
> --- a/arch/arm/mach-omap2/omap4-mpuss-lowpower.c
> +++ b/arch/arm/mach-omap2/omap4-mpuss-lowpower.c
> @@ -25,7 +25,7 @@
> * ON(Inactive)OFF ON(Inactive)
> * OFF OFF CSWR
> * OFF OFF OSWR (*TBD)
> - * OFF OFF OFF* (*TBD)
> + * OFF OFF OFF
> * --
> *
> * Note: CPU0 is the master core and it is the last CPU to go down
> @@ -291,6 +291,7 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
> power_state)
>* Check MPUSS next state and save GIC if needed
>* GIC lost during MPU OFF and OSWR
>*/
> + pwrdm_clear_all_prev_pwrst(mpuss_pd);
> if (pwrdm_read_next_pwrst(mpuss_pd) == PWRDM_POWER_OFF) {
> omap_wakeupgen_save();
> gic_save_context();
> @@ -357,6 +358,8 @@ int __init omap4_mpuss_init(void)
> pr_err("Lookup failed for CPU0 pwrdm\n");
> return -ENODEV;
> }
> + /* Clear CPU previous power domain state */
> + pwrdm_clear_all_prev_pwrst(pm_info->pwrdm);
? duplicate of lines immediately following.
> /* Clear CPU previous power domain state */
> pwrdm_clear_all_prev_pwrst(pm_info->pwrdm);
> @@ -394,6 +397,9 @@ int __init omap4_mpuss_init(void)
> return -ENODEV;
> }
>
> + /* Clear CPU previous power domain state */
> + pwrdm_clear_all_prev_pwrst(mpuss_pd);
> +
> /*
>* Find out how many interrupts are supported.
>* OMAP4 supports max of 128 SPIs where as GIC can support
> diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
> index 125f565..9b46b3e 100644
> --- a/arch/arm/mach-omap2/pm-debug.c
> +++ b/arch/arm/mach-omap2/pm-debug.c
> @@ -588,6 +588,8 @@ static int option_set(void *data, u64 val)
> omap_pm_disable_off_mode();
> if (cpu_is_omap34xx())
> omap3_pm_off_mode_enable(val);
> + else if (cpu_is_omap44xx())
> + omap4_pm_off_mode_enable(val);
> }
>
> return 0;
> diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
> index 1c1b0ab..f557407 100644
> --- a/arch/arm/mach-omap2/pm.h
> +++ b/arch/arm/mach-omap2/pm.h
> @@ -17,6 +17,7 @@
>
> extern void *omap3_secure_ram_storage;
> extern void omap3_pm_off_mode_enable(int);
> +extern void omap4_pm_off_mode_enable(int);
> extern void omap_sram_idle(void);
> extern int omap3_can_sleep(void);
> extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
> index 9a9dc41..f527e33 100644
> --- a/arch/arm/mach-omap2/pm44xx.c
> +++ b/arch/arm/mach-omap2/pm44xx.c
> @@ -1,8 +1,9 @@
> /*
> * OMAP4 Power Management Routines
> *
> - * Copyright (C) 2010 Texas Instruments, Inc.
> + * Copyright (C) 2010-2011 Texas Instruments, Inc.
> * Rajendra Nayak
> + * Santosh Shilimkar
> *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License version 2 as
> @@ -21,6 +22,7 @@
>
> #include "powerdomain.h"
> #include "clockdomain.h"
> +#include "pm.h"
>
> struct power_state {
> struct powerdomain *pwrdm;
> @@ -36,7 +38,50 @@ static LIST_HEAD(pwrst_list);
> #ifdef CONFIG_SUSPEND
> static int omap4_pm_suspend(void)
> {
> - do_wfi();
> + struct power_state *pwrst;
> + int state, ret = 0;
> + u32 cpu_id = smp_processor_id();
> +
> + /* Save current powerdomain state */
> + list_for_each_entry(pwrst, &pwrst_list, node) {
> + pwrst->saved_state = pwrdm_read_next_pwrst(pwrst->pwrdm);
> + }
> +
> + /* Set targeted power domain states by suspend */
> + list_for_each_entry(pwrst, &pwrst_list, node) {
> + /* FIXME: Remove this check when CORE retention is supported */
> + if (!strcmp(pwrst->pwrdm->name, "mpu_pwrdm"))
> + omap_set_pwrdm_state(pwrst->pwrdm, pwrst->next_state);
> + }
pwrst_list is the list of powerdomains to that will be changed
Re: [PATCH 10/17] omap4: pm: Add L2 cache lowpower support
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 | 11 +
> arch/arm/mach-omap2/omap4-sar-layout.h |2 +
> arch/arm/mach-omap2/sleep44xx.S| 64
>
> 3 files changed, 77 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap4-mpuss-lowpower.c
> b/arch/arm/mach-omap2/omap4-mpuss-lowpower.c
> index a30f19b..bff768f 100644
> --- a/arch/arm/mach-omap2/omap4-mpuss-lowpower.c
> +++ b/arch/arm/mach-omap2/omap4-mpuss-lowpower.c
> @@ -49,6 +49,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -341,6 +342,7 @@ int __init omap4_mpuss_init(void)
> {
> struct omap4_cpu_pm_info *pm_info;
> u8 i;
> + u32 val;
This will cause an 'unused variable' compiler warning when
!CONFIG_CACHE_L2X0
[...]
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/17] omap4: pm: Add WakeupGen save/restore support
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 mechinism also does
> restore of wakeupgen on mpu OFF/OSWR
Changelog needs some clarification...
The way I read the above is that "save is not needed, but we do it
anyways for consistency"
It's not terribly clear (to me) how "consistent state" would be lost
if this does not happen.
IOW, describing a potential inconsistent state would be helpful for the
changelog (and code.)
> Signed-off-by: Santosh Shilimkar
> Reviewed-by: Kevin Hilman
> ---
> arch/arm/mach-omap2/include/mach/omap-wakeupgen.h |1 +
> arch/arm/mach-omap2/omap-wakeupgen.c | 74
> +
> arch/arm/mach-omap2/omap4-mpuss-lowpower.c|2 +
> arch/arm/mach-omap2/omap4-sar-layout.h| 11 +++
> 4 files changed, 88 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h
> b/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h
> index f10d106..66f31c3 100644
> --- a/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h
> +++ b/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h
> @@ -37,4 +37,5 @@
>
> extern int __init omap_wakeupgen_init(void);
> extern void omap_wakeupgen_irqmask_all(unsigned int cpu, unsigned int set);
> +extern void omap_wakeupgen_save(void);
> #endif
> diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c
> b/arch/arm/mach-omap2/omap-wakeupgen.c
> index e26a0ed..0f0a5ed 100644
> --- a/arch/arm/mach-omap2/omap-wakeupgen.c
> +++ b/arch/arm/mach-omap2/omap-wakeupgen.c
> @@ -24,6 +24,9 @@
> #include
>
> #include
> +#include
> +
> +#include "omap4-sar-layout.h"
>
> #define NR_BANKS 4
> #define MAX_IRQS 128
> @@ -54,6 +57,11 @@ static inline void cpu_writel(u32 val, u8 idx, u32 cpu)
> (cpu * CPU_ENA_OFFSET) + (idx * 4));
> }
>
> +static inline void sar_writel(u32 val, u32 offset, u8 idx)
> +{
> + __raw_writel(val, sar_ram_base + offset + (idx * 4));
> +}
> +
aha, another function that belongs in the SAR code.
[...]
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/17] omap4: pm: Add GIC save/restore support
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/supposed/
> to be saved. Refer to ROM code specs for the GIC layout details.
Does this doc have a name? I've never seen such a thing and would
really like to.
> Signed-off-by: Santosh Shilimkar
> Reviewed-by: Kevin Hilman
> ---
> arch/arm/mach-omap2/omap-hotplug.c |4 +
> arch/arm/mach-omap2/omap4-mpuss-lowpower.c | 176
> +++-
> arch/arm/mach-omap2/omap4-sar-layout.h | 20 +++
> 3 files changed, 199 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap-hotplug.c
> b/arch/arm/mach-omap2/omap-hotplug.c
> index cf4ab15..deab389 100644
> --- a/arch/arm/mach-omap2/omap-hotplug.c
> +++ b/arch/arm/mach-omap2/omap-hotplug.c
> @@ -19,6 +19,8 @@
> #include
>
> #include
> +#include
> +
> #include
> #include
>
> @@ -58,6 +60,7 @@ void platform_cpu_die(unsigned int cpu)
>* clear all interrupt wakeup sources
>*/
> omap_wakeupgen_irqmask_all(cpu, 1);
> + gic_secondary_set(0, true);
> omap4_enter_lowpower(cpu, PWRDM_POWER_OFF);
> this_cpu = hard_smp_processor_id();
> if (omap_read_auxcoreboot0() == this_cpu) {
> @@ -65,6 +68,7 @@ void platform_cpu_die(unsigned int cpu)
>* OK, proper wakeup, we're done
>*/
> omap_wakeupgen_irqmask_all(this_cpu, 0);
> + gic_secondary_set(0, false);
>
> /* Restore clockdomain to hardware supervised */
> clkdm_allow_idle(cpu1_clkdm);
> diff --git a/arch/arm/mach-omap2/omap4-mpuss-lowpower.c
> b/arch/arm/mach-omap2/omap4-mpuss-lowpower.c
> index c0f358d..4140251 100644
> --- a/arch/arm/mach-omap2/omap4-mpuss-lowpower.c
> +++ b/arch/arm/mach-omap2/omap4-mpuss-lowpower.c
> @@ -47,6 +47,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
> #include
> @@ -59,6 +61,19 @@
>
> #define CPU0_ID 0x0
> #define CPU1_ID 0x1
> +#define GIC_MASK_ALL 0x0
> +#define GIC_ISR_NON_SECURE 0x
> +#define SPI_ENABLE_SET_OFFSET0x04
> +#define PPI_PRI_OFFSET 0x1c
> +#define SPI_PRI_OFFSET 0x20
> +#define SPI_TARGET_OFFSET0x20
> +#define SPI_CONFIG_OFFSET0x20
> +
> +/* GIC save SAR bank base */
> +static struct powerdomain *mpuss_pd;
> +
> +/* Variables to store maximum spi(Shared Peripheral Interrupts) registers. */
> +static u32 max_spi_irq, max_spi_reg;
>
> struct omap4_cpu_pm_info {
> struct powerdomain *pwrdm;
> @@ -67,6 +82,17 @@ struct omap4_cpu_pm_info {
>
> static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
>
> +/* Helper functions */
> +static inline void sar_writel(u32 val, u32 offset, u8 idx)
> +{
> + __raw_writel(val, sar_ram_base + offset + 4 * idx);
> +}
aha, this is what I was thinking of in the earlier SAR patch.
Something like this should be part of the SAR code, not here.
> +static inline u32 gic_readl(u32 offset, u8 idx)
> +{
> + return __raw_readl(gic_dist_base_addr + offset + 4 * idx);
> +}
Similarily, it would be nice tos see this as part of GIC code so
this code doesn't have to access a global base address pointer.
> /*
> * Set the CPUx powerdomain's previous power state
> */
> @@ -124,6 +150,85 @@ static void scu_pwrst_prepare(unsigned int cpu_id,
> unsigned int cpu_state)
> }
>
> /*
> + * Save GIC context in SAR RAM. Restore is done by ROM code
> + * GIC is lost only when MPU hits OSWR or OFF. It consists
> + * of a distributor and a per-CPU interface module. The GIC
> + * save restore is optimised to save only necessary registers.
> + */
> +static void gic_save_context(void)
> +{
> + u8 i;
> + u32 val;
> +
> + /*
> + * Interrupt Clear Enable registers are inverse of set enable
> + * and hence not needed to be saved. ROM code programs it
> + * based on Set Enable register values.
> + */
> +
> + /* Save CPU 0 Interrupt Set Enable register */
> + val = gic_readl(GIC_DIST_ENABLE_SET, 0);
> + sar_writel(val, ICDISER_CPU0_OFFSET, 0);
> +
> + /* Disable interrupts on CPU1 */
> + sar_writel(GIC_MASK_ALL, ICDISER_CPU1_OFFSET, 0);
> +
> + /* Save all SPI Set Enable register */
> + for (i = 0; i < max_spi_reg; i++) {
> + val = gic_readl(GIC_DIST_ENABLE_SET + SPI_ENABLE_SET_OFFSET, i);
> + sar_writel(val, ICDISER_SPI_OFFSET, i);
> + }
> +
> + /*
> + * Interrupt Priority Registers
> + * Secure sw accesses, last 5 bits of the 8 bits (bi
Re: [PATCH 07/17] omap4: pm: CPU1 wakeup workaround form Low power modes
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 wakeup, CPU1
> restores its clockdomain hardware supervised mode.
>
> More details can be found in OMAP4430 TRM - Version J
> Section :
> 4.3.4.2 Power States of CPU0 and CPU1
>
> Signed-off-by: Santosh Shilimkar
> Reviewed-by: Kevin Hilman
> ---
> arch/arm/mach-omap2/omap-hotplug.c |9 +
> arch/arm/mach-omap2/omap-smp.c | 27 ++-
> 2 files changed, 35 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap-hotplug.c
> b/arch/arm/mach-omap2/omap-hotplug.c
> index 9f8f097..cf4ab15 100644
> --- a/arch/arm/mach-omap2/omap-hotplug.c
> +++ b/arch/arm/mach-omap2/omap-hotplug.c
> @@ -23,6 +23,7 @@
> #include
>
> #include "powerdomain.h"
> +#include "clockdomain.h"
>
> int platform_cpu_kill(unsigned int cpu)
> {
> @@ -36,6 +37,11 @@ int platform_cpu_kill(unsigned int cpu)
> void platform_cpu_die(unsigned int cpu)
> {
> unsigned int this_cpu;
> + static struct clockdomain *cpu1_clkdm;
> +
> + /* To avoid cpu1 clockdomain lookup every time */
minor: comment doesn't really match code and could just be removed
> + if (!cpu1_clkdm)
> + cpu1_clkdm = clkdm_lookup("mpu1_clkdm");
>
> flush_cache_all();
> dsb();
> @@ -59,6 +65,9 @@ void platform_cpu_die(unsigned int cpu)
>* OK, proper wakeup, we're done
>*/
> omap_wakeupgen_irqmask_all(this_cpu, 0);
> +
> + /* Restore clockdomain to hardware supervised */
> + clkdm_allow_idle(cpu1_clkdm);
> break;
> }
> pr_debug("CPU%u: spurious wakeup call\n", cpu);
> diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
> index b105a29..31c9b79 100644
> --- a/arch/arm/mach-omap2/omap-smp.c
> +++ b/arch/arm/mach-omap2/omap-smp.c
> @@ -25,6 +25,8 @@
> #include
> #include
>
> +#include "clockdomain.h"
> +
> /* SCU base address */
> void __iomem *scu_base;
>
> @@ -48,6 +50,8 @@ void __cpuinit platform_secondary_init(unsigned int cpu)
>
> int __cpuinit boot_secondary(unsigned int cpu, struct task_struct *idle)
> {
> + static struct clockdomain *cpu1_clkdm;
> + static bool booted;
> /*
>* Set synchronisation state between this boot processor
>* and the secondary one
> @@ -63,7 +67,28 @@ int __cpuinit boot_secondary(unsigned int cpu, struct
> task_struct *idle)
> omap_modify_auxcoreboot0(0x200, 0xfdff);
> flush_cache_all();
> smp_wmb();
> - smp_cross_call(cpumask_of(cpu), 1);
> +
> + /* To avoid cpu1 clockdomain lookup every time */
ditto
> + if (!cpu1_clkdm)
> + cpu1_clkdm = clkdm_lookup("mpu1_clkdm");
> +
> + /*
> + * 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. To wakeup CPU1, CPU0 forces the CPU1 clockdomain to
> + * software force wakeup. After the wakeup, CPU1 restores its
> + * clockdomain hardware supervised mode.
> + * More details can be found in OMAP4430 TRM - Version J
> + * Section :
> + * 4.3.4.2 Power States of CPU0 and CPU1
> + */
> + if (booted) {
> + clkdm_wakeup(cpu1_clkdm);
> + } else {
> + dsb_sev();
> + booted = true;
> + }
>
> /*
>* Now the secondary core is starting up let it run its
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/17] omap4: pm: Initialise all the clockdomains to supported states
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
> ---
> arch/arm/mach-omap2/pm44xx.c | 22 +-
> 1 files changed, 21 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
> index b142673..9a9dc41 100644
> --- a/arch/arm/mach-omap2/pm44xx.c
> +++ b/arch/arm/mach-omap2/pm44xx.c
> @@ -17,9 +17,11 @@
> #include
> #include
>
> -#include "powerdomain.h"
> #include
>
> +#include "powerdomain.h"
> +#include "clockdomain.h"
> +
> struct power_state {
> struct powerdomain *pwrdm;
> u32 next_state;
> @@ -74,6 +76,22 @@ static const struct platform_suspend_ops omap_pm_ops = {
> };
> #endif /* CONFIG_SUSPEND */
>
> +/*
> + * Enable hardwarew supervised mode for all clockdomains if it's
typo: hardware
> + * supported. Initiate sleep transition for other clockdomains, if
> + * they are not used
> + */
> +static int __init clkdms_setup(struct clockdomain *clkdm, void *unused)
> +{
> + if (clkdm->flags & CLKDM_CAN_ENABLE_AUTO)
> + clkdm_allow_idle(clkdm);
> + else if (clkdm->flags & CLKDM_CAN_FORCE_SLEEP &&
> + atomic_read(&clkdm->usecount) == 0)
> + clkdm_sleep(clkdm);
> + return 0;
> +}
> +
> +
> static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
> {
> struct power_state *pwrst;
> @@ -116,6 +134,8 @@ static int __init omap4_pm_init(void)
> /* Enable autoidle for all clks which support it*/
> omap_clk_enable_autoidle();
>
> + (void) clkdm_for_each(clkdms_setup, NULL);
> +
> ret = omap4_mpuss_init();
> if (ret) {
> pr_err("Failed to initialise OMAP4 MPUSS\n");
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/17] omap4: pm: Add CPUx OFF mode support
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/cpuilde/CPUidle/
> Signed-off-by: Santosh Shilimkar
> Reviewed-by: Kevin Hilman
> ---
> arch/arm/mach-omap2/Makefile|4 +-
> arch/arm/mach-omap2/include/mach/omap4-common.h | 46 +++
> arch/arm/mach-omap2/omap4-mpuss-lowpower.c | 241
> arch/arm/mach-omap2/omap4-sar-layout.h | 14 +
> arch/arm/mach-omap2/pm44xx.c|6 +
> arch/arm/mach-omap2/sleep44xx.S | 334
> +++
> 6 files changed, 644 insertions(+), 1 deletions(-)
> create mode 100644 arch/arm/mach-omap2/omap4-mpuss-lowpower.c
> create mode 100644 arch/arm/mach-omap2/sleep44xx.S
>
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index 54ff219..5d94f7e 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -63,13 +63,15 @@ obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
> obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o pm_bus.o voltage.o
> obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o voltage.o \
> cpuidle34xx.o pm_bus.o
> -obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o voltage.o pm_bus.o
> +obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o voltage.o pm_bus.o \
> +omap4-mpuss-lowpower.o sleep44xx.o
> obj-$(CONFIG_PM_DEBUG) += pm-debug.o
> obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o
> obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3)+= smartreflex-class3.o
>
> AFLAGS_sleep24xx.o :=-Wa,-march=armv6
> AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a
> +AFLAGS_sleep44xx.o :=-Wa,-march=armv7-a
>
> ifeq ($(CONFIG_PM_VERBOSE),y)
> CFLAGS_pm_bus.o += -DDEBUG
> diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h
> b/arch/arm/mach-omap2/include/mach/omap4-common.h
> index 0e5edd8..74c9aa7 100644
> --- a/arch/arm/mach-omap2/include/mach/omap4-common.h
> +++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
> @@ -13,6 +13,9 @@
> #ifndef OMAP_ARCH_OMAP4_COMMON_H
> #define OMAP_ARCH_OMAP4_COMMON_H
>
> +#include
> +
> +#ifndef __ASSEMBLER__
> /*
> * wfi used in low power code. Directly opcode is used instead
> * of instruction to avoid mulit-omap build break
> @@ -33,4 +36,47 @@ extern void __iomem *scu_base;
> extern void __init gic_init_irq(void);
> extern void omap_smc1(u32 fn, u32 arg);
>
> +/*
> + * Read MPIDR: Multiprocessor affinity register
> + */
> +static inline unsigned int hard_smp_processor_id(void)
> +{
> + unsigned int cpunum;
> +
> + asm volatile (
> + "mrc p15, 0, %0, c0, c0, 5\n"
> + : "=r" (cpunum));
> + return cpunum &= 0x0F;
minor: lower-case hex numbers are preferred
> +}
> +
> +#if defined(CONFIG_SMP) && defined(CONFIG_PM)
s/CONFIG_PM/CONFIG_SUSPEND/
> +extern int omap4_mpuss_init(void);
> +extern int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state);
> +extern void omap4_cpu_suspend(unsigned int cpu, unsigned int save_state);
> +extern void omap4_cpu_resume(void);
> +
> +#else
> +
> +static inline int omap4_enter_lowpower(unsigned int cpu,
> + unsigned int power_state)
> +{
> + cpu_do_idle();
> + return 0;
> +}
> +
> +static inline int omap4_mpuss_init(void)
> +{
> + return 0;
> +}
> +
> +static inline void omap4_cpu_suspend(unsigned int cpu, unsigned int
> save_state)
> +{
> +}
> +
> +static inline void omap4_cpu_resume(void)
> +{
> +}
> +
> #endif
> +#endif /* __ASSEMBLER__ */
> +#endif /* OMAP_ARCH_OMAP4_COMMON_H */
> diff --git a/arch/arm/mach-omap2/omap4-mpuss-lowpower.c
> b/arch/arm/mach-omap2/omap4-mpuss-lowpower.c
> new file mode 100644
> index 000..c0f358d
> --- /dev/null
> +++ b/arch/arm/mach-omap2/omap4-mpuss-lowpower.c
> @@ -0,0 +1,241 @@
> +/*
> + * OMAP4 MPUSS low power code
> + *
> + * Copyright (C) 2011 Texas Instruments, Inc.
> + * Written by Santosh Shilimkar
> + *
> + * OMAP4430 MPUSS mainly consists of dual Cortex-A9 with per-CPU
> + * Local timer and Watchdog, GIC, SCU, PL310 L2 cache controller,
> + * CPU0 and CPU1 LPRM modules.
> + * CPU0, CPU1 and MPUSS each have there own power domain and
> + * hence multiple low power combinations of MPUSS are possible.
> + *
> + * The CPU0 and CPU1 can't support Closed switch Retention (CSWR)
> + * because the mode is not supported by hw constraints of dormant
> + * mode. While waking up from the dormant mode, a reset signal
> + * to the Cortex-A9 processor must be asserted by the external
> + * power controller.
> + *
> + * With architectural inputs and
Re: [PATCH 03/17] omap4: Export scu base address
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 Shilimkar > Reviewed-by: Kevin Hilman > --- > arch/arm/mach-omap2/include/mach/omap4-common.h |4 > arch/arm/mach-omap2/omap-smp.c |2 +- > 2 files changed, 5 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h > b/arch/arm/mach-omap2/include/mach/omap4-common.h > index 5b0270b..0e5edd8 100644 > --- a/arch/arm/mach-omap2/include/mach/omap4-common.h > +++ b/arch/arm/mach-omap2/include/mach/omap4-common.h > @@ -26,6 +26,10 @@ extern void __iomem *l2cache_base; > > extern void __iomem *gic_dist_base_addr; > > +#ifdef CONFIG_SMP > +extern void __iomem *scu_base; > +#endif > + > extern void __init gic_init_irq(void); > extern void omap_smc1(u32 fn, u32 arg); > > diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c > index b66cfe8..b105a29 100644 > --- a/arch/arm/mach-omap2/omap-smp.c > +++ b/arch/arm/mach-omap2/omap-smp.c > @@ -26,7 +26,7 @@ > #include > > /* SCU base address */ > -static void __iomem *scu_base; > +void __iomem *scu_base; > > static DEFINE_SPINLOCK(boot_lock); -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] omap:mailbox: resolve hang issue
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-omap2/mailbox.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 394413d..011ca50 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -193,10 +193,12 @@ static void omap2_mbox_disable_irq(struct omap_mbox *mbox,
omap_mbox_type_t irq)
{
struct omap_mbox2_priv *p = mbox->priv;
- u32 l, bit = (irq == IRQ_TX) ? p->notfull_bit : p->newmsg_bit;
- l = mbox_read_reg(p->irqdisable);
- l &= ~bit;
- mbox_write_reg(l, p->irqdisable);
+ u32 bit = (irq == IRQ_TX) ? p->notfull_bit : p->newmsg_bit;
+
+ if (!cpu_is_omap44xx())
+ bit = mbox_read_reg(p->irqdisable) & ~bit;
+
+ mbox_write_reg(bit, p->irqdisable);
}
static void omap2_mbox_ack_irq(struct omap_mbox *mbox,
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/17] omap4: pm: Add SAR RAM support
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 -
> arch/arm/mach-omap2/omap4-sar-layout.h | 24
> arch/arm/plat-omap/include/plat/omap44xx.h |1 +
> 3 files changed, 49 insertions(+), 1 deletions(-)
> create mode 100644 arch/arm/mach-omap2/omap4-sar-layout.h
>
> diff --git a/arch/arm/mach-omap2/omap4-common.c
> b/arch/arm/mach-omap2/omap4-common.c
> index 559d227..48484a5 100644
> --- a/arch/arm/mach-omap2/omap4-common.c
> +++ b/arch/arm/mach-omap2/omap4-common.c
> @@ -23,12 +23,14 @@
> #include
> #include
>
> +#include "omap4-sar-layout.h"
> +
> #ifdef CONFIG_CACHE_L2X0
> void __iomem *l2cache_base;
> #endif
>
> void __iomem *gic_dist_base_addr;
> -
> +void __iomem *sar_ram_base;
>
> void __init gic_init_irq(void)
> {
> @@ -107,3 +109,24 @@ static int __init omap_l2_cache_init(void)
> }
> early_initcall(omap_l2_cache_init);
> #endif
> +
> +/*
> + * SAR RAM used to save and restore the HW
> + * context in low power modes
> + */
> +static int __init omap4_sar_ram_init(void)
> +{
> + /*
> + * To avoid code running on other OMAPs in
> + * multi-omap builds
> + */
> + if (!cpu_is_omap44xx())
> + return -ENODEV;
> +
> + /* Static mapping, never released */
> + sar_ram_base = ioremap(OMAP44XX_SAR_RAM_BASE, SZ_8K);
> + BUG_ON(!sar_ram_base);
Again, a BUG is not approprate here.
Instead, other code needs to properly handle when sar_ram_base == NULL
> + return 0;
> +}
> +early_initcall(omap4_sar_ram_init);
> diff --git a/arch/arm/mach-omap2/omap4-sar-layout.h
> b/arch/arm/mach-omap2/omap4-sar-layout.h
> new file mode 100644
> index 000..bb66816
> --- /dev/null
> +++ b/arch/arm/mach-omap2/omap4-sar-layout.h
> @@ -0,0 +1,24 @@
> +/*
> + * omap4-sar-layout.h: OMAP4 SAR RAM layout header file
> + *
> + * Copyright (C) 2011 Texas Instruments, Inc.
> + * Santosh Shilimkar
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#ifndef OMAP_ARCH_OMAP4_SAR_LAYOUT_H
> +#define OMAP_ARCH_OMAP4_SAR_LAYOUT_H
> +
> +/*
> + * SAR BANK offsets from base address OMAP44XX_SAR_RAM_BASE
> + */
> +#define SAR_BANK1_OFFSET 0x
> +#define SAR_BANK2_OFFSET 0x1000
> +#define SAR_BANK3_OFFSET 0x2000
> +#define SAR_BANK4_OFFSET 0x3000
> +
> +extern void __iomem *sar_ram_base;
This patch creates this as global, but has no global users.
Also, personally, I don't like these 'base address as global pointer'
that are appearing throughout the OMAP4 code. This one is continuing
the pattern of some others (gic_dist_base_addr, gic_cpu_base) etc., but
I'm not crazy about them. BTW, the gic* ones also suffer from the BUG
problem and do not properly handle error conditions.
It would be much cleaner to keep this base address static (and local)
and just create some sar_read/write helpers that can be used from other
code.
Hmm, I see the assembly code uses this base address to. For that, a
helper function to get the base address could be created.
Kevin
> +#endif
> diff --git a/arch/arm/plat-omap/include/plat/omap44xx.h
> b/arch/arm/plat-omap/include/plat/omap44xx.h
> index ea2b8a6..c0d478e 100644
> --- a/arch/arm/plat-omap/include/plat/omap44xx.h
> +++ b/arch/arm/plat-omap/include/plat/omap44xx.h
> @@ -45,6 +45,7 @@
> #define OMAP44XX_WKUPGEN_BASE0x48281000
> #define OMAP44XX_MCPDM_BASE 0x40132000
> #define OMAP44XX_MCPDM_L3_BASE 0x49032000
> +#define OMAP44XX_SAR_RAM_BASE0x4a326000
>
> #define OMAP44XX_MAILBOX_BASE(L4_44XX_BASE + 0xF4000)
> #define OMAP44XX_HSUSB_OTG_BASE (L4_44XX_BASE + 0xAB000)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/17] omap4: pm: Add omap WakeupGen module support
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 delivers external interrupts directly to the GIC. > When the CPUx asserts StandbyWFI, indicating it wants to enter lowpower > state, the Standby Controller checks with the WakeupGen unit using the > idlereq/idleack handshake to make sure there is no incoming interrupts. > The GIC and WakeupGen needs to be kept in synchronisation for proper > interrupt functioning. > > Hence this patch hooks up the omap WakeupGen mask/unmask along with GIC using > architecture specific hooks. > > Signed-off-by: Santosh Shilimkar > Reviewed-by: Kevin Hilman A few comments below... > --- > arch/arm/mach-omap2/Makefile |3 +- > arch/arm/mach-omap2/include/mach/omap-wakeupgen.h | 40 > arch/arm/mach-omap2/omap-wakeupgen.c | 213 > + > arch/arm/mach-omap2/omap4-common.c|3 + > 4 files changed, 258 insertions(+), 1 deletions(-) > create mode 100644 arch/arm/mach-omap2/include/mach/omap-wakeupgen.h > create mode 100644 arch/arm/mach-omap2/omap-wakeupgen.c > > diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile > index 72f2891..54ff219 100644 > --- a/arch/arm/mach-omap2/Makefile > +++ b/arch/arm/mach-omap2/Makefile > @@ -24,7 +24,8 @@ obj-$(CONFIG_TWL4030_CORE) += omap_twl.o > obj-$(CONFIG_SMP)+= omap-smp.o omap-headsmp.o > obj-$(CONFIG_LOCAL_TIMERS) += timer-mpu.o > obj-$(CONFIG_HOTPLUG_CPU)+= omap-hotplug.o > -obj-$(CONFIG_ARCH_OMAP4) += omap44xx-smc.o omap4-common.o > +obj-$(CONFIG_ARCH_OMAP4) += omap44xx-smc.o omap4-common.o \ > +omap-wakeupgen.o > > plus_sec := $(call as-instr,.arch_extension sec,+sec) > AFLAGS_omap-headsmp.o:=-Wa,-march=armv7-a$(plus_sec) > diff --git a/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h > b/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h > new file mode 100644 > index 000..f10d106 > --- /dev/null > +++ b/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h > @@ -0,0 +1,40 @@ > +/* > + * OMAP WakeupGen header file > + * > + * Copyright (C) 2011 Texas Instruments, Inc. > + * Written by Santosh Shilimkar > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + */ > +#ifndef OMAP_ARCH_WAKEUPGEN_H > +#define OMAP_ARCH_WAKEUPGEN_H > + > +#define OMAP_WKG_CONTROL_0 0x00 > +#define OMAP_WKG_ENB_A_0 0x10 > +#define OMAP_WKG_ENB_B_0 0x14 > +#define OMAP_WKG_ENB_C_0 0x18 > +#define OMAP_WKG_ENB_D_0 0x1c > +#define OMAP_WKG_ENB_SECURE_A_0 0x20 > +#define OMAP_WKG_ENB_SECURE_B_0 0x24 > +#define OMAP_WKG_ENB_SECURE_C_0 0x28 > +#define OMAP_WKG_ENB_SECURE_D_0 0x2c > +#define OMAP_WKG_ENB_A_1 0x410 > +#define OMAP_WKG_ENB_B_1 0x414 > +#define OMAP_WKG_ENB_C_1 0x418 > +#define OMAP_WKG_ENB_D_1 0x41c > +#define OMAP_WKG_ENB_SECURE_A_1 0x420 > +#define OMAP_WKG_ENB_SECURE_B_1 0x424 > +#define OMAP_WKG_ENB_SECURE_C_1 0x428 > +#define OMAP_WKG_ENB_SECURE_D_1 0x42c > +#define OMAP_AUX_CORE_BOOT_0 0x800 > +#define OMAP_AUX_CORE_BOOT_1 0x804 > +#define OMAP_PTMSYNCREQ_MASK 0xc00 > +#define OMAP_PTMSYNCREQ_EN 0xc04 > +#define OMAP_TIMESTAMPCYCLELO0xc08 > +#define OMAP_TIMESTAMPCYCLEHI0xc0c > + > +extern int __init omap_wakeupgen_init(void); > +extern void omap_wakeupgen_irqmask_all(unsigned int cpu, unsigned int set); > +#endif > diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c > b/arch/arm/mach-omap2/omap-wakeupgen.c > new file mode 100644 > index 000..e26a0ed > --- /dev/null > +++ b/arch/arm/mach-omap2/omap-wakeupgen.c > @@ -0,0 +1,213 @@ > +/* > + * OMAP WakeupGen Source file > + * > + * 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. The WakeupGen consists of two sub-units, one for > + * each CPU and manages only SPI interrupts. Hardware requirements is that > + * the GIC and WakeupGen should be kept in sync for proper operation. > + * > + * Copyright (C) 2011 Texas Instruments, Inc. > + * Written by Santosh Shilimkar > + * > + * This program
Re: [PATCH v6 0/8] OMAP: HSMMC: hwmod adaptation
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] OMAP3 PM: Deny clock gating only for safe state
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 safe >> state >> >> Vishwanath BS writes: >> >> > Currently clock gating for MPU and core are denied whenever C1 state >> is >> > selected. >> >> Yes, that is the definition of C1. >> >> > It should be denied only when safe state is selected. >> >> Why? > Clock gating in C1 will reduce overall power consumption and it should not > impact any functionality as well. Clock gating changes latencies. >> >> This changes the definition and behavior of C1 depending on how it is >> entered. Not a good idea IMO. > I thought of adding a new C state, keeping C1 definition unchanged. Then > we will not get the real power benefit since in case of C1, clock gating > will be prevented. Let me know if you have some suggestion. My problem with this patch is that you make C1 have different behavior depending on whether it is selected directly by the governor or it is entered due to the safe state. The motiviation for this change is not at all described in the changelog. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: State of SDP4430 platform
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 IRQ registers and bq24156 were OK > > > > > > Was an errata generated for this bug? > > > > er, erratum, pardon me... > > Is an erratum present for this bug? > > Also, will you generate a patch for this to at least warn the user when > this situation occurs? Still waiting for a response to this. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Nokia n810 LCD (MIPID/blizzard) on 2.6.38
* 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 > bootloader initialized it to: The long term solution is to allow passing options to the hwmod framework to not reset pins from both board-*.c files and from cmdline. For this case it would be nice to pass info from the board-*.c file to hwmod so it knows to skip reset only for this GPIO. For booting Linux from other OS, something like hwmod.reset_disable=all is needed to keep the LCD on. Regrads, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/7] OMAP: Serial: Allow UART parameters to be configured from board file
* 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_MODE0,
> + },
...
AFAIK you should only need the OMAP_DEVICE_PAD_REMUX option for
omap24xx. And if you use that option, you also need the .idle
value.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap-mmc: Fix possible NULL pointer deref
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 dereference at virtual
address 0018
...
[3.841247] CPU: 0Not tainted (2.6.38-rc6 #5)
[3.846374] PC is at mmc_omap_cmd_done+0x1c/0x154
[3.851379] LR is at mmc_omap_cmd_done+0x1c/0x154
...
[4.140014] [] (mmc_omap_cmd_done+0x1c/0x154) from []
(mmc_omap_irq+0x27c/0x32c)
[4.149749] [] (mmc_omap_irq+0x27c/0x32c) from []
(handle_IRQ_event+0x24/0xe4)
[4.159332] [] (handle_IRQ_event+0x24/0xe4) from []
(handle_level_irq+0xbc/0x13c)
[4.169158] [] (handle_level_irq+0xbc/0x13c) from []
(asm_do_IRQ+0x70/0x94)
[4.178466] [] (asm_do_IRQ+0x70/0x94) from []
(__irq_svc+0x4c/0xb8)
Index: linux-omap-2.6/drivers/mmc/host/omap.c
===
--- linux-omap-2.6.orig/drivers/mmc/host/omap.c 2011-02-27 12:32:03.051061690
+0100
+++ linux-omap-2.6/drivers/mmc/host/omap.c 2011-02-27 12:32:27.622530875
+0100
@@ -832,7 +832,7 @@
return IRQ_HANDLED;
}
- if (end_command)
+ if (end_command && host->cmd)
mmc_omap_cmd_done(host, host->cmd);
if (host->data != NULL) {
if (transfer_error)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap-mmc: Fix possible NULL pointer deref
* 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? Acked-by: Tony Lindgren -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap2plus: Remove auto selection on PMICs
* 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 > > > > * Sanjeev Premi [110223 04:11]: > > > The current implementation almost assumes that only > > > TWL4030/TWL5030/TWl6030 are (or can be) used with the > > > OMAP processors. This is, however, not true. > > > > If selecting these on platforms that don't have twl > > causes problems the problem should be fixed. > > > > You can disable CONFIG_ARCH_OMAP2PLUS_TYPICAL, and > > then these don't get selected. > > [sp] But this means MUTLI_OMAP breaks. And same uImage > won't run on the AM3517 EVM. > > If I remember, the problem is caused due to twl specific > functions called even if it isn't present. And there is > implicit assumption on TWL in most of code. Then let's fix that problem instead. The TWL functions should not get called (or at least they should not do anything) unless the TWL chip is there. > [sp] I will be away from work for next week; may not > be able to try this; but don't you think dependency > on ARM is too generic? And this should still be fixed.. > > - depends on TWL4030_CORE && ARM > + depends on TWL4030_CORE && (ARCH_OMAP3 || ARCH_OMAP4) Well in theory all the drivers should just build on whatever platform. I don't know if changing that really improves things, we should improve the driver instead. Note for example how the tps65010.c driver also builds on x86. That allows people doing Linux generic changes to build test those changes: $git log --pretty=oneline drivers/mfd/tps65010.c 77b22897da093e80c40f03e8d83bf23e756b9fba mfd: Include instead of afdb32f2e463a195c104555ac9a8cdd39a2b6561 mfd: update workqueue usages fbae3fb1546e199ab0cd185348f8124411a1ca9d i2c: Remove all i2c_set_clientdata(clie f322d5f009743bfd92b47258ee997c889263 mfd: Fix dangling pointersRegards, ... So instead of breakage for the tps65010 driver we instead got the above changes compile tested as an extra bonus. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] OMAP2+: hwmod/clockevent: allow late-init of individual hwmods
> 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 base for others to base their branches on. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 10/18] omap3+: sr: call handler with interrupt disabled
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. Signed-off-by: Nishanth Menon --- arch/arm/mach-omap2/smartreflex.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c index 99e4c4f..a4e9f2d 100644 --- a/arch/arm/mach-omap2/smartreflex.c +++ b/arch/arm/mach-omap2/smartreflex.c @@ -278,7 +278,7 @@ static int sr_late_init(struct omap_sr *sr_info) goto error; } ret = request_irq(sr_info->irq, sr_interrupt, - 0, name, (void *)sr_info); + IRQF_DISABLED, name, (void *)sr_info); Isn't this flag a nop now? Indeed, it is, according to the comment in . So what does this patch really achieve? Carry over since I had implemented this driver originally on an ancient kernel and other than the showing off the obvious fact that I am not reading lwn.net enough, I dont think it achieved anything much :( The original intent was as following: since bootloaders may have used the same h/w logic which could generate pending interrupt status, I wanted to explicitly flag that requesting the irq should also ensure the IRQ is in disabled status before I get a chance to clean things up. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 10/18] omap3+: sr: call handler with interrupt disabled
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/mach-omap2/smartreflex.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c index 99e4c4f..a4e9f2d 100644 --- a/arch/arm/mach-omap2/smartreflex.c +++ b/arch/arm/mach-omap2/smartreflex.c @@ -278,7 +278,7 @@ static int sr_late_init(struct omap_sr *sr_info) goto error; } ret = request_irq(sr_info->irq, sr_interrupt, -0, name, (void *)sr_info); +IRQF_DISABLED, name, (void *)sr_info); Isn't this flag a nop now? Indeed, it is, according to the comment in . So what does this patch really achieve? WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH resend] omap: Fix linker error in drivers/video/omap/lcd_2430sdp.c
* 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 > > > to make it modular and neat. > > > > How about let's make mach-omap2 boards all use the new code? > > That way the old code can be omap1 only. > > That has been my long term plan, but I've never had time to start > working on it. Some (many?) of the old panel drivers are trivial to > port, needs just copying the panel timings. OK, that will probably make things a lot easier in the long run. > Some are much more complex, and porting them without having the hardware > may be a bit of a guesswork. But perhaps we can find testers for those > after the code has been ported. Sure, once we get one working others should be easy.. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] twl4030_codec cleanup
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 haven't tested them on any target board though. > I'm fine with the twl.h changes, but I think it would make sense for Tony to > take this patchset. Tony, is that ok with you ? Sure if you prefer that. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] OMAP36xx PM: Updated C state latencies for OMAP3630
> -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:
>
> > This patch has changes to update the C state latencies for OMAP3630
> and
> > disables the useless C-States, keeping only the optimized ones with
> their
> > corresponding measured latencies.
>
> I think "useless" vs. "optimized" here are not the right words, and
> doesn't summarize the problem being solved.
>
> If I understood Nicole and Vincent's summary it was that there is no
> significant power savings between some of the states, so they are not
> necessary.
Yes, also some of the C states were consuming more power than deeper C
state.
>
> Also, I believe Nicole & Vincent's research applies to both 34xx and
> 36xx.
I need to check. AFAIK, the experiments were done on OMAP3630 boards.
>
> > Only 4 C-states are kept instead of 7
> > C-States:
> > * C1 . MPU WFI clock gated + Core autogating
> > * C3 . MPU CSWR + Core inactive
> > * C5 . MPU CSWR + Core CSWR
> > * C7 . MPU OFF + Core OFF
> >
> > Thanks to Nicole Chaloub and Vincent Bour b...@ti.com>
> > for their investigation.
> >
> > Tested on ZOOM3 board using latest pm branch.
> >
> > Signed-off-by: Vishwanath BS
> > ---
> > arch/arm/mach-omap2/board-3630sdp.c | 19
> +++
> > arch/arm/mach-omap2/board-zoom.c| 19
> +++
>
> Why are these added as board-specific changes?
>
> If these are to be the default 3630 CPUidle states, add a default 36xx
> cpuidle_params_table along side the 34xx one and have CPUidle pick the
> right one at runtime.
Yes, I can do that.
Vishwa
>
> Kevin
>
> > 2 files changed, 38 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/board-3630sdp.c b/arch/arm/mach-
> omap2/board-3630sdp.c
> > index 6264564..8d05fc9
> > --- a/arch/arm/mach-omap2/board-3630sdp.c
> > +++ b/arch/arm/mach-omap2/board-3630sdp.c
> > @@ -25,6 +25,24 @@
> > #include "board-flash.h"
> > #include "mux.h"
> > #include "sdram-hynix-h8mbx00u0mer-0em.h"
> > +#include "pm.h"
> > +
> > +static struct cpuidle_params omap36xx_cpuidle_params_table[] = {
> > + /* C1 */
> > + {1, 74, 78, 152},
> > + /* C2 */
> > + {0, 165, 90, 255},
> > + /* C3 */
> > + {1, 163, 180, 345},
> > + /* C4 */
> > + {0, 2852, 605, 3457},
> > + /* C5 */
> > + {1, 800, 366, 2120},
> > + /* C6 */
> > + {0, 4080, 801, 4881},
> > + /* C7 */
> > + {1, 4300, 8794, 159000},
> > +};
> >
> > #if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91X_MODULE)
> >
> > @@ -212,6 +230,7 @@ static void __init omap_sdp_init(void)
> > board_flash_init(sdp_flash_partitions, chip_sel_sdp);
> > enable_board_wakeup_source();
> > usb_ehci_init(&ehci_pdata);
> > + omap3_pm_init_cpuidle(omap36xx_cpuidle_params_table);
> > }
> >
> > MACHINE_START(OMAP_3630SDP, "OMAP 3630SDP board")
> > diff --git a/arch/arm/mach-omap2/board-zoom.c b/arch/arm/mach-
> omap2/board-zoom.c
> > index e26754c..6bd364a
> > --- a/arch/arm/mach-omap2/board-zoom.c
> > +++ b/arch/arm/mach-omap2/board-zoom.c
> > @@ -30,6 +30,24 @@
> > #include "mux.h"
> > #include "sdram-micron-mt46h32m32lf-6.h"
> > #include "sdram-hynix-h8mbx00u0mer-0em.h"
> > +#include "pm.h"
> > +
> > +static struct cpuidle_params omap36xx_cpuidle_params_table[] = {
> > + /* C1 */
> > + {1, 74, 78, 152},
> > + /* C2 */
> > + {0, 165, 90, 255},
> > + /* C3 */
> > + {1, 163, 180, 345},
> > + /* C4 */
> > + {0, 2852, 605, 3457},
> > + /* C5 */
> > + {1, 800, 366, 2120},
> > + /* C6 */
> > + {0, 4080, 801, 4881},
> > + /* C7 */
> > + {1, 4300, 8794, 159000},
> > +};
> >
> > #define ZOOM3_EHCI_RESET_GPIO 64
> >
> > @@ -126,6 +144,7 @@ static void __init omap_zoom_init(void)
> > usb_ehci_init(&ehci_pdata);
> > }
> >
> > + omap3_pm_init_cpuidle(omap36xx_cpuidle_params_table);
> > board_nand_init(zoom_nand_partitions,
> > ARRAY_SIZE(zoom_nand_partitions),
> ZOOM_NAND_CS);
> > zoom_debugboard_init();
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 10/18] omap3+: sr: call handler with interrupt disabled
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 event else there is a risk of loosing events. Signed-off-by: Nishanth Menon --- arch/arm/mach-omap2/smartreflex.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c index 99e4c4f..a4e9f2d 100644 --- a/arch/arm/mach-omap2/smartreflex.c +++ b/arch/arm/mach-omap2/smartreflex.c @@ -278,7 +278,7 @@ static int sr_late_init(struct omap_sr *sr_info) goto error; } ret = request_irq(sr_info->irq, sr_interrupt, - 0, name, (void *)sr_info); + IRQF_DISABLED, name, (void *)sr_info); Isn't this flag a nop now? thanks. hmm... Documentation/feature-removal-schedule.txt says so as well.. I guess I was just being paranoid (again?). -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] OMAP3 PM: Deny clock gating only for safe state
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:
>
> > Currently clock gating for MPU and core are denied whenever C1 state
> is
> > selected.
>
> Yes, that is the definition of C1.
>
> > It should be denied only when safe state is selected.
>
> Why?
Clock gating in C1 will reduce overall power consumption and it should not
impact any functionality as well.
>
> This changes the definition and behavior of C1 depending on how it is
> entered. Not a good idea IMO.
I thought of adding a new C state, keeping C1 definition unchanged. Then
we will not get the real power benefit since in case of C1, clock gating
will be prevented. Let me know if you have some suggestion.
Vishwa
>
> Kevin
>
>
> > Signed-off-by: Vishwanath BS
> > ---
> > arch/arm/mach-omap2/cpuidle34xx.c | 20 ++--
> > 1 files changed, 10 insertions(+), 10 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-
> omap2/cpuidle34xx.c
> > index f8e35b3..1e4ec7f 100644
> > --- a/arch/arm/mach-omap2/cpuidle34xx.c
> > +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> > @@ -139,19 +139,9 @@ static int omap3_enter_idle(struct
> cpuidle_device *dev,
> > if (omap_irq_pending() || need_resched())
> > goto return_sleep_time;
> >
> > - if (cx->type == OMAP3_STATE_C1) {
> > - pwrdm_for_each_clkdm(mpu_pd, _cpuidle_deny_idle);
> > - pwrdm_for_each_clkdm(core_pd, _cpuidle_deny_idle);
> > - }
> > -
> > /* Execute ARM wfi */
> > omap_sram_idle();
> >
> > - if (cx->type == OMAP3_STATE_C1) {
> > - pwrdm_for_each_clkdm(mpu_pd, _cpuidle_allow_idle);
> > - pwrdm_for_each_clkdm(core_pd, _cpuidle_allow_idle);
> > - }
> > -
> > return_sleep_time:
> > getnstimeofday(&ts_postidle);
> > ts_idle = timespec_sub(ts_postidle, ts_preidle);
> > @@ -315,8 +305,18 @@ static int omap3_enter_idle_bm(struct
> cpuidle_device *dev,
> >
> > select_state:
> > dev->last_state = new_state;
> > +
> > + if (new_state == dev->safe_state) {
> > + pwrdm_for_each_clkdm(mpu_pd, _cpuidle_deny_idle);
> > + pwrdm_for_each_clkdm(core_pd, _cpuidle_deny_idle);
> > + }
> > ret = omap3_enter_idle(dev, new_state);
> >
> > + if (new_state == dev->safe_state) {
> > + pwrdm_for_each_clkdm(mpu_pd, _cpuidle_allow_idle);
> > + pwrdm_for_each_clkdm(core_pd, _cpuidle_allow_idle);
> > + }
> > +
> > /* Restore original PER state if it was modified */
> > if (per_next_state != per_saved_state)
> > pwrdm_set_next_pwrst(per_pd, per_saved_state);
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 15/18] omap3+: sr: disable spamming interrupts
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_interrupt(int irq, void *data) value = irqstat_to_notifier_v2(status); } - if (sr_class->notify) - sr_class->notify(sr_info->voltdm, value); + /* Attempt some resemblence of recovery! */ Resemblance? arrgh.. thanks for catching :) -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] omap3+: sr: Reuse sr_[start|stop]_vddautocomp functions
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/smartreflex.c | 41 ++--
1 files changed, 7 insertions(+), 34 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 11741d8..7e6002f 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -227,7 +227,7 @@ static void sr_start_vddautocomp(struct omap_sr *sr)
sr->autocomp_active = true;
}
-static void sr_stop_vddautocomp(struct omap_sr *sr)
+static void sr_stop_vddautocomp(struct omap_sr *sr, int is_volt_reset)
{
if (!sr->autocomp_active)
return;
@@ -239,7 +239,7 @@ static void sr_stop_vddautocomp(struct omap_sr *sr)
return;
}
- if (!sr_class->disable(sr->voltdm, 1))
+ if (!sr_class->disable(sr->voltdm, is_volt_reset))
sr->autocomp_active = false;
}
@@ -681,16 +681,7 @@ void omap_sr_enable(struct voltagedomain *voltdm)
return;
}
- if (!sr->autocomp_active)
- return;
-
- if (!sr_class || !(sr_class->enable) || !(sr_class->configure)) {
- dev_warn(&sr->pdev->dev, "%s: smartreflex class driver not"
- "registered\n", __func__);
- return;
- }
-
- sr_class->enable(voltdm);
+ sr_start_vddautocomp(sr);
}
/**
@@ -714,16 +705,7 @@ void omap_sr_disable(struct voltagedomain *voltdm)
return;
}
- if (!sr->autocomp_active)
- return;
-
- if (!sr_class || !(sr_class->disable)) {
- dev_warn(&sr->pdev->dev, "%s: smartreflex class driver not"
- "registered\n", __func__);
- return;
- }
-
- sr_class->disable(voltdm, 0);
+ sr_stop_vddautocomp(sr, 0);
}
/**
@@ -747,16 +729,7 @@ void omap_sr_disable_reset_volt(struct voltagedomain
*voltdm)
return;
}
- if (!sr->autocomp_active)
- return;
-
- if (!sr_class || !(sr_class->disable)) {
- dev_warn(&sr->pdev->dev, "%s: smartreflex class driver not"
- "registered\n", __func__);
- return;
- }
-
- sr_class->disable(voltdm, 1);
+ sr_stop_vddautocomp(sr, 1);
}
/**
@@ -809,7 +782,7 @@ static int omap_sr_autocomp_store(void *data, u64 val)
}
if (!val)
- sr_stop_vddautocomp(sr_info);
+ sr_stop_vddautocomp(sr_info, 1);
else
sr_start_vddautocomp(sr_info);
@@ -976,7 +949,7 @@ static int __devexit omap_sr_remove(struct platform_device
*pdev)
}
if (sr_info->autocomp_active)
- sr_stop_vddautocomp(sr_info);
+ sr_stop_vddautocomp(sr_info, 1);
list_del(&sr_info->node);
iounmap(sr_info->base);
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 ;) ). btw, this should not impact
class1.5 either - core sr.c sequencing has not been modified in sr1.5 :)
Depending on Kevin's views, either you or I or both of us can rebase
depending on whose ever series gets pulled in first.. (either should be
a very minimal effort).
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] omap3+: sr: Prevent multiple smartreflex class driver enable calls
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 to cause any problems at the moment with class3 driver.
---
arch/arm/mach-omap2/smartreflex.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 95ac336..d94894a 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -213,6 +213,9 @@ static void sr_set_regfields(struct omap_sr *sr)
static void sr_start_vddautocomp(struct omap_sr *sr)
{
+ if (sr->autocomp_active)
+ return;
+
if (!sr_class || !(sr_class->enable) || !(sr_class->configure)) {
dev_warn(&sr->pdev->dev,
"%s: smartreflex class driver not registered\n",
is'nt:
http://marc.info/?l=linux-omap&m=129906344711663&w=2
better since the issue with userspace access -> debugfs?
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] OMAP PM fixes for 2.6.38-rc
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 dd9c1549edef02290edced639f67b54a25abbe0e: Linux 2.6.38-rc7 (2011-03-01 13:55:12 -0800) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_2.6.38/pm-fixes Aaro Koskinen (1): arm: mach-omap2: smartreflex: fix another memory leak Shweta Gulati (1): OMAP2+: PM: SmartReflex: fix memory leaks in Smartreflex driver arch/arm/mach-omap2/smartreflex.c | 33 +++-- 1 files changed, 15 insertions(+), 18 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap:iommu-added cache flushing operation for L2 cache
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. regards Ramesh Gupta G -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap:iommu-added cache flushing operation for L2 cache
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...@nokia.com
>> Cc: t...@atomide.com; li...@arm.linux.org.uk; linux-
>> o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
>> ker...@vger.kernel.org; Ramesh Gupta; Hari Kanigeri
>> Subject: [PATCH] omap:iommu-added cache flushing operation for L2
>> cache
>>
>> From: Ramesh Gupta
>>
>> Signed-off-by: Ramesh Gupta
>> Signed-off-by: Hari Kanigeri
>> ---
>> arch/arm/plat-omap/iommu.c | 22 --
>> 1 files changed, 8 insertions(+), 14 deletions(-)
>>
>> diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
>> index e3eb038..aeb2c33 100644
>> --- a/arch/arm/plat-omap/iommu.c
>> +++ b/arch/arm/plat-omap/iommu.c
>> @@ -471,22 +471,15 @@ EXPORT_SYMBOL_GPL(foreach_iommu_device);
>> */
>> static void flush_iopgd_range(u32 *first, u32 *last)
>> {
>> - /* FIXME: L2 cache should be taken care of if it exists */
>> - do {
>> - asm("mcr p15, 0, %0, c7, c10, 1 @ flush_pgd"
>> - : : "r" (first));
>> - first += L1_CACHE_BYTES / sizeof(*first);
>> - } while (first <= last);
>> + dmac_flush_range(first, last);
>
> There is note just above this API.
Thank you for your inputs. I agree, I will send an updated patch with
proper apis.
regards
Ramesh Gupta G
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cbus-retu-wdt: Remove unused nonstandard interfaces
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).
Signed-off-by: Michael Buesch
---
Index: linux-2.6.38-rc6/drivers/cbus/retu-wdt.c
===
--- linux-2.6.38-rc6.orig/drivers/cbus/retu-wdt.c 2011-03-02
16:49:51.231863891 +0100
+++ linux-2.6.38-rc6/drivers/cbus/retu-wdt.c2011-03-02 16:53:47.189454637
+0100
@@ -52,7 +52,6 @@ static DEFINE_MUTEX(retu_wdt_mutex);
/* Current period of watchdog */
static unsigned int period_val = RETU_WDT_DEFAULT_TIMER;
-static int counter_param = RETU_WDT_MAX_TIMER;
struct retu_wdt_dev {
struct device *dev;
@@ -109,56 +108,6 @@ static void retu_wdt_ping_work(struct wo
retu_wdt_ping_enable(wdev);
}
-static ssize_t retu_wdt_period_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- /* Show current max counter */
- return sprintf(buf, "%u\n", (u16)period_val);
-}
-
-/*
- * Note: This inteface is non-standard and likely to disappear!
- * Use /dev/watchdog instead, that's the standard.
- */
-static ssize_t retu_wdt_period_store(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t count)
-{
- unsigned int new_period;
- int ret;
-
-#ifdef CONFIG_WATCHDOG_NOWAYOUT
- retu_wdt_ping_disable(retu_wdt);
-#endif
-
- if (sscanf(buf, "%u", &new_period) != 1) {
- printk(KERN_ALERT "retu_wdt_period_store: Invalid input\n");
- return -EINVAL;
- }
-
- ret = retu_modify_counter(new_period);
- if (ret < 0)
- return ret;
-
- return strnlen(buf, count);
-}
-
-static ssize_t retu_wdt_counter_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- u16 counter;
-
- /* Show current value in watchdog counter */
- counter = retu_read_reg(dev, RETU_REG_WATCHDOG);
-
- /* Only the 5 LSB are important */
- return snprintf(buf, PAGE_SIZE, "%u\n", (counter & 0x3F));
-}
-
-static DEVICE_ATTR(period, S_IRUGO | S_IWUSR, retu_wdt_period_show, \
- retu_wdt_period_store);
-static DEVICE_ATTR(counter, S_IRUGO, retu_wdt_counter_show, NULL);
-
static int retu_wdt_open(struct inode *inode, struct file *file)
{
if (test_and_set_bit(0, &retu_wdt->users))
@@ -175,9 +124,9 @@ static int retu_wdt_release(struct inode
struct retu_wdt_dev *wdev = file->private_data;
#ifndef CONFIG_WATCHDOG_NOWAYOUT
- retu_wdt_ping_enable(retu_wdt);
+ retu_wdt_ping_enable(wdev);
#endif
- clear_bit(0, &retu_wdt->users);
+ clear_bit(0, &wdev->users);
return 0;
}
@@ -232,18 +181,6 @@ static long retu_wdt_ioctl(struct file *
return 0;
}
-/* Start kicking retu watchdog until user space starts doing the kicking */
-static int __devinit retu_wdt_ping(void)
-{
-#ifdef CONFIG_WATCHDOG_NOWAYOUT
- retu_modify_counter(RETU_WDT_MAX_TIMER);
-#else
- retu_wdt_ping_enable(retu_wdt);
-#endif
-
- return 0;
-}
-
static const struct file_operations retu_wdt_fops = {
.owner = THIS_MODULE,
.write = retu_wdt_write,
@@ -252,8 +189,6 @@ static const struct file_operations retu
.release= retu_wdt_release,
};
-/**/
-
static int __init retu_wdt_probe(struct platform_device *pdev)
{
struct retu_wdt_dev *wdev;
@@ -265,18 +200,6 @@ static int __init retu_wdt_probe(struct
wdev->dev = &pdev->dev;
- ret = device_create_file(&pdev->dev, &dev_attr_period);
- if (ret) {
- dev_err(&pdev->dev, "Error creating sysfs period\n");
- goto free1;
- }
-
- ret = device_create_file(&pdev->dev, &dev_attr_counter);
- if (ret) {
- dev_err(&pdev->dev, "Error creating sysfs counter\n");
- goto free2;
- }
-
platform_set_drvdata(pdev, wdev);
retu_wdt = wdev;
wdev->retu_wdt_miscdev.parent = &pdev->dev;
@@ -286,38 +209,21 @@ static int __init retu_wdt_probe(struct
ret = misc_register(&(wdev->retu_wdt_miscdev));
if (ret)
- goto free3;
+ goto err_free_wdev;
INIT_DELAYED_WORK(&wdev->ping_work, retu_wdt_ping_work);
- /* passed as module parameter? */
- ret = retu_modify_counter(counter_param);
- if (ret == -EINVAL) {
- ret = retu_modify_counter(RETU_WDT_DEFAULT_TIMER);
- dev_dbg(&pdev->dev, "Initializing to default value\n");
- }
-
- /* Kick the watchdog for kern
[PATCH] cbus-retu-wdt: Fix bitfield access
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
===
--- linux-2.6.38-rc6.orig/drivers/cbus/retu-wdt.c 2011-03-02
16:46:24.574676092 +0100
+++ linux-2.6.38-rc6/drivers/cbus/retu-wdt.c2011-03-02 16:48:17.469807413
+0100
@@ -56,7 +56,7 @@ static int counter_param = RETU_WDT_MAX_
struct retu_wdt_dev {
struct device *dev;
- int users;
+ unsigned long users;
struct miscdevice retu_wdt_miscdev;
struct delayed_work ping_work;
};
@@ -161,7 +161,7 @@ static DEVICE_ATTR(counter, S_IRUGO, ret
static int retu_wdt_open(struct inode *inode, struct file *file)
{
- if (test_and_set_bit(1, (unsigned long *)&(retu_wdt->users)))
+ if (test_and_set_bit(0, &retu_wdt->users))
return -EBUSY;
file->private_data = (void *)retu_wdt;
@@ -177,7 +177,7 @@ static int retu_wdt_release(struct inode
#ifndef CONFIG_WATCHDOG_NOWAYOUT
retu_wdt_ping_enable(retu_wdt);
#endif
- wdev->users = 0;
+ clear_bit(0, &retu_wdt->users);
return 0;
}
@@ -264,7 +264,6 @@ static int __init retu_wdt_probe(struct
return -ENOMEM;
wdev->dev = &pdev->dev;
- wdev->users = 0;
ret = device_create_file(&pdev->dev, &dev_attr_period);
if (ret) {
--
Greetings, Michael.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cbus-retu-wdt: Make the watchdog driver fully preemptible
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 this.
Index: linux-2.6.38-rc6/drivers/cbus/retu-wdt.c
===
--- linux-2.6.38-rc6.orig/drivers/cbus/retu-wdt.c 2011-03-02
16:08:59.022211654 +0100
+++ linux-2.6.38-rc6/drivers/cbus/retu-wdt.c2011-03-02 16:29:43.215284501
+0100
@@ -58,13 +58,11 @@ struct retu_wdt_dev {
struct device *dev;
int users;
struct miscdevice retu_wdt_miscdev;
- struct timer_list ping_timer;
+ struct delayed_work ping_work;
};
static struct retu_wdt_dev *retu_wdt;
-static void retu_wdt_set_ping_timer(unsigned long enable);
-
static int _retu_modify_counter(unsigned int new)
{
if (retu_wdt)
@@ -86,6 +84,31 @@ static int retu_modify_counter(unsigned
return 0;
}
+/*
+ * Since retu watchdog cannot be disabled in hardware, we must kick it
+ * with a timer until userspace watchdog software takes over. Do this
+ * unless /dev/watchdog is open or CONFIG_WATCHDOG_NOWAYOUT is set.
+ */
+static void retu_wdt_ping_enable(struct retu_wdt_dev *wdev)
+{
+ _retu_modify_counter(RETU_WDT_MAX_TIMER);
+ schedule_delayed_work(&wdev->ping_work,
+ round_jiffies_relative(RETU_WDT_DEFAULT_TIMER *
HZ));
+}
+
+static void retu_wdt_ping_disable(struct retu_wdt_dev *wdev)
+{
+ _retu_modify_counter(RETU_WDT_MAX_TIMER);
+ cancel_delayed_work_sync(&wdev->ping_work);
+}
+
+static void retu_wdt_ping_work(struct work_struct *work)
+{
+ struct retu_wdt_dev *wdev = container_of(to_delayed_work(work),
+ struct retu_wdt_dev, ping_work);
+ retu_wdt_ping_enable(wdev);
+}
+
static ssize_t retu_wdt_period_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -105,7 +128,7 @@ static ssize_t retu_wdt_period_store(str
int ret;
#ifdef CONFIG_WATCHDOG_NOWAYOUT
- retu_wdt_set_ping_timer(0);
+ retu_wdt_ping_disable(retu_wdt);
#endif
if (sscanf(buf, "%u", &new_period) != 1) {
@@ -136,30 +159,13 @@ static DEVICE_ATTR(period, S_IRUGO | S_I
retu_wdt_period_store);
static DEVICE_ATTR(counter, S_IRUGO, retu_wdt_counter_show, NULL);
-/**/
-
-/*
- * Since retu watchdog cannot be disabled in hardware, we must kick it
- * with a timer until userspace watchdog software takes over. Do this
- * unless /dev/watchdog is open or CONFIG_WATCHDOG_NOWAYOUT is set.
- */
-static void retu_wdt_set_ping_timer(unsigned long enable)
-{
- _retu_modify_counter(RETU_WDT_MAX_TIMER);
- if (enable)
- mod_timer(&retu_wdt->ping_timer,
- jiffies + RETU_WDT_DEFAULT_TIMER * HZ);
- else
- del_timer_sync(&retu_wdt->ping_timer);
-}
-
static int retu_wdt_open(struct inode *inode, struct file *file)
{
if (test_and_set_bit(1, (unsigned long *)&(retu_wdt->users)))
return -EBUSY;
file->private_data = (void *)retu_wdt;
- retu_wdt_set_ping_timer(0);
+ retu_wdt_ping_disable(retu_wdt);
return nonseekable_open(inode, file);
}
@@ -169,7 +175,7 @@ static int retu_wdt_release(struct inode
struct retu_wdt_dev *wdev = file->private_data;
#ifndef CONFIG_WATCHDOG_NOWAYOUT
- retu_wdt_set_ping_timer(1);
+ retu_wdt_ping_enable(retu_wdt);
#endif
wdev->users = 0;
@@ -232,7 +238,7 @@ static int __devinit retu_wdt_ping(void)
#ifdef CONFIG_WATCHDOG_NOWAYOUT
retu_modify_counter(RETU_WDT_MAX_TIMER);
#else
- retu_wdt_set_ping_timer(1);
+ retu_wdt_ping_enable(retu_wdt);
#endif
return 0;
@@ -283,7 +289,7 @@ static int __init retu_wdt_probe(struct
if (ret)
goto free3;
- setup_timer(&wdev->ping_timer, retu_wdt_set_ping_timer, 1);
+ INIT_DELAYED_WORK(&wdev->ping_work, retu_wdt_ping_work);
/* passed as module parameter? */
ret = retu_modify_counter(counter_param);
@@ -326,6 +332,7 @@ static int __devexit retu_wdt_remove(str
misc_deregister(&wdev->retu_wdt_miscdev);
device_remove_file(&pdev->dev, &dev_attr_period);
device_remove_file(&pdev->dev, &dev_attr_counter);
+ cancel_delayed_work_sync(&wdev->ping_work);
kfree(wdev);
return 0;
--
Greetings, Michael.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 3/3] omap3+: sr: Reuse sr_[start|stop]_vddautocomp functions
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 ++--
1 files changed, 7 insertions(+), 34 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 11741d8..7e6002f 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -227,7 +227,7 @@ static void sr_start_vddautocomp(struct omap_sr *sr)
sr->autocomp_active = true;
}
-static void sr_stop_vddautocomp(struct omap_sr *sr)
+static void sr_stop_vddautocomp(struct omap_sr *sr, int is_volt_reset)
{
if (!sr->autocomp_active)
return;
@@ -239,7 +239,7 @@ static void sr_stop_vddautocomp(struct omap_sr *sr)
return;
}
- if (!sr_class->disable(sr->voltdm, 1))
+ if (!sr_class->disable(sr->voltdm, is_volt_reset))
sr->autocomp_active = false;
}
@@ -681,16 +681,7 @@ void omap_sr_enable(struct voltagedomain *voltdm)
return;
}
- if (!sr->autocomp_active)
- return;
-
- if (!sr_class || !(sr_class->enable) || !(sr_class->configure)) {
- dev_warn(&sr->pdev->dev, "%s: smartreflex class driver not"
- "registered\n", __func__);
- return;
- }
-
- sr_class->enable(voltdm);
+ sr_start_vddautocomp(sr);
}
/**
@@ -714,16 +705,7 @@ void omap_sr_disable(struct voltagedomain *voltdm)
return;
}
- if (!sr->autocomp_active)
- return;
-
- if (!sr_class || !(sr_class->disable)) {
- dev_warn(&sr->pdev->dev, "%s: smartreflex class driver not"
- "registered\n", __func__);
- return;
- }
-
- sr_class->disable(voltdm, 0);
+ sr_stop_vddautocomp(sr, 0);
}
/**
@@ -747,16 +729,7 @@ void omap_sr_disable_reset_volt(struct voltagedomain
*voltdm)
return;
}
- if (!sr->autocomp_active)
- return;
-
- if (!sr_class || !(sr_class->disable)) {
- dev_warn(&sr->pdev->dev, "%s: smartreflex class driver not"
- "registered\n", __func__);
- return;
- }
-
- sr_class->disable(voltdm, 1);
+ sr_stop_vddautocomp(sr, 1);
}
/**
@@ -809,7 +782,7 @@ static int omap_sr_autocomp_store(void *data, u64 val)
}
if (!val)
- sr_stop_vddautocomp(sr_info);
+ sr_stop_vddautocomp(sr_info, 1);
else
sr_start_vddautocomp(sr_info);
@@ -976,7 +949,7 @@ static int __devexit omap_sr_remove(struct platform_device
*pdev)
}
if (sr_info->autocomp_active)
- sr_stop_vddautocomp(sr_info);
+ sr_stop_vddautocomp(sr_info, 1);
list_del(&sr_info->node);
iounmap(sr_info->base);
--
1.7.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 2/3] omap3+: sr: Sync sr_stop_vddautocomp implementation with sr_start_vddautocomp
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/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index d94894a..11741d8 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -229,6 +229,9 @@ static void sr_start_vddautocomp(struct omap_sr *sr)
static void sr_stop_vddautocomp(struct omap_sr *sr)
{
+ if (!sr->autocomp_active)
+ return;
+
if (!sr_class || !(sr_class->disable)) {
dev_warn(&sr->pdev->dev,
"%s: smartreflex class driver not registered\n",
@@ -236,10 +239,8 @@ static void sr_stop_vddautocomp(struct omap_sr *sr)
return;
}
- if (sr->autocomp_active) {
- sr_class->disable(sr->voltdm, 1);
+ if (!sr_class->disable(sr->voltdm, 1))
sr->autocomp_active = false;
- }
}
/*
--
1.7.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 1/3] omap3+: sr: Prevent multiple smartreflex class driver enable calls
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 class3 driver.
---
arch/arm/mach-omap2/smartreflex.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 95ac336..d94894a 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -213,6 +213,9 @@ static void sr_set_regfields(struct omap_sr *sr)
static void sr_start_vddautocomp(struct omap_sr *sr)
{
+ if (sr->autocomp_active)
+ return;
+
if (!sr_class || !(sr_class->enable) || !(sr_class->configure)) {
dev_warn(&sr->pdev->dev,
"%s: smartreflex class driver not registered\n",
--
1.7.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 0/3] omap3+: sr: Minor fix and cleanups
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 rebase them on top of yours, you could take them with your set etc. -- Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] OMAP4: Enable Turbo and Nitro OPP for OMAP4
"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 full term 1GHz instead of 1G
>> Enable them by default in OPPTable. For 800Mhz devices where
> s/For 800Mhz/For the small minority of boards which use OMAP4430-800
> (800MHz device),
>> OPP-Nitro is not supported, OPP-Nitro should be disabled
>> from board file.
>
> even though the TI documentation terminology is Turbo, Nitro etc.., I
> suggest using frequencies to better map things historically.
I agree, IMO the Turbo & Nitro names are useless.
Kevin
>>
>> Signed-off-by: Shweta Gulati
>> ---
>> arch/arm/mach-omap2/opp4xxx_data.c | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/opp4xxx_data.c
>> b/arch/arm/mach-omap2/opp4xxx_data.c
>> index 705fe9a..48d79e5 100644
>> --- a/arch/arm/mach-omap2/opp4xxx_data.c
>> +++ b/arch/arm/mach-omap2/opp4xxx_data.c
>> @@ -31,9 +31,9 @@ static struct omap_opp_def __initdata
>> omap44xx_opp_def_list[] = {
>> /* MPU OPP2 - OPP100 */
>> OPP_INITIALIZER("mpu", true, 6, OMAP4430_VDD_MPU_OPP100_UV),
>> /* MPU OPP3 - OPP-Turbo */
>> - OPP_INITIALIZER("mpu", false, 8,
>> OMAP4430_VDD_MPU_OPPTURBO_UV),
>> + OPP_INITIALIZER("mpu", true, 8,
>> OMAP4430_VDD_MPU_OPPTURBO_UV),
>> /* MPU OPP4 - OPP-SB */
>> - OPP_INITIALIZER("mpu", false, 100800,
>> OMAP4430_VDD_MPU_OPPNITRO_UV),
>> + OPP_INITIALIZER("mpu", true, 100800,
>> OMAP4430_VDD_MPU_OPPNITRO_UV),
>> /* L3 OPP1 - OPP50 */
>> OPP_INITIALIZER("l3_main_1", true, 1,
>> OMAP4430_VDD_CORE_OPP50_UV),
>> /* L3 OPP2 - OPP100, OPP-Turbo, OPP-SB */
>> --
>> 1.7.0.4
>
> I am ok with the overall patch - with the minor suggestions above.
>
> Regards,
> Nishanth Menon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mfd: twl4030_codec: Remove unused and duplicate audio_mclk fields
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. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] twl4030_codec cleanup
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 the twl.h changes, but I think it would make sense for Tony to take this patchset. Tony, is that ok with you ? Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: manual merge of the usb tree with the omap tree
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
> da68ccec210c45eb99e461ad31b499b4e7043c41 ("usb: musb: Remove platform
> context save/restore API") from the usb tree.
>
> The latter removed the code modified by the former, so I did that.
Thanks. I'll let Felipe handle all of these omap merge issues, as I
thought the reason I was going to take these patches from him was to
prevent issues like this from happening :)
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 15/18] omap3+: sr: disable spamming interrupts
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 any s/w clearing option. If we detect scenarios where isr was called without the corresponding notification bit being set, instead of hanging up the system, we will disable interrupt after noting the event in the system log to try and keep system sanity and allow developer to debug and fix the condition. Signed-off-by: Nishanth Menon --- arch/arm/mach-omap2/smartreflex.c | 12 ++-- 1 files changed, 10 insertions(+), 2 deletions(-) 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_interrupt(int irq, void *data) value = irqstat_to_notifier_v2(status); } - if (sr_class->notify) - sr_class->notify(sr_info->voltdm, value); + /* Attempt some resemblence of recovery! */ Resemblance? WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 10/18] omap3+: sr: call handler with interrupt disabled
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. Signed-off-by: Nishanth Menon --- arch/arm/mach-omap2/smartreflex.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c index 99e4c4f..a4e9f2d 100644 --- a/arch/arm/mach-omap2/smartreflex.c +++ b/arch/arm/mach-omap2/smartreflex.c @@ -278,7 +278,7 @@ static int sr_late_init(struct omap_sr *sr_info) goto error; } ret = request_irq(sr_info->irq, sr_interrupt, - 0, name, (void *)sr_info); + IRQF_DISABLED, name, (void *)sr_info); Isn't this flag a nop now? WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH 0/2] twl4030_codec cleanup
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 the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 5/7] mfd: TWL4030: changes for TRITON Errata 27 workaround
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 regulators is running on their internal oscillator,
negative glitches may occur on VDD1, VDD2 output when voltage is
changed.
The OMAP device may reboot if the VDD1 or VDD2 go below the
core minimum operating voltage.
WORKAROUND
Set up the TWL5030 DC-DC power supplies to use the HFCLKIN instead of
the internal oscillator.
Errata 28:
VDD1/VDD2 clock system may hang during switching the clock source from
internal oscillator to external. VDD1/VDD2 output voltages may collapse
if clock stops.
WORKAROUND
If HFCLK is disabled in OFFMODE, modify the sleep/wakeup sequence and
setuptimes to make sure the switching will happen only when HFCLKIN is
stable.
Also use the TWL5030 watchdog to safeguard the first switching from
internal oscillator to HFCLKIN during the TWL5030 init.
IMPACT
power sequence is changed.
sleep/wakeup time values will be changed.
The workaround changes are called from twl4030_power_init(), since we have to
make some i2c_read calls to check the TRITON version & the i2c will not be
initialized in the early stage.
This workaround is required for TWL5030 Silicon version less than ES1.2
The power script & setup time changes are recommended by TI HW team.
http://omapedia.org/wiki/TWL4030_power_scripts
Changes taken from TRITON Errata27 workaround patch by Nishanth Menon.
Signed-off-by: Lesly A M
Cc: Nishanth Menon
Cc: David Derrick
Cc: Samuel Ortiz
---
arch/arm/mach-omap2/twl4030.c | 114 +
drivers/mfd/twl4030-power.c | 64 +++
include/linux/i2c/twl.h |1 +
3 files changed, 179 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/twl4030.c b/arch/arm/mach-omap2/twl4030.c
index ff344b3..87de049 100644
--- a/arch/arm/mach-omap2/twl4030.c
+++ b/arch/arm/mach-omap2/twl4030.c
@@ -137,9 +137,123 @@ static struct twl4030_resconfig twl4030_rconfig[] = {
{ 0, 0},
};
+/*
+ * Active to Sleep sequence, which is executed upon P1/P2/P3
+ * transition for sleep.
+ *
+ * The sleep sequence is adjusted to do the switching of VDD1/VDD2/VIO OSC from
+ * HFCLKIN to internal oscillator when the HFCLKIN is stable.
+ */
+static struct twl4030_ins __initdata sleep_on_seq_errata27[] = {
+ /*
+* Singular message to disable HCLKOUT.
+* Wait for ~488.32 uS to do the switching of VDD1/VDD2/VIO OSC from
+* HFCLKIN to internal oscillator before disabling HFCLKIN.
+*/
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_HFCLKOUT, RES_STATE_SLEEP), 20},
+ /* Broadcast message to put res(TYPE2 = 1) to sleep */
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R1,
+ RES_STATE_SLEEP), 2},
+ /* Broadcast message to put res(TYPE2 = 2) to sleep, disable HFCLKIN */
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
+ RES_STATE_SLEEP), 2},
+};
+
+static struct twl4030_script sleep_on_script_errata27 __initdata = {
+ .script = sleep_on_seq_errata27,
+ .size = ARRAY_SIZE(sleep_on_seq_errata27),
+ .flags = TWL4030_SLEEP_SCRIPT,
+};
+
+/*
+ * Sleep to Active sequence, which is executed upon P1/P2/P3
+ * transition for wakeup.
+ *
+ * The wakeup sequence is adjusted to do the VDD1/VDD2 voltage rampup
+ * only after HFCLKIN is stabilized and the HFCLKOUT is enabled.
+ */
+static struct twl4030_ins wakeup_seq_errata27[] __initdata = {
+ /*
+* Broadcast message to put res(TYPE2 = 2) to active.
+* Wait for ~10 mS (rampup time for OSC on the board)
+* after HFCLKIN is enabled
+*/
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
+ RES_STATE_ACTIVE), 55},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
+ RES_STATE_ACTIVE), 55},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
+ RES_STATE_ACTIVE), 54},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
+ RES_STATE_ACTIVE), 1},
+ /* Singular message to enable HCLKOUT after HFCLKIN is stabilized */
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_HFCLKOUT, RES_STATE_ACTIVE), 1},
+ /*
+* Broadcast message to put res(TYPE2 = 1) to active.
+* VDD1/VDD2 rampup after HFCLKIN is stable and HF
[PATCH v8 4/7] omap3: pm: TWL5030 version checking
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 +++
include/linux/i2c/twl.h | 17 -
2 files changed, 77 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index a35fa7d..5e706d7 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -229,6 +229,9 @@
/* is driver active, bound to a chip? */
static bool inuse;
+/* TWL IDCODE Register value */
+static u32 twl_idcode;
+
static unsigned int twl_id;
unsigned int twl_rev(void)
{
@@ -487,6 +490,61 @@ EXPORT_SYMBOL(twl_i2c_read_u8);
/*--*/
+/**
+ * twl_read_idcode_register - api to read the IDCODE register.
+ * @value: returns 32 bit IDCODE register value.
+ *
+ * Unlocks the IDCODE register and read the 32 bit value.
+ */
+int twl_read_idcode_register(void)
+{
+ int err;
+
+ err = twl_i2c_write_u8(TWL4030_MODULE_INTBR, TWL_EEPROM_R_UNLOCK,
+ REG_UNLOCK_TEST_REG);
+ if (err) {
+ pr_err("TWL4030 Unable to unlock IDCODE registers\n");
+ goto fail;
+ }
+
+ err = twl_i2c_read(TWL4030_MODULE_INTBR, (u8 *)(&twl_idcode),
+ REG_IDCODE_7_0, 4);
+ if (err) {
+ pr_err("TWL4030: unable to read IDCODE -%d\n", err);
+ goto fail;
+ }
+
+ err = twl_i2c_write_u8(TWL4030_MODULE_INTBR, 0x0, REG_UNLOCK_TEST_REG);
+ if (err) {
+ pr_err("TWL4030 Unable to relock IDCODE registers\n");
+ goto fail;
+ }
+fail:
+ return err;
+}
+
+/**
+ * twl_get_si_type - api to get TWL Si type.
+ *
+ * Api to get the TWL Si type from IDCODE value.
+ */
+int twl_get_si_type(void)
+{
+ return TWL_SIL_TYPE(twl_idcode);
+}
+EXPORT_SYMBOL(twl_get_si_type);
+
+/**
+ * twl_get_si_version - api to get TWL Si version.
+ *
+ * Api to get the TWL Si version from IDCODE value.
+ */
+int twl_get_si_version(void)
+{
+ return TWL_SIL_REV(twl_idcode);
+}
+EXPORT_SYMBOL(twl_get_si_version);
+
static struct device *
add_numbered_child(unsigned chip, const char *name, int num,
void *pdata, unsigned pdata_len,
@@ -1056,6 +1114,9 @@ twl_probe(struct i2c_client *client, const struct
i2c_device_id *id)
/* setup clock framework */
clocks_init(&client->dev, pdata->clock);
+ /* read TWL IDCODE Register */
+ twl_read_idcode_register();
+
/* load power event scripts */
if (twl_has_power() && pdata->power)
twl4030_power_init(pdata->power);
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index f4bd475..d3cc2ac 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -150,7 +150,12 @@
#define MMC_PU (0x1 << 3)
#define MMC_PD (0x1 << 2)
-
+#define TWL_SIL_TYPE(rev) ((rev) & 0x00FF)
+#define TWL_SIL_REV(rev) ((rev) >> 24)
+#define TWL_SIL_5030 0x09002F
+#define TWL5030_REV_1_00x00
+#define TWL5030_REV_1_10x10
+#define TWL5030_REV_1_20x30
#define TWL4030_CLASS_ID 0x4030
#define TWL6030_CLASS_ID 0x6030
@@ -180,6 +185,9 @@ int twl_i2c_read_u8(u8 mod_no, u8 *val, u8 reg);
int twl_i2c_write(u8 mod_no, u8 *value, u8 reg, unsigned num_bytes);
int twl_i2c_read(u8 mod_no, u8 *value, u8 reg, unsigned num_bytes);
+int twl_get_si_type(void);
+int twl_get_si_version(void);
+
int twl6030_interrupt_unmask(u8 bit_mask, u8 offset);
int twl6030_interrupt_mask(u8 bit_mask, u8 offset);
@@ -279,7 +287,12 @@ static inline int twl6030_mmc_card_detect(struct device
*dev, int slot)
*(Use TWL_4030_MODULE_INTBR)
*/
+#define REG_IDCODE_7_0 0x00
+#define REG_IDCODE_15_80x01
+#define REG_IDCODE_16_23 0x02
+#define REG_IDCODE_31_24 0x03
#define REG_GPPUPDCTR1 0x0F
+#define REG_UNLOCK_TEST_REG0x12
/*I2C1 and I2C4(SR) SDA/SCL pull-up control bits */
@@ -288,6 +301,8 @@ static inline int twl6030_mmc_card_detect(struct device
*dev, int slot)
#define SR_I2C_SCL_CTRL_PU BIT(4)
#define SR_I2C_SDA_CTRL_PU BIT(6)
+#define TWL_EEPROM_R_UNLOCK0x49
+
/*--*/
/*
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
