Re: [PATCH 3/5] ARM: twd: Add context save restore support
On Mon, Jan 24, 2011 at 3:11 AM, Russell King - ARM Linux
wrote:
> On Mon, Jan 24, 2011 at 11:06:09AM +, Russell King - ARM Linux wrote:
>> On Mon, Jan 24, 2011 at 02:21:17PM +0530, Santosh Shilimkar wrote:
>> > In CPU low power state, local timer looses its register context. This
>> > patch adds context save restore hooks which can be used by platforms
>> > appropriately.
>>
>> I thought the whole point of CLOCK_EVT_FEAT_C3STOP was that the generic
>> timer stuff wouldn't rely on it being kept alive?
>>
>> Hmm, it looks like we bypass the clockevents code by only setting the
>> TWD load value at initialization time, not when we switch to periodic
>> mode. We really ought to rewrite it whenever we switch back to periodic
>> mode.
>>
>> I suspect fixing that means you won't need this save/restore support.
>
> Untested, but should do what's required.
>
> diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
> index fd91566..60636f4 100644
> --- a/arch/arm/kernel/smp_twd.c
> +++ b/arch/arm/kernel/smp_twd.c
> @@ -36,6 +36,7 @@ static void twd_set_mode(enum clock_event_mode mode,
> /* timer load already set up */
> ctrl = TWD_TIMER_CONTROL_ENABLE | TWD_TIMER_CONTROL_IT_ENABLE
> | TWD_TIMER_CONTROL_PERIODIC;
> + __raw_writel(twd_timer_rate / HZ, twd_base + TWD_TIMER_LOAD);
> break;
> case CLOCK_EVT_MODE_ONESHOT:
> /* period set, and timer enabled in 'next_event' hook */
> @@ -81,7 +82,7 @@ int twd_timer_ack(void)
>
> static void __cpuinit twd_calibrate_rate(void)
> {
> - unsigned long load, count;
> + unsigned long count;
> u64 waitjiffies;
>
> /*
> @@ -116,10 +117,6 @@ static void __cpuinit twd_calibrate_rate(void)
> printk("%lu.%02luMHz.\n", twd_timer_rate / 100,
> (twd_timer_rate / 100) % 100);
> }
> -
> - load = twd_timer_rate / HZ;
> -
> - __raw_writel(load, twd_base + TWD_TIMER_LOAD);
> }
>
> /*
This doesn't work for oneshot timers if the TWD_TIMER_CONTROL register
gets reset by cpu idle between twd_set_mode and twd_set_next_event.
Shadowing ctrl in a percpu variable and rewriting it during every call
to twd_set_next_event does work, but that's not much different, and a
little less efficient, than just saving and restoring the control and
load registers in idle. It does have the advantage that platforms
don't need any extra calls.
--
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 2/3] OMAP3: PM: Fix CLK_SRC mask for IVA2 and MPU on 3430ES2PLUS
Hi Kevin,
> -Original Message-
> From: Kevin Hilman [mailto:khil...@ti.com]
> Sent: Tuesday, January 25, 2011 3:39 AM
> To: Rajendra Nayak
> Cc: linux-omap@vger.kernel.org; p...@pwsan.com
> Subject: Re: [RFC 2/3] OMAP3: PM: Fix CLK_SRC mask for IVA2 and MPU on
3430ES2PLUS
>
> Rajendra Nayak writes:
>
> > The IVA2_CLK_SRC and MPU_CLK_SRC for OMAP3430 ES2
> > and above are 3 bit fields.
> > Define new masks for them, and since they are used
> > in a couple of clock nodes, model separate clock
> > nodes for 3430ES1 and 3430ES2+.
>
> This part should probably be separated out as a fix for the -rc cycle.
The reason I clubbed this fix here was because it had a dependency on the
'reference by name' approach added by the previous patch.
Else I was looking at creating too many duplicate nodes, since the clock
nodes which get added in this patch (dpll1_fck_3430es2/dpll2_fck_3430es2)
are part of dpll_data.
Regards,
Rajendra
>
> Kevin
>
> > Also change reference to these new clock nodes
> > from clk pointers to clk name and make a call
> > to omap_init_clk_pts to init the pointers at
> > run time.
> >
> > Signed-off-by: Rajendra Nayak
> > ---
> > arch/arm/mach-omap2/clock3xxx_data.c | 39
++--
> > arch/arm/mach-omap2/cm-regbits-34xx.h |2 +
> > 2 files changed, 33 insertions(+), 8 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
> > index 9c87adb..c3a7ff5 100644
> > --- a/arch/arm/mach-omap2/clock3xxx_data.c
> > +++ b/arch/arm/mach-omap2/clock3xxx_data.c
> > @@ -53,10 +53,6 @@
> > * DPLL5 supplies other peripheral clocks (USBHOST, USIM).
> > */
> >
> > -/* Forward declarations for DPLL bypass clocks */
> > -static struct clk dpll1_fck;
> > -static struct clk dpll2_fck;
> > -
> > /* PRM CLOCKS */
> >
> > /* According to timer32k.c, this is a 32768Hz clock, not a 32000Hz
clock. */
> > @@ -275,7 +271,7 @@ static struct dpll_data dpll1_dd = {
> > .mult_div1_reg = OMAP_CM_REGADDR(MPU_MOD,
OMAP3430_CM_CLKSEL1_PLL),
> > .mult_mask = OMAP3430_MPU_DPLL_MULT_MASK,
> > .div1_mask = OMAP3430_MPU_DPLL_DIV_MASK,
> > - .clk_bypass = &dpll1_fck,
> > + .clk_bypass_name= "dpll1_fck",
> > .clk_ref= &sys_ck,
> > .freqsel_mask = OMAP3430_MPU_DPLL_FREQSEL_MASK,
> > .control_reg= OMAP_CM_REGADDR(MPU_MOD, OMAP3430_CM_CLKEN_PLL),
> > @@ -347,7 +343,7 @@ static struct dpll_data dpll2_dd = {
> > .mult_div1_reg = OMAP_CM_REGADDR(OMAP3430_IVA2_MOD,
OMAP3430_CM_CLKSEL1_PLL),
> > .mult_mask = OMAP3430_IVA2_DPLL_MULT_MASK,
> > .div1_mask = OMAP3430_IVA2_DPLL_DIV_MASK,
> > - .clk_bypass = &dpll2_fck,
> > + .clk_bypass_name= "dpll2_fck",
> > .clk_ref= &sys_ck,
> > .freqsel_mask = OMAP3430_IVA2_DPLL_FREQSEL_MASK,
> > .control_reg= OMAP_CM_REGADDR(OMAP3430_IVA2_MOD,
OMAP3430_CM_CLKEN_PLL),
> > @@ -1077,6 +1073,17 @@ static struct clk dpll1_fck = {
> > .recalc = &omap2_clksel_recalc,
> > };
> >
> > +static struct clk dpll1_fck_3430es2 = {
> > + .name = "dpll1_fck",
> > + .ops= &clkops_null,
> > + .parent = &core_ck,
> > + .init = &omap2_init_clksel_parent,
> > + .clksel_reg = OMAP_CM_REGADDR(MPU_MOD,
OMAP3430_CM_CLKSEL1_PLL),
> > + .clksel_mask= OMAP3430ES2_MPU_CLK_SRC_MASK,
> > + .clksel = div4_core_clksel,
> > + .recalc = &omap2_clksel_recalc,
> > +};
> > +
> > static struct clk mpu_ck = {
> > .name = "mpu_ck",
> > .ops= &clkops_null,
> > @@ -1133,6 +1140,17 @@ static struct clk dpll2_fck = {
> > .recalc = &omap2_clksel_recalc,
> > };
> >
> > +static struct clk dpll2_fck_3430es2 = {
> > + .name = "dpll2_fck",
> > + .ops= &clkops_null,
> > + .parent = &core_ck,
> > + .init = &omap2_init_clksel_parent,
> > + .clksel_reg = OMAP_CM_REGADDR(OMAP3430_IVA2_MOD,
OMAP3430_CM_CLKSEL1_PLL),
> > + .clksel_mask= OMAP3430ES2_IVA2_CLK_SRC_MASK,
> > + .clksel = div4_core_clksel,
> > + .recalc = &omap2_clksel_recalc,
> > +};
> > +
> > static struct clk iva2_ck = {
> > .name = "iva2_ck",
> > .ops= &clkops_omap2_dflt_wait,
> > @@ -3261,11 +3279,13 @@ static struct omap_clk omap3xxx_clks[] = {
> > CLK(NULL, "clkout2_src_ck", &clkout2_src_ck, CK_3XXX),
> > CLK(NULL, "sys_clkout2", &sys_clkout2, CK_3XXX),
> > CLK(NULL, "corex2_fck", &corex2_fck,CK_3XXX),
> > - CLK(NULL, "dpll1_fck",&dpll1_fck, CK_3XXX),
> > + CLK(NULL, "dpll1_fck",&dpll1_fck, CK_3430ES1),
> > + CLK(NULL, "dpll1_fck",&dpll1_fck_3430es2,
CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
> > CLK(NULL, "mpu_ck", &mpu_ck,CK_3XXX),
> > CLK(NULL, "arm_fck", &arm_fck, CK_3XXX),
> > CLK(
RE: [PATCH v2 0/5] Clockdomain split series
> -Original Message- > From: Paul Walmsley [mailto:p...@pwsan.com] > Sent: Tuesday, January 25, 2011 12:53 PM > To: Rajendra Nayak > Cc: linux-omap@vger.kernel.org; Benoit Cousson; Kevin Hilman > Subject: RE: [PATCH v2 0/5] Clockdomain split series > > On Tue, 25 Jan 2011, Rajendra Nayak wrote: > > > Thanks Paul. > > By the way, could you please repost these one more time with > the linux-arm-kernel mailing list cc'ed? That way I won't have to do > it, and any comments that others might have on that list can go to the > appropriate people. Sure, will do. > > > - 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: [PATCH v2 0/5] Clockdomain split series
On Tue, 25 Jan 2011, Rajendra Nayak wrote: > Thanks Paul. By the way, could you please repost these one more time with the linux-arm-kernel mailing list cc'ed? That way I won't have to do it, and any comments that others might have on that list can go to the appropriate people. - 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: [PATCH v2 0/5] Clockdomain split series
> -Original Message- > From: Paul Walmsley [mailto:p...@pwsan.com] > Sent: Tuesday, January 25, 2011 12:51 PM > To: Rajendra Nayak > Cc: linux-omap@vger.kernel.org; b-cous...@ti.com; khil...@ti.com > Subject: Re: [PATCH v2 0/5] Clockdomain split series > > Hi Rajendra, > > On Tue, 18 Jan 2011, Rajendra Nayak wrote: > > > This patch series is an effort to split the clockdomain > > framework into platform independent and platform specific parts > > as was done for the powerdomain framework. > > > > This certainlly helps remove the various cpu_is_* checks > > which exist today in the framework and makes > > the code more maintainable and readable. > > > > The series is boot tested on OMAP2430/3430/4430SDP platforms. > > Also on OMAP3430SDP, OFF mode in suspend path is validated > > using the omap3_pm_defconfig. > > > > This series is based on latest mainline kernel and > > can be found here > > git://gitorious.org/omap-pm/linux.git clockdomain-split-v2 > > Thanks. I've queued these five patches, along with your powerdomain > trivial header file removal fix, for 2.6.39. They are in the > 'pwrdm_clkdm_a_2.6.39' branch of git://git.pwsan.com/linux-2.6 - the > branch is currently based on v2.6.38-rc2. Thanks Paul. > > > - 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: [PATCH v2 0/5] Clockdomain split series
Hi Rajendra, On Tue, 18 Jan 2011, Rajendra Nayak wrote: > This patch series is an effort to split the clockdomain > framework into platform independent and platform specific parts > as was done for the powerdomain framework. > > This certainlly helps remove the various cpu_is_* checks > which exist today in the framework and makes > the code more maintainable and readable. > > The series is boot tested on OMAP2430/3430/4430SDP platforms. > Also on OMAP3430SDP, OFF mode in suspend path is validated > using the omap3_pm_defconfig. > > This series is based on latest mainline kernel and > can be found here > git://gitorious.org/omap-pm/linux.git clockdomain-split-v2 Thanks. I've queued these five patches, along with your powerdomain trivial header file removal fix, for 2.6.39. They are in the 'pwrdm_clkdm_a_2.6.39' branch of git://git.pwsan.com/linux-2.6 - the branch is currently based on v2.6.38-rc2. - 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: [PATCH] OMAP3EVM:FIX: Reset the SMSC911x Ethernet controller in board_init
On Tue, Jan 25, 2011 at 12:26, Hiremath, Vaibhav wrote:
>
>> -Original Message-
>> From: Varadarajan, Charulatha
>> Sent: Tuesday, January 25, 2011 12:20 PM
>> To: Hiremath, Vaibhav
>> Cc: linux-omap@vger.kernel.org; Hilman, Kevin; t...@atomide.com
>> Subject: Re: [PATCH] OMAP3EVM:FIX: Reset the SMSC911x Ethernet controller
>> in board_init
>>
>> <>
>>
>> Missed this one in the previous threads.
>>
>> >> > +
>> >> > eth_cs = OMAP3EVM_SMSC911X_CS;
>> >> >
>> >> > l3ck = clk_get(NULL, "l3_ck");
>> >> > @@ -136,6 +141,22 @@ static inline void __init
>> >> omap3evm_init_smsc911x(void)
>> >> > else
>> >> > rate = clk_get_rate(l3ck);
>> >> >
>> >> > + /* Configure ethernet controller reset gpio */
>> >> > + if (cpu_is_omap3430()) {
>> >>
>> >> cpu_is_omap3430() is not required, as this board init would not be
>> >> called otherwise.
>> > [Hiremath, Vaibhav] That is not quite true, why do you say this?
>>
>> The board file init means that the cpu info is already identified.
>> Do you think that omap3evm_init_smsc911x() would be called for
>> other than OMAP3430?
>>
> [Hiremath, Vaibhav] Yes, for all processors version (OMAP35x, AM/DM37x) which
> uses this EVM file.
Ok. Thanks for the clarification.
>
> Thanks,
> Vaibhav
>> >
>> >>
>> >> > + if (gpio_request(eth_rst, "SMSC911x gpio") < 0) {
>> >> > + pr_err(KERN_ERR "Failed to request GPIO7 for
>> >> smsc911x\n");
>> >> > + return;
>> >> > + }
>> >> > +
>> >> > + gpio_direction_output(eth_rst, 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
RE: [PATCH] OMAP3EVM:FIX: Reset the SMSC911x Ethernet controller in board_init
> -Original Message-
> From: Varadarajan, Charulatha
> Sent: Tuesday, January 25, 2011 12:20 PM
> To: Hiremath, Vaibhav
> Cc: linux-omap@vger.kernel.org; Hilman, Kevin; t...@atomide.com
> Subject: Re: [PATCH] OMAP3EVM:FIX: Reset the SMSC911x Ethernet controller
> in board_init
>
> <>
>
> Missed this one in the previous threads.
>
> >> > +
> >> > eth_cs = OMAP3EVM_SMSC911X_CS;
> >> >
> >> > l3ck = clk_get(NULL, "l3_ck");
> >> > @@ -136,6 +141,22 @@ static inline void __init
> >> omap3evm_init_smsc911x(void)
> >> > else
> >> > rate = clk_get_rate(l3ck);
> >> >
> >> > + /* Configure ethernet controller reset gpio */
> >> > + if (cpu_is_omap3430()) {
> >>
> >> cpu_is_omap3430() is not required, as this board init would not be
> >> called otherwise.
> > [Hiremath, Vaibhav] That is not quite true, why do you say this?
>
> The board file init means that the cpu info is already identified.
> Do you think that omap3evm_init_smsc911x() would be called for
> other than OMAP3430?
>
[Hiremath, Vaibhav] Yes, for all processors version (OMAP35x, AM/DM37x) which
uses this EVM file.
Thanks,
Vaibhav
> >
> >>
> >> > + if (gpio_request(eth_rst, "SMSC911x gpio") < 0) {
> >> > + pr_err(KERN_ERR "Failed to request GPIO7 for
> >> smsc911x\n");
> >> > + return;
> >> > + }
> >> > +
> >> > + gpio_direction_output(eth_rst, 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
Re: [PATCH] OMAP3EVM:FIX: Reset the SMSC911x Ethernet controller in board_init
<>
Missed this one in the previous threads.
>> > +
>> > eth_cs = OMAP3EVM_SMSC911X_CS;
>> >
>> > l3ck = clk_get(NULL, "l3_ck");
>> > @@ -136,6 +141,22 @@ static inline void __init
>> omap3evm_init_smsc911x(void)
>> > else
>> > rate = clk_get_rate(l3ck);
>> >
>> > + /* Configure ethernet controller reset gpio */
>> > + if (cpu_is_omap3430()) {
>>
>> cpu_is_omap3430() is not required, as this board init would not be
>> called otherwise.
> [Hiremath, Vaibhav] That is not quite true, why do you say this?
The board file init means that the cpu info is already identified.
Do you think that omap3evm_init_smsc911x() would be called for
other than OMAP3430?
>
>>
>> > + if (gpio_request(eth_rst, "SMSC911x gpio") < 0) {
>> > + pr_err(KERN_ERR "Failed to request GPIO7 for
>> smsc911x\n");
>> > + return;
>> > + }
>> > +
>> > + gpio_direction_output(eth_rst, 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
Re: [PATCH-V2] OMAP3EVM: Made backlight GPIO default state to off
On Tue, Jan 25, 2011 at 10:50, Hiremath, Vaibhav wrote:
>
>> -Original Message-
>> From: Varadarajan, Charulatha [mailto:ch...@ti.com]
>> Sent: Tuesday, January 25, 2011 10:24 AM
>> To: Hiremath, Vaibhav
>> Cc: Semwal, Sumit; linux-omap@vger.kernel.org; t...@atomide.com;
>> tomi.valkei...@nokia.com
>> Subject: Re: [PATCH-V2] OMAP3EVM: Made backlight GPIO default state to off
>>
>> On Tue, Jan 25, 2011 at 10:18, Hiremath, Vaibhav wrote:
>> >
>> >> -Original Message-
>> >> From: Semwal, Sumit
>> >>
>> >> Vaibhav,
>> >>
>> >> On Tue, Jan 25, 2011 at 12:52 AM, Vaibhav Hiremath
>> >> wrote:
>> >> > If you choose default output to DVI, the LCD backlight used to
>> >> > stay on, since panel->disable function never gets called.
>> >> >
>> >> > So, during init put backlight GPIO to off state and the driver
>> >> > code will decide which output to enable.
>> >> >
>> >> > Signed-off-by: Vaibhav Hiremath
>> >> > ---
>> >> > Changes from V1 -
>> >> > - Added check for return value
>> >> >
>> >> > arch/arm/mach-omap2/board-omap3evm.c | 15 +--
>> >> > 1 files changed, 13 insertions(+), 2 deletions(-)
>> >> >
>> >> > diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
>> >> omap2/board-omap3evm.c
>> >> > index 7119380..a888a7d 100644
>> >> > --- a/arch/arm/mach-omap2/board-omap3evm.c
>> >> > +++ b/arch/arm/mach-omap2/board-omap3evm.c
>> >> > @@ -411,6 +411,8 @@ static struct platform_device leds_gpio = {
>> >> > static int omap3evm_twl_gpio_setup(struct device *dev,
>> >> > unsigned gpio, unsigned ngpio)
>> >> > {
>> >> > + int r;
>> >> > +
>> >> > /* gpio + 0 is "mmc0_cd" (input/IRQ) */
>> >> > omap_mux_init_gpio(63, OMAP_PIN_INPUT);
>> >> > mmc[0].gpio_cd = gpio + 0;
>> >> > @@ -426,8 +428,17 @@ static int omap3evm_twl_gpio_setup(struct device
>> >> *dev,
>> >> > */
>> >> >
>> >> > /* TWL4030_GPIO_MAX + 0 == ledA, LCD Backlight control */
>> >> > - gpio_request(gpio + TWL4030_GPIO_MAX, "EN_LCD_BKL");
>> >> > - gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
>> >> > + r = gpio_request(gpio + TWL4030_GPIO_MAX, "EN_LCD_BKL");
>> >> > + if (r)
>> >> > + printk(KERN_ERR "failed to get lcd_bkl gpio\n");
>> >> So even if the gpio_request fails, this code prints an error and
>> >> continues?
>> > [Hiremath, Vaibhav] yes, that's correct and intended.
>>
>> As pointed out by Sumit, you should not continue modifying the
>> direction of a gpio whose request failed (may be some other module
>> is using this gpio)? Please mention why this is intentionally done so.
>>
> [Hiremath, Vaibhav] First of all, if you look at implementation of gpio_xxx,
> it does handle all these scenarios gracefully.
I guess you are talking about gpio_ensure_requested() used
in gpio_xxx calls. That would throw warnings if the gpio is not
requested but being used (eg., set output direction).
>
> And second point is, the request is happening for backlight gpio (which is
> not something MUST required), so even if we fail to get handle here I think
> we should not return an error, just flag the warning and continue.
If this is the case, I guess, we need do a gpio_request() at all.
Instead, we shall directly do a gpio_direction_output(). But I
would like to differ.
>
> Let me understand, why do you want to return from middle of function, for
> backlight gpio request, which means we will not call
> "platform_device_register" for leds_gpio and many other things. And also if
> you look at the twl4030-gpio.c, we do same thing -
Well, I am not saying that you should return from the function,
if gpio_request fails. I am suggesting that you should not continue
using the gpio whose request failed. One reason why gpio_request()
might fail is in case some other request has already happened for
the same gpio.
>
>
> } else if (pdata->setup) {
> int status;
>
> status = pdata->setup(&pdev->dev,
> pdata->gpio_base, TWL4030_GPIO_MAX);
> if (status)
> dev_dbg(&pdev->dev, "setup --> %d\n", status);
> }
> return ret;
>
> I hope this clarifies your doubts.
>
> Thanks,
> Vaibhav
>> >
>> > Thanks,
>> > Vaibhav
>> >> > +
>> >> > + if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2)
>> >> > + r = gpio_direction_output(gpio + TWL4030_GPIO_MAX,
>> 1);
>> >> > + else
>> >> > + r = gpio_direction_output(gpio + TWL4030_GPIO_MAX,
>> 0);
>> >> > +
>> >> > + if (r)
>> >> > + printk(KERN_ERR "failed to set direction of lcd_bkl
>> >> gpio\n");
>> >> >
>> >> > /* gpio + 7 == DVI Enable */
>> >> > gpio_request(gpio + 7, "EN_DVI");
>> >> > --
>> >> > 1.6.2.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/major
RE: [PATCH-V2] OMAP3EVM: Made backlight GPIO default state to off
> -Original Message-
> From: Varadarajan, Charulatha [mailto:ch...@ti.com]
> Sent: Tuesday, January 25, 2011 10:24 AM
> To: Hiremath, Vaibhav
> Cc: Semwal, Sumit; linux-omap@vger.kernel.org; t...@atomide.com;
> tomi.valkei...@nokia.com
> Subject: Re: [PATCH-V2] OMAP3EVM: Made backlight GPIO default state to off
>
> On Tue, Jan 25, 2011 at 10:18, Hiremath, Vaibhav wrote:
> >
> >> -Original Message-
> >> From: Semwal, Sumit
> >> Sent: Tuesday, January 25, 2011 8:05 AM
> >> To: Hiremath, Vaibhav
> >> Cc: linux-omap@vger.kernel.org; t...@atomide.com;
> tomi.valkei...@nokia.com
> >> Subject: Re: [PATCH-V2] OMAP3EVM: Made backlight GPIO default state to
> off
> >>
> >> Vaibhav,
> >>
> >> On Tue, Jan 25, 2011 at 12:52 AM, Vaibhav Hiremath
> >> wrote:
> >> > If you choose default output to DVI, the LCD backlight used to
> >> > stay on, since panel->disable function never gets called.
> >> >
> >> > So, during init put backlight GPIO to off state and the driver
> >> > code will decide which output to enable.
> >> >
> >> > Signed-off-by: Vaibhav Hiremath
> >> > ---
> >> > Changes from V1 -
> >> > - Added check for return value
> >> >
> >> > arch/arm/mach-omap2/board-omap3evm.c | 15 +--
> >> > 1 files changed, 13 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
> >> omap2/board-omap3evm.c
> >> > index 7119380..a888a7d 100644
> >> > --- a/arch/arm/mach-omap2/board-omap3evm.c
> >> > +++ b/arch/arm/mach-omap2/board-omap3evm.c
> >> > @@ -411,6 +411,8 @@ static struct platform_device leds_gpio = {
> >> > static int omap3evm_twl_gpio_setup(struct device *dev,
> >> > unsigned gpio, unsigned ngpio)
> >> > {
> >> > + int r;
> >> > +
> >> > /* gpio + 0 is "mmc0_cd" (input/IRQ) */
> >> > omap_mux_init_gpio(63, OMAP_PIN_INPUT);
> >> > mmc[0].gpio_cd = gpio + 0;
> >> > @@ -426,8 +428,17 @@ static int omap3evm_twl_gpio_setup(struct device
> >> *dev,
> >> > */
> >> >
> >> > /* TWL4030_GPIO_MAX + 0 == ledA, LCD Backlight control */
> >> > - gpio_request(gpio + TWL4030_GPIO_MAX, "EN_LCD_BKL");
> >> > - gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
> >> > + r = gpio_request(gpio + TWL4030_GPIO_MAX, "EN_LCD_BKL");
> >> > + if (r)
> >> > + printk(KERN_ERR "failed to get lcd_bkl gpio\n");
> >> So even if the gpio_request fails, this code prints an error and
> >> continues?
> > [Hiremath, Vaibhav] yes, that's correct and intended.
>
> As pointed out by Sumit, you should not continue modifying the
> direction of a gpio whose request failed (may be some other module
> is using this gpio)? Please mention why this is intentionally done so.
>
[Hiremath, Vaibhav] First of all, if you look at implementation of gpio_xxx, it
does handle all these scenarios gracefully.
And second point is, the request is happening for backlight gpio (which is not
something MUST required), so even if we fail to get handle here I think we
should not return an error, just flag the warning and continue.
Let me understand, why do you want to return from middle of function, for
backlight gpio request, which means we will not call "platform_device_register"
for leds_gpio and many other things. And also if you look at the
twl4030-gpio.c, we do same thing -
} else if (pdata->setup) {
int status;
status = pdata->setup(&pdev->dev,
pdata->gpio_base, TWL4030_GPIO_MAX);
if (status)
dev_dbg(&pdev->dev, "setup --> %d\n", status);
}
return ret;
I hope this clarifies your doubts.
Thanks,
Vaibhav
> >
> > Thanks,
> > Vaibhav
> >> > +
> >> > + if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2)
> >> > + r = gpio_direction_output(gpio + TWL4030_GPIO_MAX,
> 1);
> >> > + else
> >> > + r = gpio_direction_output(gpio + TWL4030_GPIO_MAX,
> 0);
> >> > +
> >> > + if (r)
> >> > + printk(KERN_ERR "failed to set direction of lcd_bkl
> >> gpio\n");
> >> >
> >> > /* gpio + 7 == DVI Enable */
> >> > gpio_request(gpio + 7, "EN_DVI");
> >> > --
> >> > 1.6.2.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
> >> >
> > --
> > 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-V2] OMAP3EVM: Made backlight GPIO default state to off
On Tue, Jan 25, 2011 at 10:18, Hiremath, Vaibhav wrote:
>
>> -Original Message-
>> From: Semwal, Sumit
>> Sent: Tuesday, January 25, 2011 8:05 AM
>> To: Hiremath, Vaibhav
>> Cc: linux-omap@vger.kernel.org; t...@atomide.com; tomi.valkei...@nokia.com
>> Subject: Re: [PATCH-V2] OMAP3EVM: Made backlight GPIO default state to off
>>
>> Vaibhav,
>>
>> On Tue, Jan 25, 2011 at 12:52 AM, Vaibhav Hiremath
>> wrote:
>> > If you choose default output to DVI, the LCD backlight used to
>> > stay on, since panel->disable function never gets called.
>> >
>> > So, during init put backlight GPIO to off state and the driver
>> > code will decide which output to enable.
>> >
>> > Signed-off-by: Vaibhav Hiremath
>> > ---
>> > Changes from V1 -
>> > - Added check for return value
>> >
>> > arch/arm/mach-omap2/board-omap3evm.c | 15 +--
>> > 1 files changed, 13 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
>> omap2/board-omap3evm.c
>> > index 7119380..a888a7d 100644
>> > --- a/arch/arm/mach-omap2/board-omap3evm.c
>> > +++ b/arch/arm/mach-omap2/board-omap3evm.c
>> > @@ -411,6 +411,8 @@ static struct platform_device leds_gpio = {
>> > static int omap3evm_twl_gpio_setup(struct device *dev,
>> > unsigned gpio, unsigned ngpio)
>> > {
>> > + int r;
>> > +
>> > /* gpio + 0 is "mmc0_cd" (input/IRQ) */
>> > omap_mux_init_gpio(63, OMAP_PIN_INPUT);
>> > mmc[0].gpio_cd = gpio + 0;
>> > @@ -426,8 +428,17 @@ static int omap3evm_twl_gpio_setup(struct device
>> *dev,
>> > */
>> >
>> > /* TWL4030_GPIO_MAX + 0 == ledA, LCD Backlight control */
>> > - gpio_request(gpio + TWL4030_GPIO_MAX, "EN_LCD_BKL");
>> > - gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
>> > + r = gpio_request(gpio + TWL4030_GPIO_MAX, "EN_LCD_BKL");
>> > + if (r)
>> > + printk(KERN_ERR "failed to get lcd_bkl gpio\n");
>> So even if the gpio_request fails, this code prints an error and
>> continues?
> [Hiremath, Vaibhav] yes, that's correct and intended.
As pointed out by Sumit, you should not continue modifying the
direction of a gpio whose request failed (may be some other module
is using this gpio)? Please mention why this is intentionally done so.
>
> Thanks,
> Vaibhav
>> > +
>> > + if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2)
>> > + r = gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1);
>> > + else
>> > + r = gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
>> > +
>> > + if (r)
>> > + printk(KERN_ERR "failed to set direction of lcd_bkl
>> gpio\n");
>> >
>> > /* gpio + 7 == DVI Enable */
>> > gpio_request(gpio + 7, "EN_DVI");
>> > --
>> > 1.6.2.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
>> >
> --
> 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-V2] OMAP3EVM: Made backlight GPIO default state to off
> -Original Message-
> From: Semwal, Sumit
> Sent: Tuesday, January 25, 2011 8:05 AM
> To: Hiremath, Vaibhav
> Cc: linux-omap@vger.kernel.org; t...@atomide.com; tomi.valkei...@nokia.com
> Subject: Re: [PATCH-V2] OMAP3EVM: Made backlight GPIO default state to off
>
> Vaibhav,
>
> On Tue, Jan 25, 2011 at 12:52 AM, Vaibhav Hiremath
> wrote:
> > If you choose default output to DVI, the LCD backlight used to
> > stay on, since panel->disable function never gets called.
> >
> > So, during init put backlight GPIO to off state and the driver
> > code will decide which output to enable.
> >
> > Signed-off-by: Vaibhav Hiremath
> > ---
> > Changes from V1 -
> > - Added check for return value
> >
> > arch/arm/mach-omap2/board-omap3evm.c | 15 +--
> > 1 files changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
> omap2/board-omap3evm.c
> > index 7119380..a888a7d 100644
> > --- a/arch/arm/mach-omap2/board-omap3evm.c
> > +++ b/arch/arm/mach-omap2/board-omap3evm.c
> > @@ -411,6 +411,8 @@ static struct platform_device leds_gpio = {
> > static int omap3evm_twl_gpio_setup(struct device *dev,
> > unsigned gpio, unsigned ngpio)
> > {
> > + int r;
> > +
> > /* gpio + 0 is "mmc0_cd" (input/IRQ) */
> > omap_mux_init_gpio(63, OMAP_PIN_INPUT);
> > mmc[0].gpio_cd = gpio + 0;
> > @@ -426,8 +428,17 @@ static int omap3evm_twl_gpio_setup(struct device
> *dev,
> > */
> >
> > /* TWL4030_GPIO_MAX + 0 == ledA, LCD Backlight control */
> > - gpio_request(gpio + TWL4030_GPIO_MAX, "EN_LCD_BKL");
> > - gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
> > + r = gpio_request(gpio + TWL4030_GPIO_MAX, "EN_LCD_BKL");
> > + if (r)
> > + printk(KERN_ERR "failed to get lcd_bkl gpio\n");
> So even if the gpio_request fails, this code prints an error and
> continues?
[Hiremath, Vaibhav] yes, that's correct and intended.
Thanks,
Vaibhav
> > +
> > + if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2)
> > + r = gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1);
> > + else
> > + r = gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
> > +
> > + if (r)
> > + printk(KERN_ERR "failed to set direction of lcd_bkl
> gpio\n");
> >
> > /* gpio + 7 == DVI Enable */
> > gpio_request(gpio + 7, "EN_DVI");
> > --
> > 1.6.2.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
> >
--
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: PM: DMA: Enable runtime pm
On Mon, Jan 24, 2011 at 04:26:01PM -0800, Kevin Hilman wrote: > "G, Manjunath Kondaiah" writes: > > > Kevin, > > > > On Mon, Jan 24, 2011 at 01:43:31PM -0800, Kevin Hilman wrote: > >> "G, Manjunath Kondaiah" writes: > >> > >> > From: Manjunath G Kondaiah > >> > > >> > Enable runtime pm and use pm_runtime_get_sync and pm_runtime_put > >> > for OMAP DMA driver. > >> > > >> > Since DMA driver callback will happen from interrupt context and > >> > DMA client driver will release all DMA resources from interrupt > >> > context itself, pm_runtime_put_sync() cannot be used in DMA driver. > >> > Instead, pm_runtime_put() is used which is asynchronous call and > >> > gets executed in work queue. > >> > >> It's fine that the asynchronous version of put is uses (it's actually > >> preferred.) However, the description is confusing here. You talk about > >> driver callbacks here but in the patch, your calling _put() from > >> omap_dma_free(), not from the callback. > > > > All dma client drivers are calling omap_dma_free from callback > > context. > > Maybe so, but that's not a requirement of the API. I have a DMA test > driver that doesn't do that. > > It's also legitimate (and IMO, expected) for a client driver to, for > example do a omap_dma_request() on module load and omap_free_dma() on > module unload and only use omap_start_dma() + callbacks for xfers. > It would be nice (and IMO, expected) that the channels would go idle > between xfers (using the autosuspend feature for timeouts.) I can use autosuspend feature which can handle if there is no free_dma and also if there is no callback registered by the client. > > > I can update this info in patch description if it is useful. > > > >> > >> You're also calling _get() from the request. That means, as long as the > >> DMA channel is allocated, it will be active. > >> > >> Wouldn't it be better to do the 'get' when the channel is started > > > > No. omap_dma_request will call omap_clear_dma which in turn access all > > channel > > specific registers for writing zeros. > > Of course, you always have to do get/put around any device access. > > >> and the 'put' when the callback has finished, possibly using the > > > > after omap_free_dma, none of the dma registers are accessed hence it is > > safe to > > use _put immediately after free_dma. > > Right, but my point above is: what if the user does not call free_dma? > What if the client will be using the channel again sometime in the > future, but will be idle. What I would expect is that the channel > could go idle until another xfer is initiated rather than waiting for > the channel to be freed. ok. > > > Also, dma driver is not aware of callback completion status since it will be > > executed in client driver. > > Why not? DMA driver knows when the callback returns. You are right. We can get this info from DMA interrupt handler. -Manjunath [...] -- 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] OMAP3EVM:FIX: Reset the SMSC911x Ethernet controller in board_init
> -Original Message- > From: Hilman, Kevin > Sent: Tuesday, January 25, 2011 2:52 AM > To: Hiremath, Vaibhav > Cc: linux-omap@vger.kernel.org; Varadarajan, Charulatha; t...@atomide.com > Subject: Re: [PATCH] OMAP3EVM:FIX: Reset the SMSC911x Ethernet controller > in board_init > > "Hiremath, Vaibhav" writes: > > >> > > >> > With addition of HWMOD support to GPIO, the Ethernet controller > >> > goes undetected for OMAP35xEVM. So explicitely assert the reset > signal > >> to > >> > Ethernet controller smsc911x - > >> > > >> > - GPIO7 (>=RevG version of EVM's) > >> > - GPIO64 (<=RevD version of EVM's) > >> > > >> > I have tested this patch on RevG version of EVM with ES3.1 Si. > >> > This patch is based on intial version from Charulatha V. > >> > > >> > Signed-off-by: Vaibhav Hiremath > >> > >> This didn't apply cleanly to l-o master, with or without your previous > >> patches which touch the EVM board file. > >> > > [Hiremath, Vaibhav] may be order in which you apply the patches is > different, but should have been trivial to fix, right? > > I would suggest you to use newer version. > > The order of applying doesn't matter. Applying the original patch alone > didn't apply, applying it after the other didn't apply. V2 doesn't > apply cleanly either. > > Please be sure it applies cleanly to: > > commit 5b698d68c1a9ebeae76a0e4ca4dbfdb10357143d > Author: Thomas Weber > Date: Thu Jan 20 14:12:11 2011 + > > omap: omap-mcbsp: Fix building after replacement > > Fix building omap-mcbsp after replacing ARCH_OMAP24x0 in > commit 8a9c1aa6a4caa7db1c2fca4b47168af9077e0f95. > > > If your series of EVM patches are interdependent, I suggest sending them > as a series, so it's clear that they are dependent on each other. > Also, please Cc linux-arm-kernel on OMAP patches intended for upstream. > [Hiremath, Vaibhav] My head is pointing to same commit. But I think you are right, I should have made complete series of patches. Since these patches are functionally/logically not dependent on each other so I did not make it as a series. Let me create series and send it again. > This one (network GPIO) should be separated out though, and go into > .38-rc (as well as -stable) since omap3evm is has not been bootable > since 2.6.37. > [Hiremath, Vaibhav] I agree. > >> > --- > >> > NOTE: I have not been able to test it on older version of EVM's. > >> > >> After manually applying, > >> > >> Tested-by: Kevin Hilman > >> > >> I tested on my rev D board with DHCP + nfs rootfs and it's working well. > >> > > [Hiremath, Vaibhav] Thanks a lot for validating it. > > > >> While testing though, I also noticed that the smsc driver is dumping > >> some warnings (below) while trying to get the MAC address, resulting in > >> not using the actual MAC but generating a random one. > >> > >> This isn't related to your patch, since it also happens with l-o master, > >> but was wondering if you saw the same thing? > >> > > [Hiremath, Vaibhav] Yes I did see this message, and this is coming from > > > > #ifdef CONFIG_DEBUG_SPINLOCK > > #define SMSC_ASSERT_MAC_LOCK(pdata) \ > > WARN_ON(!spin_is_locked(&pdata->mac_lock)) > > > > And the root-cause is, in __init function we are calling > smsc911x_read_mac_address->smsc911x_mac_read without holding mac_lock. > > > > I will submit the patch to net mailing list for this. > > Thanks, please Cc linux-omap as well. > [Hiremath, Vaibhav] Will do. Thanks, Vaibhav > 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 00/13] OMAP: Basic DVFS Framework
Hi, On Mon, Jan 24, 2011 at 12:00:47PM -0800, Kevin Hilman wrote: > This layer should not be used by drivers, and is OMAP specific. > > The generic interfaces to DVFS for drivers and other kernel code are > CPUfreq and the regulator framework. Ok, now it makes sense. Thanks for the info :-) -- balbi -- 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/5] ARM: gic: Add hooks for architecture specific extensions
On Mon, Jan 24, 2011 at 12:51 AM, Santosh Shilimkar wrote: > Few architectures combine the GIC with an external interrupt controller. > On such systems it may be necessary to update both the GIC registers > and the external controller's registers to control IRQ behavior. > > This can be addressed in couple of possible methods. > 1. Export common GIC routines along with 'struct irq_chip gic_chip' > and allow architectures to have custom function by override. > > 2. Provide architecture specific function pointer hooks > within GIC library and leave platforms to add the necessary > code as part of these hooks. > > First one might be non-intrusive but have few shortcomings like arch needs > to have there own custom gic library. Locks used should be common since it > caters to same IRQs etc. Maintenance point of view also it leads to > multiple file fixes. > > The second probably is cleaner and portable. It ensures that all the > common GIC infrastructure is not touched and also provides archs to > address their specific issue. This method would work for most of Tegra's needs, although we would need gic_set_type and gic_ack_irq to have arch extensions as well. However, it does not allow for irq_retrigger, which can be implemented on Tegra. -- 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] OMAP3EVM: Made backlight GPIO default state to off
Vaibhav,
On Tue, Jan 25, 2011 at 12:52 AM, Vaibhav Hiremath wrote:
> If you choose default output to DVI, the LCD backlight used to
> stay on, since panel->disable function never gets called.
>
> So, during init put backlight GPIO to off state and the driver
> code will decide which output to enable.
>
> Signed-off-by: Vaibhav Hiremath
> ---
> Changes from V1 -
> - Added check for return value
>
> arch/arm/mach-omap2/board-omap3evm.c | 15 +--
> 1 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap3evm.c
> b/arch/arm/mach-omap2/board-omap3evm.c
> index 7119380..a888a7d 100644
> --- a/arch/arm/mach-omap2/board-omap3evm.c
> +++ b/arch/arm/mach-omap2/board-omap3evm.c
> @@ -411,6 +411,8 @@ static struct platform_device leds_gpio = {
> static int omap3evm_twl_gpio_setup(struct device *dev,
> unsigned gpio, unsigned ngpio)
> {
> + int r;
> +
> /* gpio + 0 is "mmc0_cd" (input/IRQ) */
> omap_mux_init_gpio(63, OMAP_PIN_INPUT);
> mmc[0].gpio_cd = gpio + 0;
> @@ -426,8 +428,17 @@ static int omap3evm_twl_gpio_setup(struct device *dev,
> */
>
> /* TWL4030_GPIO_MAX + 0 == ledA, LCD Backlight control */
> - gpio_request(gpio + TWL4030_GPIO_MAX, "EN_LCD_BKL");
> - gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
> + r = gpio_request(gpio + TWL4030_GPIO_MAX, "EN_LCD_BKL");
> + if (r)
> + printk(KERN_ERR "failed to get lcd_bkl gpio\n");
So even if the gpio_request fails, this code prints an error and continues?
> +
> + if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2)
> + r = gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1);
> + else
> + r = gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
> +
> + if (r)
> + printk(KERN_ERR "failed to set direction of lcd_bkl gpio\n");
>
> /* gpio + 7 == DVI Enable */
> gpio_request(gpio + 7, "EN_DVI");
> --
> 1.6.2.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
>
--
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] omap2+: Fix omap_serial_early_init to work with init_early hook
The new init_early hook happens at the end of setup_arch,
which is too early for kzalloc. However, there's no need
to call omap_serial_early_init that early, so fix this
by setting it up as a core_initcall.
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 8f47609..5678c33 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -400,8 +400,6 @@ void __init omap2_init_common_infrastructure(void)
void __init omap2_init_common_devices(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1)
{
- omap_serial_early_init();
-
if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
_omap2_init_reprogram_sdrc();
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 302da74..539ec9c 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -655,7 +655,7 @@ static void serial_out_override(struct uart_port *up, int
offset, int value)
}
#endif
-void __init omap_serial_early_init(void)
+static int __init omap_serial_early_init(void)
{
int i = 0;
@@ -672,7 +672,7 @@ void __init omap_serial_early_init(void)
uart = kzalloc(sizeof(struct omap_uart_state), GFP_KERNEL);
if (WARN_ON(!uart))
- return;
+ return -ENODEV;
uart->oh = oh;
uart->num = i++;
@@ -691,7 +691,10 @@ void __init omap_serial_early_init(void)
*/
uart->oh->flags |= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET;
} while (1);
+
+ return 0;
}
+core_initcall(omap_serial_early_init);
/**
* omap_serial_init_port() - initialize single serial port
diff --git a/arch/arm/plat-omap/include/plat/serial.h
b/arch/arm/plat-omap/include/plat/serial.h
index cec5d56..a1a118d 100644
--- a/arch/arm/plat-omap/include/plat/serial.h
+++ b/arch/arm/plat-omap/include/plat/serial.h
@@ -96,7 +96,6 @@
struct omap_board_data;
-extern void __init omap_serial_early_init(void);
extern void omap_serial_init(void);
extern void omap_serial_init_port(struct omap_board_data *bdata);
extern int omap_uart_can_sleep(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
[PATCH] omap2+: Make omap_hwmod_late_init into core_initcall
Otherwise things will fail with early_init changes.
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index e66687b..8f47609 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -402,8 +402,6 @@ void __init omap2_init_common_devices(struct
omap_sdrc_params *sdrc_cs0,
{
omap_serial_early_init();
- omap_hwmod_late_init();
-
if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
_omap2_init_reprogram_sdrc();
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e282e35..eacdfd3 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1628,7 +1628,7 @@ int __init omap_hwmod_init(struct omap_hwmod **ohs)
* to struct clk pointers for each registered omap_hwmod. Also calls
* _setup() on each hwmod. Returns 0.
*/
-int omap_hwmod_late_init(void)
+static int __init omap_hwmod_late_init(void)
{
int r;
@@ -1644,6 +1644,7 @@ int omap_hwmod_late_init(void)
return 0;
}
+core_initcall(omap_hwmod_late_init);
/**
* omap_hwmod_enable - enable an omap_hwmod
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 1eee85a..fedd829 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -539,7 +539,6 @@ int omap_hwmod_init(struct omap_hwmod **ohs);
struct omap_hwmod *omap_hwmod_lookup(const char *name);
int omap_hwmod_for_each(int (*fn)(struct omap_hwmod *oh, void *data),
void *data);
-int omap_hwmod_late_init(void);
int omap_hwmod_enable(struct omap_hwmod *oh);
int _omap_hwmod_enable(struct omap_hwmod *oh);
--
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] ARM: OMAP2: use early init hook
* Russell King - ARM Linux [110124 13:51]: > On Mon, Jan 24, 2011 at 12:26:29PM -0800, Tony Lindgren wrote: > > * Tony Lindgren [110124 12:16]: > > > > > > So far tested on zoom3 only, but the following gets it booting > > > on top of your patch. > > > > Looks like there are some other patches needed too.. At least > > omap4 still fails with these. > > From what I remember, the problem I saw on OMAP4 was hwmod related as > it seemed to be using ioremap() - which with its initialization moved > before memory allocators were up and running causes an oops. To me it seems _find_mpu_rt_base should be moved to omap_hwmod_late_init as we don't want to have a static mapping for everything. AFAIK the oh->_mpu_rt_va should not be needed early. Any comments on that Paul? See also the two patches I'll post as a reply to this thread make omap_hwmod_late_init a core_initcall. The issue for omap4 still needs to be sorted out. And then we can see which omap initcalls really need to be core_initcalls. 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 v4 1/4] TI816X: Update common omap platform files
Kevin Hilman wrote on Tuesday, January 25, 2011 1:33 AM: > "Pedanekar, Hemant" writes: > >> Hi Kevin, >> >> Hilman, Kevin wrote on Saturday, January 22, 2011 4:01 AM: >> >>> Hi Hemant, >>> >>> Hemant Pedanekar writes: >>> This patch updates the common platform files with TI816X support. Also adds new files for TI816X module base addresses and irq > definitions. >>> [...] >>> diff --git a/arch/arm/plat-omap/include/plat/irqs-ti816x.h >>> b/arch/arm/plat-omap/include/plat/irqs-ti816x.h new file mode 100644 index 000..3ec5d1b >> [...] +#define TI816X_IRQ_SECPUBINT 116 +#define TI816X_IRQ_SECSECINT 117 +#define TI816X_IRQ_SECPUBSWINT118 +#define TI816X_IRQ_SECSECSWINT119 +#define TI816X_IRQ_SMRFLX0120 +#define TI816X_IRQ_SMRFLX1121 +#define TI816X_IRQ_SYS_MMU122 +#define TI816X_IRQ_MC_MMU 123 +#define TI816X_IRQ_DMM124 + + +#endif >>> >>> For new platforms, We don't need to have a list of all the IRQ numbers. >>> >>> Driver code should always be getting IRQ numbers (and base addresses >>> etc.) from struct resource/platform_data, which is populated from >>> omap_hwmod. >>> >> >> Are you suggesting to get rid of this file altogether or the IRQs which >> may never be used from kernel be removed from this file (and added later >> If needed)? >> >> Or shall I add this file only in hwmod patch which will be submitted later? > > You can get rid of the file altogether. Even the hwmod data can just > have IRQ numbers and you shouldn't need to add a header file with the > defines. > > Kevin Ok got it. Thanks. Hemant-- 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: PM: DMA: Enable runtime pm
"G, Manjunath Kondaiah" writes:
> Kevin,
>
> On Mon, Jan 24, 2011 at 01:43:31PM -0800, Kevin Hilman wrote:
>> "G, Manjunath Kondaiah" writes:
>>
>> > From: Manjunath G Kondaiah
>> >
>> > Enable runtime pm and use pm_runtime_get_sync and pm_runtime_put
>> > for OMAP DMA driver.
>> >
>> > Since DMA driver callback will happen from interrupt context and
>> > DMA client driver will release all DMA resources from interrupt
>> > context itself, pm_runtime_put_sync() cannot be used in DMA driver.
>> > Instead, pm_runtime_put() is used which is asynchronous call and
>> > gets executed in work queue.
>>
>> It's fine that the asynchronous version of put is uses (it's actually
>> preferred.) However, the description is confusing here. You talk about
>> driver callbacks here but in the patch, your calling _put() from
>> omap_dma_free(), not from the callback.
>
> All dma client drivers are calling omap_dma_free from callback
> context.
Maybe so, but that's not a requirement of the API. I have a DMA test
driver that doesn't do that.
It's also legitimate (and IMO, expected) for a client driver to, for
example do a omap_dma_request() on module load and omap_free_dma() on
module unload and only use omap_start_dma() + callbacks for xfers.
It would be nice (and IMO, expected) that the channels would go idle
between xfers (using the autosuspend feature for timeouts.)
> I can update this info in patch description if it is useful.
>
>>
>> You're also calling _get() from the request. That means, as long as the
>> DMA channel is allocated, it will be active.
>>
>> Wouldn't it be better to do the 'get' when the channel is started
>
> No. omap_dma_request will call omap_clear_dma which in turn access all channel
> specific registers for writing zeros.
Of course, you always have to do get/put around any device access.
>> and the 'put' when the callback has finished, possibly using the
>
> after omap_free_dma, none of the dma registers are accessed hence it is safe
> to
> use _put immediately after free_dma.
Right, but my point above is: what if the user does not call free_dma?
What if the client will be using the channel again sometime in the
future, but will be idle. What I would expect is that the channel
could go idle until another xfer is initiated rather than waiting for
the channel to be freed.
> Also, dma driver is not aware of callback completion status since it will be
> executed in client driver.
Why not? DMA driver knows when the callback returns.
Kevin
>> 'autosuspend' feature with a timeout so that back-to-back DMA transfers
>> will not have have additional latency between transfers?
>>
>> > Boot tested on OMAP4 blaze and all applicable tests are executed
>> > along with dma hwmod series.
>>
>> Any OMAP2 or OMAP3 testing?
>>
>> > Signed-off-by: G, Manjunath Kondaiah
>> > ---
>> > Discussion and alignment for using runtime API's in DMA can be accessed at:
>> > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg37819.html
>> > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg38355.html
>> > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg38391.html
>> > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg38400.html
>> >
>> > arch/arm/plat-omap/dma.c | 18 +-
>> > 1 files changed, 17 insertions(+), 1 deletions(-)
>> >
>> > diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
>> > index c4b2b47..48ee292 100644
>> > --- a/arch/arm/plat-omap/dma.c
>> > +++ b/arch/arm/plat-omap/dma.c
>> > @@ -35,6 +35,7 @@
>> > #include
>> > #include
>> > #include
>> > +#include
>> >
>> > #include
>> > #include
>> > @@ -58,6 +59,7 @@ enum { DMA_CHAIN_STARTED, DMA_CHAIN_NOTSTARTED };
>> > #define OMAP_FUNC_MUX_ARM_BASE(0xfffe1000 + 0xec)
>> >
>> > static struct omap_system_dma_plat_info *p;
>> > +static struct platform_device *pd;
>> > static struct omap_dma_dev_attr *d;
>> >
>> > static int enable_1510_mode;
>> > @@ -676,6 +678,7 @@ int omap_request_dma(int dev_id, const char *dev_name,
>> >unsigned long flags;
>> >struct omap_dma_lch *chan;
>> >
>> > + pm_runtime_get_sync(&pd->dev);
>> >spin_lock_irqsave(&dma_chan_lock, flags);
>> >for (ch = 0; ch < dma_chan_count; ch++) {
>> >if (free_ch == -1 && dma_chan[ch].dev_id == -1) {
>> > @@ -686,6 +689,7 @@ int omap_request_dma(int dev_id, const char *dev_name,
>> >}
>> >if (free_ch == -1) {
>> >spin_unlock_irqrestore(&dma_chan_lock, flags);
>> > + pm_runtime_put(&pd->dev);
>> >return -EBUSY;
>> >}
>> >chan = dma_chan + free_ch;
>> > @@ -779,7 +783,7 @@ void omap_free_dma(int lch)
>> >p->dma_write(0, CCR, lch);
>> >omap_clear_dma(lch);
>> >}
>> > -
>> > + pm_runtime_put(&pd->dev);
>> >spin_lock_irqsave(&dma_chan_lock, flags);
>> >dma_chan[lch].dev_id = -1;
>> >dma_chan[lch].next_lch = -1;
>> > @@ -1979,6 +1983,7 @@ static int __devinit omap_s
Re: [PATCH] OMAP2+: remove unused UART base addresses from omap_globals
On Mon, Jan 24, 2011 at 01:54:18PM -0800, Kevin Hilman wrote: > "G, Manjunath Kondaiah" writes: > > > We need additional changes for removing these macros since omap2+ till > > omap3 hwmod uart db is not using dma request lines in omap4 way. > > Feel free to send the DMA changes as an additional patch. This is > independent of my changes, so can be a separate patch. No problem. I have cleanup changes for other drivers also so I can merge these changes. -Manjunath [...] -- 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: PM: DMA: Enable runtime pm
Kevin,
On Mon, Jan 24, 2011 at 01:43:31PM -0800, Kevin Hilman wrote:
> "G, Manjunath Kondaiah" writes:
>
> > From: Manjunath G Kondaiah
> >
> > Enable runtime pm and use pm_runtime_get_sync and pm_runtime_put
> > for OMAP DMA driver.
> >
> > Since DMA driver callback will happen from interrupt context and
> > DMA client driver will release all DMA resources from interrupt
> > context itself, pm_runtime_put_sync() cannot be used in DMA driver.
> > Instead, pm_runtime_put() is used which is asynchronous call and
> > gets executed in work queue.
>
> It's fine that the asynchronous version of put is uses (it's actually
> preferred.) However, the description is confusing here. You talk about
> driver callbacks here but in the patch, your calling _put() from
> omap_dma_free(), not from the callback.
All dma client drivers are calling omap_dma_free from callback context. I can
update this info in patch description if it is useful.
>
> You're also calling _get() from the request. That means, as long as the
> DMA channel is allocated, it will be active.
>
> Wouldn't it be better to do the 'get' when the channel is started
No. omap_dma_request will call omap_clear_dma which in turn access all channel
specific registers for writing zeros.
> and the 'put' when the callback has finished, possibly using the
after omap_free_dma, none of the dma registers are accessed hence it is safe to
use _put immediately after free_dma.
Also, dma driver is not aware of callback completion status since it will be
executed in client driver.
> 'autosuspend' feature with a timeout so that back-to-back DMA transfers
> will not have have additional latency between transfers?
>
> > Boot tested on OMAP4 blaze and all applicable tests are executed
> > along with dma hwmod series.
>
> Any OMAP2 or OMAP3 testing?
>
> > Signed-off-by: G, Manjunath Kondaiah
> > ---
> > Discussion and alignment for using runtime API's in DMA can be accessed at:
> > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg37819.html
> > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg38355.html
> > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg38391.html
> > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg38400.html
> >
> > arch/arm/plat-omap/dma.c | 18 +-
> > 1 files changed, 17 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
> > index c4b2b47..48ee292 100644
> > --- a/arch/arm/plat-omap/dma.c
> > +++ b/arch/arm/plat-omap/dma.c
> > @@ -35,6 +35,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -58,6 +59,7 @@ enum { DMA_CHAIN_STARTED, DMA_CHAIN_NOTSTARTED };
> > #define OMAP_FUNC_MUX_ARM_BASE (0xfffe1000 + 0xec)
> >
> > static struct omap_system_dma_plat_info *p;
> > +static struct platform_device *pd;
> > static struct omap_dma_dev_attr *d;
> >
> > static int enable_1510_mode;
> > @@ -676,6 +678,7 @@ int omap_request_dma(int dev_id, const char *dev_name,
> > unsigned long flags;
> > struct omap_dma_lch *chan;
> >
> > + pm_runtime_get_sync(&pd->dev);
> > spin_lock_irqsave(&dma_chan_lock, flags);
> > for (ch = 0; ch < dma_chan_count; ch++) {
> > if (free_ch == -1 && dma_chan[ch].dev_id == -1) {
> > @@ -686,6 +689,7 @@ int omap_request_dma(int dev_id, const char *dev_name,
> > }
> > if (free_ch == -1) {
> > spin_unlock_irqrestore(&dma_chan_lock, flags);
> > + pm_runtime_put(&pd->dev);
> > return -EBUSY;
> > }
> > chan = dma_chan + free_ch;
> > @@ -779,7 +783,7 @@ void omap_free_dma(int lch)
> > p->dma_write(0, CCR, lch);
> > omap_clear_dma(lch);
> > }
> > -
> > + pm_runtime_put(&pd->dev);
> > spin_lock_irqsave(&dma_chan_lock, flags);
> > dma_chan[lch].dev_id = -1;
> > dma_chan[lch].next_lch = -1;
> > @@ -1979,6 +1983,7 @@ static int __devinit omap_system_dma_probe(struct
> > platform_device *pdev)
> > return -EINVAL;
> > }
> >
> > + pd = pdev;
>
> minor: platform_device pointers are more commonly named pdev
>
> > d = p->dma_attr;
> > errata = p->errata;
> >
> > @@ -2000,6 +2005,9 @@ static int __devinit omap_system_dma_probe(struct
> > platform_device *pdev)
> > }
> > }
> >
> > + pm_runtime_enable(&pd->dev);
> > + pm_runtime_get_sync(&pd->dev);
> > +
> > spin_lock_init(&dma_chan_lock);
> > for (ch = 0; ch < dma_chan_count; ch++) {
> > omap_clear_dma(ch);
> > @@ -2065,6 +2073,14 @@ static int __devinit omap_system_dma_probe(struct
> > platform_device *pdev)
> > dma_chan[1].dev_id = 1;
> > }
> > p->show_dma_caps();
> > +
> > + /*
> > +* Note: If dma channels are reserved through boot paramters,
> > +* then dma device is always enabled.
> > +*/
> > + if (!omap_dma_
Re: [PATCH v5 0/6] OMAP: McSPI: Hwmod adaptation + runtime conversion
Hi Govindraj, "Govindraj.R" writes: > Changes invloves: > > 1) Addition of hwmod data for omap2/3/4. > 2) McSPI driver hwmod adaptation with cleanup of base address >macros and using omap-device API's. > 3) Runtime Conversion of McSPI driver. I accidentally replied to the v4 series about the refresh, but this one still needs ar refresh. Specifically, this change from Gregory Clement touches some of the same code as your patch: commit 42ce7fd6319bed8ecb26d656c476365da46b29e9 Author: Gregory CLEMENT Date: Wed Dec 29 11:52:53 2010 +0100 spi/omap2_mcspi.c: Force CS to be in inactive state after off-mode transition Kevin > > Changes from v4: > --- > 1) 4430 hwmod file alignment based on Benoit's comments. >http://www.spinics.net/lists/arm-kernel/msg111215.html >4430 Hwmod file now aligned based on: >http://gitorious.org/omap-pm/linux/blobs/pm-wip/ >hwmods-omap4-full/arch/arm/mach-omap2/omap_hwmod_44xx_data.c > > Changes from v3: > --- > 1) Updated proper Author for all patches which was missed >in v2. > 2) Modified 4430 hwmod data file so that mcspi data gets >updated in proper alphabetical order. > 3) Update omap2/3 hwmod dat files with SYSS_HAS_RESET_STATUS >flag. > > Changes from v2: > --- > 1) Fixing minor comments and adding ack from Grant Likely. > https://patchwork.kernel.org/patch/371321/ > https://patchwork.kernel.org/patch/371331/ > > Changes from v1: > --- > 1) Fixing patch 5/5 comments for hwmod+runtime > Split the patch 5/5 to hwmod adaptation > and then runtime conversion > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg33387.html > > Testing Updates: > > Was tested using data transfer test module available at: > http://dev.omapzoom.org/?p=richo/device_driver_test.git;a=blob;f=mcspi/test_code/ > utils/mcspi_modules/omap_mcspi_datatest.c; > h=e42ec10c5c844abdde6a7175a268b379fbbdb655; > hb=5d9a755d50e58de861c5e8991f2f607bc49b5dc3 > This test basically involves MISO <--> MOSI lines looped and data transfer > test > done using the above test module. > System wide suspend and ret/off counts observation, ensured that no behavioral > difference with and without this patch series. > > Benoit Cousson (1): > OMAP4: hwmod data: Add McSPI > > Charulatha V (4): > OMAP2420: hwmod data: Add McSPI > OMAP2430: hwmod data: Add McSPI > OMAP3: hwmod data: Add McSPI > OMAP: devices: Modify McSPI device to adapt to hwmod framework > > Govindraj.R (1): > OMAP: runtime: McSPI driver runtime conversion > > arch/arm/mach-omap2/devices.c | 187 --- > arch/arm/mach-omap2/omap_hwmod_2420_data.c | 156 > arch/arm/mach-omap2/omap_hwmod_2430_data.c | 219 ++ > arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 280 > > arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 267 ++ > arch/arm/plat-omap/include/plat/mcspi.h| 11 + > drivers/spi/omap2_mcspi.c | 224 +++--- > 7 files changed, 1044 insertions(+), 300 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 v4 0/6] OMAP: McSPI: Hwmod adaptation + runtime conversion
"Govindraj.R" writes: [...] > Testing Updates: > > Was tested using data transfer test module available at: > http://dev.omapzoom.org/?p=richo/device_driver_test.git;a=blob;f=mcspi/test_code/ > utils/mcspi_modules/omap_mcspi_datatest.c; > h=e42ec10c5c844abdde6a7175a268b379fbbdb655; > hb=5d9a755d50e58de861c5e8991f2f607bc49b5dc3 > This test basically involves MISO <--> MOSI lines looped and data transfer > test > done using the above test module. > System wide suspend and ret/off counts observation, ensured that no behavioral > difference with and without this patch series. Can you also report what platforms this was tested on? 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 v4 0/6] OMAP: McSPI: Hwmod adaptation + runtime conversion
Hi Govindraj, "Govindraj.R" writes: > Changes invloves: > > 1) Addition of hwmod data for omap2/3/4. > 2) McSPI driver hwmod adaptation with cleanup of base address >macros and using omap-device API's. > 3) Runtime Conversion of McSPI driver. Can you refresh this against current l-o master? It doesn't currently apply. I think this is probably ready to go into omap-testing for some broader exposure & testing. Thanks, Kevin > Changes fomr v3: > --- > 1) Updated proper Author for all patches which was missed >in v2. > 2) Modified 4430 hwmod data file so that mcspi data gets >updated in proper alphabetical order. > 3) Update omap2/3 hwmod dat files with SYSS_HAS_RESET_STATUS >flag. > > Changes from v2: > --- > 1) Fixing minor comments and adding ack from Grant Likely. > https://patchwork.kernel.org/patch/371321/ > https://patchwork.kernel.org/patch/371331/ > > Changes from v1: > --- > 1) Fixing patch 5/5 comments for hwmod+runtime > Split the patch 5/5 to hwmod adaptation > and then runtime conversion > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg33387.html > > Testing Updates: > > Was tested using data transfer test module available at: > http://dev.omapzoom.org/?p=richo/device_driver_test.git;a=blob;f=mcspi/test_code/ > utils/mcspi_modules/omap_mcspi_datatest.c; > h=e42ec10c5c844abdde6a7175a268b379fbbdb655; > hb=5d9a755d50e58de861c5e8991f2f607bc49b5dc3 > This test basically involves MISO <--> MOSI lines looped and data transfer > test > done using the above test module. > System wide suspend and ret/off counts observation, ensured that no behavioral > difference with and without this patch series. > > Benoit Cousson (1): > OMAP4: hwmod data: Add McSPI > > Charulatha V (4): > OMAP2420: hwmod data: Add McSPI > OMAP2430: hwmod data: Add McSPI > OMAP3: hwmod data: Add McSPI > OMAP: devices: Modify McSPI device to adapt to hwmod framework > > Govindraj.R (1): > OMAP: runtime: McSPI driver runtime conversion > > arch/arm/mach-omap2/devices.c | 187 --- > arch/arm/mach-omap2/omap_hwmod_2420_data.c | 156 > arch/arm/mach-omap2/omap_hwmod_2430_data.c | 219 ++ > arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 280 > > arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 266 ++ > arch/arm/plat-omap/include/plat/mcspi.h| 11 + > drivers/spi/omap2_mcspi.c | 224 +++--- > 7 files changed, 1043 insertions(+), 300 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 v1 1/3]mmc: implemented runtime pm for mmc host
2011/1/20 Chris Ball : > On Wed, Jan 19, 2011 at 09:45:57AM +, Tardy, Pierre wrote: >> Chris, >> (Sorry for top posting) >> Seems we have a intel intern disagreement. >> >> Could we have maintainer opinion on this ? > > Linus W and Ohad, any input here? Thanks, What I see is orthogonal purposes altogether. Usually there is something like two clocks and two regulators or switches available in every sufficiently advanced system: - One regulator to power the card - One clock to clock the card (MCLK) - One regulator or switch to power the MMC IP block - One clock to clock the MMC IP block The MMC core regulator handling and the clock gating I implemented is about the two first things. I think this patch is about the two *other* things, if I read it right. So drivers can register PM runtime hooks to its class device and that's probably a good thing, but doesn't it conflict with the stuff we already have in place all over the core, that makes sure that mmc_power_save_host() gets called from the mmc bus. I don't know how that fits with e.g. OMAP where they already are doing this with mmc_power_save_host() so I would really like input from them on this subject. It looks like a duplication of that mechanism, just tied to the class device instead of the mmc bus. Further this patch cannot be applied as-is. It needs a clause where it will wait for the clock gating to be sync:ed *before* calling the suspend hook. Just pm_generic_runtime_suspend won't do it. *If* we have clock gating we certainly want to make sure it is gated before this happens. With the current mmc_power_save_host() we can do this in the driver itself, taking the fact that the clock may be gated into account. The other question, whether the delay hysteresis functions in runtime PM can be reused for clock gating remains unanswered, the easiest thing to do is cook up a patch. AFAICT that involves factoring out the code dealing with that from runtime.c and when looking at it that doesn't seem easy, it strictly requires a struct device to live, and setting up abstract devices inside the MMC framework for this doesn't seem like a good idea to me. Yours, Linus Walleij -- 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 2/3] OMAP3: PM: Fix CLK_SRC mask for IVA2 and MPU on 3430ES2PLUS
Rajendra Nayak writes:
> The IVA2_CLK_SRC and MPU_CLK_SRC for OMAP3430 ES2
> and above are 3 bit fields.
> Define new masks for them, and since they are used
> in a couple of clock nodes, model separate clock
> nodes for 3430ES1 and 3430ES2+.
This part should probably be separated out as a fix for the -rc cycle.
Kevin
> Also change reference to these new clock nodes
> from clk pointers to clk name and make a call
> to omap_init_clk_pts to init the pointers at
> run time.
>
> Signed-off-by: Rajendra Nayak
> ---
> arch/arm/mach-omap2/clock3xxx_data.c | 39 ++--
> arch/arm/mach-omap2/cm-regbits-34xx.h |2 +
> 2 files changed, 33 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
> b/arch/arm/mach-omap2/clock3xxx_data.c
> index 9c87adb..c3a7ff5 100644
> --- a/arch/arm/mach-omap2/clock3xxx_data.c
> +++ b/arch/arm/mach-omap2/clock3xxx_data.c
> @@ -53,10 +53,6 @@
> * DPLL5 supplies other peripheral clocks (USBHOST, USIM).
> */
>
> -/* Forward declarations for DPLL bypass clocks */
> -static struct clk dpll1_fck;
> -static struct clk dpll2_fck;
> -
> /* PRM CLOCKS */
>
> /* According to timer32k.c, this is a 32768Hz clock, not a 32000Hz clock. */
> @@ -275,7 +271,7 @@ static struct dpll_data dpll1_dd = {
> .mult_div1_reg = OMAP_CM_REGADDR(MPU_MOD, OMAP3430_CM_CLKSEL1_PLL),
> .mult_mask = OMAP3430_MPU_DPLL_MULT_MASK,
> .div1_mask = OMAP3430_MPU_DPLL_DIV_MASK,
> - .clk_bypass = &dpll1_fck,
> + .clk_bypass_name= "dpll1_fck",
> .clk_ref= &sys_ck,
> .freqsel_mask = OMAP3430_MPU_DPLL_FREQSEL_MASK,
> .control_reg= OMAP_CM_REGADDR(MPU_MOD, OMAP3430_CM_CLKEN_PLL),
> @@ -347,7 +343,7 @@ static struct dpll_data dpll2_dd = {
> .mult_div1_reg = OMAP_CM_REGADDR(OMAP3430_IVA2_MOD,
> OMAP3430_CM_CLKSEL1_PLL),
> .mult_mask = OMAP3430_IVA2_DPLL_MULT_MASK,
> .div1_mask = OMAP3430_IVA2_DPLL_DIV_MASK,
> - .clk_bypass = &dpll2_fck,
> + .clk_bypass_name= "dpll2_fck",
> .clk_ref= &sys_ck,
> .freqsel_mask = OMAP3430_IVA2_DPLL_FREQSEL_MASK,
> .control_reg= OMAP_CM_REGADDR(OMAP3430_IVA2_MOD,
> OMAP3430_CM_CLKEN_PLL),
> @@ -1077,6 +1073,17 @@ static struct clk dpll1_fck = {
> .recalc = &omap2_clksel_recalc,
> };
>
> +static struct clk dpll1_fck_3430es2 = {
> + .name = "dpll1_fck",
> + .ops= &clkops_null,
> + .parent = &core_ck,
> + .init = &omap2_init_clksel_parent,
> + .clksel_reg = OMAP_CM_REGADDR(MPU_MOD, OMAP3430_CM_CLKSEL1_PLL),
> + .clksel_mask= OMAP3430ES2_MPU_CLK_SRC_MASK,
> + .clksel = div4_core_clksel,
> + .recalc = &omap2_clksel_recalc,
> +};
> +
> static struct clk mpu_ck = {
> .name = "mpu_ck",
> .ops= &clkops_null,
> @@ -1133,6 +1140,17 @@ static struct clk dpll2_fck = {
> .recalc = &omap2_clksel_recalc,
> };
>
> +static struct clk dpll2_fck_3430es2 = {
> + .name = "dpll2_fck",
> + .ops= &clkops_null,
> + .parent = &core_ck,
> + .init = &omap2_init_clksel_parent,
> + .clksel_reg = OMAP_CM_REGADDR(OMAP3430_IVA2_MOD,
> OMAP3430_CM_CLKSEL1_PLL),
> + .clksel_mask= OMAP3430ES2_IVA2_CLK_SRC_MASK,
> + .clksel = div4_core_clksel,
> + .recalc = &omap2_clksel_recalc,
> +};
> +
> static struct clk iva2_ck = {
> .name = "iva2_ck",
> .ops= &clkops_omap2_dflt_wait,
> @@ -3261,11 +3279,13 @@ static struct omap_clk omap3xxx_clks[] = {
> CLK(NULL, "clkout2_src_ck", &clkout2_src_ck, CK_3XXX),
> CLK(NULL, "sys_clkout2", &sys_clkout2, CK_3XXX),
> CLK(NULL, "corex2_fck", &corex2_fck,CK_3XXX),
> - CLK(NULL, "dpll1_fck",&dpll1_fck, CK_3XXX),
> + CLK(NULL, "dpll1_fck",&dpll1_fck, CK_3430ES1),
> + CLK(NULL, "dpll1_fck",&dpll1_fck_3430es2, CK_3430ES2PLUS
> | CK_AM35XX | CK_36XX),
> CLK(NULL, "mpu_ck", &mpu_ck,CK_3XXX),
> CLK(NULL, "arm_fck", &arm_fck, CK_3XXX),
> CLK("etb", "emu_mpu_alwon_ck", &emu_mpu_alwon_ck, CK_3XXX),
> - CLK(NULL, "dpll2_fck",&dpll2_fck, CK_34XX | CK_36XX),
> + CLK(NULL, "dpll2_fck",&dpll2_fck, CK_3430ES1),
> + CLK(NULL, "dpll2_fck",&dpll2_fck_3430es2, CK_3430ES2PLUS
> | CK_36XX),
> CLK(NULL, "iva2_ck", &iva2_ck, CK_34XX | CK_36XX),
> CLK(NULL, "l3_ick", &l3_ick,CK_3XXX),
> CLK(NULL, "l4_ick", &l4_ick,CK_3XXX),
> @@ -3535,6 +3555,9 @@ int __init omap3xxx_clk_init(void)
> omap2_init_clk_clkdm(c->lk.clk);
> }
>
> + /* Initialise clk pointers for parent/ref/bypass clks */
Re: [PATCH v10 00/18] OMAP2,3: hwmod DSS Adaptation
Sumit Semwal writes: > v10 of the patch series corrects return-error handling from > platform_request_irq() > based on comments from Sergei Shtylyov and Russell King. > [https://patchwork.kernel.org/patch/497911/] Tony, Assuming Tomi is OK with this series, I think these are ready to go into omap-testing for some broader testing. Kevin > v9 of this patch series adds reviewed-by and acked-by from Kevin Hilman. > > v8 of the DSS hwmod patch series fixes some issues based on findings of > Kevin Hilman on beagle. > > The VENC platform driver was not getting registered due to missed device > name update for vdda_dac regulator in some board files. This was moved from > 'omap_display' device to 'omap_venc' device in patch 14/18. > > Also, similarly for DSI platform driver, the regulator name 'vdds_dsi' needs > two > instances - one for dpi, and one for dsi. > > This version corrects the above two for all board files where 'vdda_dac' and > 'vdds_dsi' regulators are defined. [patches 14/18 and 15/18] > > Post this change, boot w/ visible framebuffer and tux was successfully > validated > on beagle, 3430SDP and zoom3. > > A patch mentioned in > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42384.html > was needed to get OMAP3 to boot up on top of linux-next of 20110115. > > OMAP4 hwmod support will be posted after the acceptance of this basic change > in > the dss2 design. > > - > [original patch introduction] > > This patch series decouples the "Clocks for DSS in hwmod adaptation" changes > from this series. Another series would be posted which could be discussed > w.r.t clocks in DSS across omap2,3. > > Removing the SYSCONFIG settings from DSS driver would also be part of these > clock changes series and not covered in this series as it depends on some of > the omap_hwmod framework changes w.r.t opt clocks handling. > > Summary of the hwmod DSS design: > > DSS, DISPC, DSI, RFBI, VENC are made as platform drivers each > corresponding to the hwmod class in the hwmod database. > > Each of these platform drivers' init / deinit are handled from core.c's > omap_dss_probe() in the exact sequence as required. > > No Hardcoding of silicon data: > hwmod database abstracts the SOC data like base addr, irq numbers and are > implemented in this patch series. > > Continue to have custom bus for display panels: > "omap_display" driver continues to be a platform driver that registers the > custom > bus. It also continues to register the display panels(omap_dss_device) on the > board to the panel drivers (omap_dss_driver) > For Eg: primary lcd device would be registered with lcd panel driver. > lcd panel driver if it is on a parallel interface would use library functions > exported from dpi.o. if it is on a dsi interface would use library functions > exported from dsi platform driver(dsi.o). > > Clocks: > Handling of clocks in DSS only is one of the design approaches, that does not > change the existing implementation. If each of the DSS HW IPs had to handle > their own clocks, then corresponding clock changes can be requested in the > hwmod > database as well which is not the current design/implementation. As stated, > this would be handled in another series seperately. > For Eg: VENC would need 54MCLK which is termed as dss_opt clocks as of now > apart > for the dss main clocks. Currently VENC driver needs to be aware of this and > has to > use clk_get/put, clk_enable/disable, since VENC hwmod is not aware of 54MCLK. > > > > Current dss driver: > --- > 1. Omapdss platform driver > - initialises necessary Ips dss, dispc. > - also initialises Ips like sdi, dsi, venc, rfbi > - creates a custom bus and registers the display devices/drivers > connected on the board to the custom bus. > > 2. Suspend/resume of omapdss > - in turn sends suspend/resume calls for each of the display devices > registered to it. > > Modified change: > --- > Platform driver for each DSS HW IP in addition to the software "omap_display" > driver. > > Omapdss platform driver > - initialises necessary h/w IPs' platform drivers [dss, dispc, dsi, > venc, rfbi] > and software libraries like dpi, sdi. > - continues to have a custom bus and registers the display devices > and drivers connected on the board to the custom bus. > - continues to handle suspend/resume of the display devices registered > to the custom bus. > > DSS platform driver > - initialises DSS IP alone > - Handles the clocks related to the DSS and other DSSHW IPs like RFBI, > DSI, VENC, DISPC. Previously this was a part of "omapdss" driver in > core.c > - Continues to handle the DSS IRQs. > - No suspend/resume hooks. > > DISPC platform driver > - initialises DISPC IP alone > - Gets the required clock from DSS
Re: [PATCH] OMAP2+: remove unused UART base addresses from omap_globals
"G, Manjunath Kondaiah" writes:
> We need additional changes for removing these macros since omap2+ till
> omap3 hwmod uart db is not using dma request lines in omap4 way.
Feel free to send the DMA changes as an additional patch. This is
independent of my changes, so can be a separate patch.
Thanks,
Kevin
> diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> index b85c630..7347bbc 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> @@ -366,8 +366,8 @@ static struct omap_hwmod_irq_info uart1_mpu_irqs[] =
> {
> };
>
> static struct omap_hwmod_dma_info uart1_sdma_reqs[] = {
> - { .name = "rx", .dma_req = OMAP24XX_DMA_UART1_RX, },
> - { .name = "tx", .dma_req = OMAP24XX_DMA_UART1_TX, },
> + { .name = "rx", .dma_req = 50, },
> + { .name = "tx", .dma_req = 49, },
> };
>
> static struct omap_hwmod_ocp_if *omap2420_uart1_slaves[] = {
> @@ -403,8 +403,8 @@ static struct omap_hwmod_irq_info uart2_mpu_irqs[] =
> {
> };
>
> static struct omap_hwmod_dma_info uart2_sdma_reqs[] = {
> - { .name = "rx", .dma_req = OMAP24XX_DMA_UART2_RX, },
> - { .name = "tx", .dma_req = OMAP24XX_DMA_UART2_TX, },
> + { .name = "rx", .dma_req = 52, },
> + { .name = "tx", .dma_req = 51, },
> };
>
> static struct omap_hwmod_ocp_if *omap2420_uart2_slaves[] = {
> @@ -440,8 +440,8 @@ static struct omap_hwmod_irq_info uart3_mpu_irqs[] =
> {
> };
>
> static struct omap_hwmod_dma_info uart3_sdma_reqs[] = {
> - { .name = "rx", .dma_req = OMAP24XX_DMA_UART3_RX, },
> - { .name = "tx", .dma_req = OMAP24XX_DMA_UART3_TX, },
> + { .name = "rx", .dma_req = 54, },
> + { .name = "tx", .dma_req = 53, },
> };
>
> static struct omap_hwmod_ocp_if *omap2420_uart3_slaves[] = {
> diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> index 8ecfbcd..1d8c391 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> @@ -365,8 +365,8 @@ static struct omap_hwmod_irq_info uart1_mpu_irqs[] =
> {
> };
>
> static struct omap_hwmod_dma_info uart1_sdma_reqs[] = {
> - { .name = "rx", .dma_req = OMAP24XX_DMA_UART1_RX, },
> - { .name = "tx", .dma_req = OMAP24XX_DMA_UART1_TX, },
> + { .name = "rx", .dma_req = 50, },
> + { .name = "tx", .dma_req = 49, },
> };
>
> static struct omap_hwmod_ocp_if *omap2430_uart1_slaves[] = {
> @@ -402,8 +402,8 @@ static struct omap_hwmod_irq_info uart2_mpu_irqs[] =
> {
> };
>
> static struct omap_hwmod_dma_info uart2_sdma_reqs[] = {
> - { .name = "rx", .dma_req = OMAP24XX_DMA_UART2_RX, },
> - { .name = "tx", .dma_req = OMAP24XX_DMA_UART2_TX, },
> + { .name = "rx", .dma_req = 52, },
> + { .name = "tx", .dma_req = 51, },
> };
>
> static struct omap_hwmod_ocp_if *omap2430_uart2_slaves[] = {
> @@ -439,8 +439,8 @@ static struct omap_hwmod_irq_info uart3_mpu_irqs[] =
> {
> };
>
> static struct omap_hwmod_dma_info uart3_sdma_reqs[] = {
> - { .name = "rx", .dma_req = OMAP24XX_DMA_UART3_RX, },
> - { .name = "tx", .dma_req = OMAP24XX_DMA_UART3_TX, },
> + { .name = "rx", .dma_req = 54, },
> + { .name = "tx", .dma_req = 53, },
> };
>
> static struct omap_hwmod_ocp_if *omap2430_uart3_slaves[] = {
> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> index 8d81813..1595cc0 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> @@ -518,8 +518,8 @@ static struct omap_hwmod_irq_info uart1_mpu_irqs[] =
> {
> };
>
> static struct omap_hwmod_dma_info uart1_sdma_reqs[] = {
> - { .name = "tx", .dma_req = OMAP24XX_DMA_UART1_TX, },
> - { .name = "rx", .dma_req = OMAP24XX_DMA_UART1_RX, },
> + { .name = "tx", .dma_req = 49, },
> + { .name = "rx", .dma_req = 50, },
> };
>
> static struct omap_hwmod_ocp_if *omap3xxx_uart1_slaves[] = {
> @@ -555,8 +555,8 @@ static struct omap_hwmod_irq_info uart2_mpu_irqs[] =
> {
> };
>
> static struct omap_hwmod_dma_info uart2_sdma_reqs[] = {
> - { .name = "tx", .dma_req = OMAP24XX_DMA_UART2_TX, },
> - { .name = "rx", .dma_req = OMAP24XX_DMA_UART2_RX, },
> + { .name = "tx", .dma_req = 51, },
> + { .name = "rx", .dma_req = 52, },
> };
>
> static struct omap_hwmod_ocp_if *omap3xxx_uart2_slaves[] = {
> @@ -592,8 +592,8 @@ static struct omap_hwmod_irq_info uart3_mpu_irqs[] =
> {
> };
>
> static struct omap_hwmod_dma_info uart3_sdma_reqs[] = {
> - { .name = "tx", .dma_req = OMAP24XX_DMA_UART3_TX, },
> - { .name = "rx", .dma_req = OMAP24XX_DMA_UART3_RX, },
> + { .name = "tx", .dma_req = 53, },
> + { .name = "rx", .dma_req = 54, },
> };
>
> static struct omap_hwmod_ocp_if *omap3xxx_uart3_slaves[] = {
> @@ -629,8 +629,8 @@ static struct omap_hwmod_irq_info uart4_mpu_irqs[] =
> {
> };
>
> static struct omap_hwmod
Re: [PATCH] ARM: OMAP2: use early init hook
On Mon, Jan 24, 2011 at 12:26:29PM -0800, Tony Lindgren wrote: > * Tony Lindgren [110124 12:16]: > > > > So far tested on zoom3 only, but the following gets it booting > > on top of your patch. > > Looks like there are some other patches needed too.. At least > omap4 still fails with these. >From what I remember, the problem I saw on OMAP4 was hwmod related as it seemed to be using ioremap() - which with its initialization moved before memory allocators were up and running causes an oops. -- 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: [PATCHv3] OMAP: Enable Magic SysRq on serial console ttyOx
Govindraj writes: > On Fri, Jan 21, 2011 at 3:31 PM, Thomas Weber wrote: >> Magic SysRq key is not working for OMAP on new serial >> console ttyOx because SUPPORT_SYSRQ is not defined >> for omap-serial. >> >> This patch defines SUPPORT_SYSRQ in omap-serial and >> enables handling of Magic SysRq character. >> >> Further there is an issue of losing first break character. >> Removing the reset of the lsr_break_flag fixes this issue. >> >> Signed-off-by: Thomas Weber > > > Acked-by: Govindraj.R > Tested-by: Manjunath G Kondaiah > Acked-by: Kevin Hilman Greg, this one should go for .38-rc. Feel free to merge, or we can take it through the OMAP tree with your ack. 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] OMAP: PM: DMA: Enable runtime pm
"G, Manjunath Kondaiah" writes:
> From: Manjunath G Kondaiah
>
> Enable runtime pm and use pm_runtime_get_sync and pm_runtime_put
> for OMAP DMA driver.
>
> Since DMA driver callback will happen from interrupt context and
> DMA client driver will release all DMA resources from interrupt
> context itself, pm_runtime_put_sync() cannot be used in DMA driver.
> Instead, pm_runtime_put() is used which is asynchronous call and
> gets executed in work queue.
It's fine that the asynchronous version of put is uses (it's actually
preferred.) However, the description is confusing here. You talk about
driver callbacks here but in the patch, your calling _put() from
omap_dma_free(), not from the callback.
You're also calling _get() from the request. That means, as long as the
DMA channel is allocated, it will be active.
Wouldn't it be better to do the 'get' when the channel is started and
the 'put' when the callback has finished, possibly using the
'autosuspend' feature with a timeout so that back-to-back DMA transfers
will not have have additional latency between transfers?
> Boot tested on OMAP4 blaze and all applicable tests are executed
> along with dma hwmod series.
Any OMAP2 or OMAP3 testing?
> Signed-off-by: G, Manjunath Kondaiah
> ---
> Discussion and alignment for using runtime API's in DMA can be accessed at:
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg37819.html
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg38355.html
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg38391.html
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg38400.html
>
> arch/arm/plat-omap/dma.c | 18 +-
> 1 files changed, 17 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
> index c4b2b47..48ee292 100644
> --- a/arch/arm/plat-omap/dma.c
> +++ b/arch/arm/plat-omap/dma.c
> @@ -35,6 +35,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -58,6 +59,7 @@ enum { DMA_CHAIN_STARTED, DMA_CHAIN_NOTSTARTED };
> #define OMAP_FUNC_MUX_ARM_BASE (0xfffe1000 + 0xec)
>
> static struct omap_system_dma_plat_info *p;
> +static struct platform_device *pd;
> static struct omap_dma_dev_attr *d;
>
> static int enable_1510_mode;
> @@ -676,6 +678,7 @@ int omap_request_dma(int dev_id, const char *dev_name,
> unsigned long flags;
> struct omap_dma_lch *chan;
>
> + pm_runtime_get_sync(&pd->dev);
> spin_lock_irqsave(&dma_chan_lock, flags);
> for (ch = 0; ch < dma_chan_count; ch++) {
> if (free_ch == -1 && dma_chan[ch].dev_id == -1) {
> @@ -686,6 +689,7 @@ int omap_request_dma(int dev_id, const char *dev_name,
> }
> if (free_ch == -1) {
> spin_unlock_irqrestore(&dma_chan_lock, flags);
> + pm_runtime_put(&pd->dev);
> return -EBUSY;
> }
> chan = dma_chan + free_ch;
> @@ -779,7 +783,7 @@ void omap_free_dma(int lch)
> p->dma_write(0, CCR, lch);
> omap_clear_dma(lch);
> }
> -
> + pm_runtime_put(&pd->dev);
> spin_lock_irqsave(&dma_chan_lock, flags);
> dma_chan[lch].dev_id = -1;
> dma_chan[lch].next_lch = -1;
> @@ -1979,6 +1983,7 @@ static int __devinit omap_system_dma_probe(struct
> platform_device *pdev)
> return -EINVAL;
> }
>
> + pd = pdev;
minor: platform_device pointers are more commonly named pdev
> d = p->dma_attr;
> errata = p->errata;
>
> @@ -2000,6 +2005,9 @@ static int __devinit omap_system_dma_probe(struct
> platform_device *pdev)
> }
> }
>
> + pm_runtime_enable(&pd->dev);
> + pm_runtime_get_sync(&pd->dev);
> +
> spin_lock_init(&dma_chan_lock);
> for (ch = 0; ch < dma_chan_count; ch++) {
> omap_clear_dma(ch);
> @@ -2065,6 +2073,14 @@ static int __devinit omap_system_dma_probe(struct
> platform_device *pdev)
> dma_chan[1].dev_id = 1;
> }
> p->show_dma_caps();
> +
> + /*
> + * Note: If dma channels are reserved through boot paramters,
> + * then dma device is always enabled.
> + */
> + if (!omap_dma_reserve_channels)
> + pm_runtime_put(&pd->dev);
> +
Readability would be improved if there was an unconditional
pm_runtime_put() at the end of this function preceeded by an extra
pm_runtime_get() (async version) if reserve_channels has been used.
Kevin
> return 0;
>
> exit_dma_irq_fail:
--
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 4/4] arch/arm/mach-omap2/smartreflex.c: Add missing IS_ERR test
Julia Lawall writes:
> Function _sr_lookup, defined in the same file, returns ERR_PTR not NULL in
> an error case.
Thanks, will queue this via the OMAP tree for 2.6.38-rc.
Kevin
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> //
> @r@
> identifier f;
> @@
> f(...) { ... return ERR_PTR(...); }
>
> @@
> identifier r.f, fld;
> expression x;
> statement S1,S2;
> @@
> x = f(...)
> ... when != IS_ERR(x)
> (
> if (IS_ERR(x) ||...) S1 else S2
> |
> *x->fld
> )
> //
>
> Signed-off-by: Julia Lawall
>
> ---
> arch/arm/mach-omap2/smartreflex.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/smartreflex.c
> b/arch/arm/mach-omap2/smartreflex.c
> index 77ecebf..d7deadf 100644
> --- a/arch/arm/mach-omap2/smartreflex.c
> +++ b/arch/arm/mach-omap2/smartreflex.c
> @@ -966,7 +966,7 @@ static int __devexit omap_sr_remove(struct
> platform_device *pdev)
> }
>
> sr_info = _sr_lookup(pdata->voltdm);
> - if (!sr_info) {
> + if (IS_ERR(sr_info)) {
> dev_warn(&pdev->dev, "%s: omap_sr struct not found\n",
> __func__);
> return -EINVAL;
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
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] OMAP3EVM:FIX: Reset the SMSC911x Ethernet controller in board_init
"Hiremath, Vaibhav" writes: >> > >> > With addition of HWMOD support to GPIO, the Ethernet controller >> > goes undetected for OMAP35xEVM. So explicitely assert the reset signal >> to >> > Ethernet controller smsc911x - >> > >> >- GPIO7 (>=RevG version of EVM's) >> >- GPIO64 (<=RevD version of EVM's) >> > >> > I have tested this patch on RevG version of EVM with ES3.1 Si. >> > This patch is based on intial version from Charulatha V. >> > >> > Signed-off-by: Vaibhav Hiremath >> >> This didn't apply cleanly to l-o master, with or without your previous >> patches which touch the EVM board file. >> > [Hiremath, Vaibhav] may be order in which you apply the patches is different, > but should have been trivial to fix, right? > I would suggest you to use newer version. The order of applying doesn't matter. Applying the original patch alone didn't apply, applying it after the other didn't apply. V2 doesn't apply cleanly either. Please be sure it applies cleanly to: commit 5b698d68c1a9ebeae76a0e4ca4dbfdb10357143d Author: Thomas Weber Date: Thu Jan 20 14:12:11 2011 + omap: omap-mcbsp: Fix building after replacement Fix building omap-mcbsp after replacing ARCH_OMAP24x0 in commit 8a9c1aa6a4caa7db1c2fca4b47168af9077e0f95. If your series of EVM patches are interdependent, I suggest sending them as a series, so it's clear that they are dependent on each other. Also, please Cc linux-arm-kernel on OMAP patches intended for upstream. This one (network GPIO) should be separated out though, and go into .38-rc (as well as -stable) since omap3evm is has not been bootable since 2.6.37. >> > --- >> > NOTE: I have not been able to test it on older version of EVM's. >> >> After manually applying, >> >> Tested-by: Kevin Hilman >> >> I tested on my rev D board with DHCP + nfs rootfs and it's working well. >> > [Hiremath, Vaibhav] Thanks a lot for validating it. > >> While testing though, I also noticed that the smsc driver is dumping >> some warnings (below) while trying to get the MAC address, resulting in >> not using the actual MAC but generating a random one. >> >> This isn't related to your patch, since it also happens with l-o master, >> but was wondering if you saw the same thing? >> > [Hiremath, Vaibhav] Yes I did see this message, and this is coming from > > #ifdef CONFIG_DEBUG_SPINLOCK > #define SMSC_ASSERT_MAC_LOCK(pdata) \ > WARN_ON(!spin_is_locked(&pdata->mac_lock)) > > And the root-cause is, in __init function we are calling > smsc911x_read_mac_address->smsc911x_mac_read without holding mac_lock. > > I will submit the patch to net mailing list for this. Thanks, please Cc linux-omap as well. 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] ARM: OMAP2: use early init hook
* Tony Lindgren [110124 12:16]: > > So far tested on zoom3 only, but the following gets it booting > on top of your patch. Looks like there are some other patches needed too.. At least omap4 still fails with these. 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] ARM: OMAP2: use early init hook
* Russell King - ARM Linux [110123 09:12]: > Move non-mapping and non-irq initialization code out of .map_io and > .init_irq respectively into the new init_early hook. Nice :) > Signed-off-by: Russell King > --- > I think I've updated this patch correctly for the new platforms merged > into mainline. > > Please ensure that new platforms merged after this patch also use the > new structure, and note that the initializers should be listed in the > following order: > > .fixup > .reserve > .map_io > .init_early > .init_irq > .timer > .init_machine > > This is the order in which they are called, so it helps to make sense > when reading the board level code if they're arranged in called order. OK, will do. Will also add this also into omap-testing. Any other issues that might remain should be easy to fix. 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] ARM: OMAP2: use early init hook
* Russell King - ARM Linux [110123 09:47]:
> On Sun, Jan 23, 2011 at 05:13:44PM +, Russell King - ARM Linux wrote:
> > Move non-mapping and non-irq initialization code out of .map_io and
> > .init_irq respectively into the new init_early hook.
> >
> > Signed-off-by: Russell King
> > ---
> > I think I've updated this patch correctly for the new platforms merged
> > into mainline.
>
> Grr, this breaks on OMAP because some of this stuff wants to do ioremap()
> and therefore wants the kmem allocators initialized. That's rather
> annoying...
So far tested on zoom3 only, but the following gets it booting
on top of your patch.
Want to take this one into your series?
Meanwhile, I'll add these both into our omap-testing branch
for some more testing.
Regards,
Tony
From: Tony Lindgren
Date: Mon, 24 Jan 2011 11:56:37 -0800
Subject: [PATCH] omap2+: Fix omap_serial_early_init to work with init_early hook
The new init_early hook happens at the end of setup_arch,
which is too early for kzalloc. However, there's no need
to call omap_serial_early_init that early, so fix this
by setting it up as a subsys_initcall.
Signed-off-by: Tony Lindgren
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -400,8 +400,6 @@ void __init omap2_init_common_infrastructure(void)
void __init omap2_init_common_devices(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1)
{
- omap_serial_early_init();
-
omap_hwmod_late_init();
if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -655,7 +655,7 @@ static void serial_out_override(struct uart_port *up, int
offset, int value)
}
#endif
-void __init omap_serial_early_init(void)
+static int __init omap_serial_early_init(void)
{
int i = 0;
@@ -691,7 +691,10 @@ void __init omap_serial_early_init(void)
*/
uart->oh->flags |= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET;
} while (1);
+
+ return 0;
}
+subsys_initcall(omap_serial_early_init);
/**
* omap_serial_init_port() - initialize single serial port
--- a/arch/arm/plat-omap/include/plat/serial.h
+++ b/arch/arm/plat-omap/include/plat/serial.h
@@ -96,7 +96,6 @@
struct omap_board_data;
-extern void __init omap_serial_early_init(void);
extern void omap_serial_init(void);
extern void omap_serial_init_port(struct omap_board_data *bdata);
extern int omap_uart_can_sleep(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 v4 1/4] TI816X: Update common omap platform files
"Pedanekar, Hemant" writes: > Hi Kevin, > > Hilman, Kevin wrote on Saturday, January 22, 2011 4:01 AM: > >> Hi Hemant, >> >> Hemant Pedanekar writes: >> >>> This patch updates the common platform files with TI816X support. Also >>> adds new files for TI816X module base addresses and irq definitions. >> [...] >> >>> diff --git a/arch/arm/plat-omap/include/plat/irqs-ti816x.h >> b/arch/arm/plat-omap/include/plat/irqs-ti816x.h >>> new file mode 100644 >>> index 000..3ec5d1b > [...] >>> +#define TI816X_IRQ_SECPUBINT 116 >>> +#define TI816X_IRQ_SECSECINT 117 >>> +#define TI816X_IRQ_SECPUBSWINT 118 >>> +#define TI816X_IRQ_SECSECSWINT 119 >>> +#define TI816X_IRQ_SMRFLX0 120 >>> +#define TI816X_IRQ_SMRFLX1 121 >>> +#define TI816X_IRQ_SYS_MMU 122 >>> +#define TI816X_IRQ_MC_MMU 123 >>> +#define TI816X_IRQ_DMM 124 >>> + >>> + >>> +#endif >> >> For new platforms, We don't need to have a list of all the >> IRQ numbers. >> >> Driver code should always be getting IRQ numbers (and base addresses >> etc.) from struct resource/platform_data, which is populated >> from omap_hwmod. >> > > Are you suggesting to get rid of this file altogether or the IRQs which > may never be used from kernel be removed from this file (and added later > If needed)? > > Or shall I add this file only in hwmod patch which will be submitted later? You can get rid of the file altogether. Even the hwmod data can just have IRQ numbers and you shouldn't need to add a header file with the defines. 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 00/13] OMAP: Basic DVFS Framework
Felipe Balbi writes: > Hi, > > On Fri, Jan 21, 2011 at 07:30:52PM +0530, Vishwanath BS wrote: >> This patch series introduces support for Dynamic Voltage and Frequency >> Scaling >> (DVFS) for OMAP devices. >> >> For detailed design details, refer to DVFS Documentation. > > If this is supposed to be used by drivers I would rather not as it's yet > another OMAP-specific API to use. This layer should not be used by drivers, and is OMAP specific. The generic interfaces to DVFS for drivers and other kernel code are CPUfreq and the regulator framework. 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] OMAP3EVM:FIX: Reset the SMSC911x Ethernet controller in board_init
> -Original Message- > From: Hilman, Kevin > Sent: Tuesday, January 25, 2011 1:14 AM > To: Hiremath, Vaibhav > Cc: linux-omap@vger.kernel.org; Varadarajan, Charulatha; t...@atomide.com > Subject: Re: [PATCH] OMAP3EVM:FIX: Reset the SMSC911x Ethernet controller > in board_init > > Hi Vaibhav, > > hvaib...@ti.com writes: > > > From: Vaibhav Hiremath > > > > With addition of HWMOD support to GPIO, the Ethernet controller > > goes undetected for OMAP35xEVM. So explicitely assert the reset signal > to > > Ethernet controller smsc911x - > > > > - GPIO7 (>=RevG version of EVM's) > > - GPIO64 (<=RevD version of EVM's) > > > > I have tested this patch on RevG version of EVM with ES3.1 Si. > > This patch is based on intial version from Charulatha V. > > > > Signed-off-by: Vaibhav Hiremath > > This didn't apply cleanly to l-o master, with or without your previous > patches which touch the EVM board file. > [Hiremath, Vaibhav] may be order in which you apply the patches is different, but should have been trivial to fix, right? I would suggest you to use newer version. > > --- > > NOTE: I have not been able to test it on older version of EVM's. > > After manually applying, > > Tested-by: Kevin Hilman > > I tested on my rev D board with DHCP + nfs rootfs and it's working well. > [Hiremath, Vaibhav] Thanks a lot for validating it. > While testing though, I also noticed that the smsc driver is dumping > some warnings (below) while trying to get the MAC address, resulting in > not using the actual MAC but generating a random one. > > This isn't related to your patch, since it also happens with l-o master, > but was wondering if you saw the same thing? > [Hiremath, Vaibhav] Yes I did see this message, and this is coming from #ifdef CONFIG_DEBUG_SPINLOCK #define SMSC_ASSERT_MAC_LOCK(pdata) \ WARN_ON(!spin_is_locked(&pdata->mac_lock)) And the root-cause is, in __init function we are calling smsc911x_read_mac_address->smsc911x_mac_read without holding mac_lock. I will submit the patch to net mailing list for this. Thanks, Vaibhav > A first glance looks like there are problems with the locking in the > driver, but I didn't look very deep. > > Kevin > > > [2.221832] smsc911x: Driver version 2008-10-21. > [2.227447] [ cut here ] > [2.232574] WARNING: at > /work/kernel/omap/dev/drivers/net/smsc911x.c:261 > smsc911x_mac_read+0x24/0x220() > [2.242645] Modules linked in: > [2.246124] [] (unwind_backtrace+0x0/0xe0) from [] > (warn_slowpath_common+0x4c/0x64) > [2.256256] [] (warn_slowpath_common+0x4c/0x64) from > [] (warn_slowpath_null+0x18/0x1c) > [2.266632] [] (warn_slowpath_null+0x18/0x1c) from > [] (smsc911x_mac_read+0x24/0x220) > [2.276855] [] (smsc911x_mac_read+0x24/0x220) from > [] (smsc911x_read_mac_address+0x18/0x6c) > [2.287750] [] (smsc911x_read_mac_address+0x18/0x6c) from > [] (smsc911x_drv_probe+0x498/0x1788) > [2.298858] [] (smsc911x_drv_probe+0x498/0x1788) from > [] (platform_drv_probe+0x14/0x18) > [2.309356] [] (platform_drv_probe+0x14/0x18) from > [] (driver_probe_device+0xc8/0x184) > [2.319793] [] (driver_probe_device+0xc8/0x184) from > [] (__driver_attach+0x68/0x8c) > [2.329895] [] (__driver_attach+0x68/0x8c) from [] > (bus_for_each_dev+0x48/0x74) > [2.339660] [] (bus_for_each_dev+0x48/0x74) from [] > (bus_add_driver+0x9c/0x228) > [2.349426] [] (bus_add_driver+0x9c/0x228) from [] > (driver_register+0xa0/0x124) > [2.359191] [] (driver_register+0xa0/0x124) from [] > (do_one_initcall+0xb4/0x18c) > [2.369018] [] (do_one_initcall+0xb4/0x18c) from [] > (kernel_init+0x150/0x218) > [2.378631] [] (kernel_init+0x150/0x218) from [] > (kernel_thread_exit+0x0/0x8) > [2.388427] ---[ end trace 5ae2d34b582d5786 ]--- > [2.393493] [ cut here ] > [2.398406] WARNING: at > /work/kernel/omap/dev/drivers/net/smsc911x.c:244 > smsc911x_mac_complete+0x20/0xac() > [2.408813] Modules linked in: > [2.412139] [] (unwind_backtrace+0x0/0xe0) from [] > (warn_slowpath_common+0x4c/0x64) > [2.422241] [] (warn_slowpath_common+0x4c/0x64) from > [] (warn_slowpath_null+0x18/0x1c) > [2.432647] [] (warn_slowpath_null+0x18/0x1c) from > [] (smsc911x_mac_complete+0x20/0xac) > [2.443176] [] (smsc911x_mac_complete+0x20/0xac) from > [] (smsc911x_mac_read+0x1a0/0x220) > [2.453735] [] (smsc911x_mac_read+0x1a0/0x220) from > [] (smsc911x_read_mac_address+0x18/0x6c) > [2.464691] [] (smsc911x_read_mac_address+0x18/0x6c) from > [] (smsc911x_drv_probe+0x498/0x1788) > [2.475860] [] (smsc911x_drv_probe+0x498/0x1788) from > [] (platform_drv_probe+0x14/0x18) > [2.486328] [] (platform_drv_probe+0x14/0x18) from > [] (driver_probe_device+0xc8/0x184) > [2.496734] [] (driver_probe_device+0xc8/0x184) from > [] (__driver_attach+0x68/0x8c) > [2.506866] [] (__driver_attach+0x68/0x8c) from [] > (bus_for_each_dev+0x48/0x74) > [2.516601] [] (bus_for_e
Re: [PATCH] OMAP3EVM:FIX: Reset the SMSC911x Ethernet controller in board_init
Hi Vaibhav, hvaib...@ti.com writes: > From: Vaibhav Hiremath > > With addition of HWMOD support to GPIO, the Ethernet controller > goes undetected for OMAP35xEVM. So explicitely assert the reset signal to > Ethernet controller smsc911x - > > - GPIO7 (>=RevG version of EVM's) > - GPIO64 (<=RevD version of EVM's) > > I have tested this patch on RevG version of EVM with ES3.1 Si. > This patch is based on intial version from Charulatha V. > > Signed-off-by: Vaibhav Hiremath This didn't apply cleanly to l-o master, with or without your previous patches which touch the EVM board file. > --- > NOTE: I have not been able to test it on older version of EVM's. After manually applying, Tested-by: Kevin Hilman I tested on my rev D board with DHCP + nfs rootfs and it's working well. While testing though, I also noticed that the smsc driver is dumping some warnings (below) while trying to get the MAC address, resulting in not using the actual MAC but generating a random one. This isn't related to your patch, since it also happens with l-o master, but was wondering if you saw the same thing? A first glance looks like there are problems with the locking in the driver, but I didn't look very deep. Kevin [2.221832] smsc911x: Driver version 2008-10-21. [2.227447] [ cut here ] [2.232574] WARNING: at /work/kernel/omap/dev/drivers/net/smsc911x.c:261 smsc911x_mac_read+0x24/0x220() [2.242645] Modules linked in: [2.246124] [] (unwind_backtrace+0x0/0xe0) from [] (warn_slowpath_common+0x4c/0x64) [2.256256] [] (warn_slowpath_common+0x4c/0x64) from [] (warn_slowpath_null+0x18/0x1c) [2.266632] [] (warn_slowpath_null+0x18/0x1c) from [] (smsc911x_mac_read+0x24/0x220) [2.276855] [] (smsc911x_mac_read+0x24/0x220) from [] (smsc911x_read_mac_address+0x18/0x6c) [2.287750] [] (smsc911x_read_mac_address+0x18/0x6c) from [] (smsc911x_drv_probe+0x498/0x1788) [2.298858] [] (smsc911x_drv_probe+0x498/0x1788) from [] (platform_drv_probe+0x14/0x18) [2.309356] [] (platform_drv_probe+0x14/0x18) from [] (driver_probe_device+0xc8/0x184) [2.319793] [] (driver_probe_device+0xc8/0x184) from [] (__driver_attach+0x68/0x8c) [2.329895] [] (__driver_attach+0x68/0x8c) from [] (bus_for_each_dev+0x48/0x74) [2.339660] [] (bus_for_each_dev+0x48/0x74) from [] (bus_add_driver+0x9c/0x228) [2.349426] [] (bus_add_driver+0x9c/0x228) from [] (driver_register+0xa0/0x124) [2.359191] [] (driver_register+0xa0/0x124) from [] (do_one_initcall+0xb4/0x18c) [2.369018] [] (do_one_initcall+0xb4/0x18c) from [] (kernel_init+0x150/0x218) [2.378631] [] (kernel_init+0x150/0x218) from [] (kernel_thread_exit+0x0/0x8) [2.388427] ---[ end trace 5ae2d34b582d5786 ]--- [2.393493] [ cut here ] [2.398406] WARNING: at /work/kernel/omap/dev/drivers/net/smsc911x.c:244 smsc911x_mac_complete+0x20/0xac() [2.408813] Modules linked in: [2.412139] [] (unwind_backtrace+0x0/0xe0) from [] (warn_slowpath_common+0x4c/0x64) [2.422241] [] (warn_slowpath_common+0x4c/0x64) from [] (warn_slowpath_null+0x18/0x1c) [2.432647] [] (warn_slowpath_null+0x18/0x1c) from [] (smsc911x_mac_complete+0x20/0xac) [2.443176] [] (smsc911x_mac_complete+0x20/0xac) from [] (smsc911x_mac_read+0x1a0/0x220) [2.453735] [] (smsc911x_mac_read+0x1a0/0x220) from [] (smsc911x_read_mac_address+0x18/0x6c) [2.464691] [] (smsc911x_read_mac_address+0x18/0x6c) from [] (smsc911x_drv_probe+0x498/0x1788) [2.475860] [] (smsc911x_drv_probe+0x498/0x1788) from [] (platform_drv_probe+0x14/0x18) [2.486328] [] (platform_drv_probe+0x14/0x18) from [] (driver_probe_device+0xc8/0x184) [2.496734] [] (driver_probe_device+0xc8/0x184) from [] (__driver_attach+0x68/0x8c) [2.506866] [] (__driver_attach+0x68/0x8c) from [] (bus_for_each_dev+0x48/0x74) [2.516601] [] (bus_for_each_dev+0x48/0x74) from [] (bus_add_driver+0x9c/0x228) [2.526367] [] (bus_add_driver+0x9c/0x228) from [] (driver_register+0xa0/0x124) [2.536132] [] (driver_register+0xa0/0x124) from [] (do_one_initcall+0xb4/0x18c) [2.545989] [] (do_one_initcall+0xb4/0x18c) from [] (kernel_init+0x150/0x218) [2.72] [] (kernel_init+0x150/0x218) from [] (kernel_thread_exit+0x0/0x8) [2.565124] ---[ end trace 5ae2d34b582d5787 ]--- [2.570037] [ cut here ] [2.575103] WARNING: at /work/kernel/omap/dev/drivers/net/smsc911x.c:261 smsc911x_mac_read+0x24/0x220() [2.585144] Modules linked in: [2.588470] [] (unwind_backtrace+0x0/0xe0) from [] (warn_slowpath_common+0x4c/0x64) [2.598602] [] (warn_slowpath_common+0x4c/0x64) from [] (warn_slowpath_null+0x18/0x1c) [2.609008] [] (warn_slowpath_null+0x18/0x1c) from [] (smsc911x_mac_read+0x24/0x220) [2.619201] [] (smsc911x_mac_read+0x24/0x220) from [] (smsc911x_read_mac_address+0x28/0x6c) [2.630065] [] (smsc911x_read_mac_address+0x28/0x6c) from [] (smsc911x_drv_probe+0x498/
[PATCH] OMAP3EVM: Set TSC wakeup option in pad config
Set OMAP_PIN_OFF_WAKEUPENABLE to enable the wake-up
functionality from touchscreen controller.
Signed-off-by: Vaibhav Hiremath
---
arch/arm/mach-omap2/board-omap3evm.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 1716f4c..233496f 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -721,7 +721,8 @@ static struct omap_board_mux omap35x_board_mux[] __initdata
= {
OMAP_PIN_OFF_INPUT_PULLUP |
OMAP_PIN_OFF_OUTPUT_LOW |
OMAP_PIN_OFF_WAKEUPENABLE),
OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
- OMAP_PIN_OFF_INPUT_PULLUP |
OMAP_PIN_OFF_OUTPUT_LOW),
+ OMAP_PIN_OFF_INPUT_PULLUP |
OMAP_PIN_OFF_OUTPUT_LOW |
+ OMAP_PIN_OFF_WAKEUPENABLE),
OMAP3_MUX(SYS_BOOT5, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
OMAP_PIN_OFF_NONE),
OMAP3_MUX(GPMC_WAIT2, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
@@ -734,7 +735,8 @@ static struct omap_board_mux omap36x_board_mux[] __initdata
= {
OMAP_PIN_OFF_INPUT_PULLUP |
OMAP_PIN_OFF_OUTPUT_LOW |
OMAP_PIN_OFF_WAKEUPENABLE),
OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
- OMAP_PIN_OFF_INPUT_PULLUP |
OMAP_PIN_OFF_OUTPUT_LOW),
+ OMAP_PIN_OFF_INPUT_PULLUP |
OMAP_PIN_OFF_OUTPUT_LOW |
+ OMAP_PIN_OFF_WAKEUPENABLE),
/* AM/DM37x EVM: DSS data bus muxed with sys_boot */
OMAP3_MUX(DSS_DATA18, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
OMAP3_MUX(DSS_DATA19, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
--
1.6.2.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
[PATCH 4/4] arch/arm/mach-omap2/smartreflex.c: Add missing IS_ERR test
Function _sr_lookup, defined in the same file, returns ERR_PTR not NULL in
an error case.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
//
@r@
identifier f;
@@
f(...) { ... return ERR_PTR(...); }
@@
identifier r.f, fld;
expression x;
statement S1,S2;
@@
x = f(...)
... when != IS_ERR(x)
(
if (IS_ERR(x) ||...) S1 else S2
|
*x->fld
)
//
Signed-off-by: Julia Lawall
---
arch/arm/mach-omap2/smartreflex.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 77ecebf..d7deadf 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -966,7 +966,7 @@ static int __devexit omap_sr_remove(struct platform_device
*pdev)
}
sr_info = _sr_lookup(pdata->voltdm);
- if (!sr_info) {
+ if (IS_ERR(sr_info)) {
dev_warn(&pdev->dev, "%s: omap_sr struct not found\n",
__func__);
return -EINVAL;
--
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-V2] OMAP3EVM:FIX: Reset the smsc911x ethernet controller in board_init
With addition of hwmod support to gpio, the ethernet controller
goes undetected for OMAP35xEVM. So explicitly assert the reset signal to
ethernet controller smsc911x -
- GPIO7 (>=RevG version of EVM's)
- GPIO64 (<=RevD version of EVM's)
Tested this patch on RevG version of EVM with ES3.1 Si.
This patch is based on intial version from Charulatha V, reference
to original discussion -
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg35784.html
Signed-off-by: Vaibhav Hiremath
---
Changes from V1 -
- Removed hardcoded value for rst gpio
- Added check for return value to gpio_direction_output api
arch/arm/mach-omap2/board-omap3evm.c | 39 +-
1 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index a888a7d..1716f4c 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -58,6 +58,13 @@
#define OMAP3EVM_ETHR_ID_REV 0x50
#define OMAP3EVM_ETHR_GPIO_IRQ 176
#define OMAP3EVM_SMSC911X_CS 5
+/*
+ * Eth Reset signal
+ * 64 = Generation 1 (<=RevD)
+ * 7 = Generation 2 (>=RevE)
+ */
+#define OMAP3EVM_GEN1_ETHR_GPIO_RST64
+#define OMAP3EVM_GEN2_ETHR_GPIO_RST7
static u8 omap3_evm_version;
@@ -124,10 +131,15 @@ static struct platform_device omap3evm_smsc911x_device = {
static inline void __init omap3evm_init_smsc911x(void)
{
- int eth_cs;
+ int eth_cs, eth_rst;
struct clk *l3ck;
unsigned int rate;
+ if (get_omap3_evm_rev() == OMAP3EVM_BOARD_GEN_1)
+ eth_rst = OMAP3EVM_GEN1_ETHR_GPIO_RST;
+ else
+ eth_rst = OMAP3EVM_GEN2_ETHR_GPIO_RST;
+
eth_cs = OMAP3EVM_SMSC911X_CS;
l3ck = clk_get(NULL, "l3_ck");
@@ -136,6 +148,27 @@ static inline void __init omap3evm_init_smsc911x(void)
else
rate = clk_get_rate(l3ck);
+ /* Configure ethernet controller reset gpio */
+ if (cpu_is_omap3430()) {
+ if (gpio_request(eth_rst, "SMSC911x gpio") < 0) {
+ pr_err(KERN_ERR "Failed to request %d for smsc911x\n",
+ eth_rst);
+ return;
+ }
+
+ if (gpio_direction_output(eth_rst, 1) < 0) {
+ pr_err(KERN_ERR "Failed to set direction of %d for" \
+ " smsc911x\n", eth_rst);
+ return;
+ }
+ /* reset pulse to ethernet controller*/
+ usleep_range(150, 220);
+ gpio_set_value(eth_rst, 0);
+ usleep_range(150, 220);
+ gpio_set_value(eth_rst, 1);
+ usleep_range(1, 2);
+ }
+
if (gpio_request(OMAP3EVM_ETHR_GPIO_IRQ, "SMSC911x irq") < 0) {
printk(KERN_ERR "Failed to request GPIO%d for smsc911x IRQ\n",
OMAP3EVM_ETHR_GPIO_IRQ);
@@ -689,6 +722,10 @@ static struct omap_board_mux omap35x_board_mux[]
__initdata = {
OMAP_PIN_OFF_WAKEUPENABLE),
OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
OMAP_PIN_OFF_INPUT_PULLUP |
OMAP_PIN_OFF_OUTPUT_LOW),
+ OMAP3_MUX(SYS_BOOT5, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
+ OMAP_PIN_OFF_NONE),
+ OMAP3_MUX(GPMC_WAIT2, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
+ OMAP_PIN_OFF_NONE),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
--
1.6.2.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
[PATCH-V2] OMAP3EVM: Made backlight GPIO default state to off
If you choose default output to DVI, the LCD backlight used to
stay on, since panel->disable function never gets called.
So, during init put backlight GPIO to off state and the driver
code will decide which output to enable.
Signed-off-by: Vaibhav Hiremath
---
Changes from V1 -
- Added check for return value
arch/arm/mach-omap2/board-omap3evm.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 7119380..a888a7d 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -411,6 +411,8 @@ static struct platform_device leds_gpio = {
static int omap3evm_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
+ int r;
+
/* gpio + 0 is "mmc0_cd" (input/IRQ) */
omap_mux_init_gpio(63, OMAP_PIN_INPUT);
mmc[0].gpio_cd = gpio + 0;
@@ -426,8 +428,17 @@ static int omap3evm_twl_gpio_setup(struct device *dev,
*/
/* TWL4030_GPIO_MAX + 0 == ledA, LCD Backlight control */
- gpio_request(gpio + TWL4030_GPIO_MAX, "EN_LCD_BKL");
- gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
+ r = gpio_request(gpio + TWL4030_GPIO_MAX, "EN_LCD_BKL");
+ if (r)
+ printk(KERN_ERR "failed to get lcd_bkl gpio\n");
+
+ if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2)
+ r = gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1);
+ else
+ r = gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
+
+ if (r)
+ printk(KERN_ERR "failed to set direction of lcd_bkl gpio\n");
/* gpio + 7 == DVI Enable */
gpio_request(gpio + 7, "EN_DVI");
--
1.6.2.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
[PATCH-V2] OMAP3EVM: Add vio regulator supply required for ads7846 TSC driver
Add vio regulator supply, needed for ads7846 touchscreen controller
driver.
Tested on OMAP3 (ES3.1 Si) RevG version of EVM.
Signed-off-by: Vaibhav Hiremath
---
Changes from V1 -
- Added patch description.
arch/arm/mach-omap2/board-omap3evm.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index a158d21..ed0311c 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -538,6 +538,25 @@ static struct regulator_init_data omap3_evm_vpll2 = {
.consumer_supplies = &omap3_evm_vpll2_supply,
};
+/* ads7846 on SPI */
+static struct regulator_consumer_supply omap3evm_vio_supply =
+ REGULATOR_SUPPLY("vcc", "spi1.0");
+
+/* VIO for ads7846 */
+static struct regulator_init_data omap3evm_vio = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = &omap3evm_vio_supply,
+};
+
static struct twl4030_platform_data omap3evm_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
@@ -550,6 +569,7 @@ static struct twl4030_platform_data omap3evm_twldata = {
.codec = &omap3evm_codec_data,
.vdac = &omap3_evm_vdac,
.vpll2 = &omap3_evm_vpll2,
+ .vio= &omap3evm_vio,
};
static struct i2c_board_info __initdata omap3evm_i2c_boardinfo[] = {
--
1.6.2.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] OMAP3EVM: Add vio regulator supply required for ads7846 TSC driver
"Hiremath, Vaibhav" writes:
>> -Original Message-
>> From: Varadarajan, Charulatha [mailto:ch...@ti.com]
>> Sent: Monday, January 24, 2011 8:13 PM
>> To: Hiremath, Vaibhav
>> Cc: linux-omap@vger.kernel.org; t...@atomide.com
>> Subject: Re: [PATCH] OMAP3EVM: Add vio regulator supply required for
>> ads7846 TSC driver
>>
>> On Mon, Jan 24, 2011 at 20:02, wrote:
>> > From: Vaibhav Hiremath
>> >
>>
>> Please add a patch description.
>>
> [Hiremath, Vaibhav] I can copy/paste subject line again here, but I thought
> subject description is sufficient to explain purpose of patch so did not
> mentioned anything here.
Please summarize the change in a descriptive changelog. You can do more
than copy/paste and add a few more lines of description, e.g.
The on-board touchscreen controller on the OMAP3EVM is powered by...
The changelogs go into the *permanent* history, so changelogs should be
descriptive enough not just for those familiar with the code but for
those reading the changelogs in the future.
Thanks,
Kevin
>
>> >
>> > Signed-off-by: Vaibhav Hiremath
>> > ---
>> > arch/arm/mach-omap2/board-omap3evm.c | 20
>> > 1 files changed, 20 insertions(+), 0 deletions(-)
>> >
>> > diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
>> omap2/board-omap3evm.c
>> > index a158d21..ed0311c 100644
>> > --- a/arch/arm/mach-omap2/board-omap3evm.c
>> > +++ b/arch/arm/mach-omap2/board-omap3evm.c
>> > @@ -538,6 +538,25 @@ static struct regulator_init_data omap3_evm_vpll2 =
>> {
>> > .consumer_supplies = &omap3_evm_vpll2_supply,
>> > };
>> >
>> > +/* ads7846 on SPI */
>> > +static struct regulator_consumer_supply omap3evm_vio_supply =
>> > + REGULATOR_SUPPLY("vcc", "spi1.0");
>> > +
>> > +/* VIO for ads7846 */
>> > +static struct regulator_init_data omap3evm_vio = {
>> > + .constraints = {
>> > + .min_uV = 180,
>> > + .max_uV = 180,
>> > + .apply_uV = true,
>> > + .valid_modes_mask = REGULATOR_MODE_NORMAL
>> > + | REGULATOR_MODE_STANDBY,
>> > + .valid_ops_mask = REGULATOR_CHANGE_MODE
>> > + | REGULATOR_CHANGE_STATUS,
>> > + },
>> > + .num_consumer_supplies = 1,
>> > + .consumer_supplies = &omap3evm_vio_supply,
>> > +};
>> > +
>> > static struct twl4030_platform_data omap3evm_twldata = {
>> > .irq_base = TWL4030_IRQ_BASE,
>> > .irq_end = TWL4030_IRQ_END,
>> > @@ -550,6 +569,7 @@ static struct twl4030_platform_data omap3evm_twldata
>> = {
>> > .codec = &omap3evm_codec_data,
>> > .vdac = &omap3_evm_vdac,
>> > .vpll2 = &omap3_evm_vpll2,
>> > + .vio = &omap3evm_vio,
>> > };
>> >
>> > static struct i2c_board_info __initdata omap3evm_i2c_boardinfo[] = {
>> > --
>> > 1.6.2.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
--
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
[GIT PULL] omap fixes for v2.6.38-rc2
Hi Linus, Please pull omap fixes from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes-for-linus This is mostly to fix issues with recent omap1_defconfig and sched_clock changes. We need both the MPU timer and the 32KiHz timer usable together for omap1_defconfig. This is needed as the 32KiHz timer is not available on omap15xx or 730. Did not notice this earlier with omap1_defconfig as it does not have CONFIG_PRINTK_TIME set currently.. Regards, Tony The following changes since commit 1bae4ce27c9c90344f23c65ea6966c50ffeae2f5: Linux 2.6.38-rc2 (2011-01-21 19:01:34 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes-for-linus Adrian Hunter (1): omap: DMA: clear interrupt status correctly Daniel Morsing (1): OMAP3: Devkit8000: Fix tps65930 pullup/pulldown configuration Felipe Balbi (1): OMAP: PRCM: remove duplicated headers Igor Grinberg (2): arm: omap3: cm-t3517: rtc fix arm: omap3: cm-t3517: minor comment fix Paul Walmsley (2): OMAP: counter_32k: init clocksource as part of machine timer init OMAP4: clockdomain: bypass unimplemented wake-up dependency functions on OMAP4 Tony Lindgren (4): Merge branch 'fixes_a_2.6.38rc' of git://git.pwsan.com/linux-2.6 into omap-fixes omap1: Fix sched_clock for the MPU timer omap1: Fix booting for 15xx and 730 with omap1_defconfig omap1: Fix sched_clock implementation when both MPU timer and 32K timer are used arch/arm/mach-omap1/Kconfig |2 + arch/arm/mach-omap1/Makefile|3 +- arch/arm/mach-omap1/time.c | 101 +-- arch/arm/mach-omap1/timer32k.c | 13 ++-- arch/arm/mach-omap2/board-cm-t3517.c| 29 ++-- arch/arm/mach-omap2/board-devkit8000.c |3 +- arch/arm/mach-omap2/clock44xx_data.c|1 - arch/arm/mach-omap2/clockdomain.c | 30 +++- arch/arm/mach-omap2/clockdomains44xx_data.c |2 - arch/arm/mach-omap2/powerdomain2xxx_3xxx.c |1 - arch/arm/mach-omap2/timer-gp.c | 10 ++- arch/arm/plat-omap/Kconfig |8 +-- arch/arm/plat-omap/counter_32k.c| 22 -- arch/arm/plat-omap/dma.c|7 +- arch/arm/plat-omap/include/plat/common.h|3 + 15 files changed, 184 insertions(+), 51 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 v2] OMAP: use fncpy to copy the PM code functions to SRAM
Hi,
On Mon, Jan 24, 2011 at 5:11 PM, Dave Martin wrote:
> Hi there, I just spotted a couple of things merging your patch...
>
> On Tue, Jan 18, 2011 at 12:02 PM, wrote:
>> From: Jean Pihet
>>
>> The new fncpy API is better suited for copying some
>> code to SRAM at runtime. This patch changes the ad-hoc
>> code to the more generic fncpy API.
>>
>> Tested OK on OMAP3 in low power modes (RET/OFF)
>> using omap2plus_defconfig with !CONFIG_THUMB2_KERNEL.
>> Compile tested on OMAP1/2 using omap1_defconfig.
>>
>> Signed-off-by: Jean Pihet
>> ---
>> arch/arm/mach-omap1/pm.h | 6 +++---
>> arch/arm/mach-omap1/sleep.S | 3 +++
>> arch/arm/mach-omap1/sram.S | 1 +
>> arch/arm/mach-omap2/pm.h | 2 +-
>> arch/arm/mach-omap2/sleep24xx.S | 2 ++
>> arch/arm/mach-omap2/sleep34xx.S | 2 ++
>> arch/arm/mach-omap2/sram242x.S | 3 +++
>> arch/arm/mach-omap2/sram243x.S | 3 +++
>> arch/arm/mach-omap2/sram34xx.S | 1 +
>> arch/arm/plat-omap/include/plat/sram.h | 14 +-
>> arch/arm/plat-omap/sram.c | 14 +-
>> 11 files changed, 41 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap1/pm.h b/arch/arm/mach-omap1/pm.h
>> index 56a6479..cd926dc 100644
>> --- a/arch/arm/mach-omap1/pm.h
>> +++ b/arch/arm/mach-omap1/pm.h
>> @@ -123,9 +123,9 @@ extern void allow_idle_sleep(void);
>> extern void omap1_pm_idle(void);
>> extern void omap1_pm_suspend(void);
>>
>> -extern void omap7xx_cpu_suspend(unsigned short, unsigned short);
>> -extern void omap1510_cpu_suspend(unsigned short, unsigned short);
>> -extern void omap1610_cpu_suspend(unsigned short, unsigned short);
>> +extern void omap7xx_cpu_suspend(unsigned long, unsigned long);
>> +extern void omap1510_cpu_suspend(unsigned long, unsigned long);
>> +extern void omap1610_cpu_suspend(unsigned long, unsigned long);
>> extern void omap7xx_idle_loop_suspend(void);
>> extern void omap1510_idle_loop_suspend(void);
>> extern void omap1610_idle_loop_suspend(void);
>> diff --git a/arch/arm/mach-omap1/sleep.S b/arch/arm/mach-omap1/sleep.S
>> index ef771ce..c875bdc 100644
>> --- a/arch/arm/mach-omap1/sleep.S
>> +++ b/arch/arm/mach-omap1/sleep.S
>> @@ -58,6 +58,7 @@
>> */
>>
>> #if defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850)
>> + .align 3
>> ENTRY(omap7xx_cpu_suspend)
>>
>> @ save registers on stack
>> @@ -137,6 +138,7 @@ ENTRY(omap7xx_cpu_suspend_sz)
>> #endif /* CONFIG_ARCH_OMAP730 || CONFIG_ARCH_OMAP850 */
>>
>> #ifdef CONFIG_ARCH_OMAP15XX
>> + .align 3
>> ENTRY(omap1510_cpu_suspend)
>>
>> @ save registers on stack
>> @@ -211,6 +213,7 @@ ENTRY(omap1510_cpu_suspend_sz)
>> #endif /* CONFIG_ARCH_OMAP15XX */
>>
>> #if defined(CONFIG_ARCH_OMAP16XX)
>> + .align 3
>> ENTRY(omap1610_cpu_suspend)
>>
>> @ save registers on stack
>> diff --git a/arch/arm/mach-omap1/sram.S b/arch/arm/mach-omap1/sram.S
>> index 7724e52..692587d 100644
>> --- a/arch/arm/mach-omap1/sram.S
>> +++ b/arch/arm/mach-omap1/sram.S
>> @@ -18,6 +18,7 @@
>> /*
>> * Reprograms ULPD and CKCTL.
>> */
>> + .align 3
>> ENTRY(omap1_sram_reprogram_clock)
>> stmfd sp!, {r0 - r12, lr} @ save registers on stack
>>
>> diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
>> index 1c1b0ab..39580e6 100644
>> --- a/arch/arm/mach-omap2/pm.h
>> +++ b/arch/arm/mach-omap2/pm.h
>> @@ -92,7 +92,7 @@ extern void omap24xx_idle_loop_suspend(void);
>> extern void omap24xx_cpu_suspend(u32 dll_ctrl, void __iomem *sdrc_dlla_ctrl,
>> void __iomem *sdrc_power);
>> extern void omap34xx_cpu_suspend(u32 *addr, int save_state);
>> -extern void save_secure_ram_context(u32 *addr);
>> +extern int save_secure_ram_context(u32 *addr);
>> extern void omap3_save_scratchpad_contents(void);
>>
>> extern unsigned int omap24xx_idle_loop_suspend_sz;
>> diff --git a/arch/arm/mach-omap2/sleep24xx.S
>> b/arch/arm/mach-omap2/sleep24xx.S
>> index c7780cc..b5071a4 100644
>> --- a/arch/arm/mach-omap2/sleep24xx.S
>> +++ b/arch/arm/mach-omap2/sleep24xx.S
>> @@ -47,6 +47,7 @@
>> * Note: This code get's copied to internal SRAM at boot. When the OMAP
>> * wakes up it continues execution at the point it went to sleep.
>> */
>> + .align 3
>> ENTRY(omap24xx_idle_loop_suspend)
>> stmfd sp!, {r0, lr} @ save registers on stack
>> mov r0, #0 @ clear for mcr setup
>> @@ -82,6 +83,7 @@ ENTRY(omap24xx_idle_loop_suspend_sz)
>> * The DLL load value is not kept in RETENTION or OFF. It needs to be
>> restored
>> * at wake
>> */
>> + .align 3
>> ENTRY(omap24xx_cpu_suspend)
>> stmfd sp!, {r0 - r12, lr} @ save registers on stack
>> mov r3, #0x0 @ clear for mcr call
>> diff --git a/arch/arm/mach-omap2/sleep34xx.S
>> b/arch/arm/mach-omap2/sleep34xx.S
>> index 98d8232.
RE: OMAP3 - PM - Question - Disabling CLKEN and HFCLKOUT signals from TWL4030 scripts
Hi Lesly,
> Hi Nagendra,
>
>> Hi All,
>>
>> We are working on Power management on OMAP3 (3530) and I am trying to
>> disable CLKEN and HFCLKOUT through TWL4030 power scripts. However we have
>> not been able to achieve this.
>>
>> Following are the changes and tests done so far.
>>
>> - VAUX1, CLKEN and HFCLKOUT were assigned to P1 group.
>> - Wrote Singular messages to turn on/off these signals in TWL4030
scripts.
>> - We observed that VAUX1 is able to switch ON/OFF properly as per the
> script
>> but HFCLKOUT and CLKEN are not behaving as expected.
>> - However if we try writing CLKEN_DEV_GRP to zero, CLKEN is going low.
>> - We have made sure that SYS_OFF_MODE and CLK_REQ signals go low during
> the
>> system OFF mode, LVL_WAKEUP bit enabled in Px_SW_EVENTS, and STS_CHG bit
> in
>> STS_HW_CONDITIONS is zero.
>>
>> Is there anything that I am missing? Kindly let me know.
>
> Did try probing the sys_clkreq from OMAP?
> Yes nSLEEP1, nSLEEP2 and SYS_CLK_REQ signals go low during
system
> OFF mode.
>
> Are you sending SLEEP/OFF command in singular msg?
> Yes.
>
> Also check the HFCLKOUT_REMAP register for SLEEP_STATE[3:0], if using
SLEEP
> cmd.
>
> We are setting SLEEP_STATE field of CLKEN and HFCLKOUT to OFF mode.
>
> PSP version : 3.0.1.6
>
> Following is the TWL4030 power scripts that we are trying to get CLKEN
> signal to OFF state. This is based on rx51-peripherals.c
>
> ---
> static struct twl4030_ins sleep_on_seq[] __initdata = {
> {MSG_SINGULAR(DEV_GRP_P1, RES_CLKEN, RES_STATE_OFF), 2},
you have to sent sleep cmd to RES_HFCLKOUT also.(* attach HFCLKOUT to P3)
> };
>
> static struct twl4030_script sleep_on_script __initdata = {
> .script = sleep_on_seq,
> .size = ARRAY_SIZE(sleep_on_seq),
> .flags = TWL4030_SLEEP_SCRIPT,
> };
>
> static struct twl4030_ins wakeup_seq[] __initdata = {
> {MSG_SINGULAR(DEV_GRP_P1, RES_CLKEN, RES_STATE_ACTIVE), 2},
> };
>
> static struct twl4030_script wakeup_script __initdata = {
> .script = wakeup_seq,
> .size = ARRAY_SIZE(wakeup_seq),
> .flags = TWL4030_WAKEUP12_SCRIPT,
> };
>
> static struct twl4030_ins wakeup_p3_seq[] __initdata = {
> {MSG_SINGULAR(DEV_GRP_P3, RES_CLKEN, RES_STATE_ACTIVE), 2},
you have to wakeup cmd to RES_HFCLKOUT also. (* attach HFCLKOUT to P3)
> };
>
> static struct twl4030_script wakeup_p3_script __initdata = {
> .script = wakeup_p3_seq,
> .size = ARRAY_SIZE(wakeup_p3_seq),
> .flags = TWL4030_WAKEUP3_SCRIPT,
> };
>
> static struct twl4030_ins wrst_seq[] __initdata = {
> /*
> * Reset twl4030.
> * Reset VDD1 regulator.
> * Reset VDD2 regulator.
> * Reset VPLL1 regulator.
> * Enable sysclk output.
> * Reenable twl4030.
> */
> {MSG_SINGULAR(DEV_GRP_NULL, RES_RESET, RES_STATE_OFF), 2},
> {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, 0, 1, RES_STATE_ACTIVE),
> 0x13},
> {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_PP, 0, 3, RES_STATE_OFF),
> 0x13},
> {MSG_SINGULAR(DEV_GRP_NULL, RES_VDD1, RES_STATE_WRST), 0x13},
> {MSG_SINGULAR(DEV_GRP_NULL, RES_VDD2, RES_STATE_WRST), 0x13},
> {MSG_SINGULAR(DEV_GRP_NULL, RES_VPLL1, RES_STATE_WRST), 0x35},
> {MSG_SINGULAR(DEV_GRP_P3, RES_HFCLKOUT, RES_STATE_ACTIVE), 2},
> {MSG_SINGULAR(DEV_GRP_NULL, RES_RESET, RES_STATE_ACTIVE), 2},
> };
>
> static struct twl4030_script wrst_script __initdata = {
> .script = wrst_seq,
> .size = ARRAY_SIZE(wrst_seq),
> .flags = TWL4030_WRST_SCRIPT,
> };
>
> static struct twl4030_script *twl4030_scripts[] __initdata = {
> /* wakeup12 script should be loaded before sleep script, otherwise
a
>board might hit retention before loading of wakeup script is
>completed. This can cause boot failures depending on timing
> issues.
> */
> &wakeup_script,
> &sleep_on_script,
> &wakeup_p3_script,
> &wrst_script,
> };
>
> static struct twl4030_resconfig twl4030_rconfig[] __initdata = {
> { .resource = RES_CLKEN, .devgroup = DEV_GRP_P1,
> .type = -1, .type2 = -1 , .remap_off = RES_STATE_OFF,
.remap_sleep
> = RES_STATE_OFF
> },
> { .resource = RES_HFCLKOUT, .devgroup = -1,
> .type = -1, .type2 = -1, .remap_off = RES_STATE_OFF,
.remap_sleep
> = RES_STATE_OFF
> },
>
> { 0, 0},
> };
> --
>> Part number of TPS used in our board is TPS65950 BZXNR
>>
You are using which code base (mainline kernel) ?
We tried putting HFCLKOUT tied to P3 and put it into OFF state,
but that did not work.
1. Is it necessary to put HFCLKOUT to OFF/SLEEP before switch OFF CLKEN?
2. We observe that none of RC resources can be put into sleep/off mode. Is
there any dependency for this to work?
3. We are using Linux version 2.6.32 from PSP 3.0.1.6 release
Regards,
Lesly A M
--
To unsubsc
Re: [PATCH v2] OMAP: use fncpy to copy the PM code functions to SRAM
Hi there, I just spotted a couple of things merging your patch...
On Tue, Jan 18, 2011 at 12:02 PM, wrote:
> From: Jean Pihet
>
> The new fncpy API is better suited for copying some
> code to SRAM at runtime. This patch changes the ad-hoc
> code to the more generic fncpy API.
>
> Tested OK on OMAP3 in low power modes (RET/OFF)
> using omap2plus_defconfig with !CONFIG_THUMB2_KERNEL.
> Compile tested on OMAP1/2 using omap1_defconfig.
>
> Signed-off-by: Jean Pihet
> ---
> arch/arm/mach-omap1/pm.h | 6 +++---
> arch/arm/mach-omap1/sleep.S | 3 +++
> arch/arm/mach-omap1/sram.S | 1 +
> arch/arm/mach-omap2/pm.h | 2 +-
> arch/arm/mach-omap2/sleep24xx.S | 2 ++
> arch/arm/mach-omap2/sleep34xx.S | 2 ++
> arch/arm/mach-omap2/sram242x.S | 3 +++
> arch/arm/mach-omap2/sram243x.S | 3 +++
> arch/arm/mach-omap2/sram34xx.S | 1 +
> arch/arm/plat-omap/include/plat/sram.h | 14 +-
> arch/arm/plat-omap/sram.c | 14 +-
> 11 files changed, 41 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/pm.h b/arch/arm/mach-omap1/pm.h
> index 56a6479..cd926dc 100644
> --- a/arch/arm/mach-omap1/pm.h
> +++ b/arch/arm/mach-omap1/pm.h
> @@ -123,9 +123,9 @@ extern void allow_idle_sleep(void);
> extern void omap1_pm_idle(void);
> extern void omap1_pm_suspend(void);
>
> -extern void omap7xx_cpu_suspend(unsigned short, unsigned short);
> -extern void omap1510_cpu_suspend(unsigned short, unsigned short);
> -extern void omap1610_cpu_suspend(unsigned short, unsigned short);
> +extern void omap7xx_cpu_suspend(unsigned long, unsigned long);
> +extern void omap1510_cpu_suspend(unsigned long, unsigned long);
> +extern void omap1610_cpu_suspend(unsigned long, unsigned long);
> extern void omap7xx_idle_loop_suspend(void);
> extern void omap1510_idle_loop_suspend(void);
> extern void omap1610_idle_loop_suspend(void);
> diff --git a/arch/arm/mach-omap1/sleep.S b/arch/arm/mach-omap1/sleep.S
> index ef771ce..c875bdc 100644
> --- a/arch/arm/mach-omap1/sleep.S
> +++ b/arch/arm/mach-omap1/sleep.S
> @@ -58,6 +58,7 @@
> */
>
> #if defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850)
> + .align 3
> ENTRY(omap7xx_cpu_suspend)
>
> @ save registers on stack
> @@ -137,6 +138,7 @@ ENTRY(omap7xx_cpu_suspend_sz)
> #endif /* CONFIG_ARCH_OMAP730 || CONFIG_ARCH_OMAP850 */
>
> #ifdef CONFIG_ARCH_OMAP15XX
> + .align 3
> ENTRY(omap1510_cpu_suspend)
>
> @ save registers on stack
> @@ -211,6 +213,7 @@ ENTRY(omap1510_cpu_suspend_sz)
> #endif /* CONFIG_ARCH_OMAP15XX */
>
> #if defined(CONFIG_ARCH_OMAP16XX)
> + .align 3
> ENTRY(omap1610_cpu_suspend)
>
> @ save registers on stack
> diff --git a/arch/arm/mach-omap1/sram.S b/arch/arm/mach-omap1/sram.S
> index 7724e52..692587d 100644
> --- a/arch/arm/mach-omap1/sram.S
> +++ b/arch/arm/mach-omap1/sram.S
> @@ -18,6 +18,7 @@
> /*
> * Reprograms ULPD and CKCTL.
> */
> + .align 3
> ENTRY(omap1_sram_reprogram_clock)
> stmfd sp!, {r0 - r12, lr} @ save registers on stack
>
> diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
> index 1c1b0ab..39580e6 100644
> --- a/arch/arm/mach-omap2/pm.h
> +++ b/arch/arm/mach-omap2/pm.h
> @@ -92,7 +92,7 @@ extern void omap24xx_idle_loop_suspend(void);
> extern void omap24xx_cpu_suspend(u32 dll_ctrl, void __iomem *sdrc_dlla_ctrl,
> void __iomem *sdrc_power);
> extern void omap34xx_cpu_suspend(u32 *addr, int save_state);
> -extern void save_secure_ram_context(u32 *addr);
> +extern int save_secure_ram_context(u32 *addr);
> extern void omap3_save_scratchpad_contents(void);
>
> extern unsigned int omap24xx_idle_loop_suspend_sz;
> diff --git a/arch/arm/mach-omap2/sleep24xx.S b/arch/arm/mach-omap2/sleep24xx.S
> index c7780cc..b5071a4 100644
> --- a/arch/arm/mach-omap2/sleep24xx.S
> +++ b/arch/arm/mach-omap2/sleep24xx.S
> @@ -47,6 +47,7 @@
> * Note: This code get's copied to internal SRAM at boot. When the OMAP
> * wakes up it continues execution at the point it went to sleep.
> */
> + .align 3
> ENTRY(omap24xx_idle_loop_suspend)
> stmfd sp!, {r0, lr} @ save registers on stack
> mov r0, #0 @ clear for mcr setup
> @@ -82,6 +83,7 @@ ENTRY(omap24xx_idle_loop_suspend_sz)
> * The DLL load value is not kept in RETENTION or OFF. It needs to be restored
> * at wake
> */
> + .align 3
> ENTRY(omap24xx_cpu_suspend)
> stmfd sp!, {r0 - r12, lr} @ save registers on stack
> mov r3, #0x0 @ clear for mcr call
> diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
> index 98d8232..951a0be 100644
> --- a/arch/arm/mach-omap2/sleep34xx.S
> +++ b/arch/arm/mach-omap2/sleep34xx.S
> @@ -118,6 +118,7 @@ ENTRY(enable_omap3630_toggle_l2_on_restore)
>
> .text
> /* Functio
[RFC] serial: omap-serial: Enable the UART wake-up bits always
OMAP can do also dynamic idling so wake-up enable register should be set also while system is running. If UART_OMAP_WER is not set, then for instance the RX activity cannot wake up the UART port that is sleeping. This RX wake-up feature was working when the 8250 driver was used instead of omap-serial. Reason for this is that the 8250 doesn't set the UART_OMAP_WER and then arch/arm/mach-omap2/pm34xx.c ends up saving and restoring the reset default which is the same than value OMAP_UART_WER_MOD_WKUP here. Fix this by moving the conditional UART_OMAP_WER write from serial_omap_pm into serial_omap_startup where wake-up bits are set unconditionally. Signed-off-by: Jarkko Nikula Cc: Govindraj.R --- This problem has been here since 2.6.37 when the omap-serial was switched into use so this patch is for 2.6.39. --- drivers/serial/omap-serial.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/serial/omap-serial.c b/drivers/serial/omap-serial.c index 7f2f010..d40924a 100644 --- a/drivers/serial/omap-serial.c +++ b/drivers/serial/omap-serial.c @@ -517,6 +517,9 @@ static int serial_omap_startup(struct uart_port *port) up->ier = UART_IER_RLSI | UART_IER_RDI; serial_out(up, UART_IER, up->ier); + /* Enable module level wake up */ + serial_out(up, UART_OMAP_WER, OMAP_UART_WER_MOD_WKUP); + up->port_activity = jiffies; return 0; } @@ -824,9 +827,6 @@ serial_omap_pm(struct uart_port *port, unsigned int state, serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B); serial_out(up, UART_EFR, efr); serial_out(up, UART_LCR, 0); - /* Enable module level wake up */ - serial_out(up, UART_OMAP_WER, - (state != 0) ? OMAP_UART_WER_MOD_WKUP : 0); } static void serial_omap_release_port(struct uart_port *port) -- 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 v2] musb: am35x: fix compile error due to control apis
On Tue, 18 Jan 2011 14:15:13 -0500, Ben Gamari wrote: > On Mon, 6 Dec 2010 13:43:31 +0530, Ajay Kumar Gupta > wrote: > > As the control.h have been moved to new location and it's > > uses are not allowed to drivers directly so moving the phy > > control, interrupt clear and reset functionality to board > > files. > > > What happened to the board changes for board-am3517evm? Ping. A response would be appreciated. Cheers, - Ben -- 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] OMAP3EVM: Made backlight GPIO default state to off
> -Original Message- > From: Varadarajan, Charulatha > Sent: Monday, January 24, 2011 8:48 PM > To: Hiremath, Vaibhav > Cc: linux-omap@vger.kernel.org; tomi.valkei...@nokia.com; t...@atomide.com > Subject: Re: [PATCH] OMAP3EVM: Made backlight GPIO default state to off > > On Mon, Jan 24, 2011 at 20:33, Hiremath, Vaibhav wrote: > > > >> -Original Message- > >> From: Varadarajan, Charulatha [mailto:ch...@ti.com] > >> Sent: Monday, January 24, 2011 8:12 PM > >> To: Hiremath, Vaibhav > >> Cc: linux-omap@vger.kernel.org; tomi.valkei...@nokia.com; > t...@atomide.com > >> Subject: Re: [PATCH] OMAP3EVM: Made backlight GPIO default state to off > >> > >> On Mon, Jan 24, 2011 at 20:06, wrote: > >> > From: Vaibhav Hiremath > >> > > >> > If you choose default output to DVI, the LCD backlight stays on, > >> > since panel->disable function never gets called. > >> > > >> > So, during init put backlight GPIO to off state and the driver > >> > code will decide which output to enable. > >> > > >> > Signed-off-by: Vaibhav Hiremath > >> > --- > >> > arch/arm/mach-omap2/board-omap3evm.c | 5 - > >> > 1 files changed, 4 insertions(+), 1 deletions(-) > >> > > >> > diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach- > >> omap2/board-omap3evm.c > >> > index 1b8a806..3f5117a 100644 > >> > --- a/arch/arm/mach-omap2/board-omap3evm.c > >> > +++ b/arch/arm/mach-omap2/board-omap3evm.c > >> > @@ -448,7 +448,10 @@ static int omap3evm_twl_gpio_setup(struct device > >> *dev, > >> > > >> > /* TWL4030_GPIO_MAX + 0 == ledA, LCD Backlight control */ > >> > gpio_request(gpio + TWL4030_GPIO_MAX, "EN_LCD_BKL"); > >> > >> Check for the return value and then only proceed > >> > > [Hiremath, Vaibhav] I do agree with you, we should check the return > value. But just to clarify on this, the line above is not being added be > me. Its original code. > > Yes I noticed. But since you are fixing this part of the code (the > immediate next line), > I thought of mentioning it. > [Hiremath, Vaibhav] Why not handle in separate patch, since there are lots of instances of gpio_xxx where we do not have return check. Let this patch do what is meant to, I will submit another patch for return check where I will try to handle rest of gpio_xxx. Thanks, Vaibhav > > > > I will change the patch and submit it again shortly. > > > > Thanks, > > Vaibhav > >> > - gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0); > >> > + if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2) > >> > + gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1); > >> > >> Check for the return value > >> > >> > + else > >> > + gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0); > >> > >> Ditto > >> > >> > > >> > /* gpio + 7 == DVI Enable */ > >> > gpio_request(gpio + 7, "EN_DVI"); > >> > -- > >> > 1.6.2.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] AM/DM37x: DSS mux configuration for >Rev-B processor cards
> From: satish kumar [mailto:gsatis...@gmail.com] > Sent: Monday, January 24, 2011 8:56 PM > To: Hiremath, Vaibhav > Cc: linux-omap@vger.kernel.org; tomi.valkei...@nokia.com; t...@atomide.com > Subject: Re: [PATCH] AM/DM37x: DSS mux configuration for >Rev-B processor > > cards > Hi This is satish Satish, Very first thing is, no html posting here. > With omap4 processor in samsung board while booting, I am getting > following error. Unfortunately I have not started with OMAP4 yet, so atleast at this point of time will not be able to help you on OMAP4 specific queries. But yes, DSS point of you I should be able to. > "omapdss MANAGER error: mainclk disabled while tryingmgr_apply, > returning " > can you please provide me the solution for the above error. Which kernel version (OR TI release) are you using? I could not able to find this error message in mainline code, so it could be custom implementation. > I am getting one patch with commit Id: commit > d57f72dd11b63eb514d9ea14f8bf79458eccdd37 > but it wont removes my error. This won't help, since I could not able to trace it. Provide complete patch so that we can help. Thanks, Vaibhav > thanks in advance > Satish.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 00/13] OMAP: Basic DVFS Framework
Hi, On Mon, Jan 24, 2011 at 07:55:21PM +0530, Vishwanath Sripathy wrote: > It is not just implementation. Even the underlying design of DVFS is > closely coupled with these layers. If we try to split this DVFS framework > into generic and OMAP specific part, then the flow will become too > cumbersome since there are will be too many interactions between common > and OMAP part. Also it will reduce the code readability aspect as well. > I do not think it's worth adding some much of complexity and effort just > to avoid a driver using platform specific function pointers to call these > APIs. if what you're saying was really true then we wouldn't have generic clock API, pm_runtime, pm QoS, CPUFreq, CPUIdle, etc etc. Those are very much coupled with the underlying Hardware. In fact, every single thing is very much coupled with the underlying hardware. And even so we manage to have all of the above plus GPIOLIB, generic IRQ handling (even threaded), DMA API (which we don't use yet), etc etc etc. So, IMHO, being coupled to underlying HW is not excuse for not making a generic API, quite the opposite actually, it should be a motivation. -- balbi -- 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/13] OMAP: Basic DVFS Framework
On Monday 24 January 2011 15:25:21 Vishwanath Sripathy wrote: > On Monday, January 24, 2011 11:49 AM Felipe Balbi wrote: > > On Mon, Jan 24, 2011 at 11:31:20AM +0530, Vishwanath Sripathy wrote: > > > I do not think DVFS layer can be made a generic layer outside OMAP > > > because of the fact that DVFS is closely coupled with OMAP device layer > > > (for getting hwmod related data and clock handling), OMAP voltage layer > > > (for voltage scaling and handling of dependency voltage domains) and > > > smart reflex layer. > > > > that an implementation detail. If you: > > a. make the DVFS layer so that you need a HW-glue layer which > > will use OMAP-specific APIs; or > > > > b. pass function pointers for the generic DVFS layer to use > > > > (note that I'd rather have option (a)), you solve the problem, no ? > > It is not just implementation. Even the underlying design of DVFS is > closely coupled with these layers. If we try to split this DVFS framework > into generic and OMAP specific part, then the flow will become too > cumbersome since there are will be too many interactions between common > and OMAP part. Also it will reduce the code readability aspect as well. > I do not think it's worth adding some much of complexity and effort just > to avoid a driver using platform specific function pointers to call these > APIs. The issue with callbacks to board code is that they prevent the use of the device tree which is getting introduced on ARM platforms. We should avoid them as much as possible. -- Regards, Laurent Pinchart -- 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] OMAP3EVM: Made backlight GPIO default state to off
On Mon, Jan 24, 2011 at 20:33, Hiremath, Vaibhav wrote: > >> -Original Message- >> From: Varadarajan, Charulatha [mailto:ch...@ti.com] >> Sent: Monday, January 24, 2011 8:12 PM >> To: Hiremath, Vaibhav >> Cc: linux-omap@vger.kernel.org; tomi.valkei...@nokia.com; t...@atomide.com >> Subject: Re: [PATCH] OMAP3EVM: Made backlight GPIO default state to off >> >> On Mon, Jan 24, 2011 at 20:06, wrote: >> > From: Vaibhav Hiremath >> > >> > If you choose default output to DVI, the LCD backlight stays on, >> > since panel->disable function never gets called. >> > >> > So, during init put backlight GPIO to off state and the driver >> > code will decide which output to enable. >> > >> > Signed-off-by: Vaibhav Hiremath >> > --- >> > arch/arm/mach-omap2/board-omap3evm.c | 5 - >> > 1 files changed, 4 insertions(+), 1 deletions(-) >> > >> > diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach- >> omap2/board-omap3evm.c >> > index 1b8a806..3f5117a 100644 >> > --- a/arch/arm/mach-omap2/board-omap3evm.c >> > +++ b/arch/arm/mach-omap2/board-omap3evm.c >> > @@ -448,7 +448,10 @@ static int omap3evm_twl_gpio_setup(struct device >> *dev, >> > >> > /* TWL4030_GPIO_MAX + 0 == ledA, LCD Backlight control */ >> > gpio_request(gpio + TWL4030_GPIO_MAX, "EN_LCD_BKL"); >> >> Check for the return value and then only proceed >> > [Hiremath, Vaibhav] I do agree with you, we should check the return value. > But just to clarify on this, the line above is not being added be me. Its > original code. Yes I noticed. But since you are fixing this part of the code (the immediate next line), I thought of mentioning it. > > I will change the patch and submit it again shortly. > > Thanks, > Vaibhav >> > - gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0); >> > + if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2) >> > + gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1); >> >> Check for the return value >> >> > + else >> > + gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0); >> >> Ditto >> >> > >> > /* gpio + 7 == DVI Enable */ >> > gpio_request(gpio + 7, "EN_DVI"); >> > -- >> > 1.6.2.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] OMAP3EVM:FIX: Reset the SMSC911x Ethernet controller in board_init
> -Original Message-
> From: Varadarajan, Charulatha [mailto:ch...@ti.com]
> Sent: Monday, January 24, 2011 8:32 PM
> To: Hiremath, Vaibhav
> Cc: linux-omap@vger.kernel.org; Hilman, Kevin; t...@atomide.com
> Subject: Re: [PATCH] OMAP3EVM:FIX: Reset the SMSC911x Ethernet controller
> in board_init
>
> On Mon, Jan 24, 2011 at 20:11, wrote:
> > From: Vaibhav Hiremath
> >
>
> Thanks for the patch. I guess this problem was initially reported by
> Kevin.
> So you may consider adding his Reported-by.
>
> > With addition of HWMOD support to GPIO, the Ethernet controller
>
> %s/HWMOD/hwmod
>
[Hiremath, Vaibhav] Ok.
> > goes undetected for OMAP35xEVM. So explicitely assert the reset signal
> to
>
> %s/explicitely/explicitly
>
[Hiremath, Vaibhav] Oops. Perhaps I will have to run spell check before sending
it.
> > Ethernet controller smsc911x -
> >
> > - GPIO7 (>=RevG version of EVM's)
> > - GPIO64 (<=RevD version of EVM's)
> >
> > I have tested this patch on RevG version of EVM with ES3.1 Si.
> > This patch is based on intial version from Charulatha V.
>
> Please add the link for reference. Also please add my SOB if you find
> it relevant.
>
[Hiremath, Vaibhav] Good point, will add it.
> >
> > Signed-off-by: Vaibhav Hiremath
> > ---
> > NOTE: I have not been able to test it on older version of EVM's.
> >
> > arch/arm/mach-omap2/board-omap3evm.c | 27 ++-
> > 1 files changed, 26 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
> omap2/board-omap3evm.c
> > index 212d88c..336c012 100644
> > --- a/arch/arm/mach-omap2/board-omap3evm.c
> > +++ b/arch/arm/mach-omap2/board-omap3evm.c
> > @@ -124,10 +124,15 @@ static struct platform_device
> omap3evm_smsc911x_device = {
> >
> > static inline void __init omap3evm_init_smsc911x(void)
> > {
> > - int eth_cs;
> > + int eth_cs, eth_rst;
> > struct clk *l3ck;
> > unsigned int rate;
> >
> > + if (get_omap3_evm_rev() == OMAP3EVM_BOARD_GEN_1)
> > + eth_rst = 64;
>
> Please define macros and use them.
>
> > + else
> > + eth_rst = 7;
>
> Ditto
>
[Hiremath, Vaibhav] My original code is using macros but I changed it before
submitting to get rid of 2 #defines. But I think it makes sense to have macros,
I will add it and submit it again.
> > +
> > eth_cs = OMAP3EVM_SMSC911X_CS;
> >
> > l3ck = clk_get(NULL, "l3_ck");
> > @@ -136,6 +141,22 @@ static inline void __init
> omap3evm_init_smsc911x(void)
> > else
> > rate = clk_get_rate(l3ck);
> >
> > + /* Configure ethernet controller reset gpio */
> > + if (cpu_is_omap3430()) {
>
> cpu_is_omap3430() is not required, as this board init would not be
> called otherwise.
[Hiremath, Vaibhav] That is not quite true, why do you say this?
>
> > + if (gpio_request(eth_rst, "SMSC911x gpio") < 0) {
> > + pr_err(KERN_ERR "Failed to request GPIO7 for
> smsc911x\n");
> > + return;
> > + }
> > +
> > + gpio_direction_output(eth_rst, 1);
>
> Check for the return value
[Hiremath, Vaibhav] Will do in following version.
Thanks,
Vaibhav
>
> > + /* reset pulse to ethernet controller*/
> > + usleep_range(150, 220);
> > + gpio_set_value(eth_rst, 0);
> > + usleep_range(150, 220);
> > + gpio_set_value(eth_rst, 1);
> > + usleep_range(1, 2);
> > + }
> > +
> > if (gpio_request(OMAP3EVM_ETHR_GPIO_IRQ, "SMSC911x irq") < 0) {
> > printk(KERN_ERR "Failed to request GPIO%d for smsc911x
> IRQ\n",
> > OMAP3EVM_ETHR_GPIO_IRQ);
> > @@ -703,6 +724,10 @@ static struct omap_board_mux omap35x_board_mux[]
> __initdata = {
> > OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
> > OMAP_PIN_OFF_INPUT_PULLUP |
> OMAP_PIN_OFF_OUTPUT_LOW |
> > OMAP_PIN_OFF_WAKEUPENABLE),
> > + OMAP3_MUX(SYS_BOOT5, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
> > + OMAP_PIN_OFF_NONE),
> > + OMAP3_MUX(GPMC_WAIT2, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
> > + OMAP_PIN_OFF_NONE),
> > { .reg_offset = OMAP_MUX_TERMINATOR },
> > };
> >
> > --
> > 1.6.2.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] OMAP3EVM: Made backlight GPIO default state to off
> -Original Message- > From: Varadarajan, Charulatha [mailto:ch...@ti.com] > Sent: Monday, January 24, 2011 8:12 PM > To: Hiremath, Vaibhav > Cc: linux-omap@vger.kernel.org; tomi.valkei...@nokia.com; t...@atomide.com > Subject: Re: [PATCH] OMAP3EVM: Made backlight GPIO default state to off > > On Mon, Jan 24, 2011 at 20:06, wrote: > > From: Vaibhav Hiremath > > > > If you choose default output to DVI, the LCD backlight stays on, > > since panel->disable function never gets called. > > > > So, during init put backlight GPIO to off state and the driver > > code will decide which output to enable. > > > > Signed-off-by: Vaibhav Hiremath > > --- > > arch/arm/mach-omap2/board-omap3evm.c | 5 - > > 1 files changed, 4 insertions(+), 1 deletions(-) > > > > diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach- > omap2/board-omap3evm.c > > index 1b8a806..3f5117a 100644 > > --- a/arch/arm/mach-omap2/board-omap3evm.c > > +++ b/arch/arm/mach-omap2/board-omap3evm.c > > @@ -448,7 +448,10 @@ static int omap3evm_twl_gpio_setup(struct device > *dev, > > > > /* TWL4030_GPIO_MAX + 0 == ledA, LCD Backlight control */ > > gpio_request(gpio + TWL4030_GPIO_MAX, "EN_LCD_BKL"); > > Check for the return value and then only proceed > [Hiremath, Vaibhav] I do agree with you, we should check the return value. But just to clarify on this, the line above is not being added be me. Its original code. I will change the patch and submit it again shortly. Thanks, Vaibhav > > - gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0); > > + if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2) > > + gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1); > > Check for the return value > > > + else > > + gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0); > > Ditto > > > > > /* gpio + 7 == DVI Enable */ > > gpio_request(gpio + 7, "EN_DVI"); > > -- > > 1.6.2.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] OMAP3EVM: Add vio regulator supply required for ads7846 TSC driver
> -Original Message-
> From: Varadarajan, Charulatha [mailto:ch...@ti.com]
> Sent: Monday, January 24, 2011 8:13 PM
> To: Hiremath, Vaibhav
> Cc: linux-omap@vger.kernel.org; t...@atomide.com
> Subject: Re: [PATCH] OMAP3EVM: Add vio regulator supply required for
> ads7846 TSC driver
>
> On Mon, Jan 24, 2011 at 20:02, wrote:
> > From: Vaibhav Hiremath
> >
>
> Please add a patch description.
>
[Hiremath, Vaibhav] I can copy/paste subject line again here, but I thought
subject description is sufficient to explain purpose of patch so did not
mentioned anything here.
Thanks,
Vaibhav
> >
> > Signed-off-by: Vaibhav Hiremath
> > ---
> > arch/arm/mach-omap2/board-omap3evm.c | 20
> > 1 files changed, 20 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
> omap2/board-omap3evm.c
> > index a158d21..ed0311c 100644
> > --- a/arch/arm/mach-omap2/board-omap3evm.c
> > +++ b/arch/arm/mach-omap2/board-omap3evm.c
> > @@ -538,6 +538,25 @@ static struct regulator_init_data omap3_evm_vpll2 =
> {
> > .consumer_supplies = &omap3_evm_vpll2_supply,
> > };
> >
> > +/* ads7846 on SPI */
> > +static struct regulator_consumer_supply omap3evm_vio_supply =
> > + REGULATOR_SUPPLY("vcc", "spi1.0");
> > +
> > +/* VIO for ads7846 */
> > +static struct regulator_init_data omap3evm_vio = {
> > + .constraints = {
> > + .min_uV = 180,
> > + .max_uV = 180,
> > + .apply_uV = true,
> > + .valid_modes_mask = REGULATOR_MODE_NORMAL
> > + | REGULATOR_MODE_STANDBY,
> > + .valid_ops_mask = REGULATOR_CHANGE_MODE
> > + | REGULATOR_CHANGE_STATUS,
> > + },
> > + .num_consumer_supplies = 1,
> > + .consumer_supplies = &omap3evm_vio_supply,
> > +};
> > +
> > static struct twl4030_platform_data omap3evm_twldata = {
> > .irq_base = TWL4030_IRQ_BASE,
> > .irq_end = TWL4030_IRQ_END,
> > @@ -550,6 +569,7 @@ static struct twl4030_platform_data omap3evm_twldata
> = {
> > .codec = &omap3evm_codec_data,
> > .vdac = &omap3_evm_vdac,
> > .vpll2 = &omap3_evm_vpll2,
> > + .vio = &omap3evm_vio,
> > };
> >
> > static struct i2c_board_info __initdata omap3evm_i2c_boardinfo[] = {
> > --
> > 1.6.2.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] OMAP3EVM:FIX: Reset the SMSC911x Ethernet controller in board_init
On Mon, Jan 24, 2011 at 20:11, wrote:
> From: Vaibhav Hiremath
>
Thanks for the patch. I guess this problem was initially reported by Kevin.
So you may consider adding his Reported-by.
> With addition of HWMOD support to GPIO, the Ethernet controller
%s/HWMOD/hwmod
> goes undetected for OMAP35xEVM. So explicitely assert the reset signal to
%s/explicitely/explicitly
> Ethernet controller smsc911x -
>
> - GPIO7 (>=RevG version of EVM's)
> - GPIO64 (<=RevD version of EVM's)
>
> I have tested this patch on RevG version of EVM with ES3.1 Si.
> This patch is based on intial version from Charulatha V.
Please add the link for reference. Also please add my SOB if you find
it relevant.
>
> Signed-off-by: Vaibhav Hiremath
> ---
> NOTE: I have not been able to test it on older version of EVM's.
>
> arch/arm/mach-omap2/board-omap3evm.c | 27 ++-
> 1 files changed, 26 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap3evm.c
> b/arch/arm/mach-omap2/board-omap3evm.c
> index 212d88c..336c012 100644
> --- a/arch/arm/mach-omap2/board-omap3evm.c
> +++ b/arch/arm/mach-omap2/board-omap3evm.c
> @@ -124,10 +124,15 @@ static struct platform_device omap3evm_smsc911x_device
> = {
>
> static inline void __init omap3evm_init_smsc911x(void)
> {
> - int eth_cs;
> + int eth_cs, eth_rst;
> struct clk *l3ck;
> unsigned int rate;
>
> + if (get_omap3_evm_rev() == OMAP3EVM_BOARD_GEN_1)
> + eth_rst = 64;
Please define macros and use them.
> + else
> + eth_rst = 7;
Ditto
> +
> eth_cs = OMAP3EVM_SMSC911X_CS;
>
> l3ck = clk_get(NULL, "l3_ck");
> @@ -136,6 +141,22 @@ static inline void __init omap3evm_init_smsc911x(void)
> else
> rate = clk_get_rate(l3ck);
>
> + /* Configure ethernet controller reset gpio */
> + if (cpu_is_omap3430()) {
cpu_is_omap3430() is not required, as this board init would not be
called otherwise.
> + if (gpio_request(eth_rst, "SMSC911x gpio") < 0) {
> + pr_err(KERN_ERR "Failed to request GPIO7 for
> smsc911x\n");
> + return;
> + }
> +
> + gpio_direction_output(eth_rst, 1);
Check for the return value
> + /* reset pulse to ethernet controller*/
> + usleep_range(150, 220);
> + gpio_set_value(eth_rst, 0);
> + usleep_range(150, 220);
> + gpio_set_value(eth_rst, 1);
> + usleep_range(1, 2);
> + }
> +
> if (gpio_request(OMAP3EVM_ETHR_GPIO_IRQ, "SMSC911x irq") < 0) {
> printk(KERN_ERR "Failed to request GPIO%d for smsc911x IRQ\n",
> OMAP3EVM_ETHR_GPIO_IRQ);
> @@ -703,6 +724,10 @@ static struct omap_board_mux omap35x_board_mux[]
> __initdata = {
> OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
> OMAP_PIN_OFF_INPUT_PULLUP |
> OMAP_PIN_OFF_OUTPUT_LOW |
> OMAP_PIN_OFF_WAKEUPENABLE),
> + OMAP3_MUX(SYS_BOOT5, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
> + OMAP_PIN_OFF_NONE),
> + OMAP3_MUX(GPMC_WAIT2, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
> + OMAP_PIN_OFF_NONE),
> { .reg_offset = OMAP_MUX_TERMINATOR },
> };
>
> --
> 1.6.2.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/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
On Mon, Jan 24, 2011 at 08:24:41PM +0530, Poddar, Sourav wrote: > nfs filesystem. Thanks. -- 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:board-omap3evm: Change TWL related gpio API's to gpio*_cansleep
On Mon, Jan 24, 2011 at 20:01, wrote:
> From: Vaibhav Hiremath
>
> Since TWL GPIO's can go into sleep, and using normal
> gpio_get/set_value() API will lead to kernel dump (WARN_ON()).
> So replacing standard gpio_get/set_value() to
> gpio_get_set_value_cansleep().
>
> Signed-off-by: Vaibhav Hiremath
Reviewed-by: Charulatha V ---
> arch/arm/mach-omap2/board-omap3evm.c | 12 ++--
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap3evm.c
> b/arch/arm/mach-omap2/board-omap3evm.c
> index 323c380..a158d21 100644
> --- a/arch/arm/mach-omap2/board-omap3evm.c
> +++ b/arch/arm/mach-omap2/board-omap3evm.c
> @@ -235,9 +235,9 @@ static int omap3_evm_enable_lcd(struct omap_dss_device
> *dssdev)
> gpio_set_value(OMAP3EVM_LCD_PANEL_ENVDD, 0);
>
> if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2)
> - gpio_set_value(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 0);
> + gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 0);
> else
> - gpio_set_value(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 1);
> + gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 1);
>
> lcd_enabled = 1;
> return 0;
> @@ -248,9 +248,9 @@ static void omap3_evm_disable_lcd(struct omap_dss_device
> *dssdev)
> gpio_set_value(OMAP3EVM_LCD_PANEL_ENVDD, 1);
>
> if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2)
> - gpio_set_value(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 1);
> + gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 1);
> else
> - gpio_set_value(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 0);
> + gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 0);
>
> lcd_enabled = 0;
> }
> @@ -289,7 +289,7 @@ static int omap3_evm_enable_dvi(struct omap_dss_device
> *dssdev)
> return -EINVAL;
> }
>
> - gpio_set_value(OMAP3EVM_DVI_PANEL_EN_GPIO, 1);
> + gpio_set_value_cansleep(OMAP3EVM_DVI_PANEL_EN_GPIO, 1);
>
> dvi_enabled = 1;
> return 0;
> @@ -297,7 +297,7 @@ static int omap3_evm_enable_dvi(struct omap_dss_device
> *dssdev)
>
> static void omap3_evm_disable_dvi(struct omap_dss_device *dssdev)
> {
> - gpio_set_value(OMAP3EVM_DVI_PANEL_EN_GPIO, 0);
> + gpio_set_value_cansleep(OMAP3EVM_DVI_PANEL_EN_GPIO, 0);
>
> dvi_enabled = 0;
> }
> --
> 1.6.2.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
>
--
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
Jean
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of jean.pi...@newoldbits.com
> Sent: Monday, January 24, 2011 7:51 PM
> To: Thomas Renninger; linux-omap@vger.kernel.org
> Cc: Jean Pihet
> Subject: [PATCH] perf: add OMAP support for the new power events
>
> From: Jean Pihet
>
> The patch adds the new power management trace points for
> the OMAP architecture.
>
> 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),
> - change of power domains next power states.
>
> Tested on OMAP3 with suspend/resume, cpuidle, basic DVFS
>
[]
> diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach-
> omap2/powerdomain.c
> index eaed0df..e1feb50 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"
> @@ -406,8 +409,11 @@ int pwrdm_set_next_pwrst(struct powerdomain
> *pwrdm, u8 pwrst)
> pr_debug("powerdomain: setting next powerstate for %s to
> %0x\n",
>pwrdm->name, pwrst);
>
> - if (arch_pwrdm && arch_pwrdm->pwrdm_set_next_pwrst)
> + if (arch_pwrdm && arch_pwrdm->pwrdm_set_next_pwrst) {
> + trace_power_domain_target(pwrdm->name, pwrst,
> + smp_processor_id());
> ret = arch_pwrdm->pwrdm_set_next_pwrst(pwrdm, pwrst);
> + }
>
> return ret;
> }
We need to track the actual power domain transitions as well
at hardware level.
Can you please look at "pwrdm_pre_transition()" and
"pwrdm_post_transition()"
This code keep track of it using the next power state
and prev-power state.
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: [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
On Mon, Jan 24, 2011 at 7:41 PM, Russell King - ARM Linux wrote: > On Mon, Jan 24, 2011 at 07:17:54PM +0530, Poddar, Sourav wrote: >> On Mon, Jan 24, 2011 at 3:58 PM, Russell King - ARM Linux >> wrote: >> > On Mon, Jan 24, 2011 at 02:27:24PM +0530, Poddar, Sourav wrote: >> >> On Mon, Jan 24, 2011 at 2:08 PM, Poddar, Sourav >> >> wrote: >> >> > On Sun, Jan 23, 2011 at 3:05 PM, Russell King - ARM Linux >> >> > wrote: >> >> >> On Sat, Jan 22, 2011 at 11:44:59PM -0500, Nicolas Pitre wrote: >> >> >>> At least another person did post results: >> >> >>> >> >> >>> http://mid.gmane.org/20110117094602.ga2...@pulham.picochip.com >> >> >>> http://mid.gmane.org/20110117110308.gc2...@pulham.picochip.com >> >> >> >> >> >> Slightly different patch - there were three revisions. I can't attach >> >> >> a tested-by given to a different patch to this one. >> >> >> >> >> >>> > That means omap2plus_defconfig .38 mainline kernels >> >> >>> > (including -stable) will remain potentially dangerous when run on >> >> >>> > SMP capable hardware. >> >> >>> >> >> >>> I must admit that this series looks a bit large for stable IMHO. I >> >> >>> think that the fix for stable should limit itself only to prevent SMP >> >> >>> from being selected if anything else than CPU_32v6K is selected. >> >> >> >> >> >> The first three are the bare minimum required for -stable. >> >> >> >> >> > >> >> >> >> Boot tested the 14 patch series with CONFIG_SWP_EMULATE enabled, on >> >> the following boards : >> >> >> >> >> >> 1. Omap2420 SDP >> >> >> >> 2. Omap2430 SDP >> >> >> >> 3. Omap3430 SDP >> >> >> >> 4. Omap4 Blaze >> >> >> >> Tested-by: Sourav Poddar >> > >> > Thanks. It's also important to ascertain which filesystems were tested - >> > could you let me know please? >> > >> >> It is a custom filesystem on BusyBox v1.17.2. > > So you wrote code under fs/ for this filesystem? No. >> Please let me know if you need some other >> information. > > I'm trying to find out what _type_ of filesystem. ext2, ext3, nfs, cramfs, > etc. > nfs filesystem. -- 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] OMAP3EVM: Add vio regulator supply required for ads7846 TSC driver
On Mon, Jan 24, 2011 at 20:02, wrote:
> From: Vaibhav Hiremath
>
Please add a patch description.
>
> Signed-off-by: Vaibhav Hiremath
> ---
> arch/arm/mach-omap2/board-omap3evm.c | 20
> 1 files changed, 20 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap3evm.c
> b/arch/arm/mach-omap2/board-omap3evm.c
> index a158d21..ed0311c 100644
> --- a/arch/arm/mach-omap2/board-omap3evm.c
> +++ b/arch/arm/mach-omap2/board-omap3evm.c
> @@ -538,6 +538,25 @@ static struct regulator_init_data omap3_evm_vpll2 = {
> .consumer_supplies = &omap3_evm_vpll2_supply,
> };
>
> +/* ads7846 on SPI */
> +static struct regulator_consumer_supply omap3evm_vio_supply =
> + REGULATOR_SUPPLY("vcc", "spi1.0");
> +
> +/* VIO for ads7846 */
> +static struct regulator_init_data omap3evm_vio = {
> + .constraints = {
> + .min_uV = 180,
> + .max_uV = 180,
> + .apply_uV = true,
> + .valid_modes_mask = REGULATOR_MODE_NORMAL
> + | REGULATOR_MODE_STANDBY,
> + .valid_ops_mask = REGULATOR_CHANGE_MODE
> + | REGULATOR_CHANGE_STATUS,
> + },
> + .num_consumer_supplies = 1,
> + .consumer_supplies = &omap3evm_vio_supply,
> +};
> +
> static struct twl4030_platform_data omap3evm_twldata = {
> .irq_base = TWL4030_IRQ_BASE,
> .irq_end = TWL4030_IRQ_END,
> @@ -550,6 +569,7 @@ static struct twl4030_platform_data omap3evm_twldata = {
> .codec = &omap3evm_codec_data,
> .vdac = &omap3_evm_vdac,
> .vpll2 = &omap3_evm_vpll2,
> + .vio = &omap3evm_vio,
> };
>
> static struct i2c_board_info __initdata omap3evm_i2c_boardinfo[] = {
> --
> 1.6.2.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] OMAP3EVM: Made backlight GPIO default state to off
On Mon, Jan 24, 2011 at 20:06, wrote: > From: Vaibhav Hiremath > > If you choose default output to DVI, the LCD backlight stays on, > since panel->disable function never gets called. > > So, during init put backlight GPIO to off state and the driver > code will decide which output to enable. > > Signed-off-by: Vaibhav Hiremath > --- > arch/arm/mach-omap2/board-omap3evm.c | 5 - > 1 files changed, 4 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/mach-omap2/board-omap3evm.c > b/arch/arm/mach-omap2/board-omap3evm.c > index 1b8a806..3f5117a 100644 > --- a/arch/arm/mach-omap2/board-omap3evm.c > +++ b/arch/arm/mach-omap2/board-omap3evm.c > @@ -448,7 +448,10 @@ static int omap3evm_twl_gpio_setup(struct device *dev, > > /* TWL4030_GPIO_MAX + 0 == ledA, LCD Backlight control */ > gpio_request(gpio + TWL4030_GPIO_MAX, "EN_LCD_BKL"); Check for the return value and then only proceed > - gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0); > + if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2) > + gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1); Check for the return value > + else > + gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0); Ditto > > /* gpio + 7 == DVI Enable */ > gpio_request(gpio + 7, "EN_DVI"); > -- > 1.6.2.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
[PATCH] OMAP3EVM:FIX: Reset the SMSC911x Ethernet controller in board_init
From: Vaibhav Hiremath
With addition of HWMOD support to GPIO, the Ethernet controller
goes undetected for OMAP35xEVM. So explicitely assert the reset signal to
Ethernet controller smsc911x -
- GPIO7 (>=RevG version of EVM's)
- GPIO64 (<=RevD version of EVM's)
I have tested this patch on RevG version of EVM with ES3.1 Si.
This patch is based on intial version from Charulatha V.
Signed-off-by: Vaibhav Hiremath
---
NOTE: I have not been able to test it on older version of EVM's.
arch/arm/mach-omap2/board-omap3evm.c | 27 ++-
1 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 212d88c..336c012 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -124,10 +124,15 @@ static struct platform_device omap3evm_smsc911x_device = {
static inline void __init omap3evm_init_smsc911x(void)
{
- int eth_cs;
+ int eth_cs, eth_rst;
struct clk *l3ck;
unsigned int rate;
+ if (get_omap3_evm_rev() == OMAP3EVM_BOARD_GEN_1)
+ eth_rst = 64;
+ else
+ eth_rst = 7;
+
eth_cs = OMAP3EVM_SMSC911X_CS;
l3ck = clk_get(NULL, "l3_ck");
@@ -136,6 +141,22 @@ static inline void __init omap3evm_init_smsc911x(void)
else
rate = clk_get_rate(l3ck);
+ /* Configure ethernet controller reset gpio */
+ if (cpu_is_omap3430()) {
+ if (gpio_request(eth_rst, "SMSC911x gpio") < 0) {
+ pr_err(KERN_ERR "Failed to request GPIO7 for
smsc911x\n");
+ return;
+ }
+
+ gpio_direction_output(eth_rst, 1);
+ /* reset pulse to ethernet controller*/
+ usleep_range(150, 220);
+ gpio_set_value(eth_rst, 0);
+ usleep_range(150, 220);
+ gpio_set_value(eth_rst, 1);
+ usleep_range(1, 2);
+ }
+
if (gpio_request(OMAP3EVM_ETHR_GPIO_IRQ, "SMSC911x irq") < 0) {
printk(KERN_ERR "Failed to request GPIO%d for smsc911x IRQ\n",
OMAP3EVM_ETHR_GPIO_IRQ);
@@ -703,6 +724,10 @@ static struct omap_board_mux omap35x_board_mux[]
__initdata = {
OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
OMAP_PIN_OFF_INPUT_PULLUP |
OMAP_PIN_OFF_OUTPUT_LOW |
OMAP_PIN_OFF_WAKEUPENABLE),
+ OMAP3_MUX(SYS_BOOT5, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
+ OMAP_PIN_OFF_NONE),
+ OMAP3_MUX(GPMC_WAIT2, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
+ OMAP_PIN_OFF_NONE),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
--
1.6.2.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
[PATCH] OMAP3EVM: Made backlight GPIO default state to off
From: Vaibhav Hiremath If you choose default output to DVI, the LCD backlight stays on, since panel->disable function never gets called. So, during init put backlight GPIO to off state and the driver code will decide which output to enable. Signed-off-by: Vaibhav Hiremath --- arch/arm/mach-omap2/board-omap3evm.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c index 1b8a806..3f5117a 100644 --- a/arch/arm/mach-omap2/board-omap3evm.c +++ b/arch/arm/mach-omap2/board-omap3evm.c @@ -448,7 +448,10 @@ static int omap3evm_twl_gpio_setup(struct device *dev, /* TWL4030_GPIO_MAX + 0 == ledA, LCD Backlight control */ gpio_request(gpio + TWL4030_GPIO_MAX, "EN_LCD_BKL"); - gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0); + if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2) + gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1); + else + gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0); /* gpio + 7 == DVI Enable */ gpio_request(gpio + 7, "EN_DVI"); -- 1.6.2.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
[PATCH] AM/DM37x: DSS mux configuration for >Rev-B processor cards
From: Vaibhav Hiremath
To support higher resolution (e.g 720P@60), on OMAP36x (AM/DM37x)
DSS data bus has been muxed with sys_boot pins.
DSS[18-23] => DSS[0-5]
sys_boot[0,1 3-5] => DSS[18-23]
EVM revision >=RevB adopt this mux changes, which is going to ship outside.
Signed-off-by: Vaibhav Hiremath
---
arch/arm/mach-omap2/board-omap3evm.c | 34 --
1 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 107b1f8..1b8a806 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -693,7 +693,7 @@ static struct ehci_hcd_omap_platform_data ehci_pdata
__initdata = {
};
#ifdef CONFIG_OMAP_MUX
-static struct omap_board_mux board_mux[] __initdata = {
+static struct omap_board_mux omap35x_board_mux[] __initdata = {
OMAP3_MUX(SYS_NIRQ, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP |
OMAP_PIN_OFF_INPUT_PULLUP |
OMAP_PIN_OFF_OUTPUT_LOW |
OMAP_PIN_OFF_WAKEUPENABLE),
@@ -701,6 +701,32 @@ static struct omap_board_mux board_mux[] __initdata = {
OMAP_PIN_OFF_INPUT_PULLUP |
OMAP_PIN_OFF_OUTPUT_LOW),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
+
+static struct omap_board_mux omap36x_board_mux[] __initdata = {
+ OMAP3_MUX(SYS_NIRQ, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP |
+ OMAP_PIN_OFF_INPUT_PULLUP |
OMAP_PIN_OFF_OUTPUT_LOW |
+ OMAP_PIN_OFF_WAKEUPENABLE),
+ OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
+ OMAP_PIN_OFF_INPUT_PULLUP |
OMAP_PIN_OFF_OUTPUT_LOW),
+ /* AM/DM37x EVM: DSS data bus muxed with sys_boot */
+ OMAP3_MUX(DSS_DATA18, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
+ OMAP3_MUX(DSS_DATA19, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
+ OMAP3_MUX(DSS_DATA22, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
+ OMAP3_MUX(DSS_DATA21, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
+ OMAP3_MUX(DSS_DATA22, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
+ OMAP3_MUX(DSS_DATA23, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
+ OMAP3_MUX(SYS_BOOT0, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
+ OMAP3_MUX(SYS_BOOT1, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
+ OMAP3_MUX(SYS_BOOT3, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
+ OMAP3_MUX(SYS_BOOT4, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
+ OMAP3_MUX(SYS_BOOT5, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
+ OMAP3_MUX(SYS_BOOT6, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
+
+ { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#else
+#define omap35x_board_mux NULL
+#define omap36x_board_mux NULL
#endif
static struct omap_musb_board_data musb_board_data = {
@@ -712,7 +738,11 @@ static struct omap_musb_board_data musb_board_data = {
static void __init omap3_evm_init(void)
{
omap3_evm_get_revision();
- omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+
+ if (cpu_is_omap3630())
+ omap3_mux_init(omap36x_board_mux, OMAP_PACKAGE_CBB);
+ else
+ omap3_mux_init(omap35x_board_mux, OMAP_PACKAGE_CBB);
omap3_evm_i2c_init();
--
1.6.2.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
[PATCH] OMAP3EVM: Add vio regulator supply required for ads7846 TSC driver
From: Vaibhav Hiremath
Signed-off-by: Vaibhav Hiremath
---
arch/arm/mach-omap2/board-omap3evm.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index a158d21..ed0311c 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -538,6 +538,25 @@ static struct regulator_init_data omap3_evm_vpll2 = {
.consumer_supplies = &omap3_evm_vpll2_supply,
};
+/* ads7846 on SPI */
+static struct regulator_consumer_supply omap3evm_vio_supply =
+ REGULATOR_SUPPLY("vcc", "spi1.0");
+
+/* VIO for ads7846 */
+static struct regulator_init_data omap3evm_vio = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = &omap3evm_vio_supply,
+};
+
static struct twl4030_platform_data omap3evm_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
@@ -550,6 +569,7 @@ static struct twl4030_platform_data omap3evm_twldata = {
.codec = &omap3evm_codec_data,
.vdac = &omap3_evm_vdac,
.vpll2 = &omap3_evm_vpll2,
+ .vio= &omap3evm_vio,
};
static struct i2c_board_info __initdata omap3evm_i2c_boardinfo[] = {
--
1.6.2.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
[PATCH] OMAP:board-omap3evm: Change TWL related gpio API's to gpio*_cansleep
From: Vaibhav Hiremath
Since TWL GPIO's can go into sleep, and using normal
gpio_get/set_value() API will lead to kernel dump (WARN_ON()).
So replacing standard gpio_get/set_value() to
gpio_get_set_value_cansleep().
Signed-off-by: Vaibhav Hiremath
---
arch/arm/mach-omap2/board-omap3evm.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 323c380..a158d21 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -235,9 +235,9 @@ static int omap3_evm_enable_lcd(struct omap_dss_device
*dssdev)
gpio_set_value(OMAP3EVM_LCD_PANEL_ENVDD, 0);
if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2)
- gpio_set_value(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 0);
+ gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 0);
else
- gpio_set_value(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 1);
+ gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 1);
lcd_enabled = 1;
return 0;
@@ -248,9 +248,9 @@ static void omap3_evm_disable_lcd(struct omap_dss_device
*dssdev)
gpio_set_value(OMAP3EVM_LCD_PANEL_ENVDD, 1);
if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2)
- gpio_set_value(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 1);
+ gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 1);
else
- gpio_set_value(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 0);
+ gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 0);
lcd_enabled = 0;
}
@@ -289,7 +289,7 @@ static int omap3_evm_enable_dvi(struct omap_dss_device
*dssdev)
return -EINVAL;
}
- gpio_set_value(OMAP3EVM_DVI_PANEL_EN_GPIO, 1);
+ gpio_set_value_cansleep(OMAP3EVM_DVI_PANEL_EN_GPIO, 1);
dvi_enabled = 1;
return 0;
@@ -297,7 +297,7 @@ static int omap3_evm_enable_dvi(struct omap_dss_device
*dssdev)
static void omap3_evm_disable_dvi(struct omap_dss_device *dssdev)
{
- gpio_set_value(OMAP3EVM_DVI_PANEL_EN_GPIO, 0);
+ gpio_set_value_cansleep(OMAP3EVM_DVI_PANEL_EN_GPIO, 0);
dvi_enabled = 0;
}
--
1.6.2.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: [RFC/PATCH] OMAP3: run the ASM sleep code from DDR
On Thu, Jan 13, 2011 at 5:19 PM, wrote:
> From: Jean Pihet
>
> Most of the ASM sleep code (in arch/arm/mach-omap2/sleep34xx.S)
> is copied to internal SRAM and run from there.
> However only a small part of the code really needs to run from internal SRAM.
>
> This fix lets most of the ASM idle code run from the DDR
> in order to minimize the SRAM usage. No performance
> loss or gain can be measured with a 32KHz clock period.
>
> The only pieces of code that are mandatory in SRAM
> are:
> - the i443 erratum WA,
> - the i581 erratum WA,
> - the security extension code.
>
> SRAM usage:
> - original code:
> . 560 bytes for omap3_sram_configure_core_dpll (used by DVFS),
> . 1368 bytes for omap_sram_idle (used by suspend/resume in RETention),
> . 124 bytes for es3_sdrc_fix (used by suspend/resume in OFF mode on ES3.x),
> . 108 bytes for save_secure_ram_context (used on HS parts).
>
> With this fix the usage for suspend/resume in RETention goes down 312 bytes,
> so the
> gain in SRAM usage for suspend/resume is > 1KB.
>
> Tested on OMAP3EVM, Beagleboard (ES2.x) and N900 (ES3.1)
> in idle with full RET and OFF modes.
>
> Signed-off-by: Jean Pihet
Is there any feedback on this code?
This change would need some more testing on all OMAP3 platforms,
especially on the 36xx platforms that I do not have at hand.
Comments are welcome!
Regards,
Jean
> ---
> arch/arm/mach-omap2/pm.h | 19 ++-
> arch/arm/mach-omap2/pm34xx.c | 19 ++-
> arch/arm/mach-omap2/sleep34xx.S | 299
> +++
> 3 files changed, 200 insertions(+), 137 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
> index 1c1b0ab..ae9dec0 100644
> --- a/arch/arm/mach-omap2/pm.h
> +++ b/arch/arm/mach-omap2/pm.h
> @@ -87,18 +87,29 @@ extern int pm_dbg_regset_init(int reg_set);
> #define pm_dbg_regset_init(reg_set) do {} while (0);
> #endif /* CONFIG_PM_DEBUG */
>
> +/* 24xx */
> extern void omap24xx_idle_loop_suspend(void);
> +extern unsigned int omap24xx_idle_loop_suspend_sz;
>
> extern void omap24xx_cpu_suspend(u32 dll_ctrl, void __iomem *sdrc_dlla_ctrl,
> void __iomem *sdrc_power);
> +extern unsigned int omap24xx_cpu_suspend_sz;
> +
> +/* 3xxx */
> extern void omap34xx_cpu_suspend(u32 *addr, int save_state);
> +
> +/* omap3_do_wfi function pointer and size, for copy to SRAM */
> +extern void omap3_do_wfi(void);
> +extern unsigned int omap3_do_wfi_sz;
> +/* ... and its pointer from SRAM after copy */
> +extern void (*omap3_do_wfi_sram)(void);
> +
> +/* save_secure_ram_context function pointer and size, for copy to SRAM */
> extern void save_secure_ram_context(u32 *addr);
> -extern void omap3_save_scratchpad_contents(void);
>
> -extern unsigned int omap24xx_idle_loop_suspend_sz;
> extern unsigned int save_secure_ram_context_sz;
> -extern unsigned int omap24xx_cpu_suspend_sz;
> -extern unsigned int omap34xx_cpu_suspend_sz;
> +
> +extern void omap3_save_scratchpad_contents(void);
>
> #define PM_RTA_ERRATUM_i608 (1 << 0)
> #define PM_SDRC_WAKEUP_ERRATUM_i583 (1 << 1)
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index 5b323f2..56ca3cb 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -82,9 +82,8 @@ struct power_state {
>
> static LIST_HEAD(pwrst_list);
>
> -static void (*_omap_sram_idle)(u32 *addr, int save_state);
> -
> static int (*_omap_save_secure_sram)(u32 *addr);
> +void (*omap3_do_wfi_sram)(void);
>
> static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
> static struct powerdomain *core_pwrdm, *per_pwrdm;
> @@ -355,9 +354,6 @@ void omap_sram_idle(void)
> int core_prev_state, per_prev_state;
> u32 sdrc_pwr = 0;
>
> - if (!_omap_sram_idle)
> - return;
> -
> pwrdm_clear_all_prev_pwrst(mpu_pwrdm);
> pwrdm_clear_all_prev_pwrst(neon_pwrdm);
> pwrdm_clear_all_prev_pwrst(core_pwrdm);
> @@ -439,7 +435,7 @@ void omap_sram_idle(void)
> * get saved. The restore path then reads from this
> * location and restores them back.
> */
> - _omap_sram_idle(omap3_arm_context, save_state);
> + omap34xx_cpu_suspend(omap3_arm_context, save_state);
> cpu_init();
>
> /* Restore normal SDRC POWER settings */
> @@ -996,10 +992,17 @@ static int __init clkdms_setup(struct clockdomain
> *clkdm, void *unused)
> return 0;
> }
>
> +/*
> + * Push functions to SRAM
> + *
> + * The minimum set of functions is pushed to SRAM for execution:
> + * - omap3_do_wfi for erratum i581 WA,
> + * - save_secure_ram_context for security extensions.
> + */
> void omap_push_sram_idle(void)
> {
> - _omap_sram_idle = omap_sram_push(omap34xx_cpu_suspend,
> - omap34xx_cpu_suspend_sz);
> + omap3_do_wfi_sram = omap_sram_push(omap3_do_wfi, omap3_do_wfi_sz);
> +
> if (omap_type() != OMAP2_DEVICE_TYPE_GP)
> _omap_save
RE: [PATCH 00/13] OMAP: Basic DVFS Framework
Balbi, > -Original Message- > From: Felipe Balbi [mailto:ba...@ti.com] > Sent: Monday, January 24, 2011 11:49 AM > To: Vishwanath Sripathy > Cc: ba...@ti.com; linux-omap@vger.kernel.org; patc...@linaro.org > Subject: Re: [PATCH 00/13] OMAP: Basic DVFS Framework > > Hi, > > On Mon, Jan 24, 2011 at 11:31:20AM +0530, Vishwanath Sripathy > wrote: > > I do not think DVFS layer can be made a generic layer outside OMAP > because > > of the fact that DVFS is closely coupled with OMAP device layer (for > > getting hwmod related data and clock handling), OMAP voltage layer > (for > > voltage scaling and handling of dependency voltage domains) and > smart > > reflex layer. > > that an implementation detail. If you: > > a. make the DVFS layer so that you need a HW-glue layer which > will use OMAP-specific APIs; or > > b. pass function pointers for the generic DVFS layer to use > > (note that I'd rather have option (a)), you solve the problem, no ? It is not just implementation. Even the underlying design of DVFS is closely coupled with these layers. If we try to split this DVFS framework into generic and OMAP specific part, then the flow will become too cumbersome since there are will be too many interactions between common and OMAP part. Also it will reduce the code readability aspect as well. I do not think it's worth adding some much of complexity and effort just to avoid a driver using platform specific function pointers to call these APIs. Vishwa > > -- > balbi -- 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] perf: add OMAP support for the new power events
From: Jean Pihet
The patch adds the new power management trace points for
the OMAP architecture.
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),
- change of power domains next power states.
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 |8 +++-
3 files changed, 21 insertions(+), 2 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 8cbbead..7c5e0ee 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"
@@ -518,8 +519,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..e1feb50 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"
@@ -406,8 +409,11 @@ int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8
pwrst)
pr_debug("powerdomain: setting next powerstate for %s to %0x\n",
pwrdm->name, pwrst);
- if (arch_pwrdm && arch_pwrdm->pwrdm_set_next_pwrst)
+ if (arch_pwrdm && arch_pwrdm->pwrdm_set_next_pwrst) {
+ trace_power_domain_target(pwrdm->name, pwrst,
+ smp_processor_id());
ret = arch_pwrdm->pwrdm_set_next_pwrst(pwrdm, pwrst);
+ }
return ret;
}
--
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
Re: [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
On Mon, Jan 24, 2011 at 07:17:54PM +0530, Poddar, Sourav wrote: > On Mon, Jan 24, 2011 at 3:58 PM, Russell King - ARM Linux > wrote: > > On Mon, Jan 24, 2011 at 02:27:24PM +0530, Poddar, Sourav wrote: > >> On Mon, Jan 24, 2011 at 2:08 PM, Poddar, Sourav > >> wrote: > >> > On Sun, Jan 23, 2011 at 3:05 PM, Russell King - ARM Linux > >> > wrote: > >> >> On Sat, Jan 22, 2011 at 11:44:59PM -0500, Nicolas Pitre wrote: > >> >>> At least another person did post results: > >> >>> > >> >>> http://mid.gmane.org/20110117094602.ga2...@pulham.picochip.com > >> >>> http://mid.gmane.org/20110117110308.gc2...@pulham.picochip.com > >> >> > >> >> Slightly different patch - there were three revisions. I can't attach > >> >> a tested-by given to a different patch to this one. > >> >> > >> >>> > That means omap2plus_defconfig .38 mainline kernels > >> >>> > (including -stable) will remain potentially dangerous when run on > >> >>> > SMP capable hardware. > >> >>> > >> >>> I must admit that this series looks a bit large for stable IMHO. I > >> >>> think that the fix for stable should limit itself only to prevent SMP > >> >>> from being selected if anything else than CPU_32v6K is selected. > >> >> > >> >> The first three are the bare minimum required for -stable. > >> >> > >> > > >> > >> Boot tested the 14 patch series with CONFIG_SWP_EMULATE enabled, on > >> the following boards : > >> > >> > >> 1. Omap2420 SDP > >> > >> 2. Omap2430 SDP > >> > >> 3. Omap3430 SDP > >> > >> 4. Omap4 Blaze > >> > >> Tested-by: Sourav Poddar > > > > Thanks. It's also important to ascertain which filesystems were tested - > > could you let me know please? > > > > It is a custom filesystem on BusyBox v1.17.2. So you wrote code under fs/ for this filesystem? > Please let me know if you need some other > information. I'm trying to find out what _type_ of filesystem. ext2, ext3, nfs, cramfs, etc. -- 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] ARM: Thumb-2: Symbol manipulation macros for function body copying
Hi Dave, On Mon, Jan 24, 2011 at 2:50 PM, Dave Martin wrote: > On Thu, Jan 20, 2011 at 9:42 AM, Dave Martin wrote: >> On Wed, Jan 19, 2011 at 10:29 PM, Kevin Hilman wrote: >>> Dave Martin writes: >>> In low-level board support code, there is sometimes a need to copy a function body to another location at run-time. A straightforward call to memcpy doesn't work in Thumb-2, because bit 0 of external Thumb function symbols is set to 1, indicating that the function is Thumb. Without corrective measures, this will cause an off-by-one copy, and the copy may be called using the wrong instruction set. This patch adds an fncpy() macro to help with such copies. Particular care is needed, because C doesn't guarantee any defined behaviour when casting a function pointer to any other type. This has been observed to lead to strange optimisation side-effects when doing the arithmetic which is required in order to copy/move function bodies correctly in Thumb-2. Thanks to Russell King and Nicolas Pitre for their input on this patch. Signed-off-by: Dave Martin Tested-by: Jean Pihet >>> >>> Tested-by: Kevin Hilman >>> >>> along with Jean's OMAP patch on: >>> >>> OMAP2420/n810: including basic suspend/resume test. >>> >>> OMAP16xx/OSK: boot test only. >>> >>> Kevin >>> >> >> Thanks >> ---Dave >> > > Any more comments on this patch? > > I have no further changes so far. Ok to me. The changes are now in the omap-testing branch of Tony's tree [1]. [1] http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=shortlog;h=refs/heads/omap-testing Regards, Jean > > Cheers > ---Dave > -- > 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 v4] ARM: Thumb-2: Symbol manipulation macros for function body copying
On Thu, Jan 20, 2011 at 9:42 AM, Dave Martin wrote: > On Wed, Jan 19, 2011 at 10:29 PM, Kevin Hilman wrote: >> Dave Martin writes: >> >>> In low-level board support code, there is sometimes a need to >>> copy a function body to another location at run-time. >>> >>> A straightforward call to memcpy doesn't work in Thumb-2, >>> because bit 0 of external Thumb function symbols is set to 1, >>> indicating that the function is Thumb. Without corrective >>> measures, this will cause an off-by-one copy, and the copy >>> may be called using the wrong instruction set. >>> >>> This patch adds an fncpy() macro to help with such copies. >>> >>> Particular care is needed, because C doesn't guarantee any >>> defined behaviour when casting a function pointer to any other >>> type. This has been observed to lead to strange optimisation >>> side-effects when doing the arithmetic which is required in >>> order to copy/move function bodies correctly in Thumb-2. >>> >>> Thanks to Russell King and Nicolas Pitre for their input >>> on this patch. >>> >>> Signed-off-by: Dave Martin >>> Tested-by: Jean Pihet >> >> Tested-by: Kevin Hilman >> >> along with Jean's OMAP patch on: >> >> OMAP2420/n810: including basic suspend/resume test. >> >> OMAP16xx/OSK: boot test only. >> >> Kevin >> > > Thanks > ---Dave > Any more comments on this patch? I have no further changes so far. Cheers ---Dave -- 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/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
On Mon, Jan 24, 2011 at 3:58 PM, Russell King - ARM Linux wrote: > On Mon, Jan 24, 2011 at 02:27:24PM +0530, Poddar, Sourav wrote: >> On Mon, Jan 24, 2011 at 2:08 PM, Poddar, Sourav wrote: >> > On Sun, Jan 23, 2011 at 3:05 PM, Russell King - ARM Linux >> > wrote: >> >> On Sat, Jan 22, 2011 at 11:44:59PM -0500, Nicolas Pitre wrote: >> >>> At least another person did post results: >> >>> >> >>> http://mid.gmane.org/20110117094602.ga2...@pulham.picochip.com >> >>> http://mid.gmane.org/20110117110308.gc2...@pulham.picochip.com >> >> >> >> Slightly different patch - there were three revisions. I can't attach >> >> a tested-by given to a different patch to this one. >> >> >> >>> > That means omap2plus_defconfig .38 mainline kernels >> >>> > (including -stable) will remain potentially dangerous when run on >> >>> > SMP capable hardware. >> >>> >> >>> I must admit that this series looks a bit large for stable IMHO. I >> >>> think that the fix for stable should limit itself only to prevent SMP >> >>> from being selected if anything else than CPU_32v6K is selected. >> >> >> >> The first three are the bare minimum required for -stable. >> >> >> > >> >> Boot tested the 14 patch series with CONFIG_SWP_EMULATE enabled, on >> the following boards : >> >> >> 1. Omap2420 SDP >> >> 2. Omap2430 SDP >> >> 3. Omap3430 SDP >> >> 4. Omap4 Blaze >> >> Tested-by: Sourav Poddar > > Thanks. It's also important to ascertain which filesystems were tested - > could you let me know please? > It is a custom filesystem on BusyBox v1.17.2. Please let me know if you need some other information. -- 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/5] ARM: twd: Add context save restore support
> -Original Message-
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Monday, January 24, 2011 4:41 PM
> To: Santosh Shilimkar
> Cc: linux-arm-ker...@lists.infradead.org; catalin.mari...@arm.com;
> ccr...@android.com; linus.ml.wall...@gmail.com; linux-
> o...@vger.kernel.org
> Subject: Re: [PATCH 3/5] ARM: twd: Add context save restore support
>
> On Mon, Jan 24, 2011 at 11:06:09AM +, Russell King - ARM Linux
> wrote:
> > On Mon, Jan 24, 2011 at 02:21:17PM +0530, Santosh Shilimkar wrote:
> > > In CPU low power state, local timer looses its register context.
> This
> > > patch adds context save restore hooks which can be used by
> platforms
> > > appropriately.
> >
> > I thought the whole point of CLOCK_EVT_FEAT_C3STOP was that the
> generic
> > timer stuff wouldn't rely on it being kept alive?
> >
> > Hmm, it looks like we bypass the clockevents code by only setting
> the
> > TWD load value at initialization time, not when we switch to
> periodic
> > mode. We really ought to rewrite it whenever we switch back to
> periodic
> > mode.
> >
> > I suspect fixing that means you won't need this save/restore
> support.
>
> Untested, but should do what's required.
:) I was just typing an email and you sent a patch. Will test this
and update you.
>
> diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
> index fd91566..60636f4 100644
> --- a/arch/arm/kernel/smp_twd.c
> +++ b/arch/arm/kernel/smp_twd.c
> @@ -36,6 +36,7 @@ static void twd_set_mode(enum clock_event_mode
> mode,
> /* timer load already set up */
> ctrl = TWD_TIMER_CONTROL_ENABLE |
> TWD_TIMER_CONTROL_IT_ENABLE
> | TWD_TIMER_CONTROL_PERIODIC;
> + __raw_writel(twd_timer_rate / HZ, twd_base +
> TWD_TIMER_LOAD);
> break;
> case CLOCK_EVT_MODE_ONESHOT:
> /* period set, and timer enabled in 'next_event' hook */
> @@ -81,7 +82,7 @@ int twd_timer_ack(void)
>
> static void __cpuinit twd_calibrate_rate(void)
> {
> - unsigned long load, count;
> + unsigned long count;
> u64 waitjiffies;
>
> /*
> @@ -116,10 +117,6 @@ static void __cpuinit twd_calibrate_rate(void)
> printk("%lu.%02luMHz.\n", twd_timer_rate / 100,
> (twd_timer_rate / 100) % 100);
> }
> -
> - load = twd_timer_rate / HZ;
> -
> - __raw_writel(load, twd_base + TWD_TIMER_LOAD);
> }
>
> /*
--
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/5] ARM: twd: Add context save restore support
> -Original Message- > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] > Sent: Monday, January 24, 2011 4:36 PM > To: Santosh Shilimkar > Cc: linux-arm-ker...@lists.infradead.org; catalin.mari...@arm.com; > ccr...@android.com; linus.ml.wall...@gmail.com; linux- > o...@vger.kernel.org > Subject: Re: [PATCH 3/5] ARM: twd: Add context save restore support > > On Mon, Jan 24, 2011 at 02:21:17PM +0530, Santosh Shilimkar wrote: > > In CPU low power state, local timer looses its register context. > This > > patch adds context save restore hooks which can be used by > platforms > > appropriately. > > I thought the whole point of CLOCK_EVT_FEAT_C3STOP was that the > generic > timer stuff wouldn't rely on it being kept alive? > > Hmm, it looks like we bypass the clockevents code by only setting > the > TWD load value at initialization time, not when we switch to > periodic > mode. We really ought to rewrite it whenever we switch back to > periodic > mode. > Idea looks good though am not sure the one shot mode. > I suspect fixing that means you won't need this save/restore > support. Will try it out. 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: [PATCH 3/5] ARM: twd: Add context save restore support
On Mon, Jan 24, 2011 at 11:06:09AM +, Russell King - ARM Linux wrote:
> On Mon, Jan 24, 2011 at 02:21:17PM +0530, Santosh Shilimkar wrote:
> > In CPU low power state, local timer looses its register context. This
> > patch adds context save restore hooks which can be used by platforms
> > appropriately.
>
> I thought the whole point of CLOCK_EVT_FEAT_C3STOP was that the generic
> timer stuff wouldn't rely on it being kept alive?
>
> Hmm, it looks like we bypass the clockevents code by only setting the
> TWD load value at initialization time, not when we switch to periodic
> mode. We really ought to rewrite it whenever we switch back to periodic
> mode.
>
> I suspect fixing that means you won't need this save/restore support.
Untested, but should do what's required.
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index fd91566..60636f4 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -36,6 +36,7 @@ static void twd_set_mode(enum clock_event_mode mode,
/* timer load already set up */
ctrl = TWD_TIMER_CONTROL_ENABLE | TWD_TIMER_CONTROL_IT_ENABLE
| TWD_TIMER_CONTROL_PERIODIC;
+ __raw_writel(twd_timer_rate / HZ, twd_base + TWD_TIMER_LOAD);
break;
case CLOCK_EVT_MODE_ONESHOT:
/* period set, and timer enabled in 'next_event' hook */
@@ -81,7 +82,7 @@ int twd_timer_ack(void)
static void __cpuinit twd_calibrate_rate(void)
{
- unsigned long load, count;
+ unsigned long count;
u64 waitjiffies;
/*
@@ -116,10 +117,6 @@ static void __cpuinit twd_calibrate_rate(void)
printk("%lu.%02luMHz.\n", twd_timer_rate / 100,
(twd_timer_rate / 100) % 100);
}
-
- load = twd_timer_rate / HZ;
-
- __raw_writel(load, twd_base + TWD_TIMER_LOAD);
}
/*
--
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/5] ARM: twd: Add context save restore support
On Mon, Jan 24, 2011 at 02:21:17PM +0530, Santosh Shilimkar wrote: > In CPU low power state, local timer looses its register context. This > patch adds context save restore hooks which can be used by platforms > appropriately. I thought the whole point of CLOCK_EVT_FEAT_C3STOP was that the generic timer stuff wouldn't rely on it being kept alive? Hmm, it looks like we bypass the clockevents code by only setting the TWD load value at initialization time, not when we switch to periodic mode. We really ought to rewrite it whenever we switch back to periodic mode. I suspect fixing that means you won't need this save/restore support. -- 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 5/5] ARM: smp: Skip secondary cpu calibration to speed-up boot
On Mon, Jan 24, 2011 at 02:21:19PM +0530, Santosh Shilimkar wrote: > On some architectures, secondary cores shares clock with primiary > core and hence scale together. Hence secondary core lpj calibration > is not necessary and can be skipped to save considerable time. > > This can speed up the secondary cpu boot and hotplug cpu online > paths. I still point out that this will be a user visible change in /proc/cpuinfo. -- 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/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
On Mon, Jan 24, 2011 at 02:27:24PM +0530, Poddar, Sourav wrote: > On Mon, Jan 24, 2011 at 2:08 PM, Poddar, Sourav wrote: > > On Sun, Jan 23, 2011 at 3:05 PM, Russell King - ARM Linux > > wrote: > >> On Sat, Jan 22, 2011 at 11:44:59PM -0500, Nicolas Pitre wrote: > >>> At least another person did post results: > >>> > >>> http://mid.gmane.org/20110117094602.ga2...@pulham.picochip.com > >>> http://mid.gmane.org/20110117110308.gc2...@pulham.picochip.com > >> > >> Slightly different patch - there were three revisions. I can't attach > >> a tested-by given to a different patch to this one. > >> > >>> > That means omap2plus_defconfig .38 mainline kernels > >>> > (including -stable) will remain potentially dangerous when run on > >>> > SMP capable hardware. > >>> > >>> I must admit that this series looks a bit large for stable IMHO. I > >>> think that the fix for stable should limit itself only to prevent SMP > >>> from being selected if anything else than CPU_32v6K is selected. > >> > >> The first three are the bare minimum required for -stable. > >> > > > > Boot tested the 14 patch series with CONFIG_SWP_EMULATE enabled, on > the following boards : > > > 1. Omap2420 SDP > > 2. Omap2430 SDP > > 3. Omap3430 SDP > > 4. Omap4 Blaze > > Tested-by: Sourav Poddar Thanks. It's also important to ascertain which filesystems were tested - could you let me know please? -- 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 v7] OMAP2+: PM: omap device: API's for handling mstandby mode
Paul/Benoit, On Tue, Dec 14, 2010 at 07:18:22AM +0530, G, Manjunath Kondaiah wrote: > Paul/Benoit, > > On Fri, Dec 03, 2010 at 01:19:06PM +0100, Cousson, Benoit wrote: > > On 12/3/2010 10:47 AM, G, Manjunath Kondaiah wrote: > > >* Cousson, Benoit [2010-12-03 09:38:35 +0100]: > > > > [...] > > > > >>>v7: replaced mutex lock with spin lock. Added use count for controlling > > >>>access to sysconfig registers in case if overlapping request/release > > >>>API's > > >>>are used. > > >> > > >>I'm not sure it should be done here. I'd rather keep that code in > > >>the DMA, since this is the only user of that feature. > > > > > >Are you referring to spin lock or usage count? > > > > The spinlock is needed, I was referring to the usage count. > > > > That being said, the API proposed by Paul (request/release > > ) sound like a get/put, so maybe he had that kind of usage in mind. > > > > I'm still not convince it should be done at hwmod API level. > > > > > > Paul, > > Any thoughts on that? > > How do we proceed further? Gentle reminder! Can we please align on this so that DMA sysconfig patches can be upstreamed? Discussion on this topic can be accessed at: https://patchwork.kernel.org/patch/372231/ http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39728.html -Manjunath -- 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: PM: DMA: Enable runtime pm
From: Manjunath G Kondaiah
Enable runtime pm and use pm_runtime_get_sync and pm_runtime_put
for OMAP DMA driver.
Since DMA driver callback will happen from interrupt context and
DMA client driver will release all DMA resources from interrupt
context itself, pm_runtime_put_sync() cannot be used in DMA driver.
Instead, pm_runtime_put() is used which is asynchronous call and
gets executed in work queue.
Boot tested on OMAP4 blaze and all applicable tests are executed
along with dma hwmod series.
Signed-off-by: G, Manjunath Kondaiah
---
Discussion and alignment for using runtime API's in DMA can be accessed at:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg37819.html
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg38355.html
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg38391.html
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg38400.html
arch/arm/plat-omap/dma.c | 18 +-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index c4b2b47..48ee292 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
@@ -58,6 +59,7 @@ enum { DMA_CHAIN_STARTED, DMA_CHAIN_NOTSTARTED };
#define OMAP_FUNC_MUX_ARM_BASE (0xfffe1000 + 0xec)
static struct omap_system_dma_plat_info *p;
+static struct platform_device *pd;
static struct omap_dma_dev_attr *d;
static int enable_1510_mode;
@@ -676,6 +678,7 @@ int omap_request_dma(int dev_id, const char *dev_name,
unsigned long flags;
struct omap_dma_lch *chan;
+ pm_runtime_get_sync(&pd->dev);
spin_lock_irqsave(&dma_chan_lock, flags);
for (ch = 0; ch < dma_chan_count; ch++) {
if (free_ch == -1 && dma_chan[ch].dev_id == -1) {
@@ -686,6 +689,7 @@ int omap_request_dma(int dev_id, const char *dev_name,
}
if (free_ch == -1) {
spin_unlock_irqrestore(&dma_chan_lock, flags);
+ pm_runtime_put(&pd->dev);
return -EBUSY;
}
chan = dma_chan + free_ch;
@@ -779,7 +783,7 @@ void omap_free_dma(int lch)
p->dma_write(0, CCR, lch);
omap_clear_dma(lch);
}
-
+ pm_runtime_put(&pd->dev);
spin_lock_irqsave(&dma_chan_lock, flags);
dma_chan[lch].dev_id = -1;
dma_chan[lch].next_lch = -1;
@@ -1979,6 +1983,7 @@ static int __devinit omap_system_dma_probe(struct
platform_device *pdev)
return -EINVAL;
}
+ pd = pdev;
d = p->dma_attr;
errata = p->errata;
@@ -2000,6 +2005,9 @@ static int __devinit omap_system_dma_probe(struct
platform_device *pdev)
}
}
+ pm_runtime_enable(&pd->dev);
+ pm_runtime_get_sync(&pd->dev);
+
spin_lock_init(&dma_chan_lock);
for (ch = 0; ch < dma_chan_count; ch++) {
omap_clear_dma(ch);
@@ -2065,6 +2073,14 @@ static int __devinit omap_system_dma_probe(struct
platform_device *pdev)
dma_chan[1].dev_id = 1;
}
p->show_dma_caps();
+
+ /*
+* Note: If dma channels are reserved through boot paramters,
+* then dma device is always enabled.
+*/
+ if (!omap_dma_reserve_channels)
+ pm_runtime_put(&pd->dev);
+
return 0;
exit_dma_irq_fail:
--
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
Re: [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
On Mon, Jan 24, 2011 at 2:08 PM, Poddar, Sourav wrote: > On Sun, Jan 23, 2011 at 3:05 PM, Russell King - ARM Linux > wrote: >> On Sat, Jan 22, 2011 at 11:44:59PM -0500, Nicolas Pitre wrote: >>> At least another person did post results: >>> >>> http://mid.gmane.org/20110117094602.ga2...@pulham.picochip.com >>> http://mid.gmane.org/20110117110308.gc2...@pulham.picochip.com >> >> Slightly different patch - there were three revisions. I can't attach >> a tested-by given to a different patch to this one. >> >>> > That means omap2plus_defconfig .38 mainline kernels >>> > (including -stable) will remain potentially dangerous when run on >>> > SMP capable hardware. >>> >>> I must admit that this series looks a bit large for stable IMHO. I >>> think that the fix for stable should limit itself only to prevent SMP >>> from being selected if anything else than CPU_32v6K is selected. >> >> The first three are the bare minimum required for -stable. >> > Boot tested the 14 patch series with CONFIG_SWP_EMULATE enabled, on the following boards : 1. Omap2420 SDP 2. Omap2430 SDP 3. Omap3430 SDP 4. Omap4 Blaze Tested-by: Sourav Poddar -- 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 5/5] ARM: smp: Skip secondary cpu calibration to speed-up boot
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Santosh Shilimkar
> Sent: Monday, January 24, 2011 2:21 PM
> To: linux-arm-ker...@lists.infradead.org
> Cc: linux-omap@vger.kernel.org; ccr...@android.com;
> catalin.mari...@arm.com; li...@arm.linux.org.uk;
> linus.ml.wall...@gmail.com
> Subject: [PATCH 5/5] ARM: smp: Skip secondary cpu calibration to
> speed-up boot
>
> if (!skip_secondary_calibrate) {
> for_each_online_cpu(cpu)
> - bogosum += per_cpu(cpu_data, cpu).loops_per_jiffy;
> + bogosums += per_cpu(cpu_data,
> cpu).loops_per_jiffy;
>
> - snprintf(bogosum, sizeof(bogosum), " (%lu.%02lu
> BogoMIPS).\n",
> - bogosum / (50/HZ), (bogosum / (5000/HZ)) %
> 100);
> + snprintf(bogosum, sizeof(bogosums), " (%lu.%02lu
> BogoMIPS).\n",
> + bogosums / (50/HZ), (bogosums / (5000/HZ)) %
> 100);
> } else
> bogosum[0] = '\0';
>
Ignore this change please.
--
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 5/5] ARM: smp: Skip secondary cpu calibration to speed-up boot
On some architectures, secondary cores shares clock with primiary
core and hence scale together. Hence secondary core lpj calibration
is not necessary and can be skipped to save considerable time.
This can speed up the secondary cpu boot and hotplug cpu online
paths.
The patch is still under discussion and relevant thread is
here.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42902.html
Signed-off-by: Santosh Shilimkar
Cc: Russell King
---
arch/arm/include/asm/smp.h |8
arch/arm/kernel/smp.c | 35 ++-
arch/arm/mach-omap2/omap-smp.c |3 +++
3 files changed, 37 insertions(+), 9 deletions(-)
diff --git a/arch/arm/include/asm/smp.h b/arch/arm/include/asm/smp.h
index 96ed521..150d202 100644
--- a/arch/arm/include/asm/smp.h
+++ b/arch/arm/include/asm/smp.h
@@ -69,6 +69,14 @@ asmlinkage void secondary_start_kernel(void);
extern void platform_secondary_init(unsigned int cpu);
/*
+ * Skip the secondary calibration on architectures sharing clock
+ * with primary cpu. Needs to be called for archs inside
+ * platform_secondary_init()
+ */
+extern void secondary_skip_calibrate(void);
+
+
+/*
* Initialize cpu_possible map, and enable coherency
*/
extern void platform_smp_prepare_cpus(unsigned int);
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 4539ebc..6aa99bc 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -55,6 +55,8 @@ enum ipi_msg_type {
IPI_CPU_STOP,
};
+static unsigned int skip_secondary_calibrate;
+
int __cpuinit __cpu_up(unsigned int cpu)
{
struct cpuinfo_arm *ci = &per_cpu(cpu_data, cpu);
@@ -270,6 +272,16 @@ static void __cpuinit smp_store_cpu_info(unsigned int
cpuid)
}
/*
+ * Skip the secondary calibration on architectures sharing clock
+ * with primary cpu. Needs to be called for archs from
+ * platform_secondary_init()
+ */
+void secondary_skip_calibrate(void)
+{
+ skip_secondary_calibrate = 1;
+}
+
+/*
* This is the secondary CPU boot entry. We're using this CPUs
* idle thread stack, but a set of temporary page tables.
*/
@@ -312,7 +324,8 @@ asmlinkage void __cpuinit secondary_start_kernel(void)
*/
percpu_timer_setup();
- calibrate_delay();
+ if (!skip_secondary_calibrate)
+ calibrate_delay();
smp_store_cpu_info(cpu);
@@ -330,16 +343,20 @@ asmlinkage void __cpuinit secondary_start_kernel(void)
void __init smp_cpus_done(unsigned int max_cpus)
{
int cpu;
- unsigned long bogosum = 0;
+ char bogosum[32];
+ unsigned long bogosums = 0;
+
+ if (!skip_secondary_calibrate) {
+ for_each_online_cpu(cpu)
+ bogosums += per_cpu(cpu_data, cpu).loops_per_jiffy;
- for_each_online_cpu(cpu)
- bogosum += per_cpu(cpu_data, cpu).loops_per_jiffy;
+ snprintf(bogosum, sizeof(bogosums), " (%lu.%02lu BogoMIPS).\n",
+ bogosums / (50/HZ), (bogosums / (5000/HZ)) % 100);
+ } else
+ bogosum[0] = '\0';
- printk(KERN_INFO "SMP: Total of %d processors activated "
- "(%lu.%02lu BogoMIPS).\n",
- num_online_cpus(),
- bogosum / (50/HZ),
- (bogosum / (5000/HZ)) % 100);
+ pr_info("SMP: Total of %d processors activated%s.\n",
+ num_online_cpus(), bogosum);
}
void __init smp_prepare_boot_cpu(void)
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index b66cfe8..7342cd5 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -39,6 +39,9 @@ void __cpuinit platform_secondary_init(unsigned int cpu)
*/
gic_secondary_init(0);
+ /* Allow to skip secondary CPU calibration */
+ secondary_skip_calibrate();
+
/*
* Synchronise with the boot thread.
*/
--
1.6.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
[PATCH 1/5] ARM: gic: Add hooks for architecture specific extensions
Few architectures combine the GIC with an external interrupt controller.
On such systems it may be necessary to update both the GIC registers
and the external controller's registers to control IRQ behavior.
This can be addressed in couple of possible methods.
1. Export common GIC routines along with 'struct irq_chip gic_chip'
and allow architectures to have custom function by override.
2. Provide architecture specific function pointer hooks
within GIC library and leave platforms to add the necessary
code as part of these hooks.
First one might be non-intrusive but have few shortcomings like arch needs
to have there own custom gic library. Locks used should be common since it
caters to same IRQs etc. Maintenance point of view also it leads to
multiple file fixes.
The second probably is cleaner and portable. It ensures that all the
common GIC infrastructure is not touched and also provides archs to
address their specific issue.
Signed-off-by: Santosh Shilimkar
Cc: Russell King
---
arch/arm/common/gic.c | 28
arch/arm/include/asm/hardware/gic.h |1 +
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index 2243772..b4a9ea7 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -44,6 +44,15 @@ struct gic_chip_data {
void __iomem *cpu_base;
};
+/* Default make arch specific GIC functions NULL */
+struct irq_chip gic_arch_extn = {
+ .irq_mask = NULL,
+ .irq_unmask = NULL,
+#ifdef CONFIG_PM
+ .irq_set_wake = NULL,
+#endif
+};
+
#ifndef MAX_GIC_NR
#define MAX_GIC_NR 1
#endif
@@ -84,6 +93,8 @@ static void gic_mask_irq(struct irq_data *d)
spin_lock(&irq_controller_lock);
writel(mask, gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR + (gic_irq(d) /
32) * 4);
+ if (gic_arch_extn.irq_mask)
+ gic_arch_extn.irq_mask(d);
spin_unlock(&irq_controller_lock);
}
@@ -92,6 +103,8 @@ static void gic_unmask_irq(struct irq_data *d)
u32 mask = 1 << (d->irq % 32);
spin_lock(&irq_controller_lock);
+ if (gic_arch_extn.irq_unmask)
+ gic_arch_extn.irq_unmask(d);
writel(mask, gic_dist_base(d) + GIC_DIST_ENABLE_SET + (gic_irq(d) / 32)
* 4);
spin_unlock(&irq_controller_lock);
}
@@ -167,6 +180,18 @@ gic_set_cpu(struct irq_data *d, const struct cpumask
*mask_val, bool force)
}
#endif
+#ifdef CONFIG_PM
+static int gic_set_wake(struct irq_data *d, unsigned int on)
+{
+ int ret = -ENXIO;
+
+ if (gic_arch_extn.irq_set_wake)
+ ret = gic_arch_extn.irq_set_wake(d, on);
+
+ return ret;
+}
+#endif
+
static void gic_handle_cascade_irq(unsigned int irq, struct irq_desc *desc)
{
struct gic_chip_data *chip_data = get_irq_data(irq);
@@ -205,6 +230,9 @@ static struct irq_chip gic_chip = {
#ifdef CONFIG_SMP
.irq_set_affinity = gic_set_cpu,
#endif
+#ifdef CONFIG_PM
+ .irq_set_wake = gic_set_wake,
+#endif
};
void __init gic_cascade_irq(unsigned int gic_nr, unsigned int irq)
diff --git a/arch/arm/include/asm/hardware/gic.h
b/arch/arm/include/asm/hardware/gic.h
index 84557d3..0691f9d 100644
--- a/arch/arm/include/asm/hardware/gic.h
+++ b/arch/arm/include/asm/hardware/gic.h
@@ -34,6 +34,7 @@
#ifndef __ASSEMBLY__
extern void __iomem *gic_cpu_base_addr;
+extern struct irq_chip gic_arch_extn;
void gic_init(unsigned int, unsigned int, void __iomem *, void __iomem *);
void gic_secondary_init(unsigned int);
--
1.6.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
[PATCH 0/5] ARM: Few patches for PM enablement.
The series consist of few patches to address some common PM issues on Cortex-A9 based ARM SoCs. The skip calibration on secondary cores is still under discussion. On OMAP, the GIC save restore is done differently and hence that part isn't included. Collin already have a patch for the same which should address other SOCs. The following changes since commit 1bae4ce27c9c90344f23c65ea6966c50ffeae2f5: Linus Torvalds (1): Linux 2.6.38-rc2 Santosh Shilimkar (5): ARM: gic: Add hooks for architecture specific extensions ARM: gic: Add distributor and interface enable/disable accessory api ARM: twd: Add context save restore support ARM: scu: Move register defines to header file ARM: smp: Skip secondary cpu calibration to speed-up boot arch/arm/common/gic.c | 52 +++ arch/arm/include/asm/hardware/gic.h |3 ++ arch/arm/include/asm/localtimer.h | 13 + arch/arm/include/asm/smp.h |8 + arch/arm/include/asm/smp_scu.h |6 arch/arm/include/asm/smp_twd.h |2 + arch/arm/kernel/smp.c | 35 +-- arch/arm/kernel/smp_scu.c |6 arch/arm/kernel/smp_twd.c | 24 arch/arm/mach-omap2/omap-smp.c |3 ++ 10 files changed, 137 insertions(+), 15 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
[PATCH 2/5] ARM: gic: Add distributor and interface enable/disable accessory api
The power management code needs to have access to enable/disable the
gic cpu interface and distributor based on targetted low power
states.
This patch adds and exports one API each for distributor and cpu
interface enable/disable.
Signed-off-by: Santosh Shilimkar
Cc: Russell King
---
arch/arm/common/gic.c | 24
arch/arm/include/asm/hardware/gic.h |2 ++
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index b4a9ea7..6384bb7 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -369,6 +369,30 @@ void __cpuinit gic_enable_ppi(unsigned int irq)
local_irq_restore(flags);
}
+/* Used in power management paths */
+void gic_secondary_set(unsigned int gic_nr, unsigned int on)
+{
+ BUG_ON(gic_nr >= MAX_GIC_NR);
+
+ if (on) {
+ __raw_writel(0xf0, gic_data[gic_nr].cpu_base + GIC_CPU_PRIMASK);
+ __raw_writel(1, gic_data[gic_nr].cpu_base + GIC_CPU_CTRL);
+
+ } else {
+ __raw_writel(0, gic_data[gic_nr].cpu_base + GIC_CPU_CTRL);
+ }
+}
+
+void gic_dist_set(unsigned int gic_nr, unsigned int on)
+{
+ BUG_ON(gic_nr >= MAX_GIC_NR);
+
+ if (on)
+ __raw_writel(0x1, gic_data[gic_nr].dist_base + GIC_DIST_CTRL);
+ else
+ __raw_writel(0, gic_data[gic_nr].cpu_base + GIC_CPU_CTRL);
+}
+
#ifdef CONFIG_SMP
void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
{
diff --git a/arch/arm/include/asm/hardware/gic.h
b/arch/arm/include/asm/hardware/gic.h
index 0691f9d..638d9dc 100644
--- a/arch/arm/include/asm/hardware/gic.h
+++ b/arch/arm/include/asm/hardware/gic.h
@@ -41,6 +41,8 @@ void gic_secondary_init(unsigned int);
void gic_cascade_irq(unsigned int gic_nr, unsigned int irq);
void gic_raise_softirq(const struct cpumask *mask, unsigned int irq);
void gic_enable_ppi(unsigned int);
+void gic_secondary_set(unsigned int gic_nr, unsigned int on);
+void gic_dist_set(unsigned int gic_nr, unsigned int on);
#endif
#endif
--
1.6.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
[PATCH 3/5] ARM: twd: Add context save restore support
In CPU low power state, local timer looses its register context. This
patch adds context save restore hooks which can be used by platforms
appropriately.
Signed-off-by: Santosh Shilimkar
Cc: Russell King
---
arch/arm/include/asm/localtimer.h | 13 +
arch/arm/include/asm/smp_twd.h|2 ++
arch/arm/kernel/smp_twd.c | 24
3 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/localtimer.h
b/arch/arm/include/asm/localtimer.h
index 6bc63ab..6753754 100644
--- a/arch/arm/include/asm/localtimer.h
+++ b/arch/arm/include/asm/localtimer.h
@@ -31,6 +31,9 @@ asmlinkage void do_local_timer(struct pt_regs *);
#define local_timer_ack() twd_timer_ack()
+#define local_timer_save(cpu) twd_context_save(cpu);
+#define local_timer_restore(cpu) twd_context_save(cpu);
+
#else
/*
@@ -46,6 +49,16 @@ int local_timer_ack(void);
*/
void local_timer_setup(struct clock_event_device *);
+/*
+ * Save local timer register context
+ */
+void local_timer_save(unsigned int cpu);
+
+/*
+ * Restore local timer register context
+ */
+void local_timer_restoree(unsigned int cpu);
+
#endif
#endif
diff --git a/arch/arm/include/asm/smp_twd.h b/arch/arm/include/asm/smp_twd.h
index fed9981..7828f29 100644
--- a/arch/arm/include/asm/smp_twd.h
+++ b/arch/arm/include/asm/smp_twd.h
@@ -24,5 +24,7 @@ extern void __iomem *twd_base;
int twd_timer_ack(void);
void twd_timer_setup(struct clock_event_device *);
+void twd_context_save(unsigned int cpu);
+void twd_context_restore(unsigned int cpu);
#endif
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index fd91566..f3098e4 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -24,6 +24,12 @@
/* set up by the platform code */
void __iomem *twd_base;
+/* Timer context to be saved in low power modes */
+struct twd_registers {
+ unsigned long timer_ctrl;
+ unsigned long timer_load;
+};
+static DEFINE_PER_CPU(struct twd_registers, twd_context);
static unsigned long twd_timer_rate;
static void twd_set_mode(enum clock_event_mode mode,
@@ -145,3 +151,21 @@ void __cpuinit twd_timer_setup(struct clock_event_device
*clk)
clockevents_register_device(clk);
}
+
+/* Low power context save */
+void twd_context_save(unsigned int cpu)
+{
+ struct twd_registers *regs = &per_cpu(twd_context, cpu);
+
+ regs->timer_ctrl = __raw_readl(twd_base + TWD_TIMER_CONTROL);
+ regs->timer_load = __raw_readl(twd_base + TWD_TIMER_LOAD);
+}
+
+/* Low power context restore */
+void twd_context_restore(unsigned int cpu)
+{
+ struct twd_registers *regs = &per_cpu(twd_context, cpu);
+
+ __raw_writel(regs->timer_load, twd_base + TWD_TIMER_LOAD);
+ __raw_writel(regs->timer_ctrl, twd_base + TWD_TIMER_CONTROL);
+}
--
1.6.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
[PATCH 4/5] ARM: scu: Move register defines to header file
This patch moves SCU register defines from smp_scu.c to smp_scu.h so that its available for platforms to use The SCU CPU power status registers is used for power management on OMAP4. Signed-off-by: Santosh Shilimkar Cc: Russell King --- arch/arm/include/asm/smp_scu.h |6 ++ arch/arm/kernel/smp_scu.c |6 -- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm/include/asm/smp_scu.h b/arch/arm/include/asm/smp_scu.h index 2376835..b6f42c9 100644 --- a/arch/arm/include/asm/smp_scu.h +++ b/arch/arm/include/asm/smp_scu.h @@ -1,6 +1,12 @@ #ifndef __ASMARM_ARCH_SCU_H #define __ASMARM_ARCH_SCU_H +#define SCU_CTRL 0x00 +#define SCU_CONFIG 0x04 +#define SCU_CPU_STATUS 0x08 +#define SCU_INVALIDATE 0x0c +#define SCU_FPGA_REVISION 0x10 + unsigned int scu_get_core_count(void __iomem *); void scu_enable(void __iomem *); diff --git a/arch/arm/kernel/smp_scu.c b/arch/arm/kernel/smp_scu.c index 9ab4149..ee7bf47 100644 --- a/arch/arm/kernel/smp_scu.c +++ b/arch/arm/kernel/smp_scu.c @@ -14,12 +14,6 @@ #include #include -#define SCU_CTRL 0x00 -#define SCU_CONFIG 0x04 -#define SCU_CPU_STATUS 0x08 -#define SCU_INVALIDATE 0x0c -#define SCU_FPGA_REVISION 0x10 - /* * Get the number of CPU cores from the SCU configuration */ -- 1.6.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
[PATCH 5/5] ARM: smp: Skip secondary cpu calibration to speed-up boot
if (!skip_secondary_calibrate) {
for_each_online_cpu(cpu)
- bogosum += per_cpu(cpu_data, cpu).loops_per_jiffy;
+ bogosums += per_cpu(cpu_data, cpu).loops_per_jiffy;
- snprintf(bogosum, sizeof(bogosum), " (%lu.%02lu BogoMIPS).\n",
- bogosum / (50/HZ), (bogosum / (5000/HZ)) % 100);
+ snprintf(bogosum, sizeof(bogosums), " (%lu.%02lu BogoMIPS).\n",
+ bogosums / (50/HZ), (bogosums / (5000/HZ)) % 100);
} else
bogosum[0] = '\0';
--
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
