Re: [PATCH V2] ARM: OMAP: counter: add locking to read_persistent_clock
Hi Tony,
[snip..]
>> > index dbf1e03..2bc51fb 100644
>> > --- a/arch/arm/plat-omap/counter_32k.c
>> > +++ b/arch/arm/plat-omap/counter_32k.c
>> > @@ -55,22 +55,29 @@ static u32 notrace omap_32k_read_sched_clock(void)
>> > * nsecs and adds to a monotonically increasing timespec.
>> > */
>> > static struct timespec persistent_ts;
>> > -static cycles_t cycles, last_cycles;
>> > +static cycles_t cycles;
>> > static unsigned int persistent_mult, persistent_shift;
>> > +static DEFINE_SPINLOCK(read_persistent_clock_lock);
>> > +
>> > static void omap_read_persistent_clock(struct timespec *ts)
>> > {
>> > unsigned long long nsecs;
>> > - cycles_t delta;
>> > - struct timespec *tsp = &persistent_ts;
>> > + cycles_t last_cycles;
>> > + unsigned long flags;
>> > +
>> > + spin_lock_irqsave(&read_persistent_clock_lock, flags);
>> >
>> > last_cycles = cycles;
>> > cycles = sync32k_cnt_reg ? __raw_readl(sync32k_cnt_reg) : 0;
>> > - delta = cycles - last_cycles;
>> >
>> > - nsecs = clocksource_cyc2ns(delta, persistent_mult, persistent_shift);
>> > + nsecs = clocksource_cyc2ns(cycles - last_cycles,
>> > + persistent_mult, persistent_shift);
>
> ..I think there's another bug here where cycles - last_cycles
> returns wrong value when the timer wraps around as cycles_t is
> 64 bits and the counter is 32 bits. It seems it's been there
> since when the read_persistent_clock was added with commit
> d92cfcbe (OMAP: timekeeping: time should not stop during suspend)?
>
> It seems that after this patch cycles should not be cycles_t
> but u32, and the result of cycles - last_cycles should also
> be u32.
>
cycles_t is defined as typedef unsigned long cycles_t;
Am i missing something here ?
Thanks,
Sricharan
--
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/1] usb: Include generic_interrupt for OMAP2_PLUS
Hi, On Mon, Sep 24, 2012 at 09:09:14AM -0700, Tony Lindgren wrote: > * Felipe Balbi [120924 06:08]: > > Hi, > > > > On Mon, Sep 24, 2012 at 03:54:22PM +0300, Philippe De Swert wrote: > > > Hi, > > > > > > On 24/09/2012, Felipe Balbi wrote: > > > > SoB's mail doesn't From mail. > > > > > > Well still in the progress of migrating of my personal to work laptop. > > > Since the patch does not seem correct the replacement will have > > > matching addresses. > > > > > > >> /*-*/ > > > >> > > > >> #if defined(CONFIG_SOC_OMAP2430) || defined(CONFIG_SOC_OMAP3430) || \ > > > >> - defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_ARCH_U8500) > > > >> + defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_ARCH_U8500) || \ > > > >> + defined(CONFIG_ARCH_OMAP2PLUS) > > > > > > > > Weird, how can you build OMAP2PLUS without SOC_OMAP ?? > > > > > > It seems entirely possible. I quickly tried to look if it got defined > > > somewhere and it does not seem to be set anywhere. That is why I got > > > the impression it was replaced by CONFIG_ARCH_OMAP2PLUS. I'll dig > > > deeper to find out why SOC_OMAP is not set if it should be. > > > > > > From the .config I got (used menuconfig) > > > > > > # > > > # TI OMAP2/3/4 Specific Features > > > # > > > CONFIG_ARCH_OMAP2PLUS_TYPICAL=y > > > CONFIG_SOC_HAS_OMAP2_SDRC=y > > > # CONFIG_ARCH_OMAP2 is not set > > > CONFIG_ARCH_OMAP3=y > > > # CONFIG_ARCH_OMAP4 is not set > > > # CONFIG_SOC_OMAP5 is not set > > > # CONFIG_SOC_OMAP3430 is not set > > > # CONFIG_SOC_TI81XX is not set > > > # CONFIG_SOC_AM33XX is not set > > > CONFIG_OMAP_PACKAGE_CBB=y > > > > > > Not a mention of CONFIG_SOC_OMAP2430 and CONFIG_SOC_OMAP3430 did not > > > get set (while it is not a 3430 but a 3630 I am using). Maybe > > > CONFIG_ARCH_OMAP3 would have been a better choice then? > > > > that's quite f**ked up. Tony, why doesn't SOC_OMAP3430 get set for all > > OMAP3 boards ? And another question: why don't we have a matching > > SOC_OMAP3530, SOC_OMAP3630 and so on ? > > ARCH_OMAP3 will probably eventually just disappear and > be replaced with ARCH_OMAP2PLUS + SOC_. But there's > no need to do it right now as most of that should be > internal to arch/arm/mach-omap2 anyways. I would just > set the driver to depend on ARCH_OMAP2PLUS, and rely on > the platform_data and DT to do something if specified. > That means that on 2420 musb should not probe unless > tusb6010 in specified. > > It seems that things like fifo_mode and generic_interrupt > can all be set during the probe based on the platform_data > or DT passed information? Then maybe it's best to just remove the ifdefs and always provide generic_interrupt() ? Anyone against it ? -- balbi signature.asc Description: Digital signature
Re: [PATCH] arm: make FORCE_MAX_ZONEORDER configurable for TI AM33XX
On Tue, Sep 25, 2012 at 10:05:30AM +0200, Yegor Yefremov wrote: > How should I change the patch to make it proper? SA is broken anyway: No it isn't. This is what it produces _today_, and has done for the last 5-10 years without modification # CONFIG_CLEANCACHE is not set # CONFIG_FRONTSWAP is not set CONFIG_FORCE_MAX_ZONEORDER=9 CONFIG_LEDS=y CONFIG_LEDS_CPU=y > config FORCE_MAX_ZONEORDER > int "Maximum zone order" if ARCH_SHMOBILE > range 11 64 if ARCH_SHMOBILE > default "9" if SA > default "11" > > AFAIK if ARCH_SHMOBILE defines dependency on ARCH_SHMOBILE, No it doens't. int "Maximum zone order" if ARCH_SHMOBILE is far from being the same as: int "Maximum zone order" depends on ARCH_SHMOBILE The former defines a condition upon which the option is offered in GUIs - or to put it another way, it defines the visibility of the option. The latter defines a dependency which must be met for the option to be both visible and appear in the resulting configuration file. > so SA won't be evaluated (at least if I select SA And did you check that SA remains selected? I bet you didn't. Or maybe you tested your patched version. Whatever. The original works, and has been known to work for years. Your patch breaks it. It's really as simple as that. -- 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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.
Hi Greg,
Ping on this?
On Tue, Sep 18, 2012 at 6:10 PM, Sourav Poddar wrote:
> Greg's tty-next is not booting on 2420 based N800. The failure is
> observed at serial init itself. The reason might be that n800 tries to
> resume even though it is not suspended before.
>
> Reported-by: Paul Walmsley
> Signed-off-by: Sourav Poddar
> ---
> This patch is developed on top of greg's tty-next branch
> CommitId: e740d8f tty: serial: Samsung: Fix return value +
> the following patch which I have already posted to the mailing list.
> http://comments.gmane.org/gmane.linux.ports.arm.omap/84729
>
> drivers/tty/serial/omap-serial.c | 11 ++-
> 1 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/tty/serial/omap-serial.c
> b/drivers/tty/serial/omap-serial.c
> index 3c05c5e..bc355f2 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -110,6 +110,7 @@ struct uart_omap_port {
> u32 calc_latency;
> struct work_struct qos_work;
> struct pinctrl *pins;
> + unsigned intsuspended:1;
> };
>
> #define to_uart_omap_port(p) ((container_of((p), struct uart_omap_port,
> port)))
> @@ -1545,14 +1546,20 @@ static int serial_omap_runtime_suspend(struct device
> *dev)
> up->latency = PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE;
> schedule_work(&up->qos_work);
>
> + up->suspended = true;
> +
> return 0;
> }
>
> static int serial_omap_runtime_resume(struct device *dev)
> {
> struct uart_omap_port *up = dev_get_drvdata(dev);
> + u32 loss_cnt;
> +
> + if (!up->suspended)
> + return 0;
>
> - u32 loss_cnt = serial_omap_get_context_loss_count(up);
> + loss_cnt = serial_omap_get_context_loss_count(up);
>
> if (up->context_loss_cnt != loss_cnt)
> serial_omap_restore_context(up);
> @@ -1560,6 +1567,8 @@ static int serial_omap_runtime_resume(struct device
> *dev)
> up->latency = up->calc_latency;
> schedule_work(&up->qos_work);
>
> + up->suspended = false;
> +
> return 0;
> }
> #endif
> --
> 1.7.1
>
~Sourav
--
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] arm: make FORCE_MAX_ZONEORDER configurable for TI AM33XX
From: Yegor Yefremov FORCE_MAX_ZONEORDER of 12 is needed to allocation more than 4MB of consistent DMA memory (da8xx frame buffer driver). Signed-off-by: Dejan Gacnik Signed-off-by: Yegor Yefremov --- Changes: v2: fix SA breakage arch/arm/Kconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 2f88d8d..b5f242e 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1766,8 +1766,8 @@ config HW_PERF_EVENTS source "mm/Kconfig" config FORCE_MAX_ZONEORDER - int "Maximum zone order" if ARCH_SHMOBILE - range 11 64 if ARCH_SHMOBILE + int "Maximum zone order" if ARCH_SHMOBILE || SOC_AM33XX + range 11 64 if ARCH_SHMOBILE || SOC_AM33XX default "9" if SA default "11" help -- 1.7.7 -- 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: make FORCE_MAX_ZONEORDER configurable for TI AM33XX
On 25.09.2012 10:14, Russell King - ARM Linux wrote: > On Tue, Sep 25, 2012 at 10:05:30AM +0200, Yegor Yefremov wrote: >> How should I change the patch to make it proper? SA is broken anyway: > No it isn't. This is what it produces _today_, and has done for the last > 5-10 years without modification > > # CONFIG_CLEANCACHE is not set > # CONFIG_FRONTSWAP is not set > CONFIG_FORCE_MAX_ZONEORDER=9 > CONFIG_LEDS=y > CONFIG_LEDS_CPU=y > >> config FORCE_MAX_ZONEORDER >> int "Maximum zone order" if ARCH_SHMOBILE >> range 11 64 if ARCH_SHMOBILE >> default "9" if SA >> default "11" >> >> AFAIK if ARCH_SHMOBILE defines dependency on ARCH_SHMOBILE, > No it doens't. > > int "Maximum zone order" if ARCH_SHMOBILE > > is far from being the same as: > > int "Maximum zone order" > depends on ARCH_SHMOBILE > > The former defines a condition upon which the option is offered in GUIs - > or to put it another way, it defines the visibility of the option. > > The latter defines a dependency which must be met for the option to be > both visible and appear in the resulting configuration file. > >> so SA won't be evaluated (at least if I select SA > And did you check that SA remains selected? I bet you didn't. Or > maybe you tested your patched version. Whatever. The original works, > and has been known to work for years. Your patch breaks it. It's > really as simple as that. Thanks for explanation. I think I've got it now. Please review the v2 version. Yegor -- 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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.
On Tue, Sep 25, 2012 at 01:52:03PM +0530, Poddar, Sourav wrote: > Hi Greg, > > Ping on this? > > On Tue, Sep 18, 2012 at 6:10 PM, Sourav Poddar wrote: > > Greg's tty-next is not booting on 2420 based N800. The failure is > > observed at serial init itself. The reason might be that n800 tries to > > resume even though it is not suspended before. How is this happening? I think that needs proper investigation - or if it's had more investigation, then the results needs to be included in the commit description so that everyone can understand the issue here. We should not be resuming a device which hasn't been suspended. Maybe the runtime PM enable sequence is wrong, and that's what should be fixed instead? This sequence in the probe() function: pm_runtime_irq_safe(&pdev->dev); pm_runtime_enable(&pdev->dev); pm_runtime_get_sync(&pdev->dev); would enable runtime PM while the s/w state indicates that it's disabled, and then that pm_runtime_get_sync() will want to resume the device. See the section "5. Runtime PM Initialization, Device Probing and Removal" in Documentation/power/runtime_pm.txt, specifically the second paragraph of that section. -- 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] arm: make FORCE_MAX_ZONEORDER configurable for TI AM33XX
On Tue, Sep 25, 2012 at 10:26:30AM +0200, yegorsli...@googlemail.com wrote: > From: Yegor Yefremov > > FORCE_MAX_ZONEORDER of 12 is needed to allocation more than 4MB > of consistent DMA memory (da8xx frame buffer driver). Okay, so the patch description says "This needs to be 12 on this platform". > config FORCE_MAX_ZONEORDER > - int "Maximum zone order" if ARCH_SHMOBILE > - range 11 64 if ARCH_SHMOBILE > + int "Maximum zone order" if ARCH_SHMOBILE || SOC_AM33XX > + range 11 64 if ARCH_SHMOBILE || SOC_AM33XX but you leave it up to the user to select something that may not be suitable. Wouldn't _just_ adding: default "12" if SOC_AM33XX after the "range", and making no other changes be good enough and match what the patch description says? -- 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: make FORCE_MAX_ZONEORDER configurable for TI AM33XX
On 25.09.2012 02:37, Tony Lindgren wrote: > * Russell King - ARM Linux [120924 16:17]: >> On Mon, Sep 24, 2012 at 09:05:11PM +0200, Yegor Yefremov wrote: >>> On Mon, Sep 24, 2012 at 7:18 PM, Tony Lindgren wrote: * yegorsli...@googlemail.com [120703 07:26]: > From: Yegor Yefremov > > FORCE_MAX_ZONEORDER of 12 is needed to allocation more than 4MB > of consistent DMA memory (da8xx frame buffer driver). Sorry for the delay on this one, looks like this one is still valid. I'll apply it. >>> >>> Thanks. >>> >>> Yegor >>> > Signed-off-by: Dejan Gacnik > Signed-off-by: Yegor Yefremov > --- > arch/arm/Kconfig |5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index e876819..ff14c1e 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1725,8 +1725,9 @@ config HW_PERF_EVENTS > source "mm/Kconfig" > > config FORCE_MAX_ZONEORDER > - int "Maximum zone order" if ARCH_SHMOBILE > - range 11 64 if ARCH_SHMOBILE > + int "Maximum zone order" > + depends on ARCH_SHMOBILE || SOC_AM33XX > + range 11 64 if ARCH_SHMOBILE || SOC_AM33XX > default "9" if SA > default "11" >> >> NAK. This patch breaks SA platforms. To see why, read the patch. > > OK let's drop this. How should I change the patch to make it proper? SA is broken anyway: config FORCE_MAX_ZONEORDER int "Maximum zone order" if ARCH_SHMOBILE range 11 64 if ARCH_SHMOBILE default "9" if SA default "11" AFAIK if ARCH_SHMOBILE defines dependency on ARCH_SHMOBILE, so SA won't be evaluated (at least if I select SA include/generated/autoconf.h shows "11"). If I add SA to dependency list like this: depends on ARCH_SHMOBILE || SOC_AM33XX || SA the prompt in "Kernel features" becomes visible, but it doesn't have the default value of "9", but "11". Am I missing something? Yegor -- 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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.
On Tue, Sep 25, 2012 at 09:30:29AM +0100, Russell King - ARM Linux wrote: > On Tue, Sep 25, 2012 at 01:52:03PM +0530, Poddar, Sourav wrote: > > Hi Greg, > > > > Ping on this? > > > > On Tue, Sep 18, 2012 at 6:10 PM, Sourav Poddar wrote: > > > Greg's tty-next is not booting on 2420 based N800. The failure is > > > observed at serial init itself. The reason might be that n800 tries to > > > resume even though it is not suspended before. > > How is this happening? I think that needs proper investigation - or if > it's had more investigation, then the results needs to be included in > the commit description so that everyone can understand the issue here. > > We should not be resuming a device which hasn't been suspended. Maybe > the runtime PM enable sequence is wrong, and that's what should be fixed > instead? > > This sequence in the probe() function: > > pm_runtime_irq_safe(&pdev->dev); > pm_runtime_enable(&pdev->dev); > pm_runtime_get_sync(&pdev->dev); > > would enable runtime PM while the s/w state indicates that it's disabled, > and then that pm_runtime_get_sync() will want to resume the device. See > the section "5. Runtime PM Initialization, Device Probing and Removal" > in Documentation/power/runtime_pm.txt, specifically the second paragraph > of that section. that was tested. It worked in pandaboard but didn't work on beagleboard XM. Sourav tried to start a discussion about that, but it simply died... In any case, pm_runtime_get_sync() in probe will always call runtime_resume callback, right ? -- balbi signature.asc Description: Digital signature
[PATCH] arm: increase FORCE_MAX_ZONEORDER for TI AM33XX
From: Yegor Yefremov FORCE_MAX_ZONEORDER of 12 is needed to allocation more than 4MB of consistent DMA memory (da8xx frame buffer driver). Signed-off-by: Dejan Gacnik Signed-off-by: Yegor Yefremov --- arch/arm/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 2f88d8d..06d489e 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1768,6 +1768,7 @@ source "mm/Kconfig" config FORCE_MAX_ZONEORDER int "Maximum zone order" if ARCH_SHMOBILE range 11 64 if ARCH_SHMOBILE + default "12" if SOC_AM33XX default "9" if SA default "11" help -- 1.7.7 -- 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] arm: make FORCE_MAX_ZONEORDER configurable for TI AM33XX
On 25.09.2012 10:32, Russell King - ARM Linux wrote: > On Tue, Sep 25, 2012 at 10:26:30AM +0200, yegorsli...@googlemail.com wrote: >> From: Yegor Yefremov >> >> FORCE_MAX_ZONEORDER of 12 is needed to allocation more than 4MB >> of consistent DMA memory (da8xx frame buffer driver). > > Okay, so the patch description says "This needs to be 12 on this platform". > >> config FORCE_MAX_ZONEORDER >> -int "Maximum zone order" if ARCH_SHMOBILE >> -range 11 64 if ARCH_SHMOBILE >> +int "Maximum zone order" if ARCH_SHMOBILE || SOC_AM33XX >> +range 11 64 if ARCH_SHMOBILE || SOC_AM33XX > > but you leave it up to the user to select something that may not be > suitable. Wouldn't _just_ adding: > > default "12" if SOC_AM33XX > > after the "range", and making no other changes be good enough and match > what the patch description says? You're right. As we don't allocate anything, but increase the possible size, it shouldn't break anything. Tony is it O.K. with you? Patch sent. Yegor -- 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
query on [PATCH 2/3] usb: otg: add device tree support to otg library
Hi Marc,
This is a query regarding patch,
"usb: otg: add device tree support to otg library" [1]
It seems there is so far no consensus on this change.
Do you have ideas to proceed on this ? is there something
that I can help you to proceed on this ?
Something like this would be required for USB support
on beagle bone (AM335X), which has 2 phy's of same type.
Or is the plan to use generic phy framework instead ?
Regards
Afzal
[1] http://marc.info/?l=linux-usb&m=134574263632422&w=2
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj"��!�i
Re: [PATCH v3] ARM: OMAP4: twl-common: Support for additional devices on i2c1 bus
Hi Tony,
On 09/24/2012 08:34 PM, Tony Lindgren wrote:
> * Tony Lindgren [120924 08:44]:
>> * Peter Ujfalusi [120924 02:24]:
>>> On OMAP4 the i2c1 bus is dedicated for the PMIC and audio related devices.
>>> Manufacturers can opt to use different codec than twl6040 and also can add
>>> audio related IC to the bus (external amplifier for example on SDP4430).
>>>
>>> Make it possible to add different set of additional devices to i2c1 bus on
>>> OMAP4 boards.
>>>
>>> Signed-off-by: Peter Ujfalusi
>>> ---
>>> Hi Tony,
>>>
>>> I have refreshed the patch on top of arm-soc/for-next branch. Would it be
>>> possible to queue this patch via arm-soc so it will be in 3.7-rc1 already?
>>> Originally this patch was sent for 3.6...
>>
>> Yes sorry the platform code has been been badly ignored
>> lately.. Let's see if we can still get it in now that there's
>> -rc7 tagged.
>
> I've updated this for the sparse IRQ changes that remove irqs.h.
> Updated patch below.
Looks good to me.
Thank you,
Péter
>
> Tony
>
>
> From: Peter Ujfalusi
> Date: Mon, 24 Sep 2012 12:24:48 +0300
> Subject: [PATCH] ARM: OMAP4: twl-common: Support for additional devices on
> i2c1 bus
>
> On OMAP4 the i2c1 bus is dedicated for the PMIC and audio related devices.
> Manufacturers can opt to use different codec than twl6040 and also can add
> audio related IC to the bus (external amplifier for example on SDP4430).
>
> Make it possible to add different set of additional devices to i2c1 bus on
> OMAP4 boards.
>
> Signed-off-by: Peter Ujfalusi
> [t...@atomide.com: updated for removal of irqs.h]
> Signed-off-by: Tony Lindgren
>
> diff --git a/arch/arm/mach-omap2/board-4430sdp.c
> b/arch/arm/mach-omap2/board-4430sdp.c
> index e82098f..749ce96 100644
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -545,6 +545,14 @@ static struct twl6040_platform_data twl6040_data = {
> .audpwron_gpio = 127,
> };
>
> +static struct i2c_board_info __initdata sdp4430_i2c_1_boardinfo[] = {
> + {
> + I2C_BOARD_INFO("twl6040", 0x4b),
> + .irq = 119 + OMAP44XX_IRQ_GIC_START,
> + .platform_data = &twl6040_data,
> + },
> +};
> +
> static struct twl4030_platform_data sdp4430_twldata = {
> /* Regulators */
> .vusim = &sdp4430_vusim,
> @@ -578,8 +586,8 @@ static int __init omap4_i2c_init(void)
> TWL_COMMON_REGULATOR_CLK32KG |
> TWL_COMMON_REGULATOR_V1V8 |
> TWL_COMMON_REGULATOR_V2V1);
> - omap4_pmic_init("twl6030", &sdp4430_twldata,
> - &twl6040_data, 119 + OMAP44XX_IRQ_GIC_START);
> + omap4_pmic_init("twl6030", &sdp4430_twldata, sdp4430_i2c_1_boardinfo,
> + ARRAY_SIZE(sdp4430_i2c_1_boardinfo));
> omap_register_i2c_bus(2, 400, NULL, 0);
> omap_register_i2c_bus(3, 400, sdp4430_i2c_3_boardinfo,
> ARRAY_SIZE(sdp4430_i2c_3_boardinfo));
> diff --git a/arch/arm/mach-omap2/board-omap4panda.c
> b/arch/arm/mach-omap2/board-omap4panda.c
> index 45fe2d3..7b592d3 100644
> --- a/arch/arm/mach-omap2/board-omap4panda.c
> +++ b/arch/arm/mach-omap2/board-omap4panda.c
> @@ -264,6 +264,14 @@ static struct twl6040_platform_data twl6040_data = {
> .audpwron_gpio = 127,
> };
>
> +static struct i2c_board_info __initdata panda_i2c_1_boardinfo[] = {
> + {
> + I2C_BOARD_INFO("twl6040", 0x4b),
> + .irq = 119 + OMAP44XX_IRQ_GIC_START,
> + .platform_data = &twl6040_data,
> + },
> +};
> +
> /* Panda board uses the common PMIC configuration */
> static struct twl4030_platform_data omap4_panda_twldata;
>
> @@ -291,8 +299,8 @@ static int __init omap4_panda_i2c_init(void)
> TWL_COMMON_REGULATOR_CLK32KG |
> TWL_COMMON_REGULATOR_V1V8 |
> TWL_COMMON_REGULATOR_V2V1);
> - omap4_pmic_init("twl6030", &omap4_panda_twldata,
> - &twl6040_data, 119 + OMAP44XX_IRQ_GIC_START);
> + omap4_pmic_init("twl6030", &omap4_panda_twldata, panda_i2c_1_boardinfo,
> + ARRAY_SIZE(panda_i2c_1_boardinfo));
> omap_register_i2c_bus(2, 400, NULL, 0);
> /*
>* Bus 3 is attached to the DVI port where devices like the pico DLP
> diff --git a/arch/arm/mach-omap2/twl-common.c
> b/arch/arm/mach-omap2/twl-common.c
> index 99be94e..af93acc 100644
> --- a/arch/arm/mach-omap2/twl-common.c
> +++ b/arch/arm/mach-omap2/twl-common.c
> @@ -40,16 +40,6 @@ static struct i2c_board_info __initdata
> pmic_i2c_board_info = {
> .flags = I2C_CLIENT_WAKE,
> };
>
> -static struct i2c_board_info __initdata omap4_i2c1_board_info[] = {
> - {
> - .addr = 0x48,
> - .flags = I2C_CLIENT_WAKE,
> - },
> - {
> - I2C_BOARD_INFO("twl6040", 0x4b),
> - },
> -};
> -
> #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH
Re: query on [PATCH 2/3] usb: otg: add device tree support to otg library
Hi Afzal, On 09/25/2012 10:47 AM, Mohammed, Afzal wrote: > This is a query regarding patch, > "usb: otg: add device tree support to otg library" [1] > > It seems there is so far no consensus on this change. After I have posted this patch, Kishon had posted a better solution [2]. We discussed the patch, but he has not posted any updates since then. > Do you have ideas to proceed on this ? is there something > that I can help you to proceed on this ? I'm interested in to get these patches into the kernel soon. Kishon any news on this patch? > Something like this would be required for USB support > on beagle bone (AM335X), which has 2 phy's of same type. > > Or is the plan to use generic phy framework instead ? Yes, Kishon's patches look more generic than mine. Marc [2] https://patchwork.kernel.org/patch/1457801/ -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/1] usb: Include generic_interrupt for OMAP2_PLUS
Hi, On 25/09/2012, Felipe Balbi wrote: >> > > Not a mention of CONFIG_SOC_OMAP2430 and CONFIG_SOC_OMAP3430 did not >> > > get set (while it is not a 3430 but a 3630 I am using). Maybe >> > > CONFIG_ARCH_OMAP3 would have been a better choice then? >> > >> > that's quite f**ked up. Tony, why doesn't SOC_OMAP3430 get set for all >> > OMAP3 boards ? And another question: why don't we have a matching >> > SOC_OMAP3530, SOC_OMAP3630 and so on ? >> >> ARCH_OMAP3 will probably eventually just disappear and >> be replaced with ARCH_OMAP2PLUS + SOC_. But there's >> no need to do it right now as most of that should be >> internal to arch/arm/mach-omap2 anyways. I would just >> set the driver to depend on ARCH_OMAP2PLUS, and rely on >> the platform_data and DT to do something if specified. >> That means that on 2420 musb should not probe unless >> tusb6010 in specified. >> >> It seems that things like fifo_mode and generic_interrupt >> can all be set during the probe based on the platform_data >> or DT passed information? > > Then maybe it's best to just remove the ifdefs and always provide > generic_interrupt() ? > > Anyone against it ? Well it seems there are only two drivers that use it omap2430 and ux500. Maybe we somehow link it to the drivers that need it? (I might have missed other drivers but it looks like it is just those two) Regards, Philippe -- 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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.
On Tue, Sep 25, 2012 at 11:31:20AM +0300, Felipe Balbi wrote: > On Tue, Sep 25, 2012 at 09:30:29AM +0100, Russell King - ARM Linux wrote: > > How is this happening? I think that needs proper investigation - or if > > it's had more investigation, then the results needs to be included in > > the commit description so that everyone can understand the issue here. > > > > We should not be resuming a device which hasn't been suspended. Maybe > > the runtime PM enable sequence is wrong, and that's what should be fixed > > instead? > > > > This sequence in the probe() function: > > > > pm_runtime_irq_safe(&pdev->dev); > > pm_runtime_enable(&pdev->dev); > > pm_runtime_get_sync(&pdev->dev); > > > > would enable runtime PM while the s/w state indicates that it's disabled, > > and then that pm_runtime_get_sync() will want to resume the device. See > > the section "5. Runtime PM Initialization, Device Probing and Removal" > > in Documentation/power/runtime_pm.txt, specifically the second paragraph > > of that section. > > that was tested. It worked in pandaboard but didn't work on beagleboard > XM. Sourav tried to start a discussion about that, but it simply died... > > In any case, pm_runtime_get_sync() in probe will always call > runtime_resume callback, right ? Well, if the runtime PM state says it's suspended, and then you enable runtime PM, the first call to pm_runtime_get_sync() will trigger a resume attempt. The patch description is complaining about resume events without there being a preceding suspend event. This could well be why. -- 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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.
On Tue, Sep 25, 2012 at 10:12:28AM +0100, Russell King - ARM Linux wrote: > On Tue, Sep 25, 2012 at 11:31:20AM +0300, Felipe Balbi wrote: > > On Tue, Sep 25, 2012 at 09:30:29AM +0100, Russell King - ARM Linux wrote: > > > How is this happening? I think that needs proper investigation - or if > > > it's had more investigation, then the results needs to be included in > > > the commit description so that everyone can understand the issue here. > > > > > > We should not be resuming a device which hasn't been suspended. Maybe > > > the runtime PM enable sequence is wrong, and that's what should be fixed > > > instead? > > > > > > This sequence in the probe() function: > > > > > > pm_runtime_irq_safe(&pdev->dev); > > > pm_runtime_enable(&pdev->dev); > > > pm_runtime_get_sync(&pdev->dev); > > > > > > would enable runtime PM while the s/w state indicates that it's disabled, > > > and then that pm_runtime_get_sync() will want to resume the device. See > > > the section "5. Runtime PM Initialization, Device Probing and Removal" > > > in Documentation/power/runtime_pm.txt, specifically the second paragraph > > > of that section. > > > > that was tested. It worked in pandaboard but didn't work on beagleboard > > XM. Sourav tried to start a discussion about that, but it simply died... > > > > In any case, pm_runtime_get_sync() in probe will always call > > runtime_resume callback, right ? > > Well, if the runtime PM state says it's suspended, and then you enable > runtime PM, the first call to pm_runtime_get_sync() will trigger a resume > attempt. The patch description is complaining about resume events without > there being a preceding suspend event. > > This could well be why. that's most likely, of course. But should we cause a regression to beagleboard XM because of that ? Also, if you look into chapter 9 of the runtime_pm documentation, starting on line 822 you'll see documentation suggests the use of mystruct->is_suspended flag. -- balbi signature.asc Description: Digital signature
Re: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.
On Tue, Sep 25, 2012 at 12:11:14PM +0300, Felipe Balbi wrote: > On Tue, Sep 25, 2012 at 10:12:28AM +0100, Russell King - ARM Linux wrote: > > On Tue, Sep 25, 2012 at 11:31:20AM +0300, Felipe Balbi wrote: > > > On Tue, Sep 25, 2012 at 09:30:29AM +0100, Russell King - ARM Linux wrote: > > > > How is this happening? I think that needs proper investigation - or if > > > > it's had more investigation, then the results needs to be included in > > > > the commit description so that everyone can understand the issue here. > > > > > > > > We should not be resuming a device which hasn't been suspended. Maybe > > > > the runtime PM enable sequence is wrong, and that's what should be fixed > > > > instead? > > > > > > > > This sequence in the probe() function: > > > > > > > > pm_runtime_irq_safe(&pdev->dev); > > > > pm_runtime_enable(&pdev->dev); > > > > pm_runtime_get_sync(&pdev->dev); > > > > > > > > would enable runtime PM while the s/w state indicates that it's > > > > disabled, > > > > and then that pm_runtime_get_sync() will want to resume the device. See > > > > the section "5. Runtime PM Initialization, Device Probing and Removal" > > > > in Documentation/power/runtime_pm.txt, specifically the second paragraph > > > > of that section. > > > > > > that was tested. It worked in pandaboard but didn't work on beagleboard > > > XM. Sourav tried to start a discussion about that, but it simply died... > > > > > > In any case, pm_runtime_get_sync() in probe will always call > > > runtime_resume callback, right ? > > > > Well, if the runtime PM state says it's suspended, and then you enable > > runtime PM, the first call to pm_runtime_get_sync() will trigger a resume > > attempt. The patch description is complaining about resume events without > > there being a preceding suspend event. > > > > This could well be why. > > that's most likely, of course. But should we cause a regression to > beagleboard XM because of that ? What would cause a regression on beagleboard XM? I have not suggested any change other than more investigation of the issue and a fuller patch description - yet you're screaming (idiotically IMHO) that mere investigation would break beagleboard. Well, if it's _that_ fragile, that mere investigation of this issue by someone elsewhere on the planet would break your beagleboard, maybe it deserves to be broken! -- 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] OMAPDSS: Cleanup DSSDBG with dynamic pr_debug function
>> diff --git a/drivers/video/omap2/dss/apply.c
>> b/drivers/video/omap2/dss/apply.c
>> index 6354bb8..cb86d94 100644
>> --- a/drivers/video/omap2/dss/apply.c
>> +++ b/drivers/video/omap2/dss/apply.c
>> @@ -559,7 +559,7 @@ static void dss_ovl_write_regs(struct omap_overlay *ovl)
>> struct mgr_priv_data *mp;
>> int r;
>>
>> - DSSDBGF("%d", ovl->id);
>> + DSSDBG("%d", ovl->id);
>
> I don't think this is good. It's true that dyn-debug can print the
> function name, but that's optional. The debug message should be somehow
> sensible independently, but in this case only a number is printed which
> is totally meaningless.
>
> Either the messages should be modified to give a hint what's going on,
> or the DSSDBGF could be kept for now. In the above case the debug
> message could be something like "writing ovl %d regs".
>
> However, I think it'd be easier just to keep the DSSDBGF for now, and
> remove it gradually.
>
>> if (!op->enabled || !op->info_dirty)
>> return;
>> @@ -594,7 +594,7 @@ static void dss_ovl_write_regs_extra(struct omap_overlay
>> *ovl)
>> struct ovl_priv_data *op = get_ovl_priv(ovl);
>> struct mgr_priv_data *mp;
>>
>> - DSSDBGF("%d", ovl->id);
>> + DSSDBG("%d", ovl->id);
>>
>> if (!op->extra_info_dirty)
>> return;
>> @@ -618,7 +618,7 @@ static void dss_mgr_write_regs(struct
>> omap_overlay_manager *mgr)
>> struct mgr_priv_data *mp = get_mgr_priv(mgr);
>> struct omap_overlay *ovl;
>>
>> - DSSDBGF("%d", mgr->id);
>> + DSSDBG("%d", mgr->id);
>>
>> if (!mp->enabled)
>> return;
>> @@ -644,7 +644,7 @@ static void dss_mgr_write_regs_extra(struct
>> omap_overlay_manager *mgr)
>> {
>> struct mgr_priv_data *mp = get_mgr_priv(mgr);
>>
>> - DSSDBGF("%d", mgr->id);
>> + DSSDBG("%d", mgr->id);
>>
>> if (!mp->extra_info_dirty)
>> return;
>> diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
>> index 8d815e3..8304cc6b 100644
>> --- a/drivers/video/omap2/dss/dsi.c
>> +++ b/drivers/video/omap2/dss/dsi.c
>> @@ -1525,8 +1525,6 @@ int dsi_pll_set_clock_div(struct platform_device
>> *dsidev,
>> u8 regn_start, regn_end, regm_start, regm_end;
>> u8 regm_dispc_start, regm_dispc_end, regm_dsi_start, regm_dsi_end;
>>
>> - DSSDBGF();
>> -
>> dsi->current_cinfo.clkin = cinfo->clkin;
>> dsi->current_cinfo.fint = cinfo->fint;
>> dsi->current_cinfo.clkin4ddr = cinfo->clkin4ddr;
>> @@ -2334,8 +2332,6 @@ static int dsi_cio_init(struct omap_dss_device *dssdev)
>> int r;
>> u32 l;
>>
>> - DSSDBGF();
>> -
>> r = dss_dsi_enable_pads(dsi->module_id, dsi_get_lane_mask(dssdev));
>> if (r)
>> return r;
>> @@ -2686,7 +2682,7 @@ static void dsi_vc_initial_config(struct
>> platform_device *dsidev, int channel)
>> {
>> u32 r;
>>
>> - DSSDBGF("%d", channel);
>> + DSSDBG("%d", channel);
>>
>> r = dsi_read_reg(dsidev, DSI_VC_CTRL(channel));
>>
>> @@ -2718,7 +2714,7 @@ static int dsi_vc_config_source(struct platform_device
>> *dsidev, int channel,
>> if (dsi->vc[channel].source == source)
>> return 0;
>>
>> - DSSDBGF("%d", channel);
>> + DSSDBG("%d", channel);
>>
>> dsi_sync_vc(dsidev, channel);
>>
>> @@ -3475,7 +3471,7 @@ static int dsi_enter_ulps(struct platform_device
>> *dsidev)
>> int r, i;
>> unsigned mask;
>>
>> - DSSDBGF();
>> + DSSDBG("");
>
> This debug message is even less meaningful than the overlay number =).
> Again, I think either keep the DSSDBGF, or print something sensible,
> like "entering ULPS".
>
I dont think it would be wise enough to update code for one and keep
the older version for another when both DSSDBG and DSSDBGF are almost
one and the same. Its better to add something meaningful to the prints
as you have mentioned like "writing ovl %d regs" and "DSI entering
ULPS".
>>
>> WARN_ON(!dsi_bus_is_locked(dsidev));
>>
>> @@ -4184,7 +4180,7 @@ int omapdss_dsi_set_clocks(struct omap_dss_device
>> *dssdev,
>> unsigned long pck;
>> int r;
>>
>> - DSSDBGF("ddr_clk %lu, lp_clk %lu", ddr_clk, lp_clk);
>> + DSSDBG("ddr_clk %lu, lp_clk %lu", ddr_clk, lp_clk);
>>
>> mutex_lock(&dsi->lock);
>>
>> diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
>> index 5e9fd769..3a2caab 100644
>> --- a/drivers/video/omap2/dss/dss.h
>> +++ b/drivers/video/omap2/dss/dss.h
>> @@ -29,38 +29,20 @@
>>
>> #ifdef DEBUG
>> extern bool dss_debug;
>
> You still left the dss_debug option here, even if it's not used by the
> DSSDBG anymore. What's your plan about this?
>
> Tomi
>
dss_debug and DEBUG need to remain here as it is being used by
functions omap_dispc_irq_handler() and _dsi_print_reset_status() in
dispc.c and dsi.c. I am little bit unsure of how to deal with it.
There could be a single print in omap_dispc_irq_handler() but it is a
bit tricky in _dsi_print
[PATCHv5 00/10] ARM: OMAP: PM usecounting changes
Hi, Changes compared to previous version: - Fixed OMAP4 support (patches 7-10) - Dropped debugging support from this set for now - Rebased on top of 3.6-rc5 + func-pwrst + omap4-ret code (omap4 support easier to test with these) - Patch #1: * dropped clkdm_usecount_inc / clkdm_usecount_dec APIs * clkdm_clk_enable / disable are used now instead * some code ordering changed for the new setup to work properly * changed BUG_ON calls to WARN_ON - Patch #2: * added spinlock for protecting voltdm callbacks * pwrdm lock extended to protect pwrdm callbacks - Patch #3: * dropped generic API call for the cpu pwrdm idle / wakeup * instead use pwrdm_clkdm_enable / disable calls directly from PM code * omap4 support fixed to work properly with SMP, added omap4 specific CPU pwrdm idle / wakeup calls for this purpose - Patch #4: * no changes * added 'Reviewed-by' tag for Rajendra - Patch #5: * no changes, just rebase - Patch #6: * no changes Tested with OMAP3 beagle, omap4460 GP panda + omap4430 EMU blaze boards. I will be posting new versions for the voltdm fixes + auto retention + panda board tps6236x support code later on today, which are based on top of this set. Branch also available here: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.6-rc5-pwrdm-changes-v5 -Tero -- 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
[PATCHv5 01/10] ARM: OMAP3+: voltage/pwrdm/clkdm/clock add recursive usecount tracking
This patch fixes the usecount tracking for omap3+, previously the
usecount numbers were rather bogus and were not really useful for
any purpose. Now usecount numbers track the number of really active
clients on each domain. This patch also adds support for usecount
tracking on powerdomain level and autoidle flag for clocks that
are hardware controlled and should be skipped in usecount
calculations.
Signed-off-by: Tero Kristo
Cc: Paul Walmsley
Cc: Kevin Hilman
---
arch/arm/mach-omap2/clkt_iclk.c | 21 ++
arch/arm/mach-omap2/clockdomain.c | 15 -
arch/arm/mach-omap2/dpll3xxx.c | 19
arch/arm/mach-omap2/powerdomain.c | 35 +++
arch/arm/mach-omap2/powerdomain.h |4 +++
arch/arm/plat-omap/clock.c |6 +
arch/arm/plat-omap/include/plat/clock.h |2 +
7 files changed, 101 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt_iclk.c b/arch/arm/mach-omap2/clkt_iclk.c
index 3d43fba..1afc599 100644
--- a/arch/arm/mach-omap2/clkt_iclk.c
+++ b/arch/arm/mach-omap2/clkt_iclk.c
@@ -21,6 +21,7 @@
#include "clock2xxx.h"
#include "cm2xxx_3xxx.h"
#include "cm-regbits-24xx.h"
+#include "clockdomain.h"
/* Private functions */
@@ -34,6 +35,16 @@ void omap2_clkt_iclk_allow_idle(struct clk *clk)
v = __raw_readl((__force void __iomem *)r);
v |= (1 << clk->enable_bit);
__raw_writel(v, (__force void __iomem *)r);
+
+ /* Remove this clock from parent clockdomain usecounts */
+ if (clk->usecount && clk->clkdm)
+ clkdm_clk_disable(clk->clkdm, clk);
+
+ /*
+* Mark as autoidle, so we continue to ignore this clock in
+* parent clkdm usecount calculations
+*/
+ clk->autoidle = true;
}
/* XXX */
@@ -46,6 +57,16 @@ void omap2_clkt_iclk_deny_idle(struct clk *clk)
v = __raw_readl((__force void __iomem *)r);
v &= ~(1 << clk->enable_bit);
__raw_writel(v, (__force void __iomem *)r);
+
+ /*
+* Disable autoidle flag so further clkdm usecounts take this
+* clock into account
+*/
+ clk->autoidle = false;
+
+ /* Add clock back to parent clockdomain usecount */
+ if (clk->usecount && clk->clkdm)
+ clkdm_clk_enable(clk->clkdm, clk);
}
/* Public data */
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index 8664f5a..8c8518c 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -910,6 +910,7 @@ bool clkdm_in_hwsup(struct clockdomain *clkdm)
static int _clkdm_clk_hwmod_enable(struct clockdomain *clkdm)
{
unsigned long flags;
+ int usecount;
if (!clkdm || !arch_clkdm || !arch_clkdm->clkdm_clk_enable)
return -EINVAL;
@@ -919,11 +920,14 @@ static int _clkdm_clk_hwmod_enable(struct clockdomain
*clkdm)
* should be called for every clock instance or hwmod that is
* enabled, so the clkdm can be force woken up.
*/
- if ((atomic_inc_return(&clkdm->usecount) > 1) && autodeps)
+ usecount = atomic_inc_return(&clkdm->usecount);
+ if (usecount > 1 && autodeps)
return 0;
spin_lock_irqsave(&clkdm->lock, flags);
arch_clkdm->clkdm_clk_enable(clkdm);
+ if (usecount == 1)
+ pwrdm_clkdm_enable(clkdm->pwrdm.ptr);
pwrdm_state_switch(clkdm->pwrdm.ptr);
spin_unlock_irqrestore(&clkdm->lock, flags);
@@ -949,6 +953,7 @@ static int _clkdm_clk_hwmod_disable(struct clockdomain
*clkdm)
spin_lock_irqsave(&clkdm->lock, flags);
arch_clkdm->clkdm_clk_disable(clkdm);
+ pwrdm_clkdm_disable(clkdm->pwrdm.ptr);
pwrdm_state_switch(clkdm->pwrdm.ptr);
spin_unlock_irqrestore(&clkdm->lock, flags);
@@ -981,6 +986,10 @@ int clkdm_clk_enable(struct clockdomain *clkdm, struct clk
*clk)
if (!clk)
return -EINVAL;
+ /* If autoidle clock, do not update clkdm usecounts */
+ if (clk->autoidle)
+ return 0;
+
return _clkdm_clk_hwmod_enable(clkdm);
}
@@ -1007,6 +1016,10 @@ int clkdm_clk_disable(struct clockdomain *clkdm, struct
clk *clk)
if (!clk)
return -EINVAL;
+ /* If autoidle clock, do not update clkdm usecounts */
+ if (clk->autoidle)
+ return 0;
+
return _clkdm_clk_hwmod_disable(clkdm);
}
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index b9c8d2f..da660d2 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -34,6 +34,7 @@
#include "clock.h"
#include "cm2xxx_3xxx.h"
#include "cm-regbits-34xx.h"
+#include "clockdomain.h"
/* CM_AUTOIDLE_PLL*.AUTO_* bit values */
#define DPLL_AUTOIDLE_DISABLE 0x0
@@ -571,6 +572,15 @@ void omap3_dpll_allow_idle(struct clk *clk)
v |= DPLL_AUTOIDLE_LO
[PATCHv5 02/10] ARM: OMAP3+: voltage: add support for voltagedomain usecounts
These are updated based on powerdomain usecounts. Also added support
for voltdm->sleep and voltdm->wakeup calls that will be invoked once
voltagedomain enters sleep or wakes up based on usecount numbers. These
will be used for controlling voltage scaling functionality.
Signed-off-by: Tero Kristo
Cc: Paul Walmsley
Cc: Kevin Hilman
---
arch/arm/mach-omap2/powerdomain.c | 17 +-
arch/arm/mach-omap2/voltage.c | 62 +
arch/arm/mach-omap2/voltage.h | 13
3 files changed, 91 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index ba49029..ca54aec 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -1475,10 +1477,16 @@ int pwrdm_state_switch(struct powerdomain *pwrdm)
*/
void pwrdm_clkdm_enable(struct powerdomain *pwrdm)
{
+ unsigned long flags;
+
if (!pwrdm)
return;
- atomic_inc(&pwrdm->usecount);
+ if (atomic_inc_return(&pwrdm->usecount) == 1) {
+ spin_lock_irqsave(&pwrdm->lock, flags);
+ voltdm_pwrdm_enable(pwrdm->voltdm.ptr);
+ spin_unlock_irqrestore(&pwrdm->lock, flags);
+ }
}
/**
@@ -1492,12 +1500,19 @@ void pwrdm_clkdm_enable(struct powerdomain *pwrdm)
void pwrdm_clkdm_disable(struct powerdomain *pwrdm)
{
int val;
+ unsigned long flags;
if (!pwrdm)
return;
val = atomic_dec_return(&pwrdm->usecount);
+ if (!val) {
+ spin_lock_irqsave(&pwrdm->lock, flags);
+ voltdm_pwrdm_disable(pwrdm->voltdm.ptr);
+ spin_unlock_irqrestore(&pwrdm->lock, flags);
+ }
+
WARN_ON(val < 0);
}
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 4dc60e8..9eb1a4b 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -340,6 +340,67 @@ int voltdm_add_pwrdm(struct voltagedomain *voltdm, struct
powerdomain *pwrdm)
}
/**
+ * voltdm_pwrdm_enable - increase usecount for a voltagedomain
+ * @voltdm: struct voltagedomain * to increase count for
+ *
+ * Increases usecount for a given voltagedomain. If the usecount reaches
+ * 1, the domain is awakened from idle and the function will call the
+ * voltagedomain->wakeup callback for this domain.
+ */
+void voltdm_pwrdm_enable(struct voltagedomain *voltdm)
+{
+ unsigned long flags;
+
+ if (!voltdm)
+ return;
+
+ if (atomic_inc_return(&voltdm->usecount) == 1 && voltdm->wakeup) {
+ spin_lock_irqsave(&voltdm->lock, flags);
+ voltdm->wakeup(voltdm);
+ spin_unlock_irqrestore(&voltdm->lock, flags);
+ }
+}
+
+/**
+ * voltdm_pwrdm_disable - decrease usecount for a voltagedomain
+ * @voltdm: struct voltagedomain * to decrease count for
+ *
+ * Decreases the usecount for a given voltagedomain. If the usecount
+ * reaches zero, the domain can idle and the function will call the
+ * voltagedomain->sleep callback, and calculate the overall target
+ * state for the voltagedomain.
+ */
+void voltdm_pwrdm_disable(struct voltagedomain *voltdm)
+{
+ u8 target_state = PWRDM_POWER_OFF;
+ int state;
+ struct powerdomain *pwrdm;
+ int val;
+ unsigned long flags;
+
+ if (!voltdm)
+ return;
+
+ val = atomic_dec_return(&voltdm->usecount);
+
+ WARN_ON(val < 0);
+
+ if (val == 0) {
+ spin_lock_irqsave(&voltdm->lock, flags);
+ /* Determine target state for voltdm */
+ list_for_each_entry(pwrdm, &voltdm->pwrdm_list, voltdm_node) {
+ state = pwrdm_read_next_pwrst(pwrdm);
+ if (state > target_state)
+ target_state = state;
+ }
+ voltdm->target_state = target_state;
+ if (voltdm->sleep)
+ voltdm->sleep(voltdm);
+ spin_unlock_irqrestore(&voltdm->lock, flags);
+ }
+}
+
+/**
* voltdm_for_each_pwrdm - call function for each pwrdm in a voltdm
* @voltdm: struct voltagedomain * to iterate over
* @fn: callback function *
@@ -402,6 +463,7 @@ static int _voltdm_register(struct voltagedomain *voltdm)
INIT_LIST_HEAD(&voltdm->pwrdm_list);
list_add(&voltdm->node, &voltdm_list);
+ spin_lock_init(&voltdm->lock);
pr_debug("voltagedomain: registered %s\n", voltdm->name);
return 0;
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 0ac2caf..7f4f99d 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -15,6 +15,7 @@
#define __ARCH_ARM_MACH_OMAP2_VOLTAGE_H
#include
+#include
#include
@@ -56,10 +57,14 @@ struct omap_vfsm_instance {
* @pwrdm_list: list_head linking all powerdomains in this voltagedomain
* @vc: pointer to VC channel associated w
[PATCHv5 03/10] ARM: OMAP3: add manual control for mpu / core pwrdm usecounting
mpu / core powerdomain usecounts are now statically increased
by 1 during MPU activity. This allows the domains to reflect
actual usage, and will allow the usecount to reach 0 just before
all CPUs are ready to idle. Proper powerdomain usecounts are
propageted to voltagedomain level also, and will allow vc
callbacks to be triggered at right point of time.
Signed-off-by: Tero Kristo
Cc: Paul Walmsley
Cc: Kevin Hilman
---
arch/arm/mach-omap2/common.h |6 ++
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 72 -
arch/arm/mach-omap2/omap-smp.c|2 +
arch/arm/mach-omap2/pm34xx.c | 21
4 files changed, 100 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 6ea837a..a445a02 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -292,6 +292,8 @@ extern int omap4_finish_suspend(unsigned long cpu_state);
extern void omap4_cpu_resume(void);
extern int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state);
extern u32 omap4_mpuss_read_prev_context_state(void);
+extern void omap4_pm_cpu_online(void);
+extern void omap4_pm_cpu_offline(void);
#else
static inline int omap4_enter_lowpower(unsigned int cpu,
unsigned int power_state)
@@ -323,6 +325,10 @@ static inline u32 omap4_mpuss_read_prev_context_state(void)
{
return 0;
}
+
+static inline void omap4_pm_cpu_online(void) { }
+
+static inline void omap4_pm_cpu_offline(void) { }
#endif
struct omap_sdrc_params;
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 230bdcd..0ad2337 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -72,8 +72,9 @@ struct omap4_cpu_pm_info {
};
static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
-static struct powerdomain *mpuss_pd;
+static struct powerdomain *mpuss_pd, *core_pd;
static void __iomem *sar_base;
+static atomic_t __initdata init_cpu_online_count;
/*
* Program the wakeup routine address for the CPU0 and CPU1
@@ -216,6 +217,50 @@ static void save_l2x0_context(void)
#endif
/**
+ * omap4_pm_cpu_online - increase the number of online CPUs
+ *
+ * This function increases the usecounts for MPU and CORE powerdomains,
+ * which allows the domains to properly reflect usage with online CPUs
+ * also. CORE powerdomain usecount is increased, as MPU is using memories,
+ * which are powered through CORE powerdomain (SDRAM). If this function is
+ * called before PM init has completed (mpuss_pd / core_pd are not defined),
+ * a temporary init time variable is increased instead; its contents
+ * will be moved to the powerdomain usecounts once PM init completes.
+ */
+void omap4_pm_cpu_online(void)
+{
+ if (!mpuss_pd || !core_pd) {
+ atomic_inc(&init_cpu_online_count);
+ return;
+ }
+
+ pwrdm_clkdm_enable(mpuss_pd);
+ pwrdm_clkdm_enable(core_pd);
+}
+
+/**
+ * omap4_pm_cpu_offline - decrease the number of online CPUs
+ *
+ * This function decreases the usecounts for MPU and CORE powerdomains,
+ * which allows the domains to properly reflect usage with online CPUs
+ * also. CORE powerdomain usecount is decreased, as MPU is using memories,
+ * which are powered through CORE powerdomain (SDRAM). If this function is
+ * called before PM init has completed (mpuss_pd / core_pd are not defined),
+ * a temporary init time variable is increased instead; its contents
+ * will be moved to the powerdomain usecounts once PM init completes.
+ */
+void omap4_pm_cpu_offline(void)
+{
+ if (!mpuss_pd || !core_pd) {
+ atomic_dec(&init_cpu_online_count);
+ return;
+ }
+
+ pwrdm_clkdm_disable(mpuss_pd);
+ pwrdm_clkdm_disable(core_pd);
+}
+
+/**
* omap4_enter_lowpower: OMAP4 MPUSS Low Power Entry Function
* The purpose of this function is to manage low power programming
* of OMAP4 MPUSS subsystem
@@ -274,11 +319,17 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
scu_pwrst_prepare(cpu, power_state);
l2x0_pwrst_prepare(cpu, save_state);
+ /* Decrement usecounts for MPU and CORE pd as we are entering idle */
+ omap4_pm_cpu_offline();
+
/*
* Call low level function with targeted low power state.
*/
cpu_suspend(save_state, omap4_finish_suspend);
+ /* Increment usecounts for MPU and CORE pd as we are leaving idle */
+ omap4_pm_cpu_online();
+
/*
* Restore the CPUx power state to ON otherwise CPUx
* power domain can transitions to programmed low power
@@ -315,6 +366,8 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned
int power_state)
set_cpu_wakeup_addr(cpu, virt_to_phys(pm_info->secondary_startup));
scu_pwrst_prepare(cpu, power_state);
+ omap4_
[PATCHv5 05/10] ARM: OMAP: clockdomain: add support for preventing autodep delete
Some clockdomains bug out if their autodeps are deleted before idle.
This happens namely with OMAP3 PER domain, it will bug out if it
doesn't have wakedeps enabled when it enters off-mode. This patch
adds support for new flag 'CLKDM_NO_AUTODEP_DISABLE' which does this.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/clockdomain.c |3 +++
arch/arm/mach-omap2/clockdomain.h |4
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index 8c8518c..2fa433a 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -201,6 +201,9 @@ void _clkdm_del_autodeps(struct clockdomain *clkdm)
if (!autodeps || clkdm->flags & CLKDM_NO_AUTODEPS)
return;
+ if (clkdm->flags & CLKDM_NO_AUTODEP_DISABLE)
+ return;
+
for (autodep = autodeps; autodep->clkdm.ptr; autodep++) {
if (IS_ERR(autodep->clkdm.ptr))
continue;
diff --git a/arch/arm/mach-omap2/clockdomain.h
b/arch/arm/mach-omap2/clockdomain.h
index 5601dc1..9b8733e 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -34,6 +34,9 @@
* CLKDM_ACTIVE_WITH_MPU: The PRCM guarantees that this clockdomain is
* active whenever the MPU is active. True for interconnects and
* the WKUP clockdomains.
+ * CLKDM_NO_AUTODEP_DISABLE: Prevent clockdomain code from deleting autodeps.
+ * Needed for PER domain on omap3, as it will bug out with off-mode if
+ * wakedeps are removed.
*/
#define CLKDM_CAN_FORCE_SLEEP (1 << 0)
#define CLKDM_CAN_FORCE_WAKEUP (1 << 1)
@@ -41,6 +44,7 @@
#define CLKDM_CAN_DISABLE_AUTO (1 << 3)
#define CLKDM_NO_AUTODEPS (1 << 4)
#define CLKDM_ACTIVE_WITH_MPU (1 << 5)
+#define CLKDM_NO_AUTODEP_DISABLE (1 << 6)
#define CLKDM_CAN_HWSUP(CLKDM_CAN_ENABLE_AUTO |
CLKDM_CAN_DISABLE_AUTO)
#define CLKDM_CAN_SWSUP(CLKDM_CAN_FORCE_SLEEP |
CLKDM_CAN_FORCE_WAKEUP)
--
1.7.4.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
[PATCHv5 04/10] ARM: OMAP3: set autoidle flag for sdrc_ick
sdrc_ick doesn't have autoidle flag on HW, but is always automatically
idled. Thus mark the autoidle flag statically as true for it to reflect
hardware behavior. The clock will no longer show as active in usecount
dumps and will allow the voltdm->sleep / wakeup calls to work properly.
Signed-off-by: Tero Kristo
Cc: Paul Walmsley
Cc: Kevin Hilman
Reviewed-by: Rajendra Nayak
---
arch/arm/mach-omap2/clock3xxx_data.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 83bed9a..1ddc7fc 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -1739,6 +1739,7 @@ static struct clk sdrc_ick = {
.flags = ENABLE_ON_INIT,
.clkdm_name = "core_l3_clkdm",
.recalc = &followparent_recalc,
+ .autoidle = true,
};
static struct clk gpmc_fck = {
--
1.7.4.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
[PATCHv5 06/10] ARM: OMAP3: do not delete per_clkdm autodeps during idle
Previously, PER clock domain was always enabled, as the usecounts
for this domain incorrectly always showed positive value. On HW
level though, the domain enters idle as it is set in HW supervised
mode. Now, when the usecounts reflect real values, PER domain
will be put to HWSUP sleep mode, which means its autodeps are deleted.
Removing wakedeps for PER domain will cause multiple problems.
First of all, coming back from idle, PER domain remains idle as the
wakedeps have been disabled for the domain, and this causes a crash
with the GPIO code, as the resume code attempts to access domain
which is not active. Just enabling the interface clocks for the GPIO
does not help, as they are autoidled and don't bring the domain out
of idle. Secondly, there are multiple erratas for omap3, which say
that the wakedeps should be enabled for the PER domain, see e.g.
errata i582 for omap3630.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/clockdomains3xxx_data.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomains3xxx_data.c
b/arch/arm/mach-omap2/clockdomains3xxx_data.c
index 56089c4..3b3c524 100644
--- a/arch/arm/mach-omap2/clockdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/clockdomains3xxx_data.c
@@ -370,7 +370,7 @@ static struct clockdomain usbhost_am35x_clkdm = {
static struct clockdomain per_clkdm = {
.name = "per_clkdm",
.pwrdm = { .name = "per_pwrdm" },
- .flags = CLKDM_CAN_HWSUP_SWSUP,
+ .flags = CLKDM_CAN_HWSUP_SWSUP | CLKDM_NO_AUTODEP_DISABLE,
.dep_bit= OMAP3430_EN_PER_SHIFT,
.wkdep_srcs = per_wkdeps,
.sleepdep_srcs = per_sleepdeps,
--
1.7.4.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
[PATCHv5 08/10] ARM: OMAP4: hwmod: add support for hwmod autoidle flag
If a hwmod is in HWAUTO mode, it will idle automatically and should not
be accounted for in the clkdm / pwrdm usecounts. Thus, flag modules in
such mode as autoidle during init, and ignore these in subsequent
usecount calculations.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/clockdomain.c|6 ++
arch/arm/mach-omap2/omap_hwmod.c |3 +++
arch/arm/plat-omap/include/plat/omap_hwmod.h |2 ++
3 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index 2fa433a..0ee7d09a 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -1055,6 +1055,9 @@ int clkdm_hwmod_enable(struct clockdomain *clkdm, struct
omap_hwmod *oh)
if (!oh)
return -EINVAL;
+ if (oh->flags & HWMOD_AUTOIDLE)
+ return 0;
+
return _clkdm_clk_hwmod_enable(clkdm);
}
@@ -1086,6 +1089,9 @@ int clkdm_hwmod_disable(struct clockdomain *clkdm, struct
omap_hwmod *oh)
if (!oh)
return -EINVAL;
+ if (oh->flags & HWMOD_AUTOIDLE)
+ return 0;
+
return _clkdm_clk_hwmod_disable(clkdm);
}
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index f826917..6807b02 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2377,6 +2377,9 @@ static int __init _register(struct omap_hwmod *oh)
INIT_LIST_HEAD(&oh->slave_ports);
spin_lock_init(&oh->_lock);
+ if (cpu_is_omap44xx() && oh->prcm.omap4.modulemode == MODULEMODE_HWCTRL)
+ oh->flags |= HWMOD_AUTOIDLE;
+
oh->_state = _HWMOD_STATE_REGISTERED;
/*
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 0f840a9..36130f9 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -440,6 +440,7 @@ struct omap_hwmod_omap4_prcm {
* in order to complete the reset. Optional clocks will be disabled
* again after the reset.
* HWMOD_16BIT_REG: Module has 16bit registers
+ * HWMOD_AUTOIDLE: Module is controlled automatically by hardware
*/
#define HWMOD_SWSUP_SIDLE (1 << 0)
#define HWMOD_SWSUP_MSTANDBY (1 << 1)
@@ -450,6 +451,7 @@ struct omap_hwmod_omap4_prcm {
#define HWMOD_NO_IDLEST(1 << 6)
#define HWMOD_CONTROL_OPT_CLKS_IN_RESET(1 << 7)
#define HWMOD_16BIT_REG(1 << 8)
+#define HWMOD_AUTOIDLE (1 << 9)
/*
* omap_hwmod._int_flags definitions
--
1.7.4.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
[PATCHv5 07/10] ARM: OMAP4: clock data: set autoidle flag for dss_fck
dss_fck is currently being used improperly within the hwmod database
as an interface clock for DSS hwmods. This causes the dss_fck to
be enabled even if the dss powerdomain itself is idle, resulting
in wrong data within the powerdomain usecounts. Marked dss_fck as
autoidle which makes the clock to disappear from usecounts for now.
This patch can be reverted once the interface clocks for DSS hwmods
have been properly fixed.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/clock44xx_data.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index d7f55e4..95834d7 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -1408,6 +1408,7 @@ static struct clk dss_fck = {
.clkdm_name = "l3_dss_clkdm",
.parent = &l3_div_ck,
.recalc = &followparent_recalc,
+ .autoidle = true,
};
static struct clk efuse_ctrl_cust_fck = {
--
1.7.4.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
[PATCHv5 09/10] ARM: OMAP4: hwmod data: set mpu hwmod modulemode to hwauto
This makes sure it is handled as autoidle type by the usecounting.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 2d13b33..367de25 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2492,6 +2492,7 @@ static struct omap_hwmod omap44xx_mpu_hwmod = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_MPU_MPU_CLKCTRL_OFFSET,
.context_offs = OMAP4_RM_MPU_MPU_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
},
},
};
--
1.7.4.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
[PATCHv5 10/10] ARM: OMAP4: clock data: flag hw controlled clocks as autoidle
This makes sure these clocks are ignored by the clkdm / pwrdm usecounting.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/clock44xx_data.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 95834d7..d2fb4e8 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3356,8 +3356,11 @@ int __init omap4xxx_clk_init(void)
*/
for (c = omap44xx_clks; c < omap44xx_clks + ARRAY_SIZE(omap44xx_clks);
- c++)
+ c++) {
+ if (c->lk.clk->enable_bit == OMAP4430_MODULEMODE_HWCTRL)
+ c->lk.clk->autoidle = true;
clk_preinit(c->lk.clk);
+ }
for (c = omap44xx_clks; c < omap44xx_clks + ARRAY_SIZE(omap44xx_clks);
c++)
--
1.7.4.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: [PATCHv5 02/10] ARM: OMAP3+: voltage: add support for voltagedomain usecounts
On Tue, Sep 25, 2012 at 12:32:37PM +0300, Tero Kristo wrote:
> diff --git a/arch/arm/mach-omap2/powerdomain.c
> b/arch/arm/mach-omap2/powerdomain.c
> index ba49029..ca54aec 100644
> --- a/arch/arm/mach-omap2/powerdomain.c
> +++ b/arch/arm/mach-omap2/powerdomain.c
> @@ -1475,10 +1477,16 @@ int pwrdm_state_switch(struct powerdomain *pwrdm)
> */
> void pwrdm_clkdm_enable(struct powerdomain *pwrdm)
> {
> + unsigned long flags;
> +
> if (!pwrdm)
> return;
>
> - atomic_inc(&pwrdm->usecount);
> + if (atomic_inc_return(&pwrdm->usecount) == 1) {
> + spin_lock_irqsave(&pwrdm->lock, flags);
> + voltdm_pwrdm_enable(pwrdm->voltdm.ptr);
> + spin_unlock_irqrestore(&pwrdm->lock, flags);
> + }
This looks like the classic "I like atomic types because they have magic
properties" brain-deadness.
What would happen to users of this if you had this sequence:
pwrdm->usecount starts off as 1.
Thread0 Thread1
atomic_inc_return() (returns 1)
atomic_inc_return() (returns 2)
starts using stuff in power domain
spin_lock_irqsave()
voltdm_pwrdm_enable()
spin_unlock_irqrestore()
?
--
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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.
Hi, On Tue, Sep 25, 2012 at 10:21:18AM +0100, Russell King - ARM Linux wrote: > On Tue, Sep 25, 2012 at 12:11:14PM +0300, Felipe Balbi wrote: > > On Tue, Sep 25, 2012 at 10:12:28AM +0100, Russell King - ARM Linux wrote: > > > On Tue, Sep 25, 2012 at 11:31:20AM +0300, Felipe Balbi wrote: > > > > On Tue, Sep 25, 2012 at 09:30:29AM +0100, Russell King - ARM Linux > > > > wrote: > > > > > How is this happening? I think that needs proper investigation - or > > > > > if > > > > > it's had more investigation, then the results needs to be included in > > > > > the commit description so that everyone can understand the issue here. > > > > > > > > > > We should not be resuming a device which hasn't been suspended. Maybe > > > > > the runtime PM enable sequence is wrong, and that's what should be > > > > > fixed > > > > > instead? > > > > > > > > > > This sequence in the probe() function: > > > > > > > > > > pm_runtime_irq_safe(&pdev->dev); > > > > > pm_runtime_enable(&pdev->dev); > > > > > pm_runtime_get_sync(&pdev->dev); > > > > > > > > > > would enable runtime PM while the s/w state indicates that it's > > > > > disabled, > > > > > and then that pm_runtime_get_sync() will want to resume the device. > > > > > See > > > > > the section "5. Runtime PM Initialization, Device Probing and Removal" > > > > > in Documentation/power/runtime_pm.txt, specifically the second > > > > > paragraph > > > > > of that section. > > > > > > > > that was tested. It worked in pandaboard but didn't work on beagleboard > > > > XM. Sourav tried to start a discussion about that, but it simply died... > > > > > > > > In any case, pm_runtime_get_sync() in probe will always call > > > > runtime_resume callback, right ? > > > > > > Well, if the runtime PM state says it's suspended, and then you enable > > > runtime PM, the first call to pm_runtime_get_sync() will trigger a resume > > > attempt. The patch description is complaining about resume events without > > > there being a preceding suspend event. > > > > > > This could well be why. > > > > that's most likely, of course. But should we cause a regression to > > beagleboard XM because of that ? > > What would cause a regression on beagleboard XM? I have not suggested > any change other than more investigation of the issue and a fuller patch > description - yet you're screaming (idiotically IMHO) that mere > investigation would break beagleboard. > > Well, if it's _that_ fragile, that mere investigation of this issue by > someone elsewhere on the planet would break your beagleboard, maybe it > deserves to be broken! why are you always so over the top like that ? This is just counter-productive to say the least. What I'm trying to say here, is that there might be a bug either on pm core or on OMAP3's implementation and I'd like to get input from Tony, Santosh, Paul, etc before going forward. Maybe it's something they've already been through, or maybe it rings a bell and points to somewhere we should look for. anyway, instead of feeding your ego, we can stop this discussion and let Sourav see what he can come up with. -- balbi signature.asc Description: Digital signature
Re: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.
Hi, On Tue, Sep 25, 2012 at 2:51 PM, Russell King - ARM Linux wrote: > On Tue, Sep 25, 2012 at 12:11:14PM +0300, Felipe Balbi wrote: >> On Tue, Sep 25, 2012 at 10:12:28AM +0100, Russell King - ARM Linux wrote: >> > On Tue, Sep 25, 2012 at 11:31:20AM +0300, Felipe Balbi wrote: >> > > On Tue, Sep 25, 2012 at 09:30:29AM +0100, Russell King - ARM Linux wrote: >> > > > How is this happening? I think that needs proper investigation - or if >> > > > it's had more investigation, then the results needs to be included in >> > > > the commit description so that everyone can understand the issue here. >> > > > >> > > > We should not be resuming a device which hasn't been suspended. Maybe >> > > > the runtime PM enable sequence is wrong, and that's what should be >> > > > fixed >> > > > instead? >> > > > >> > > > This sequence in the probe() function: >> > > > >> > > > pm_runtime_irq_safe(&pdev->dev); >> > > > pm_runtime_enable(&pdev->dev); >> > > > pm_runtime_get_sync(&pdev->dev); >> > > > >> > > > would enable runtime PM while the s/w state indicates that it's >> > > > disabled, >> > > > and then that pm_runtime_get_sync() will want to resume the device. >> > > > See >> > > > the section "5. Runtime PM Initialization, Device Probing and Removal" >> > > > in Documentation/power/runtime_pm.txt, specifically the second >> > > > paragraph >> > > > of that section. >> > > >> > > that was tested. It worked in pandaboard but didn't work on beagleboard >> > > XM. Sourav tried to start a discussion about that, but it simply died... >> > > >> > > In any case, pm_runtime_get_sync() in probe will always call >> > > runtime_resume callback, right ? >> > >> > Well, if the runtime PM state says it's suspended, and then you enable >> > runtime PM, the first call to pm_runtime_get_sync() will trigger a resume >> > attempt. The patch description is complaining about resume events without >> > there being a preceding suspend event. >> > >> > This could well be why. >> >> that's most likely, of course. But should we cause a regression to >> beagleboard XM because of that ? > > What would cause a regression on beagleboard XM? I have not suggested > any change other than more investigation of the issue and a fuller patch > description - yet you're screaming (idiotically IMHO) that mere > investigation would break beagleboard. > > Well, if it's _that_ fragile, that mere investigation of this issue by > someone elsewhere on the planet would break your beagleboard, maybe it > deserves to be broken! The issue was observed at serial init itself in the N800 board and the log does not show up much. http://www.pwsan.com/omap/testlogs/test_tty_next_e36851d0/20120910020323/boot/2420n800/2420n800_log.txt What we thought the problem might be with n800 is that it tries to resume when it didn't suspend before. There are two ways through which we thought of handling this issue: a) set device as active before enabling pm (which will prevent pm_runtime_set_active(dev); pm_runtime_enable(dev); OR b) adding a "suspended" flag to struct omap_uart_port which gets set on suspend and cleared on resume. Then on resume you can check: if (!up->suspended) return 0; But using "pm_runtime_set_active" approach breaks things even on beagle board xm, though it works fine on Panda. Therefore, we used the "suspended" flag approach. So. I just wanted to get some feedback from community about how using "pm_runtime_set_active" behaves differently in omap3 and omap4. -- 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] OMAPDSS: Cleanup DSSDBG with dynamic pr_debug function
On Tue, 2012-09-25 at 15:00 +0530, Mahapatra, Chandrabhanu wrote:
> > This debug message is even less meaningful than the overlay number =).
> > Again, I think either keep the DSSDBGF, or print something sensible,
> > like "entering ULPS".
> >
>
> I dont think it would be wise enough to update code for one and keep
> the older version for another when both DSSDBG and DSSDBGF are almost
> one and the same. Its better to add something meaningful to the prints
> as you have mentioned like "writing ovl %d regs" and "DSI entering
> ULPS".
I didn't mean to leave DSSDBGF unchanged. I meant that it should work as
it works now, printing the func name, but using pr_debug.
> >>
> >> WARN_ON(!dsi_bus_is_locked(dsidev));
> >>
> >> @@ -4184,7 +4180,7 @@ int omapdss_dsi_set_clocks(struct omap_dss_device
> >> *dssdev,
> >> unsigned long pck;
> >> int r;
> >>
> >> - DSSDBGF("ddr_clk %lu, lp_clk %lu", ddr_clk, lp_clk);
> >> + DSSDBG("ddr_clk %lu, lp_clk %lu", ddr_clk, lp_clk);
> >>
> >> mutex_lock(&dsi->lock);
> >>
> >> diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
> >> index 5e9fd769..3a2caab 100644
> >> --- a/drivers/video/omap2/dss/dss.h
> >> +++ b/drivers/video/omap2/dss/dss.h
> >> @@ -29,38 +29,20 @@
> >>
> >> #ifdef DEBUG
> >> extern bool dss_debug;
> >
> > You still left the dss_debug option here, even if it's not used by the
> > DSSDBG anymore. What's your plan about this?
> >
> > Tomi
> >
>
> dss_debug and DEBUG need to remain here as it is being used by
> functions omap_dispc_irq_handler() and _dsi_print_reset_status() in
It would be good to clean all this in one patch series.
> dispc.c and dsi.c. I am little bit unsure of how to deal with it.
> There could be a single print in omap_dispc_irq_handler() but it is a
> bit tricky in _dsi_print_reset_status().
>
> May be a macro like this one can be used in _dsi_print_reset_status()
>
> #define DSI_FLD_GET(fld, start, end)\
> FLD_GET(dsi_read_reg(dsidev, DSI_##fld), start, end);
>
> pr_debug("PLL (%d) CIO (%d) \n PHY (%x%x%x, %d, %d, %d) \n",
> DSI_FLD_GET(PLL_STATUS, 0, 0),
> DSI_FLD_GET(COMPLEXIO_CFG1, 29, 29),
> DSI_FLD_GET(DSIPHY_CFG5, bo, bo),
> DSI_FLD_GET(DSIPHY_CFG5, b1, b1),
>..);
> This could be defined at the beginning of the function and later at its end.
Yes, I think something like that could work. I don't see any problem
with having temporary helper macros to help creating the debug message.
> As you had previously mentioned a print like
>
> #define PIS(x) (status & DSI_IRQ_##x) ? (#x " ") : ""
>
> pr_debug("DSI IRQ: 0x%x: %s%s%s",
> status,
> PIS(WAKEUP),
> PIS(RESYNC),
> PIS(PLL_LOCK));
>
> could help in print_irq_status() but I am still unsure how to deal
> with conditional statements in print_irq_status() like
> if (dss_has_feature(FEAT_MGR_LCD3))
> PIS(SYNC_LOST3);
> Should we use approach like
>
> pr_debug("DSI IRQ: 0x%x: %s%s%s%s...",
> status,
> PIS(WAKEUP),
> PIS(RESYNC),
> PIS(PLL_LOCK)
> dss_has_feature(FEAT_MGR_LCD3) ? PIS(SYNC_LOST3) : ""
> .. );
Yes, that looks fine to me.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 1/5] drivers: usb: phy: add a new driver for omap usb2 phy
Hi, On Mon, Sep 24, 2012 at 6:45 PM, Rob Herring wrote: > On 09/06/2012 09:57 AM, Kishon Vijay Abraham I wrote: >> All phy related programming like enabling/disabling the clocks, powering >> on/off the phy is taken care of by this driver. It is also used for OTG >> related functionality like srp. >> >> This also includes device tree support for usb2 phy driver and >> the documentation with device tree binding information is updated. >> >> Currently writing to control module register is taken care in this >> driver which will be removed once the control module driver is in place. >> >> Cc: Felipe Balbi >> Signed-off-by: Kishon Vijay Abraham I >> --- >> Documentation/devicetree/bindings/usb/usb-phy.txt | 17 ++ >> drivers/usb/phy/Kconfig |9 + >> drivers/usb/phy/Makefile |1 + >> drivers/usb/phy/omap-usb2.c | 271 >> + >> include/linux/usb/omap_usb.h | 46 >> include/linux/usb/phy_companion.h | 34 +++ >> 6 files changed, 378 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/usb/usb-phy.txt >> create mode 100644 drivers/usb/phy/omap-usb2.c >> create mode 100644 include/linux/usb/omap_usb.h >> create mode 100644 include/linux/usb/phy_companion.h >> >> diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt >> b/Documentation/devicetree/bindings/usb/usb-phy.txt >> new file mode 100644 >> index 000..80d4148 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/usb/usb-phy.txt > > This is a very generic name... > >> @@ -0,0 +1,17 @@ >> +USB PHY >> + >> +OMAP USB2 PHY >> + >> +Required properties: >> + - compatible: Should be "ti,omap-usb2" > > ...for a specific phy. However, I do think a generic binding to describe > host ctrlr to phy connections is needed. > >> + - reg : Address and length of the register set for the device. Also >> +add the address of control module dev conf register until a driver for >> +control module is added > > The dts should describe the h/w, not what you need for the current > driver. The 2nd reg field does not belong here. Indeed. This was discussed and agreed upon as a interim solution till we have a control module driver in place to write to the control module register. > >> + >> +This is usually a subnode of ocp2scp to which it is connected. > > How is usb port to phy connection described? Currently the usb controller to phy connection is established only by type. We have a couple of patches being currently discussed in the list to establish the connection by phandle. https://patchwork.kernel.org/patch/1457801/ (Generic PHY Framework: devm_of_phy_get()) http://www.spinics.net/lists/linux-usb/msg69547.html Thanks Kishon -- 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
Powering OMAP's pins
Hi Tony, Each pin of OMAP requires a particular power to be enabled for the pin to function (Ball Characteristics table from data manual). Is there a plan how this is managed with pinctrl? Currently each driver needs to make sure the correct regulators are enabled for the pins it uses, which is platform specific and messy. As a driver maintainer, I would wish that the pins would just get enabled automatically when I call pm_runtime_get()... Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCHv5 00/10] ARM: OMAP: PM usecounting changes
Hi Tero, On Tuesday 25 September 2012 03:02 PM, Tero Kristo wrote: Hi, Changes compared to previous version: Did you get a chance to look at the issue I reported about autodeps? http://www.mail-archive.com/linux-omap@vger.kernel.org/msg72876.html regards, Rajendra - Fixed OMAP4 support (patches 7-10) - Dropped debugging support from this set for now - Rebased on top of 3.6-rc5 + func-pwrst + omap4-ret code (omap4 support easier to test with these) - Patch #1: * dropped clkdm_usecount_inc / clkdm_usecount_dec APIs * clkdm_clk_enable / disable are used now instead * some code ordering changed for the new setup to work properly * changed BUG_ON calls to WARN_ON - Patch #2: * added spinlock for protecting voltdm callbacks * pwrdm lock extended to protect pwrdm callbacks - Patch #3: * dropped generic API call for the cpu pwrdm idle / wakeup * instead use pwrdm_clkdm_enable / disable calls directly from PM code * omap4 support fixed to work properly with SMP, added omap4 specific CPU pwrdm idle / wakeup calls for this purpose - Patch #4: * no changes * added 'Reviewed-by' tag for Rajendra - Patch #5: * no changes, just rebase - Patch #6: * no changes Tested with OMAP3 beagle, omap4460 GP panda + omap4430 EMU blaze boards. I will be posting new versions for the voltdm fixes + auto retention + panda board tps6236x support code later on today, which are based on top of this set. Branch also available here: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.6-rc5-pwrdm-changes-v5 -Tero -- 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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.
On Tue, Sep 25, 2012 at 12:48:16PM +0300, Felipe Balbi wrote: > Hi, > > On Tue, Sep 25, 2012 at 10:21:18AM +0100, Russell King - ARM Linux wrote: > > On Tue, Sep 25, 2012 at 12:11:14PM +0300, Felipe Balbi wrote: > > > On Tue, Sep 25, 2012 at 10:12:28AM +0100, Russell King - ARM Linux wrote: > > > > On Tue, Sep 25, 2012 at 11:31:20AM +0300, Felipe Balbi wrote: > > > > > On Tue, Sep 25, 2012 at 09:30:29AM +0100, Russell King - ARM Linux > > > > > wrote: > > > > > > How is this happening? I think that needs proper investigation - > > > > > > or if > > > > > > it's had more investigation, then the results needs to be included > > > > > > in > > > > > > the commit description so that everyone can understand the issue > > > > > > here. > > > > > > > > > > > > We should not be resuming a device which hasn't been suspended. > > > > > > Maybe > > > > > > the runtime PM enable sequence is wrong, and that's what should be > > > > > > fixed > > > > > > instead? > > > > > > > > > > > > This sequence in the probe() function: > > > > > > > > > > > > pm_runtime_irq_safe(&pdev->dev); > > > > > > pm_runtime_enable(&pdev->dev); > > > > > > pm_runtime_get_sync(&pdev->dev); > > > > > > > > > > > > would enable runtime PM while the s/w state indicates that it's > > > > > > disabled, > > > > > > and then that pm_runtime_get_sync() will want to resume the device. > > > > > > See > > > > > > the section "5. Runtime PM Initialization, Device Probing and > > > > > > Removal" > > > > > > in Documentation/power/runtime_pm.txt, specifically the second > > > > > > paragraph > > > > > > of that section. > > > > > > > > > > that was tested. It worked in pandaboard but didn't work on > > > > > beagleboard > > > > > XM. Sourav tried to start a discussion about that, but it simply > > > > > died... > > > > > > > > > > In any case, pm_runtime_get_sync() in probe will always call > > > > > runtime_resume callback, right ? > > > > > > > > Well, if the runtime PM state says it's suspended, and then you enable > > > > runtime PM, the first call to pm_runtime_get_sync() will trigger a > > > > resume > > > > attempt. The patch description is complaining about resume events > > > > without > > > > there being a preceding suspend event. > > > > > > > > This could well be why. > > > > > > that's most likely, of course. But should we cause a regression to > > > beagleboard XM because of that ? > > > > What would cause a regression on beagleboard XM? I have not suggested > > any change other than more investigation of the issue and a fuller patch > > description - yet you're screaming (idiotically IMHO) that mere > > investigation would break beagleboard. > > > > Well, if it's _that_ fragile, that mere investigation of this issue by > > someone elsewhere on the planet would break your beagleboard, maybe it > > deserves to be broken! > > why are you always so over the top like that ? This is just > counter-productive to say the least. Because you are accusing me of potentially breaking your beagleboard for merely suggesting further investigation and a better commit message. You are the one going over the top, not me. -- 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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.
On Tue, Sep 25, 2012 at 11:29:58AM +0100, Russell King - ARM Linux wrote: > On Tue, Sep 25, 2012 at 12:48:16PM +0300, Felipe Balbi wrote: > > Hi, > > > > On Tue, Sep 25, 2012 at 10:21:18AM +0100, Russell King - ARM Linux wrote: > > > On Tue, Sep 25, 2012 at 12:11:14PM +0300, Felipe Balbi wrote: > > > > On Tue, Sep 25, 2012 at 10:12:28AM +0100, Russell King - ARM Linux > > > > wrote: > > > > > On Tue, Sep 25, 2012 at 11:31:20AM +0300, Felipe Balbi wrote: > > > > > > On Tue, Sep 25, 2012 at 09:30:29AM +0100, Russell King - ARM Linux > > > > > > wrote: > > > > > > > How is this happening? I think that needs proper investigation - > > > > > > > or if > > > > > > > it's had more investigation, then the results needs to be > > > > > > > included in > > > > > > > the commit description so that everyone can understand the issue > > > > > > > here. > > > > > > > > > > > > > > We should not be resuming a device which hasn't been suspended. > > > > > > > Maybe > > > > > > > the runtime PM enable sequence is wrong, and that's what should > > > > > > > be fixed > > > > > > > instead? > > > > > > > > > > > > > > This sequence in the probe() function: > > > > > > > > > > > > > > pm_runtime_irq_safe(&pdev->dev); > > > > > > > pm_runtime_enable(&pdev->dev); > > > > > > > pm_runtime_get_sync(&pdev->dev); > > > > > > > > > > > > > > would enable runtime PM while the s/w state indicates that it's > > > > > > > disabled, > > > > > > > and then that pm_runtime_get_sync() will want to resume the > > > > > > > device. See > > > > > > > the section "5. Runtime PM Initialization, Device Probing and > > > > > > > Removal" > > > > > > > in Documentation/power/runtime_pm.txt, specifically the second > > > > > > > paragraph > > > > > > > of that section. > > > > > > > > > > > > that was tested. It worked in pandaboard but didn't work on > > > > > > beagleboard > > > > > > XM. Sourav tried to start a discussion about that, but it simply > > > > > > died... > > > > > > > > > > > > In any case, pm_runtime_get_sync() in probe will always call > > > > > > runtime_resume callback, right ? > > > > > > > > > > Well, if the runtime PM state says it's suspended, and then you enable > > > > > runtime PM, the first call to pm_runtime_get_sync() will trigger a > > > > > resume > > > > > attempt. The patch description is complaining about resume events > > > > > without > > > > > there being a preceding suspend event. > > > > > > > > > > This could well be why. > > > > > > > > that's most likely, of course. But should we cause a regression to > > > > beagleboard XM because of that ? > > > > > > What would cause a regression on beagleboard XM? I have not suggested > > > any change other than more investigation of the issue and a fuller patch > > > description - yet you're screaming (idiotically IMHO) that mere > > > investigation would break beagleboard. > > > > > > Well, if it's _that_ fragile, that mere investigation of this issue by > > > someone elsewhere on the planet would break your beagleboard, maybe it > > > deserves to be broken! > > > > why are you always so over the top like that ? This is just > > counter-productive to say the least. > > Because you are accusing me of potentially breaking your beagleboard > for merely suggesting further investigation and a better commit message. Where did I accuse you of anyting ? I just mentioned we experienced a regression with beagleboard XM when using pm_runtime_set_active(). here's my quote: > that was tested. It worked in pandaboard but didn't work on > beagleboard XM. Sourav tried to start a discussion about that, but it > simply died... To add extra info, here you go: We pinged Paul and asked if he had seen that before, he had no pointers... Because Documentation/power/runtime_pm.txt was using a mystruct->is_suspended flag, we just decided to follow the same "design" since no-one was able to suggest why pm_runtime_set_active() was breaking beagleXM nor how it was supposed to actually work. Reading the code: pm_runtime_set_active() would tell pm_runtime core the device is actually active by setting runtime_status to RPM_ACTIVE, thus the following pm_runtime_get_sync() wouldn't actually call runtime_resume() callback, but it would increment usage_counter. I can't see why this would fail on beagleXM, but it does and we'd like to hear in which situations this could fail... -- balbi signature.asc Description: Digital signature
Re: query on [PATCH 2/3] usb: otg: add device tree support to otg library
Hi, On Tue, Sep 25, 2012 at 2:24 PM, Marc Kleine-Budde wrote: > Hi Afzal, > > On 09/25/2012 10:47 AM, Mohammed, Afzal wrote: >> This is a query regarding patch, >> "usb: otg: add device tree support to otg library" [1] >> >> It seems there is so far no consensus on this change. > > After I have posted this patch, Kishon had posted a better solution [2]. > We discussed the patch, but he has not posted any updates since then. > >> Do you have ideas to proceed on this ? is there something >> that I can help you to proceed on this ? > > I'm interested in to get these patches into the kernel soon. Kishon any > news on this patch? > >> Something like this would be required for USB support >> on beagle bone (AM335X), which has 2 phy's of same type. >> >> Or is the plan to use generic phy framework instead ? > > Yes, Kishon's patches look more generic than mine. Will post the next version by this week. Thanks Kishon -- 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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.
Right, let's get this thread back onto a constructive footing and try to understand the problems here. On Tue, Sep 25, 2012 at 03:26:06PM +0530, Poddar, Sourav wrote: > The issue was observed at serial init itself in the N800 board and the > log does not show up much. > http://www.pwsan.com/omap/testlogs/test_tty_next_e36851d0/20120910020323/boot/2420n800/2420n800_log.txt Right, so output stops when ttyO2 is initialized. > What we thought the problem might be with n800 is that it tries to > resume when it didn't suspend before. > > There are two ways through which we thought of handling this issue: > > a) set device as active before enabling pm (which will prevent > > pm_runtime_set_active(dev); > pm_runtime_enable(dev); > > OR > > b) adding a "suspended" flag to struct omap_uart_port which gets set on > suspend and cleared on resume. Then on resume you can check: > > if (!up->suspended) > return 0; > > But using "pm_runtime_set_active" approach breaks things even on > beagle board xm, though it works fine on Panda. Right, so now the question becomes - what is different on the Beagle Board that prevents solution (a) from working - or put it another way, have we uncovered _another_ bug. For N800, for ttyO0 and ttyO1 which aren't in use, it may be correct. We don't know for certain. For ttyO2, the port is clearly already in use as it's being used for console output. So that means it's _not_ in suspended state, and therefore the initial runtime PM state is wrong. For Beagleboard - who knows, we have no information on that. All we know is that your (a) sequence causes a regression. Anyway, let's analyse the code paths. What is pm_runtime_get_sync() doing? Well, it calls __pm_runtime_resume(, RPM_GET_PUT). That alters the parent device's state (which doesn't matter for this, as the platform device is a child of the main platform device, which has no runtime PM.) It then calls the resume callback (from the pm domain/type/class/bus/ driver) and then does an idle check. OMAP devices have a pm domain, so this is the candidate for the callback at this level, which gets us into _od_runtime_resume(). This calls omap_device_enable() before then moving on to the driver's runtime resume method, and at that point the runtime PM resume is complete. So, with your (a) solution, what's different is that we omit calling omap_device_enable(). Therefore, my hunch is the reason that Beagleboard doesn't work is because it doesn't like missing that call. I bet if you do this: omap_device_enable(dev); pm_runtime_set_active(dev); pm_runtime_enable(dev); that this will solve your problem, and Beagleboard will continue working. What we have is a mismatch in both your case, and the Beagleboard case, between the real state of the hardware, the runtime PM state, and the OMAP hwmod state, and the above should bring all those states entirely into line with each other for _every_ case. It doesn't need any hacks to prevent resume callbacks without prior suspends (which, incidentally, the runtime PM core already guarantees provided you get the initial state correct.) -- 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: query on [PATCH 2/3] usb: otg: add device tree support to otg library
On Tue, Sep 25, 2012 at 16:21:39, ABRAHAM, KISHON VIJAY wrote: > On Tue, Sep 25, 2012 at 2:24 PM, Marc Kleine-Budde > wrote: > > I'm interested in to get these patches into the kernel soon. Kishon any > > news on this patch? > > > >> Something like this would be required for USB support > >> on beagle bone (AM335X), which has 2 phy's of same type. > >> > >> Or is the plan to use generic phy framework instead ? > > > > Yes, Kishon's patches look more generic than mine. > Will post the next version by this week. Thanks Marc and Kishon Regards Afzal
Re: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.
On Tue, Sep 25, 2012 at 01:37:03PM +0300, Felipe Balbi wrote: > On Tue, Sep 25, 2012 at 11:29:58AM +0100, Russell King - ARM Linux wrote: > > Because you are accusing me of potentially breaking your beagleboard > > for merely suggesting further investigation and a better commit message. > > Where did I accuse you of anyting ? I just mentioned we experienced a > regression with beagleboard XM when using pm_runtime_set_active(). I quote: :> But should we cause a regression to beagleboard XM because of that ? I say again: I was _only_ suggesting further investigation, yet you were mouthing off about causing a regression to beagleboard "because of that", effectively saying that no, we should not do any further investigation and this is the only fix. > To add extra info, here you go: Finally, something constructive. > We pinged Paul and asked if he had seen that before, he had no > pointers... Because Documentation/power/runtime_pm.txt was using a > mystruct->is_suspended flag, we just decided to follow the same > "design" since no-one was able to suggest why pm_runtime_set_active() > was breaking beagleXM nor how it was supposed to actually work. > > Reading the code: pm_runtime_set_active() would tell pm_runtime core > the device is actually active by setting runtime_status to RPM_ACTIVE, > thus the following pm_runtime_get_sync() wouldn't actually call > runtime_resume() callback, but it would increment usage_counter. > > I can't see why this would fail on beagleXM, but it does and we'd like > to hear in which situations this could fail... Well, I've just spent five minutes analysing the code paths - which I hadn't looked at before - and I've pointed out what's probably causing the problem for Beagle. I think you owe me an appology over your aggressive attitude towards my suggestions that there needed to be some further investigation. -- 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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.
On Tue, Sep 25, 2012 at 12:11:14PM +0300, Felipe Balbi wrote: > that's most likely, of course. But should we cause a regression to > beagleboard XM because of that ? Also, if you look into chapter 9 of the > runtime_pm documentation, starting on line 822 you'll see documentation > suggests the use of mystruct->is_suspended flag. BTW, I'll point out a fatal flaw in your justification above. If you read the entire example, you'll see that the is_suspended flag is _not_ used to prevent resumes without suspends, but is used as a flag to control whether the driver processes requests or not. That's entirely functionally different from using a "is_suspended" flag in the way you mention above. Section 5 is quite clear about the requirements at initialization time for runtime PM, and nothing in section 9 contradicts that, and the is_suspended flag in that example has nothing to do with any of this. -- 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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.
Hi, On Tue, Sep 25, 2012 at 12:07:03PM +0100, Russell King - ARM Linux wrote: > On Tue, Sep 25, 2012 at 01:37:03PM +0300, Felipe Balbi wrote: > > On Tue, Sep 25, 2012 at 11:29:58AM +0100, Russell King - ARM Linux wrote: > > > Because you are accusing me of potentially breaking your beagleboard > > > for merely suggesting further investigation and a better commit message. > > > > Where did I accuse you of anyting ? I just mentioned we experienced a > > regression with beagleboard XM when using pm_runtime_set_active(). > > I quote: > :> But should we cause a regression to beagleboard XM because of that ? > maybe that wasn't the best way to put it, but I was trying to point out that either there was a bug on pm core or omap_device/hwmod, not that we shouldn't investigate. > I say again: I was _only_ suggesting further investigation, yet you > were mouthing off about causing a regression to beagleboard "because > of that", effectively saying that no, we should not do any further > investigation and this is the only fix. not what I meant, but fair enough... The "because of that" was supposed to mean "because of pm_runtime_set_active()". I find the documentation for that particular call to be rather poor and a bit confusing, specially when further down, the very same document uses a "is_suspended" flag which, in fact, shouldn't be needed when we have pm_runtime_is_suspended() and the like. > > We pinged Paul and asked if he had seen that before, he had no > > pointers... Because Documentation/power/runtime_pm.txt was using a > > mystruct->is_suspended flag, we just decided to follow the same > > "design" since no-one was able to suggest why pm_runtime_set_active() > > was breaking beagleXM nor how it was supposed to actually work. > > > > Reading the code: pm_runtime_set_active() would tell pm_runtime core > > the device is actually active by setting runtime_status to RPM_ACTIVE, > > thus the following pm_runtime_get_sync() wouldn't actually call > > runtime_resume() callback, but it would increment usage_counter. > > > > I can't see why this would fail on beagleXM, but it does and we'd like > > to hear in which situations this could fail... > > Well, I've just spent five minutes analysing the code paths - which I > hadn't looked at before - and I've pointed out what's probably causing > the problem for Beagle. I think you owe me an appology over your > aggressive attitude towards my suggestions that there needed to be > some further investigation. I don't see any aggressive attitude towards what you suggested, actually. Mailing list archives are available to check, but the one cursing around was always yourself and THAT deserves an apology. If you still think I've been at all aggressive, then sure, I apologize, it wasn't what I meant though. -- balbi signature.asc Description: Digital signature
Re: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.
On Tue, Sep 25, 2012 at 02:12:43PM +0300, Felipe Balbi wrote: > I don't see any aggressive attitude towards what you suggested, > actually. Mailing list archives are available to check, but the one > cursing around was always yourself and THAT deserves an apology. Total rubbish. No apology, because I wasn't cursing you. Whatever, I'm not going to re-explain the email thread. What I said was that your raising of beagleboard breakage (twice) was idiotic to a request for investigation. That's a statement I _still_ fully agree with, and I'll say it again if I have to. Trying to shut down investigation because investigation may break something _is_ idiotic - especially if the investigation reveals potential reasons why that breakage would occur. Further investigation is precisely how we arrive at better solutions. -- 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: [PATCHv5 00/10] ARM: OMAP: PM usecounting changes
On Tue, 2012-09-25 at 15:56 +0530, Rajendra Nayak wrote: > Hi Tero, > > On Tuesday 25 September 2012 03:02 PM, Tero Kristo wrote: > > Hi, > > > > Changes compared to previous version: > > Did you get a chance to look at the issue I reported about autodeps? > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg72876.html Not really, I didn't think that bug report was meant for me, I kind of thought it only happened with your set. But now looking at your email in detail, I guess you are saying there is a bug in this code (the one that touches iclk stuff), which causes the USB / DSS domains to follow MPU/CORE, is that right? -Tero > > regards, > Rajendra > > > > > - Fixed OMAP4 support (patches 7-10) > > - Dropped debugging support from this set for now > > - Rebased on top of 3.6-rc5 + func-pwrst + omap4-ret code > >(omap4 support easier to test with these) > > - Patch #1: > >* dropped clkdm_usecount_inc / clkdm_usecount_dec APIs > >* clkdm_clk_enable / disable are used now instead > >* some code ordering changed for the new setup to work properly > >* changed BUG_ON calls to WARN_ON > > - Patch #2: > >* added spinlock for protecting voltdm callbacks > >* pwrdm lock extended to protect pwrdm callbacks > > - Patch #3: > >* dropped generic API call for the cpu pwrdm idle / wakeup > >* instead use pwrdm_clkdm_enable / disable calls directly from PM code > >* omap4 support fixed to work properly with SMP, added omap4 specific > > CPU pwrdm idle / wakeup calls for this purpose > > - Patch #4: > >* no changes > >* added 'Reviewed-by' tag for Rajendra > > - Patch #5: > >* no changes, just rebase > > - Patch #6: > >* no changes > > > > Tested with OMAP3 beagle, omap4460 GP panda + omap4430 EMU blaze boards. > > > > I will be posting new versions for the voltdm fixes + auto retention + > > panda board tps6236x support code later on today, which are based on top > > of this set. > > > > Branch also available here: > > > > git://gitorious.org/~kristo/omap-pm/omap-pm-work.git > > branch: mainline-3.6-rc5-pwrdm-changes-v5 > > > > -Tero > > > > > > -- > > 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: [PATCHv5 02/10] ARM: OMAP3+: voltage: add support for voltagedomain usecounts
On Tue, 2012-09-25 at 10:41 +0100, Russell King - ARM Linux wrote:
> On Tue, Sep 25, 2012 at 12:32:37PM +0300, Tero Kristo wrote:
> > diff --git a/arch/arm/mach-omap2/powerdomain.c
> > b/arch/arm/mach-omap2/powerdomain.c
> > index ba49029..ca54aec 100644
> > --- a/arch/arm/mach-omap2/powerdomain.c
> > +++ b/arch/arm/mach-omap2/powerdomain.c
> > @@ -1475,10 +1477,16 @@ int pwrdm_state_switch(struct powerdomain *pwrdm)
> > */
> > void pwrdm_clkdm_enable(struct powerdomain *pwrdm)
> > {
> > + unsigned long flags;
> > +
> > if (!pwrdm)
> > return;
> >
> > - atomic_inc(&pwrdm->usecount);
> > + if (atomic_inc_return(&pwrdm->usecount) == 1) {
> > + spin_lock_irqsave(&pwrdm->lock, flags);
> > + voltdm_pwrdm_enable(pwrdm->voltdm.ptr);
> > + spin_unlock_irqrestore(&pwrdm->lock, flags);
> > + }
>
> This looks like the classic "I like atomic types because they have magic
> properties" brain-deadness.
Hi Russell,
Thats a good catch, I was actually thinking about this sequence myself
also, but decided to leave it as is here due to similarity with the
existing code in mach-omap2/clockdomain.c, see e.g.
_clkdm_clk_hwmod_enable. Maybe those parts should be fixed also...?
>
> What would happen to users of this if you had this sequence:
>
> pwrdm->usecount starts off as 1.
>
> Thread0 Thread1
> atomic_inc_return() (returns 1)
> atomic_inc_return() (returns 2)
> starts using stuff in power domain
> spin_lock_irqsave()
> voltdm_pwrdm_enable()
> spin_unlock_irqrestore()
>
> ?
That as such wouldn't break anything, as the callback isn't doing
anything too critical, but yes, for the sequencing of events it is bad.
The alternate implementation I was thinking was to drop the atomic_t and
just use an int for the usecount, and protect the usecount also with the
spinlock. However, there might be some performance issues if this is
done (but I think it is actually better than having some rather
mysterious bugs instead.)
-Tero
--
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: [PATCHv5 00/10] ARM: OMAP: PM usecounting changes
On Tuesday 25 September 2012 05:23 PM, Tero Kristo wrote: On Tue, 2012-09-25 at 15:56 +0530, Rajendra Nayak wrote: Hi Tero, On Tuesday 25 September 2012 03:02 PM, Tero Kristo wrote: Hi, Changes compared to previous version: Did you get a chance to look at the issue I reported about autodeps? http://www.mail-archive.com/linux-omap@vger.kernel.org/msg72876.html Not really, I didn't think that bug report was meant for me, I kind of thought it only happened with your set. But now looking at your email in detail, I guess you are saying there is a bug in this code (the one that touches iclk stuff), which causes the USB / DSS domains to follow MPU/CORE, is that right? Yes, basically the autodeps remain set, even while the module is not in use at all, which causes them to come in and out of sleep along with MPU. -Tero regards, Rajendra - Fixed OMAP4 support (patches 7-10) - Dropped debugging support from this set for now - Rebased on top of 3.6-rc5 + func-pwrst + omap4-ret code (omap4 support easier to test with these) - Patch #1: * dropped clkdm_usecount_inc / clkdm_usecount_dec APIs * clkdm_clk_enable / disable are used now instead * some code ordering changed for the new setup to work properly * changed BUG_ON calls to WARN_ON - Patch #2: * added spinlock for protecting voltdm callbacks * pwrdm lock extended to protect pwrdm callbacks - Patch #3: * dropped generic API call for the cpu pwrdm idle / wakeup * instead use pwrdm_clkdm_enable / disable calls directly from PM code * omap4 support fixed to work properly with SMP, added omap4 specific CPU pwrdm idle / wakeup calls for this purpose - Patch #4: * no changes * added 'Reviewed-by' tag for Rajendra - Patch #5: * no changes, just rebase - Patch #6: * no changes Tested with OMAP3 beagle, omap4460 GP panda + omap4430 EMU blaze boards. I will be posting new versions for the voltdm fixes + auto retention + panda board tps6236x support code later on today, which are based on top of this set. Branch also available here: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.6-rc5-pwrdm-changes-v5 -Tero -- 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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.
On 19 September 2012 17:29, Felipe Balbi wrote: > this is what I mean, actually. If we remove pm_runtime_get_sync() in > exchange for pm_runtime_set_active() before pm_runtime_enable(), it > works on PandaBoard, but breaks BeagleBoard. > Perhaps it suggests that OMAP4 (PandaBoard) serial port is already activated but OMAP3 (BeagleBoard) isn't. So we need to reflect that either by doing pm_runtime_set_active() only on OMAP4 or by bringing up the OMAP3 too before the pm_runtime_set_active() call. BTW I understand get_sync(), set_active() and enable() are for different purposes, they can't be traded for one another. -- 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] OMAPDSS: DISPC: Add predecimation limit for TILER based rotations
On Mon, 2012-09-24 at 12:08 +0530, Chandrabhanu Mahapatra wrote: > In OMAP4 and OMAP5 when TILER 2D burst mode is used, a maximum of one line can > be skipped as per the respective TRMs. The MBlockStride OCP signal, which is > sum of ROWINC and image width in memory, is only 17 bits wide. In 2D mode > TILER > supports 8192, 16384, 32768 and 65536 values of MBlockStride. In case when 2 > or > more lines are skipped the ROWINC value exceeds 65536 resulting in OCP errors. > So, maximum vertical predecimation achievable is 2. > > Signed-off-by: Chandrabhanu Mahapatra > --- > drivers/video/omap2/dss/dispc.c |9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) Thanks, looks fine to me. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCHv5 00/10] ARM: OMAP: PM usecounting changes
On Tue, 2012-09-25 at 17:53 +0530, Rajendra Nayak wrote: > On Tuesday 25 September 2012 05:23 PM, Tero Kristo wrote: > > On Tue, 2012-09-25 at 15:56 +0530, Rajendra Nayak wrote: > >> Hi Tero, > >> > >> On Tuesday 25 September 2012 03:02 PM, Tero Kristo wrote: > >>> Hi, > >>> > >>> Changes compared to previous version: > >> > >> Did you get a chance to look at the issue I reported about autodeps? > >> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg72876.html > > > > Not really, I didn't think that bug report was meant for me, I kind of > > thought it only happened with your set. But now looking at your email in > > detail, I guess you are saying there is a bug in this code (the one that > > touches iclk stuff), which causes the USB / DSS domains to follow > > MPU/CORE, is that right? > > Yes, basically the autodeps remain set, even while the module is not in > use at all, which causes them to come in and out of sleep along with MPU. Actually I think I accidentally fixed this problem with the latest rev, due to the fact that I am using generic clkdm_clk_enable / disable calls from iclk now. I also just tested this (while fixing the complaint from Russell), and it looks like both USB and DSS pwrdms are remaining nicely idle on OMAP3. -Tero > > > > > -Tero > > > >> > >> regards, > >> Rajendra > >> > >>> > >>> - Fixed OMAP4 support (patches 7-10) > >>> - Dropped debugging support from this set for now > >>> - Rebased on top of 3.6-rc5 + func-pwrst + omap4-ret code > >>> (omap4 support easier to test with these) > >>> - Patch #1: > >>> * dropped clkdm_usecount_inc / clkdm_usecount_dec APIs > >>> * clkdm_clk_enable / disable are used now instead > >>> * some code ordering changed for the new setup to work properly > >>> * changed BUG_ON calls to WARN_ON > >>> - Patch #2: > >>> * added spinlock for protecting voltdm callbacks > >>> * pwrdm lock extended to protect pwrdm callbacks > >>> - Patch #3: > >>> * dropped generic API call for the cpu pwrdm idle / wakeup > >>> * instead use pwrdm_clkdm_enable / disable calls directly from PM code > >>> * omap4 support fixed to work properly with SMP, added omap4 specific > >>> CPU pwrdm idle / wakeup calls for this purpose > >>> - Patch #4: > >>> * no changes > >>> * added 'Reviewed-by' tag for Rajendra > >>> - Patch #5: > >>> * no changes, just rebase > >>> - Patch #6: > >>> * no changes > >>> > >>> Tested with OMAP3 beagle, omap4460 GP panda + omap4430 EMU blaze boards. > >>> > >>> I will be posting new versions for the voltdm fixes + auto retention + > >>> panda board tps6236x support code later on today, which are based on top > >>> of this set. > >>> > >>> Branch also available here: > >>> > >>> git://gitorious.org/~kristo/omap-pm/omap-pm-work.git > >>> branch: mainline-3.6-rc5-pwrdm-changes-v5 > >>> > >>> -Tero > >>> > >>> > >>> -- > >>> 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 10/18] OMAPDSS: DISPC: Configure input and output sizes for writeback
On Tue, 2012-09-25 at 11:49 +0530, Archit Taneja wrote:
> Writeback uses the WB_PICTURE_SIZE register to define the size of the content
> written to memory, this is the output of the scaler. It uses the WB_SIZE
> register to define the size of the content coming from the overlay/manager to
> which it is connected, this is the input to the scaler. This naming is
> different
> as compared to overlays.
>
> Add checks for writeback in dispc_ovl_set_input_size() and
> dispc_ovl_set_output_size() to write to the correct registers.
>
> Signed-off-by: Archit Taneja
> ---
> drivers/video/omap2/dss/dispc.c |7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
> index e42e902..04fdd33 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -719,7 +719,7 @@ static void dispc_ovl_set_input_size(enum omap_plane
> plane, int width,
> {
> u32 val = FLD_VAL(height - 1, 26, 16) | FLD_VAL(width - 1, 10, 0);
>
> - if (plane == OMAP_DSS_GFX)
> + if (plane == OMAP_DSS_GFX || plane == OMAP_DSS_WB)
> dispc_write_reg(DISPC_OVL_SIZE(plane), val);
> else
> dispc_write_reg(DISPC_OVL_PICTURE_SIZE(plane), val);
> @@ -734,7 +734,10 @@ static void dispc_ovl_set_output_size(enum omap_plane
> plane, int width,
>
> val = FLD_VAL(height - 1, 26, 16) | FLD_VAL(width - 1, 10, 0);
>
> - dispc_write_reg(DISPC_OVL_SIZE(plane), val);
> + if (plane == OMAP_DSS_WB)
> + dispc_write_reg(DISPC_OVL_PICTURE_SIZE(plane), val);
> + else
> + dispc_write_reg(DISPC_OVL_SIZE(plane), val);
> }
Should we just rename the dispc registers to DISPC_OVL_IN_SIZE and
DISPC_OVL_OUT_SIZE, and then we could do without the ifs? The registers
have always confused me a bit, I don't know why they are named so in the
TRM.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH v2 16/18] OMAPDSS: DISPC: Configure writeback FIFOs
On Tue, 2012-09-25 at 11:49 +0530, Archit Taneja wrote: > Extend the DISPC fifo functions to also configure the writeback FIFO > thresholds. > > The most optimal configuration for writeback is to push out data to the > interconnect the moment writeback pushes enough pixels in the FIFO to form a > burst. This reduces the chance of writeback overflowing it's FIFO. Hmm, why is this optimal? The FIFO for WB is the output fifo, right? In mem-to-mem mode the whole WB pipeline can stall, so the fifo can't overflow? If so, isn't it better to collect more data and flush all that to the memory, instead of sending each burst-size piece one by one? Then again, if the input side is reading pixels from the memory all the time, even if the output fifo helps to keep the output side idle for longer periods, it probably doesn't help as the input side keeps the memory bus awake. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH V2] ARM: OMAP: counter: add locking to read_persistent_clock
* R, Sricharan [120925 00:44]:
> Hi Tony,
>
> [snip..]
>
> >> > index dbf1e03..2bc51fb 100644
> >> > --- a/arch/arm/plat-omap/counter_32k.c
> >> > +++ b/arch/arm/plat-omap/counter_32k.c
> >> > @@ -55,22 +55,29 @@ static u32 notrace omap_32k_read_sched_clock(void)
> >> > * nsecs and adds to a monotonically increasing timespec.
> >> > */
> >> > static struct timespec persistent_ts;
> >> > -static cycles_t cycles, last_cycles;
> >> > +static cycles_t cycles;
> >> > static unsigned int persistent_mult, persistent_shift;
> >> > +static DEFINE_SPINLOCK(read_persistent_clock_lock);
> >> > +
> >> > static void omap_read_persistent_clock(struct timespec *ts)
> >> > {
> >> > unsigned long long nsecs;
> >> > - cycles_t delta;
> >> > - struct timespec *tsp = &persistent_ts;
> >> > + cycles_t last_cycles;
> >> > + unsigned long flags;
> >> > +
> >> > + spin_lock_irqsave(&read_persistent_clock_lock, flags);
> >> >
> >> > last_cycles = cycles;
> >> > cycles = sync32k_cnt_reg ? __raw_readl(sync32k_cnt_reg) : 0;
> >> > - delta = cycles - last_cycles;
> >> >
> >> > - nsecs = clocksource_cyc2ns(delta, persistent_mult, persistent_shift);
> >> > + nsecs = clocksource_cyc2ns(cycles - last_cycles,
> >> > + persistent_mult, persistent_shift);
> >
> > ..I think there's another bug here where cycles - last_cycles
> > returns wrong value when the timer wraps around as cycles_t is
> > 64 bits and the counter is 32 bits. It seems it's been there
> > since when the read_persistent_clock was added with commit
> > d92cfcbe (OMAP: timekeeping: time should not stop during suspend)?
> >
> > It seems that after this patch cycles should not be cycles_t
> > but u32, and the result of cycles - last_cycles should also
> > be u32.
> >
> cycles_t is defined as typedef unsigned long cycles_t;
> Am i missing something here ?
Oh right, cycles_t is unsigned long, it's OK then. Must
have grepped for it from some other arch.
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 v2] arm: make FORCE_MAX_ZONEORDER configurable for TI AM33XX
* Yegor Yefremov [120925 01:47]: > On 25.09.2012 10:32, Russell King - ARM Linux wrote: > > On Tue, Sep 25, 2012 at 10:26:30AM +0200, yegorsli...@googlemail.com wrote: > >> From: Yegor Yefremov > >> > >> FORCE_MAX_ZONEORDER of 12 is needed to allocation more than 4MB > >> of consistent DMA memory (da8xx frame buffer driver). > > > > Okay, so the patch description says "This needs to be 12 on this platform". > > > >> config FORCE_MAX_ZONEORDER > >> - int "Maximum zone order" if ARCH_SHMOBILE > >> - range 11 64 if ARCH_SHMOBILE > >> + int "Maximum zone order" if ARCH_SHMOBILE || SOC_AM33XX > >> + range 11 64 if ARCH_SHMOBILE || SOC_AM33XX > > > > but you leave it up to the user to select something that may not be > > suitable. Wouldn't _just_ adding: > > > > default "12" if SOC_AM33XX > > > > after the "range", and making no other changes be good enough and match > > what the patch description says? > > You're right. As we don't allocate anything, but increase the possible size, > it shouldn't break anything. Tony is it O.K. with you? Sure. 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: Powering OMAP's pins
* Tomi Valkeinen [120925 03:22]: > Hi Tony, > > Each pin of OMAP requires a particular power to be enabled for the pin > to function (Ball Characteristics table from data manual). Is there a > plan how this is managed with pinctrl? Currently each driver needs to > make sure the correct regulators are enabled for the pins it uses, which > is platform specific and messy. > > As a driver maintainer, I would wish that the pins would just get > enabled automatically when I call pm_runtime_get()... Hmm can you clarify a bit what exactly do you want to do there with pm_runtime_get()? Call the regulator framework? 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
[PATCHv6 00/11]: ARM: OMAP: PM usecounting changes
Hi, Changes compared to previous version: - Added patch #1 for fixing a potential race condition within clockdomain code - Fixed patch #3 (old patch #2) regarding a similar race condition within the voltagedomain code Tested with OMAP3 beagle, OMAP4460 GP panda, OMAP4430 EMU blaze devices. Branch available: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.6-rc5-pwrdm-changes-v6 -Tero -- 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
[PATCHv6 02/11] ARM: OMAP3+: voltage/pwrdm/clkdm/clock add recursive usecount tracking
This patch fixes the usecount tracking for omap3+, previously the
usecount numbers were rather bogus and were not really useful for
any purpose. Now usecount numbers track the number of really active
clients on each domain. This patch also adds support for usecount
tracking on powerdomain level and autoidle flag for clocks that
are hardware controlled and should be skipped in usecount
calculations.
Signed-off-by: Tero Kristo
Cc: Paul Walmsley
Cc: Kevin Hilman
---
arch/arm/mach-omap2/clkt_iclk.c | 21 ++
arch/arm/mach-omap2/clockdomain.c | 16 +-
arch/arm/mach-omap2/dpll3xxx.c | 19
arch/arm/mach-omap2/powerdomain.c | 35 +++
arch/arm/mach-omap2/powerdomain.h |4 +++
arch/arm/plat-omap/clock.c |6 +
arch/arm/plat-omap/include/plat/clock.h |2 +
7 files changed, 102 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt_iclk.c b/arch/arm/mach-omap2/clkt_iclk.c
index 3d43fba..1afc599 100644
--- a/arch/arm/mach-omap2/clkt_iclk.c
+++ b/arch/arm/mach-omap2/clkt_iclk.c
@@ -21,6 +21,7 @@
#include "clock2xxx.h"
#include "cm2xxx_3xxx.h"
#include "cm-regbits-24xx.h"
+#include "clockdomain.h"
/* Private functions */
@@ -34,6 +35,16 @@ void omap2_clkt_iclk_allow_idle(struct clk *clk)
v = __raw_readl((__force void __iomem *)r);
v |= (1 << clk->enable_bit);
__raw_writel(v, (__force void __iomem *)r);
+
+ /* Remove this clock from parent clockdomain usecounts */
+ if (clk->usecount && clk->clkdm)
+ clkdm_clk_disable(clk->clkdm, clk);
+
+ /*
+* Mark as autoidle, so we continue to ignore this clock in
+* parent clkdm usecount calculations
+*/
+ clk->autoidle = true;
}
/* XXX */
@@ -46,6 +57,16 @@ void omap2_clkt_iclk_deny_idle(struct clk *clk)
v = __raw_readl((__force void __iomem *)r);
v &= ~(1 << clk->enable_bit);
__raw_writel(v, (__force void __iomem *)r);
+
+ /*
+* Disable autoidle flag so further clkdm usecounts take this
+* clock into account
+*/
+ clk->autoidle = false;
+
+ /* Add clock back to parent clockdomain usecount */
+ if (clk->usecount && clk->clkdm)
+ clkdm_clk_enable(clk->clkdm, clk);
}
/* Public data */
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index 173905d..7715353 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -910,6 +910,7 @@ bool clkdm_in_hwsup(struct clockdomain *clkdm)
static int _clkdm_clk_hwmod_enable(struct clockdomain *clkdm)
{
unsigned long flags;
+ int usecount;
if (!clkdm || !arch_clkdm || !arch_clkdm->clkdm_clk_enable)
return -EINVAL;
@@ -921,12 +922,16 @@ static int _clkdm_clk_hwmod_enable(struct clockdomain
*clkdm)
* should be called for every clock instance or hwmod that is
* enabled, so the clkdm can be force woken up.
*/
- if ((atomic_inc_return(&clkdm->usecount) > 1) && autodeps) {
+ usecount = atomic_inc_return(&clkdm->usecount);
+
+ if (usecount > 1 && autodeps) {
spin_unlock_irqrestore(&clkdm->lock, flags);
return 0;
}
arch_clkdm->clkdm_clk_enable(clkdm);
+ if (usecount == 1)
+ pwrdm_clkdm_enable(clkdm->pwrdm.ptr);
pwrdm_state_switch(clkdm->pwrdm.ptr);
spin_unlock_irqrestore(&clkdm->lock, flags);
@@ -956,6 +961,7 @@ static int _clkdm_clk_hwmod_disable(struct clockdomain
*clkdm)
}
arch_clkdm->clkdm_clk_disable(clkdm);
+ pwrdm_clkdm_disable(clkdm->pwrdm.ptr);
pwrdm_state_switch(clkdm->pwrdm.ptr);
spin_unlock_irqrestore(&clkdm->lock, flags);
@@ -988,6 +994,10 @@ int clkdm_clk_enable(struct clockdomain *clkdm, struct clk
*clk)
if (!clk)
return -EINVAL;
+ /* If autoidle clock, do not update clkdm usecounts */
+ if (clk->autoidle)
+ return 0;
+
return _clkdm_clk_hwmod_enable(clkdm);
}
@@ -1014,6 +1024,10 @@ int clkdm_clk_disable(struct clockdomain *clkdm, struct
clk *clk)
if (!clk)
return -EINVAL;
+ /* If autoidle clock, do not update clkdm usecounts */
+ if (clk->autoidle)
+ return 0;
+
return _clkdm_clk_hwmod_disable(clkdm);
}
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index b9c8d2f..da660d2 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -34,6 +34,7 @@
#include "clock.h"
#include "cm2xxx_3xxx.h"
#include "cm-regbits-34xx.h"
+#include "clockdomain.h"
/* CM_AUTOIDLE_PLL*.AUTO_* bit values */
#define DPLL_AUTOIDLE_DISABLE 0x0
@@ -571,6 +572,15 @@ void omap3_dpll_allow_idle(struct clk *clk)
v |= DPLL_AUTOIDLE_LOW_POWER_
[PATCHv6 03/11] ARM: OMAP3+: voltage: add support for voltagedomain usecounts
These are updated based on powerdomain usecounts. Also added support
for voltdm->sleep and voltdm->wakeup calls that will be invoked once
voltagedomain enters sleep or wakes up based on usecount numbers. These
will be used for controlling voltage scaling functionality.
Signed-off-by: Tero Kristo
Cc: Paul Walmsley
Cc: Kevin Hilman
---
arch/arm/mach-omap2/powerdomain.c | 17 +-
arch/arm/mach-omap2/voltage.c | 65 +
arch/arm/mach-omap2/voltage.h | 13 +++
3 files changed, 94 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index ba49029..abc50c2 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -1475,10 +1475,17 @@ int pwrdm_state_switch(struct powerdomain *pwrdm)
*/
void pwrdm_clkdm_enable(struct powerdomain *pwrdm)
{
+ unsigned long flags;
+
if (!pwrdm)
return;
- atomic_inc(&pwrdm->usecount);
+ spin_lock_irqsave(&pwrdm->lock, flags);
+
+ if (atomic_inc_return(&pwrdm->usecount) == 1)
+ voltdm_pwrdm_enable(pwrdm->voltdm.ptr);
+
+ spin_unlock_irqrestore(&pwrdm->lock, flags);
}
/**
@@ -1492,12 +1499,20 @@ void pwrdm_clkdm_enable(struct powerdomain *pwrdm)
void pwrdm_clkdm_disable(struct powerdomain *pwrdm)
{
int val;
+ unsigned long flags;
if (!pwrdm)
return;
+ spin_lock_irqsave(&pwrdm->lock, flags);
+
val = atomic_dec_return(&pwrdm->usecount);
+ if (!val)
+ voltdm_pwrdm_disable(pwrdm->voltdm.ptr);
+
+ spin_unlock_irqrestore(&pwrdm->lock, flags);
+
WARN_ON(val < 0);
}
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 4dc60e8..0fc2a25 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -340,6 +340,70 @@ int voltdm_add_pwrdm(struct voltagedomain *voltdm, struct
powerdomain *pwrdm)
}
/**
+ * voltdm_pwrdm_enable - increase usecount for a voltagedomain
+ * @voltdm: struct voltagedomain * to increase count for
+ *
+ * Increases usecount for a given voltagedomain. If the usecount reaches
+ * 1, the domain is awakened from idle and the function will call the
+ * voltagedomain->wakeup callback for this domain.
+ */
+void voltdm_pwrdm_enable(struct voltagedomain *voltdm)
+{
+ unsigned long flags;
+
+ if (!voltdm)
+ return;
+
+ spin_lock_irqsave(&voltdm->lock, flags);
+
+ if (atomic_inc_return(&voltdm->usecount) == 1 && voltdm->wakeup)
+ voltdm->wakeup(voltdm);
+
+ spin_unlock_irqrestore(&voltdm->lock, flags);
+}
+
+/**
+ * voltdm_pwrdm_disable - decrease usecount for a voltagedomain
+ * @voltdm: struct voltagedomain * to decrease count for
+ *
+ * Decreases the usecount for a given voltagedomain. If the usecount
+ * reaches zero, the domain can idle and the function will call the
+ * voltagedomain->sleep callback, and calculate the overall target
+ * state for the voltagedomain.
+ */
+void voltdm_pwrdm_disable(struct voltagedomain *voltdm)
+{
+ u8 target_state = PWRDM_POWER_OFF;
+ int state;
+ struct powerdomain *pwrdm;
+ int val;
+ unsigned long flags;
+
+ if (!voltdm)
+ return;
+
+ spin_lock_irqsave(&voltdm->lock, flags);
+
+ val = atomic_dec_return(&voltdm->usecount);
+
+ WARN_ON(val < 0);
+
+ if (val == 0) {
+ /* Determine target state for voltdm */
+ list_for_each_entry(pwrdm, &voltdm->pwrdm_list, voltdm_node) {
+ state = pwrdm_read_next_pwrst(pwrdm);
+ if (state > target_state)
+ target_state = state;
+ }
+ voltdm->target_state = target_state;
+ if (voltdm->sleep)
+ voltdm->sleep(voltdm);
+ }
+
+ spin_unlock_irqrestore(&voltdm->lock, flags);
+}
+
+/**
* voltdm_for_each_pwrdm - call function for each pwrdm in a voltdm
* @voltdm: struct voltagedomain * to iterate over
* @fn: callback function *
@@ -402,6 +466,7 @@ static int _voltdm_register(struct voltagedomain *voltdm)
INIT_LIST_HEAD(&voltdm->pwrdm_list);
list_add(&voltdm->node, &voltdm_list);
+ spin_lock_init(&voltdm->lock);
pr_debug("voltagedomain: registered %s\n", voltdm->name);
return 0;
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 0ac2caf..7f4f99d 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -15,6 +15,7 @@
#define __ARCH_ARM_MACH_OMAP2_VOLTAGE_H
#include
+#include
#include
@@ -56,10 +57,14 @@ struct omap_vfsm_instance {
* @pwrdm_list: list_head linking all powerdomains in this voltagedomain
* @vc: pointer to VC channel associated with this voltagedomain
* @vp: pointer to VP associated with this voltagedomain
+ *
[PATCHv6 01/11] ARM: OMAP: clockdomain: Fix locking on _clkdm_clk_hwmod_enable / disable
Previously the code only acquired spinlock after increasing / decreasing
the usecount value, which is wrong. This leaves a small window where
a task switch may occur between the check of the usecount and the actual
wakeup / sleep of the domain. Fixed by moving the spinlock locking before
the usecount access. Left the usecount as atomic_t if someone wants an
easy access to the parameter through atomic_read.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/clockdomain.c | 15 +++
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index 8664f5a..173905d 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -914,15 +914,18 @@ static int _clkdm_clk_hwmod_enable(struct clockdomain
*clkdm)
if (!clkdm || !arch_clkdm || !arch_clkdm->clkdm_clk_enable)
return -EINVAL;
+ spin_lock_irqsave(&clkdm->lock, flags);
+
/*
* For arch's with no autodeps, clkcm_clk_enable
* should be called for every clock instance or hwmod that is
* enabled, so the clkdm can be force woken up.
*/
- if ((atomic_inc_return(&clkdm->usecount) > 1) && autodeps)
+ if ((atomic_inc_return(&clkdm->usecount) > 1) && autodeps) {
+ spin_unlock_irqrestore(&clkdm->lock, flags);
return 0;
+ }
- spin_lock_irqsave(&clkdm->lock, flags);
arch_clkdm->clkdm_clk_enable(clkdm);
pwrdm_state_switch(clkdm->pwrdm.ptr);
spin_unlock_irqrestore(&clkdm->lock, flags);
@@ -939,15 +942,19 @@ static int _clkdm_clk_hwmod_disable(struct clockdomain
*clkdm)
if (!clkdm || !arch_clkdm || !arch_clkdm->clkdm_clk_disable)
return -EINVAL;
+ spin_lock_irqsave(&clkdm->lock, flags);
+
if (atomic_read(&clkdm->usecount) == 0) {
+ spin_unlock_irqrestore(&clkdm->lock, flags);
WARN_ON(1); /* underflow */
return -ERANGE;
}
- if (atomic_dec_return(&clkdm->usecount) > 0)
+ if (atomic_dec_return(&clkdm->usecount) > 0) {
+ spin_unlock_irqrestore(&clkdm->lock, flags);
return 0;
+ }
- spin_lock_irqsave(&clkdm->lock, flags);
arch_clkdm->clkdm_clk_disable(clkdm);
pwrdm_state_switch(clkdm->pwrdm.ptr);
spin_unlock_irqrestore(&clkdm->lock, flags);
--
1.7.4.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
[PATCHv6 05/11] ARM: OMAP3: set autoidle flag for sdrc_ick
sdrc_ick doesn't have autoidle flag on HW, but is always automatically
idled. Thus mark the autoidle flag statically as true for it to reflect
hardware behavior. The clock will no longer show as active in usecount
dumps and will allow the voltdm->sleep / wakeup calls to work properly.
Signed-off-by: Tero Kristo
Cc: Paul Walmsley
Cc: Kevin Hilman
Reviewed-by: Rajendra Nayak
---
arch/arm/mach-omap2/clock3xxx_data.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 83bed9a..1ddc7fc 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -1739,6 +1739,7 @@ static struct clk sdrc_ick = {
.flags = ENABLE_ON_INIT,
.clkdm_name = "core_l3_clkdm",
.recalc = &followparent_recalc,
+ .autoidle = true,
};
static struct clk gpmc_fck = {
--
1.7.4.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
[PATCHv6 06/11] ARM: OMAP: clockdomain: add support for preventing autodep delete
Some clockdomains bug out if their autodeps are deleted before idle.
This happens namely with OMAP3 PER domain, it will bug out if it
doesn't have wakedeps enabled when it enters off-mode. This patch
adds support for new flag 'CLKDM_NO_AUTODEP_DISABLE' which does this.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/clockdomain.c |3 +++
arch/arm/mach-omap2/clockdomain.h |4
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index 7715353..4f01c8f 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -201,6 +201,9 @@ void _clkdm_del_autodeps(struct clockdomain *clkdm)
if (!autodeps || clkdm->flags & CLKDM_NO_AUTODEPS)
return;
+ if (clkdm->flags & CLKDM_NO_AUTODEP_DISABLE)
+ return;
+
for (autodep = autodeps; autodep->clkdm.ptr; autodep++) {
if (IS_ERR(autodep->clkdm.ptr))
continue;
diff --git a/arch/arm/mach-omap2/clockdomain.h
b/arch/arm/mach-omap2/clockdomain.h
index 5601dc1..9b8733e 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -34,6 +34,9 @@
* CLKDM_ACTIVE_WITH_MPU: The PRCM guarantees that this clockdomain is
* active whenever the MPU is active. True for interconnects and
* the WKUP clockdomains.
+ * CLKDM_NO_AUTODEP_DISABLE: Prevent clockdomain code from deleting autodeps.
+ * Needed for PER domain on omap3, as it will bug out with off-mode if
+ * wakedeps are removed.
*/
#define CLKDM_CAN_FORCE_SLEEP (1 << 0)
#define CLKDM_CAN_FORCE_WAKEUP (1 << 1)
@@ -41,6 +44,7 @@
#define CLKDM_CAN_DISABLE_AUTO (1 << 3)
#define CLKDM_NO_AUTODEPS (1 << 4)
#define CLKDM_ACTIVE_WITH_MPU (1 << 5)
+#define CLKDM_NO_AUTODEP_DISABLE (1 << 6)
#define CLKDM_CAN_HWSUP(CLKDM_CAN_ENABLE_AUTO |
CLKDM_CAN_DISABLE_AUTO)
#define CLKDM_CAN_SWSUP(CLKDM_CAN_FORCE_SLEEP |
CLKDM_CAN_FORCE_WAKEUP)
--
1.7.4.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
[PATCHv6 04/11] ARM: OMAP3: add manual control for mpu / core pwrdm usecounting
mpu / core powerdomain usecounts are now statically increased
by 1 during MPU activity. This allows the domains to reflect
actual usage, and will allow the usecount to reach 0 just before
all CPUs are ready to idle. Proper powerdomain usecounts are
propageted to voltagedomain level also, and will allow vc
callbacks to be triggered at right point of time.
Signed-off-by: Tero Kristo
Cc: Paul Walmsley
Cc: Kevin Hilman
---
arch/arm/mach-omap2/common.h |6 ++
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 72 -
arch/arm/mach-omap2/omap-smp.c|2 +
arch/arm/mach-omap2/pm34xx.c | 21
4 files changed, 100 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 6ea837a..a445a02 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -292,6 +292,8 @@ extern int omap4_finish_suspend(unsigned long cpu_state);
extern void omap4_cpu_resume(void);
extern int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state);
extern u32 omap4_mpuss_read_prev_context_state(void);
+extern void omap4_pm_cpu_online(void);
+extern void omap4_pm_cpu_offline(void);
#else
static inline int omap4_enter_lowpower(unsigned int cpu,
unsigned int power_state)
@@ -323,6 +325,10 @@ static inline u32 omap4_mpuss_read_prev_context_state(void)
{
return 0;
}
+
+static inline void omap4_pm_cpu_online(void) { }
+
+static inline void omap4_pm_cpu_offline(void) { }
#endif
struct omap_sdrc_params;
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 230bdcd..0ad2337 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -72,8 +72,9 @@ struct omap4_cpu_pm_info {
};
static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
-static struct powerdomain *mpuss_pd;
+static struct powerdomain *mpuss_pd, *core_pd;
static void __iomem *sar_base;
+static atomic_t __initdata init_cpu_online_count;
/*
* Program the wakeup routine address for the CPU0 and CPU1
@@ -216,6 +217,50 @@ static void save_l2x0_context(void)
#endif
/**
+ * omap4_pm_cpu_online - increase the number of online CPUs
+ *
+ * This function increases the usecounts for MPU and CORE powerdomains,
+ * which allows the domains to properly reflect usage with online CPUs
+ * also. CORE powerdomain usecount is increased, as MPU is using memories,
+ * which are powered through CORE powerdomain (SDRAM). If this function is
+ * called before PM init has completed (mpuss_pd / core_pd are not defined),
+ * a temporary init time variable is increased instead; its contents
+ * will be moved to the powerdomain usecounts once PM init completes.
+ */
+void omap4_pm_cpu_online(void)
+{
+ if (!mpuss_pd || !core_pd) {
+ atomic_inc(&init_cpu_online_count);
+ return;
+ }
+
+ pwrdm_clkdm_enable(mpuss_pd);
+ pwrdm_clkdm_enable(core_pd);
+}
+
+/**
+ * omap4_pm_cpu_offline - decrease the number of online CPUs
+ *
+ * This function decreases the usecounts for MPU and CORE powerdomains,
+ * which allows the domains to properly reflect usage with online CPUs
+ * also. CORE powerdomain usecount is decreased, as MPU is using memories,
+ * which are powered through CORE powerdomain (SDRAM). If this function is
+ * called before PM init has completed (mpuss_pd / core_pd are not defined),
+ * a temporary init time variable is increased instead; its contents
+ * will be moved to the powerdomain usecounts once PM init completes.
+ */
+void omap4_pm_cpu_offline(void)
+{
+ if (!mpuss_pd || !core_pd) {
+ atomic_dec(&init_cpu_online_count);
+ return;
+ }
+
+ pwrdm_clkdm_disable(mpuss_pd);
+ pwrdm_clkdm_disable(core_pd);
+}
+
+/**
* omap4_enter_lowpower: OMAP4 MPUSS Low Power Entry Function
* The purpose of this function is to manage low power programming
* of OMAP4 MPUSS subsystem
@@ -274,11 +319,17 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
scu_pwrst_prepare(cpu, power_state);
l2x0_pwrst_prepare(cpu, save_state);
+ /* Decrement usecounts for MPU and CORE pd as we are entering idle */
+ omap4_pm_cpu_offline();
+
/*
* Call low level function with targeted low power state.
*/
cpu_suspend(save_state, omap4_finish_suspend);
+ /* Increment usecounts for MPU and CORE pd as we are leaving idle */
+ omap4_pm_cpu_online();
+
/*
* Restore the CPUx power state to ON otherwise CPUx
* power domain can transitions to programmed low power
@@ -315,6 +366,8 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned
int power_state)
set_cpu_wakeup_addr(cpu, virt_to_phys(pm_info->secondary_startup));
scu_pwrst_prepare(cpu, power_state);
+ omap4_
[PATCHv6 08/11] ARM: OMAP4: clock data: set autoidle flag for dss_fck
dss_fck is currently being used improperly within the hwmod database
as an interface clock for DSS hwmods. This causes the dss_fck to
be enabled even if the dss powerdomain itself is idle, resulting
in wrong data within the powerdomain usecounts. Marked dss_fck as
autoidle which makes the clock to disappear from usecounts for now.
This patch can be reverted once the interface clocks for DSS hwmods
have been properly fixed.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/clock44xx_data.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index d7f55e4..95834d7 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -1408,6 +1408,7 @@ static struct clk dss_fck = {
.clkdm_name = "l3_dss_clkdm",
.parent = &l3_div_ck,
.recalc = &followparent_recalc,
+ .autoidle = true,
};
static struct clk efuse_ctrl_cust_fck = {
--
1.7.4.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
[PATCHv6 07/11] ARM: OMAP3: do not delete per_clkdm autodeps during idle
Previously, PER clock domain was always enabled, as the usecounts
for this domain incorrectly always showed positive value. On HW
level though, the domain enters idle as it is set in HW supervised
mode. Now, when the usecounts reflect real values, PER domain
will be put to HWSUP sleep mode, which means its autodeps are deleted.
Removing wakedeps for PER domain will cause multiple problems.
First of all, coming back from idle, PER domain remains idle as the
wakedeps have been disabled for the domain, and this causes a crash
with the GPIO code, as the resume code attempts to access domain
which is not active. Just enabling the interface clocks for the GPIO
does not help, as they are autoidled and don't bring the domain out
of idle. Secondly, there are multiple erratas for omap3, which say
that the wakedeps should be enabled for the PER domain, see e.g.
errata i582 for omap3630.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/clockdomains3xxx_data.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomains3xxx_data.c
b/arch/arm/mach-omap2/clockdomains3xxx_data.c
index 56089c4..3b3c524 100644
--- a/arch/arm/mach-omap2/clockdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/clockdomains3xxx_data.c
@@ -370,7 +370,7 @@ static struct clockdomain usbhost_am35x_clkdm = {
static struct clockdomain per_clkdm = {
.name = "per_clkdm",
.pwrdm = { .name = "per_pwrdm" },
- .flags = CLKDM_CAN_HWSUP_SWSUP,
+ .flags = CLKDM_CAN_HWSUP_SWSUP | CLKDM_NO_AUTODEP_DISABLE,
.dep_bit= OMAP3430_EN_PER_SHIFT,
.wkdep_srcs = per_wkdeps,
.sleepdep_srcs = per_sleepdeps,
--
1.7.4.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
[PATCHv6 10/11] ARM: OMAP4: hwmod data: set mpu hwmod modulemode to hwauto
This makes sure it is handled as autoidle type by the usecounting.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 2d13b33..367de25 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2492,6 +2492,7 @@ static struct omap_hwmod omap44xx_mpu_hwmod = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_MPU_MPU_CLKCTRL_OFFSET,
.context_offs = OMAP4_RM_MPU_MPU_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
},
},
};
--
1.7.4.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
[PATCHv6 09/11] ARM: OMAP4: hwmod: add support for hwmod autoidle flag
If a hwmod is in HWAUTO mode, it will idle automatically and should not
be accounted for in the clkdm / pwrdm usecounts. Thus, flag modules in
such mode as autoidle during init, and ignore these in subsequent
usecount calculations.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/clockdomain.c|6 ++
arch/arm/mach-omap2/omap_hwmod.c |3 +++
arch/arm/plat-omap/include/plat/omap_hwmod.h |2 ++
3 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index 4f01c8f..af88ae5 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -1063,6 +1063,9 @@ int clkdm_hwmod_enable(struct clockdomain *clkdm, struct
omap_hwmod *oh)
if (!oh)
return -EINVAL;
+ if (oh->flags & HWMOD_AUTOIDLE)
+ return 0;
+
return _clkdm_clk_hwmod_enable(clkdm);
}
@@ -1094,6 +1097,9 @@ int clkdm_hwmod_disable(struct clockdomain *clkdm, struct
omap_hwmod *oh)
if (!oh)
return -EINVAL;
+ if (oh->flags & HWMOD_AUTOIDLE)
+ return 0;
+
return _clkdm_clk_hwmod_disable(clkdm);
}
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index f826917..6807b02 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2377,6 +2377,9 @@ static int __init _register(struct omap_hwmod *oh)
INIT_LIST_HEAD(&oh->slave_ports);
spin_lock_init(&oh->_lock);
+ if (cpu_is_omap44xx() && oh->prcm.omap4.modulemode == MODULEMODE_HWCTRL)
+ oh->flags |= HWMOD_AUTOIDLE;
+
oh->_state = _HWMOD_STATE_REGISTERED;
/*
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 0f840a9..36130f9 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -440,6 +440,7 @@ struct omap_hwmod_omap4_prcm {
* in order to complete the reset. Optional clocks will be disabled
* again after the reset.
* HWMOD_16BIT_REG: Module has 16bit registers
+ * HWMOD_AUTOIDLE: Module is controlled automatically by hardware
*/
#define HWMOD_SWSUP_SIDLE (1 << 0)
#define HWMOD_SWSUP_MSTANDBY (1 << 1)
@@ -450,6 +451,7 @@ struct omap_hwmod_omap4_prcm {
#define HWMOD_NO_IDLEST(1 << 6)
#define HWMOD_CONTROL_OPT_CLKS_IN_RESET(1 << 7)
#define HWMOD_16BIT_REG(1 << 8)
+#define HWMOD_AUTOIDLE (1 << 9)
/*
* omap_hwmod._int_flags definitions
--
1.7.4.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
[PATCHv6 11/11] ARM: OMAP4: clock data: flag hw controlled clocks as autoidle
This makes sure these clocks are ignored by the clkdm / pwrdm usecounting.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/clock44xx_data.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 95834d7..d2fb4e8 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3356,8 +3356,11 @@ int __init omap4xxx_clk_init(void)
*/
for (c = omap44xx_clks; c < omap44xx_clks + ARRAY_SIZE(omap44xx_clks);
- c++)
+ c++) {
+ if (c->lk.clk->enable_bit == OMAP4430_MODULEMODE_HWCTRL)
+ c->lk.clk->autoidle = true;
clk_preinit(c->lk.clk);
+ }
for (c = omap44xx_clks; c < omap44xx_clks + ARRAY_SIZE(omap44xx_clks);
c++)
--
1.7.4.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
[PATCHv7 00/21] ARM: OMAP3+: auto retention support
Hi, This set applies on top of linux-3.6-rc5 + func-pwrst code (from Jean) + omap4 core retention set (from me) + PM usecounting changes set (from me). Changes compared to previous version: - Added proper OMAP4 auto-retention support (now that the PM usecount set below supports OMAP4 also properly) - Merged TPS6236x support to this set (patches 16,18-20), without this there will be an issue with patch #21, as panda board will misbehave without TPS support and auto-ret enabled - Patch #15 fixes the addressing of voltage channels for OMAP4, without this the voltage channels either end up changing wrong voltage channel or not changing anything at all - Patch #16 is new based on the discussion earlier on the separate TPS set * uses proper I2C parameters based on board data, this is still in a data table though, as calculating these runtime would be rather complicated (if even possible, as it requires some higher order mathematics according to my understanding) - Patch #17 enables high speed I2C communication for voltage channel on OMAP4 (this now works thanks to patch #16) - Patch #18 is needed for 4460 boards, otherwise the boot-up OPP detection fails and voltage control doesn't work at all on 4460 boards - Patch #19 was pulled from the TPS support set - Patch #20 was pulled from the TPS support set, with following changes: * board setup for the GPIOs was sanitized a bit * dropped a number of unused defines from the code Working branch available: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.6-rc5-omap-auto-ret-v7 Testing done: - hw used: omap3 beagle rev c4, omap4460 gp panda, omap4430 emu blaze - suspend + cpuidle - measured core + mpu voltage rails on all setups to verify that the voltage transitions work properly during idle -Tero -- 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
[PATCHv7 01/21] ARM: OMAP3+: PM: VP: use uV for max and min voltage limits
From: Nishanth Menon
Every PMIC has it's own eccentricities, For example, one of the
PMIC has MSB set to 1 for a specific function - voltage enable!
using an hardcoded value specific for TWL when copied over to
such an implementation causes the system to crash as the MSB bit
was 0 and the voltage got disabled!.
Instead we use actual values and depend on the convertion routines
to abstract out the eccentricities of each PMIC.
With this, we can now move the voltages to a common location in
voltage.h as they are no longer dependent on PMICs and expect the
PMIC's conversion routines to set a cap if the voltage is out of
reach for the PMIC.
Reported-by: Jon Hunter
Signed-off-by: Nishanth Menon
Signed-off-by: Vishwanath BS
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/omap_twl.c | 17 -
arch/arm/mach-omap2/voltage.h | 22 --
arch/arm/mach-omap2/vp.c |4 ++--
3 files changed, 22 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index f515a1a..df4e7c3 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -30,16 +30,6 @@
#define OMAP3_VP_VSTEPMAX_VSTEPMAX 0x04
#define OMAP3_VP_VLIMITTO_TIMEOUT_US 200
-#define OMAP3430_VP1_VLIMITTO_VDDMIN 0x14
-#define OMAP3430_VP1_VLIMITTO_VDDMAX 0x42
-#define OMAP3430_VP2_VLIMITTO_VDDMIN 0x18
-#define OMAP3430_VP2_VLIMITTO_VDDMAX 0x2c
-
-#define OMAP3630_VP1_VLIMITTO_VDDMIN 0x18
-#define OMAP3630_VP1_VLIMITTO_VDDMAX 0x3c
-#define OMAP3630_VP2_VLIMITTO_VDDMIN 0x18
-#define OMAP3630_VP2_VLIMITTO_VDDMAX 0x30
-
#define OMAP4_SRI2C_SLAVE_ADDR 0x12
#define OMAP4_VDD_MPU_SR_VOLT_REG 0x55
#define OMAP4_VDD_MPU_SR_CMD_REG 0x56
@@ -53,13 +43,6 @@
#define OMAP4_VP_VSTEPMAX_VSTEPMAX 0x04
#define OMAP4_VP_VLIMITTO_TIMEOUT_US 200
-#define OMAP4_VP_MPU_VLIMITTO_VDDMIN 0xA
-#define OMAP4_VP_MPU_VLIMITTO_VDDMAX 0x39
-#define OMAP4_VP_IVA_VLIMITTO_VDDMIN 0xA
-#define OMAP4_VP_IVA_VLIMITTO_VDDMAX 0x2D
-#define OMAP4_VP_CORE_VLIMITTO_VDDMIN 0xA
-#define OMAP4_VP_CORE_VLIMITTO_VDDMAX 0x28
-
static bool is_offset_valid;
static u8 smps_offset;
/*
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 7f4f99d..622ec4b 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -103,6 +103,24 @@ struct voltagedomain {
spinlock_t lock;
};
+/* Min and max voltages from OMAP perspective */
+#define OMAP3430_VP1_VLIMITTO_VDDMIN 85
+#define OMAP3430_VP1_VLIMITTO_VDDMAX 1425000
+#define OMAP3430_VP2_VLIMITTO_VDDMIN 90
+#define OMAP3430_VP2_VLIMITTO_VDDMAX 115
+
+#define OMAP3630_VP1_VLIMITTO_VDDMIN 90
+#define OMAP3630_VP1_VLIMITTO_VDDMAX 135
+#define OMAP3630_VP2_VLIMITTO_VDDMIN 90
+#define OMAP3630_VP2_VLIMITTO_VDDMAX 120
+
+#define OMAP4_VP_MPU_VLIMITTO_VDDMIN 83
+#define OMAP4_VP_MPU_VLIMITTO_VDDMAX 141
+#define OMAP4_VP_IVA_VLIMITTO_VDDMIN 83
+#define OMAP4_VP_IVA_VLIMITTO_VDDMAX 126
+#define OMAP4_VP_CORE_VLIMITTO_VDDMIN 83
+#define OMAP4_VP_CORE_VLIMITTO_VDDMAX 120
+
/**
* struct omap_voltdm_pmic - PMIC specific data required by voltage driver.
* @slew_rate: PMIC slew rate (in uv/us)
@@ -129,8 +147,8 @@ struct omap_voltdm_pmic {
u8 vp_erroroffset;
u8 vp_vstepmin;
u8 vp_vstepmax;
- u8 vp_vddmin;
- u8 vp_vddmax;
+ u32 vp_vddmin;
+ u32 vp_vddmax;
u8 vp_timeout_us;
bool i2c_high_speed;
u8 i2c_mcode;
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index f95c1ba..40b3dcc 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -58,8 +58,8 @@ void __init omap_vp_init(struct voltagedomain *voltdm)
sys_clk_rate = voltdm->sys_clk.rate / 1000;
timeout = (sys_clk_rate * voltdm->pmic->vp_timeout_us) / 1000;
- vddmin = voltdm->pmic->vp_vddmin;
- vddmax = voltdm->pmic->vp_vddmax;
+ vddmin = voltdm->pmic->uv_to_vsel(voltdm->pmic->vp_vddmin);
+ vddmax = voltdm->pmic->uv_to_vsel(voltdm->pmic->vp_vddmax);
waittime = DIV_ROUND_UP(voltdm->pmic->step_size * sys_clk_rate,
1000 * voltdm->pmic->slew_rate);
--
1.7.4.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
[PATCHv7 02/21] ARM: OMAP: voltage: renamed vp_vddmin and vp_vddmax fields
These are now called vddmin and vddmax, as these fields will be used
globally for selecting voltage ranges for a pmic channel, and not
only for voltage processor.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/omap_twl.c | 28 ++--
arch/arm/mach-omap2/voltage.h |4 ++--
arch/arm/mach-omap2/vp.c |4 ++--
3 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index df4e7c3..c38a530 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -149,8 +149,8 @@ static struct omap_voltdm_pmic omap3_mpu_pmic = {
.vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP3_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP3_VP_VSTEPMAX_VSTEPMAX,
- .vp_vddmin = OMAP3430_VP1_VLIMITTO_VDDMIN,
- .vp_vddmax = OMAP3430_VP1_VLIMITTO_VDDMAX,
+ .vddmin = OMAP3430_VP1_VLIMITTO_VDDMIN,
+ .vddmax = OMAP3430_VP1_VLIMITTO_VDDMAX,
.vp_timeout_us = OMAP3_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP3_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP3_VDD_MPU_SR_CONTROL_REG,
@@ -170,8 +170,8 @@ static struct omap_voltdm_pmic omap3_core_pmic = {
.vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP3_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP3_VP_VSTEPMAX_VSTEPMAX,
- .vp_vddmin = OMAP3430_VP2_VLIMITTO_VDDMIN,
- .vp_vddmax = OMAP3430_VP2_VLIMITTO_VDDMAX,
+ .vddmin = OMAP3430_VP2_VLIMITTO_VDDMIN,
+ .vddmax = OMAP3430_VP2_VLIMITTO_VDDMAX,
.vp_timeout_us = OMAP3_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP3_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP3_VDD_CORE_SR_CONTROL_REG,
@@ -191,8 +191,8 @@ static struct omap_voltdm_pmic omap4_mpu_pmic = {
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP4_VP_VSTEPMAX_VSTEPMAX,
- .vp_vddmin = OMAP4_VP_MPU_VLIMITTO_VDDMIN,
- .vp_vddmax = OMAP4_VP_MPU_VLIMITTO_VDDMAX,
+ .vddmin = OMAP4_VP_MPU_VLIMITTO_VDDMIN,
+ .vddmax = OMAP4_VP_MPU_VLIMITTO_VDDMAX,
.vp_timeout_us = OMAP4_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP4_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP4_VDD_MPU_SR_VOLT_REG,
@@ -213,8 +213,8 @@ static struct omap_voltdm_pmic omap4_iva_pmic = {
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP4_VP_VSTEPMAX_VSTEPMAX,
- .vp_vddmin = OMAP4_VP_IVA_VLIMITTO_VDDMIN,
- .vp_vddmax = OMAP4_VP_IVA_VLIMITTO_VDDMAX,
+ .vddmin = OMAP4_VP_IVA_VLIMITTO_VDDMIN,
+ .vddmax = OMAP4_VP_IVA_VLIMITTO_VDDMAX,
.vp_timeout_us = OMAP4_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP4_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP4_VDD_IVA_SR_VOLT_REG,
@@ -235,8 +235,8 @@ static struct omap_voltdm_pmic omap4_core_pmic = {
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP4_VP_VSTEPMAX_VSTEPMAX,
- .vp_vddmin = OMAP4_VP_CORE_VLIMITTO_VDDMIN,
- .vp_vddmax = OMAP4_VP_CORE_VLIMITTO_VDDMAX,
+ .vddmin = OMAP4_VP_CORE_VLIMITTO_VDDMIN,
+ .vddmax = OMAP4_VP_CORE_VLIMITTO_VDDMAX,
.vp_timeout_us = OMAP4_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP4_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP4_VDD_CORE_SR_VOLT_REG,
@@ -272,10 +272,10 @@ int __init omap3_twl_init(void)
return -ENODEV;
if (cpu_is_omap3630()) {
- omap3_mpu_pmic.vp_vddmin = OMAP3630_VP1_VLIMITTO_VDDMIN;
- omap3_mpu_pmic.vp_vddmax = OMAP3630_VP1_VLIMITTO_VDDMAX;
- omap3_core_pmic.vp_vddmin = OMAP3630_VP2_VLIMITTO_VDDMIN;
- omap3_core_pmic.vp_vddmax = OMAP3630_VP2_VLIMITTO_VDDMAX;
+ omap3_mpu_pmic.vddmin = OMAP3630_VP1_VLIMITTO_VDDMIN;
+ omap3_mpu_pmic.vddmax = OMAP3630_VP1_VLIMITTO_VDDMAX;
+ omap3_core_pmic.vddmin = OMAP3630_VP2_VLIMITTO_VDDMIN;
+ omap3_core_pmic.vddmax = OMAP3630_VP2_VLIMITTO_VDDMAX;
}
/*
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 622ec4b..2242735 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -147,8 +147,8 @@ st
[PATCHv7 03/21] ARM: OMAP3+: voltage: introduce omap vc / vp params for voltagedomains
These new structs will hold the sleep voltage levels (omap_vc_params)
and voltage processor min / max voltages (omap_vp_params.) Previously
these were part of the PMIC struct, but they do not really belong there,
as they are OMAP chip specific, not PMIC specific parameters. voltdm
code is also changed to use the new structs.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/omap_twl.c| 20 --
arch/arm/mach-omap2/vc.c | 35 ++---
arch/arm/mach-omap2/vc.h |7 +
arch/arm/mach-omap2/vc3xxx_data.c | 22 +++
arch/arm/mach-omap2/vc44xx_data.c | 28
arch/arm/mach-omap2/voltage.h | 18 ++---
arch/arm/mach-omap2/voltagedomains3xxx_data.c |5 +++
arch/arm/mach-omap2/voltagedomains44xx_data.c |8 +
arch/arm/mach-omap2/vp.h |7 +
arch/arm/mach-omap2/vp3xxx_data.c | 10 +++
arch/arm/mach-omap2/vp44xx_data.c | 15 ++
11 files changed, 147 insertions(+), 28 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index c38a530..dca1d66 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -141,10 +141,6 @@ static u8 twl6030_uv_to_vsel(unsigned long uv)
static struct omap_voltdm_pmic omap3_mpu_pmic = {
.slew_rate = 4000,
.step_size = 12500,
- .on_volt= 120,
- .onlp_volt = 100,
- .ret_volt = 975000,
- .off_volt = 60,
.volt_setup_time= 0xfff,
.vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP3_VP_VSTEPMIN_VSTEPMIN,
@@ -162,10 +158,6 @@ static struct omap_voltdm_pmic omap3_mpu_pmic = {
static struct omap_voltdm_pmic omap3_core_pmic = {
.slew_rate = 4000,
.step_size = 12500,
- .on_volt= 120,
- .onlp_volt = 100,
- .ret_volt = 975000,
- .off_volt = 60,
.volt_setup_time= 0xfff,
.vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP3_VP_VSTEPMIN_VSTEPMIN,
@@ -183,10 +175,6 @@ static struct omap_voltdm_pmic omap3_core_pmic = {
static struct omap_voltdm_pmic omap4_mpu_pmic = {
.slew_rate = 4000,
.step_size = 12660,
- .on_volt= 1375000,
- .onlp_volt = 1375000,
- .ret_volt = 83,
- .off_volt = 0,
.volt_setup_time= 0,
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
@@ -205,10 +193,6 @@ static struct omap_voltdm_pmic omap4_mpu_pmic = {
static struct omap_voltdm_pmic omap4_iva_pmic = {
.slew_rate = 4000,
.step_size = 12660,
- .on_volt= 1188000,
- .onlp_volt = 1188000,
- .ret_volt = 83,
- .off_volt = 0,
.volt_setup_time= 0,
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
@@ -227,10 +211,6 @@ static struct omap_voltdm_pmic omap4_iva_pmic = {
static struct omap_voltdm_pmic omap4_core_pmic = {
.slew_rate = 4000,
.step_size = 12660,
- .on_volt= 120,
- .onlp_volt = 120,
- .ret_volt = 83,
- .off_volt = 0,
.volt_setup_time= 0,
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 84da34f..a1e0fd6 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -137,6 +137,8 @@ int omap_vc_pre_scale(struct voltagedomain *voltdm,
vc_cmdval |= (*target_vsel << vc->common->cmd_on_shift);
voltdm->write(vc_cmdval, vc->cmdval_reg);
+ voltdm->vc_param->on = target_volt;
+
omap_vp_update_errorgain(voltdm, target_volt);
return 0;
@@ -286,6 +288,30 @@ static void __init omap_vc_i2c_init(struct voltagedomain
*voltdm)
initialized = true;
}
+/**
+ * omap_vc_calc_vsel - calculate vsel value for a channel
+ * @voltdm: channel to calculate value for
+ * @uvolt: microvolt value to convert to vsel
+ *
+ * Converts a microvolt value to vsel value for the used PMIC.
+ * This checks whether the microvolt value is out of bounds, and
+ * adjusts the value accordingly. If unsupported value detected,
+ * warning is thrown.
+ */
+static u8 omap_vc_calc_vsel(struct v
[PATCHv7 04/21] ARM: OMAP3: VC: calculate ramp times
OMAP3 VC code now uses voltage deltas + slew rates for calculating actual
ramp times for voltage changes. Previously a static value was used.
Two calculation methods are provided: i2c_timings and off_timings.
I2C timings are used during retention or off mode transition which
is initiated over I2C, and OFF timings are used if PMIC signal
(nsleep) is used to control all the off mode voltages at the same time.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/vc.c | 108 ++---
arch/arm/mach-omap2/vc.h |1 -
2 files changed, 91 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index a1e0fd6..bba0d7c 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -206,29 +206,109 @@ int omap_vc_bypass_scale(struct voltagedomain *voltdm,
return 0;
}
-static void __init omap3_vfsm_init(struct voltagedomain *voltdm)
+/**
+ * omap3_set_i2c_timings - sets i2c sleep timings for a channel
+ * @voltdm: channel to configure
+ * @off_mode: select whether retention or off mode values used
+ *
+ * Calculates and sets up voltage controller to use I2C based
+ * voltage scaling for sleep modes. This can be used for either off mode
+ * or retention. Off mode has additionally an option to use sys_off_mode
+ * pad, which uses a global signal to program the whole power IC to
+ * off-mode.
+ */
+static void omap3_set_i2c_timings(struct voltagedomain *voltdm, bool off_mode)
{
+ unsigned long voltsetup1;
+ u32 tgt_volt;
+
+ if (off_mode)
+ tgt_volt = voltdm->vc_param->off;
+ else
+ tgt_volt = voltdm->vc_param->ret;
+
+ voltsetup1 = (voltdm->vc_param->on - tgt_volt) /
+ voltdm->pmic->slew_rate;
+
+ voltsetup1 = voltsetup1 * voltdm->sys_clk.rate / 8 / 100 + 1;
+
+ voltdm->rmw(voltdm->vfsm->voltsetup_mask,
+ voltsetup1 << __ffs(voltdm->vfsm->voltsetup_mask),
+ voltdm->vfsm->voltsetup_reg);
+
/*
-* Voltage Manager FSM parameters init
-* XXX This data should be passed in from the board file
+* pmic is not controlling the voltage scaling during retention,
+* thus set voltsetup2 to 0
*/
- voltdm->write(OMAP3_CLKSETUP, OMAP3_PRM_CLKSETUP_OFFSET);
- voltdm->write(OMAP3_VOLTOFFSET, OMAP3_PRM_VOLTOFFSET_OFFSET);
- voltdm->write(OMAP3_VOLTSETUP2, OMAP3_PRM_VOLTSETUP2_OFFSET);
+ voltdm->write(0, OMAP3_PRM_VOLTSETUP2_OFFSET);
}
-static void __init omap3_vc_init_channel(struct voltagedomain *voltdm)
+/**
+ * omap3_set_off_timings - sets off-mode timings for a channel
+ * @voltdm: channel to configure
+ *
+ * Calculates and sets up off-mode timings for a channel. Off-mode
+ * can use either I2C based voltage scaling, or alternatively
+ * sys_off_mode pad can be used to send a global command to power IC.
+ * This function first checks which mode is being used, and calls
+ * omap3_set_i2c_timings() if the system is using I2C control mode.
+ * sys_off_mode has the additional benefit that voltages can be
+ * scaled to zero volt level with TWL4030 / TWL5030, I2C can only
+ * scale to 600mV.
+ */
+static void omap3_set_off_timings(struct voltagedomain *voltdm)
{
- static bool is_initialized;
+ unsigned long clksetup;
+ unsigned long voltsetup2;
+ unsigned long voltsetup2_old;
+ u32 val;
- if (is_initialized)
+ /* check if sys_off_mode is used to control off-mode voltages */
+ val = voltdm->read(OMAP3_PRM_VOLTCTRL_OFFSET);
+ if (!(val & OMAP3430_SEL_OFF_MASK)) {
+ /* No, omap is controlling them over I2C */
+ omap3_set_i2c_timings(voltdm, true);
return;
+ }
- omap3_vfsm_init(voltdm);
+ clksetup = voltdm->read(OMAP3_PRM_CLKSETUP_OFFSET);
- is_initialized = true;
+ /* voltsetup 2 in us */
+ voltsetup2 = voltdm->vc_param->on / voltdm->pmic->slew_rate;
+
+ /* convert to 32k clk cycles */
+ voltsetup2 = DIV_ROUND_UP(voltsetup2 * 32768, 100);
+
+ voltsetup2_old = voltdm->read(OMAP3_PRM_VOLTSETUP2_OFFSET);
+
+ /*
+* Update voltsetup2 if higher than current value (needed because
+* we have multiple channels with different ramp times), also
+* update voltoffset always to value recommended by TRM
+*/
+ if (voltsetup2 > voltsetup2_old) {
+ voltdm->write(voltsetup2, OMAP3_PRM_VOLTSETUP2_OFFSET);
+ voltdm->write(clksetup - voltsetup2,
+ OMAP3_PRM_VOLTOFFSET_OFFSET);
+ } else
+ voltdm->write(clksetup - voltsetup2_old,
+ OMAP3_PRM_VOLTOFFSET_OFFSET);
+
+ /*
+* omap is not controlling voltage scaling during off-mode,
+* thus set voltsetup1 to 0
+*/
+ voltdm->rmw(voltdm->vfsm->voltsetup_mask, 0,
+ voltdm->vfsm->voltsetu
[PATCHv7 05/21] ARM: OMAP4: voltage: add support for VOLTSETUP_x_OFF register
OMAP4 has two VOLTSETUP registers. One is controlling retention and
sleep voltage setup times, the other one off mode setup times. Both
of these need to be setup for stable behavior of the device.
The code setting up the new register will be added in the next
patch.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/voltage.h |2 ++
arch/arm/mach-omap2/voltagedomains44xx_data.c |3 +++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 94c6919..01ab2e5 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -41,12 +41,14 @@ struct powerdomain;
* data
* @voltsetup_mask: SETUP_TIME* bitmask in the PRM_VOLTSETUP* register
* @voltsetup_reg: register offset of PRM_VOLTSETUP from PRM base
+ * @voltsetup_off_reg: register offset of PRM_VOLTSETUP_OFF from PRM base
*
* XXX What about VOLTOFFSET/VOLTCTRL?
*/
struct omap_vfsm_instance {
u32 voltsetup_mask;
u8 voltsetup_reg;
+ u8 voltsetup_off_reg;
};
/**
diff --git a/arch/arm/mach-omap2/voltagedomains44xx_data.c
b/arch/arm/mach-omap2/voltagedomains44xx_data.c
index a2d7d9c..7da35a6 100644
--- a/arch/arm/mach-omap2/voltagedomains44xx_data.c
+++ b/arch/arm/mach-omap2/voltagedomains44xx_data.c
@@ -34,14 +34,17 @@
static const struct omap_vfsm_instance omap4_vdd_mpu_vfsm = {
.voltsetup_reg = OMAP4_PRM_VOLTSETUP_MPU_RET_SLEEP_OFFSET,
+ .voltsetup_off_reg = OMAP4_PRM_VOLTSETUP_MPU_OFF_OFFSET,
};
static const struct omap_vfsm_instance omap4_vdd_iva_vfsm = {
.voltsetup_reg = OMAP4_PRM_VOLTSETUP_IVA_RET_SLEEP_OFFSET,
+ .voltsetup_off_reg = OMAP4_PRM_VOLTSETUP_IVA_OFF_OFFSET,
};
static const struct omap_vfsm_instance omap4_vdd_core_vfsm = {
.voltsetup_reg = OMAP4_PRM_VOLTSETUP_CORE_RET_SLEEP_OFFSET,
+ .voltsetup_off_reg = OMAP4_PRM_VOLTSETUP_CORE_OFF_OFFSET,
};
static struct voltagedomain omap4_voltdm_mpu = {
--
1.7.4.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
[PATCHv7 08/21] ARM: OMAP3+: vp: use new vp_params for calculating vddmin and vddmax
Now we select the vddmin and vddmax values based on both pmic and voltage processor data, this allows usage of different power ICs. Signed-off-by: Tero Kristo --- arch/arm/mach-omap2/vp.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c index c585dfb..c9277c3 100644 --- a/arch/arm/mach-omap2/vp.c +++ b/arch/arm/mach-omap2/vp.c @@ -58,8 +58,10 @@ void __init omap_vp_init(struct voltagedomain *voltdm) sys_clk_rate = voltdm->sys_clk.rate / 1000; timeout = (sys_clk_rate * voltdm->pmic->vp_timeout_us) / 1000; - vddmin = voltdm->pmic->uv_to_vsel(voltdm->pmic->vddmin); - vddmax = voltdm->pmic->uv_to_vsel(voltdm->pmic->vddmax); + vddmin = max(voltdm->vp_param->vddmin, voltdm->pmic->vddmin); + vddmax = min(voltdm->vp_param->vddmax, voltdm->pmic->vddmax); + vddmin = voltdm->pmic->uv_to_vsel(vddmin); + vddmax = voltdm->pmic->uv_to_vsel(vddmax); waittime = DIV_ROUND_UP(voltdm->pmic->step_size * sys_clk_rate, 1000 * voltdm->pmic->slew_rate); -- 1.7.4.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
[PATCHv7 09/21] ARM: OMAP3+: voltage: use oscillator data to calculate setup times
We now use the previously defined oscillator setup / shutdown times
to calculate the register values for CLKSETUP.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/vc.c | 62 ++
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 26750fe..a587506 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -11,14 +11,20 @@
#include
#include
#include
+#include
+
+#include
#include
+#include "iomap.h"
#include "voltage.h"
#include "vc.h"
#include "prm-regbits-34xx.h"
#include "prm-regbits-44xx.h"
#include "prm44xx.h"
+#include "pm.h"
+#include "scrm44xx.h"
/**
* struct omap_vc_channel_cfg - describe the cfg_channel bitfield
@@ -206,6 +212,18 @@ int omap_vc_bypass_scale(struct voltagedomain *voltdm,
return 0;
}
+/* Convert microsecond value to number of 32kHz clock cycles */
+static inline u32 omap_usec_to_32k(u32 usec)
+{
+ return DIV_ROUND_UP_ULL(32768ULL * (u64)usec, 100ULL);
+}
+
+/* Set oscillator setup time for omap3 */
+static void omap3_set_clksetup(u32 usec, struct voltagedomain *voltdm)
+{
+ voltdm->write(omap_usec_to_32k(usec), OMAP3_PRM_CLKSETUP_OFFSET);
+}
+
/**
* omap3_set_i2c_timings - sets i2c sleep timings for a channel
* @voltdm: channel to configure
@@ -222,6 +240,12 @@ static void omap3_set_i2c_timings(struct voltagedomain
*voltdm, bool off_mode)
unsigned long voltsetup1;
u32 tgt_volt;
+ /*
+* Oscillator is shut down only if we are using sys_off_mode pad,
+* thus we set a minimal setup time here
+*/
+ omap3_set_clksetup(1, voltdm);
+
if (off_mode)
tgt_volt = voltdm->vc_param->off;
else
@@ -262,6 +286,7 @@ static void omap3_set_off_timings(struct voltagedomain
*voltdm)
unsigned long voltsetup2;
unsigned long voltsetup2_old;
u32 val;
+ u32 tstart, tshut;
/* check if sys_off_mode is used to control off-mode voltages */
val = voltdm->read(OMAP3_PRM_VOLTCTRL_OFFSET);
@@ -271,6 +296,9 @@ static void omap3_set_off_timings(struct voltagedomain
*voltdm)
return;
}
+ omap_pm_get_oscillator(&tstart, &tshut);
+ omap3_set_clksetup(tstart, voltdm);
+
clksetup = voltdm->read(OMAP3_PRM_CLKSETUP_OFFSET);
/* voltsetup 2 in us */
@@ -367,6 +395,30 @@ static u32 omap4_calc_volt_ramp(struct voltagedomain
*voltdm, u32 voltage_diff)
}
/**
+ * omap4_usec_to_val_scrm - convert microsecond value to SCRM module bitfield
+ * @usec: microseconds
+ * @shift: number of bits to shift left
+ * @mask: bitfield mask
+ *
+ * Converts microsecond value to OMAP4 SCRM bitfield. Bitfield is
+ * shifted to requested position, and checked agains the mask value.
+ * If larger, forced to the max value of the field (i.e. the mask itself.)
+ * Returns the SCRM bitfield value.
+ */
+static u32 omap4_usec_to_val_scrm(u32 usec, int shift, u32 mask)
+{
+ u32 val;
+
+ val = omap_usec_to_32k(usec) << shift;
+
+ /* Check for overflow, if yes, force to max value */
+ if (val > mask)
+ val = mask;
+
+ return val;
+}
+
+/**
* omap4_set_timings - set voltage ramp timings for a channel
* @voltdm: channel to configure
* @off_mode: whether off-mode values are used
@@ -378,6 +430,7 @@ static void omap4_set_timings(struct voltagedomain *voltdm,
bool off_mode)
u32 val;
u32 ramp;
int offset;
+ u32 tstart, tshut;
if (off_mode) {
ramp = omap4_calc_volt_ramp(voltdm,
@@ -399,6 +452,15 @@ static void omap4_set_timings(struct voltagedomain
*voltdm, bool off_mode)
val |= ramp << OMAP4430_RAMP_UP_COUNT_SHIFT;
voltdm->write(val, offset);
+
+ omap_pm_get_oscillator(&tstart, &tshut);
+
+ val = omap4_usec_to_val_scrm(tstart, OMAP4_SETUPTIME_SHIFT,
+ OMAP4_SETUPTIME_MASK);
+ val |= omap4_usec_to_val_scrm(tshut, OMAP4_DOWNTIME_SHIFT,
+ OMAP4_DOWNTIME_MASK);
+
+ __raw_writel(val, OMAP4_SCRM_CLKSETUPTIME);
}
/* OMAP4 specific voltage init functions */
--
1.7.4.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
[PATCHv7 07/21] ARM: OMAP: add support for oscillator setup
This contains startup and shutdown times for the oscillator. By default
use ULONG_MAX. Oscillator setup is used for calculating and setting up
latencies for sleep modes that disable oscillator.
Based on a patch from Nishanth Menon .
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/pm.c | 30 ++
arch/arm/mach-omap2/pm.h |8
2 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index dfe702b..b98439c 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -38,6 +38,36 @@ static struct omap_device_pm_latency *pm_lats;
*/
int (*omap_pm_suspend)(void);
+/**
+ * struct omap2_oscillator - Describe the board main oscillator latencies
+ * @startup_time: oscillator startup latency
+ * @shutdown_time: oscillator shutdown latency
+ */
+struct omap2_oscillator {
+ u32 startup_time;
+ u32 shutdown_time;
+};
+
+static struct omap2_oscillator oscillator = {
+ .startup_time = ULONG_MAX,
+ .shutdown_time = ULONG_MAX,
+};
+
+void omap_pm_setup_oscillator(u32 tstart, u32 tshut)
+{
+ oscillator.startup_time = tstart;
+ oscillator.shutdown_time = tshut;
+}
+
+void omap_pm_get_oscillator(u32 *tstart, u32 *tshut)
+{
+ if (!tstart || !tshut)
+ return;
+
+ *tstart = oscillator.startup_time;
+ *tshut = oscillator.shutdown_time;
+}
+
static int __init _init_omap_device(char *name)
{
struct omap_hwmod *oh;
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index bee3911..583b40f 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -136,4 +136,12 @@ static inline int omap4_twl_init(void)
}
#endif
+#ifdef CONFIG_PM
+extern void omap_pm_setup_oscillator(u32 tstart, u32 tshut);
+extern void omap_pm_get_oscillator(u32 *tstart, u32 *tshut);
+#else
+static inline void omap_pm_setup_oscillator(u32 tstart, u32 tshut) { }
+static inline void omap_pm_get_oscillator(u32 *tstart, u32 *tshut) { }
+#endif
+
#endif
--
1.7.4.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
[PATCHv7 11/21] TEMP: ARM: OMAP3: beagle rev-c4: enable OPP6
Beagleboard rev-c4 has a speed sorted OMAP3530 chip which can run at 720MHz.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/board-omap3beagle.c | 29 +
arch/arm/mach-omap2/opp3xxx_data.c |4
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 6202fc7..0d2a45f 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -459,6 +459,35 @@ static void __init beagle_opp_init(void)
return;
}
+ if (omap3_beagle_version == OMAP3BEAGLE_BOARD_C4) {
+ struct device *mpu_dev, *iva_dev;
+
+ mpu_dev = omap_device_get_by_hwmod_name("mpu");
+ iva_dev = omap_device_get_by_hwmod_name("iva");
+
+ if (!mpu_dev || !iva_dev) {
+ pr_err("%s: Aiee.. no mpu/dsp devices? %p %p\n",
+ __func__, mpu_dev, iva_dev);
+ return;
+ }
+ /* Enable MPU 720MHz opp */
+ r = opp_enable(mpu_dev, 72000);
+
+ /* Enable IVA 520MHz opp */
+ r |= opp_enable(iva_dev, 52000);
+
+ if (r) {
+ pr_err("%s: failed to enable higher opp %d\n",
+ __func__, r);
+ /*
+* Cleanup - disable the higher freqs - we dont care
+* about the results
+*/
+ opp_disable(mpu_dev, 72000);
+ opp_disable(iva_dev, 52000);
+ }
+ }
+
/* Custom OPP enabled for all xM versions */
if (cpu_is_omap3630()) {
struct device *mpu_dev, *iva_dev;
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c
b/arch/arm/mach-omap2/opp3xxx_data.c
index d95f3f9..a0f5fe1 100644
--- a/arch/arm/mach-omap2/opp3xxx_data.c
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -98,6 +98,8 @@ static struct omap_opp_def __initdata omap34xx_opp_def_list[]
= {
OPP_INITIALIZER("mpu", true, 55000, OMAP3430_VDD_MPU_OPP4_UV),
/* MPU OPP5 */
OPP_INITIALIZER("mpu", true, 6, OMAP3430_VDD_MPU_OPP5_UV),
+ /* MPU OPP6 : omap3530 high speed grade only */
+ OPP_INITIALIZER("mpu", false, 72000, OMAP3430_VDD_MPU_OPP5_UV),
/*
* L3 OPP1 - 41.5 MHz is disabled because: The voltage for that OPP is
@@ -123,6 +125,8 @@ static struct omap_opp_def __initdata
omap34xx_opp_def_list[] = {
OPP_INITIALIZER("iva", true, 4, OMAP3430_VDD_MPU_OPP4_UV),
/* DSP OPP5 */
OPP_INITIALIZER("iva", true, 43000, OMAP3430_VDD_MPU_OPP5_UV),
+ /* DSP OPP6 : omap3530 high speed grade only */
+ OPP_INITIALIZER("iva", false, 52000, OMAP3430_VDD_MPU_OPP5_UV),
};
static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
--
1.7.4.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
[PATCHv7 10/21] ARM: OMAP: TWL: change the vddmin / vddmax voltages to spec
As vddmin / vddmax voltages for the pmic only describe the pmic
capabilities now, change the voltages to be according to spec.
TWL data manuals give following values:
TWL4030 (SWCS019L) : VDD1: 600mV ... 1450mV, VDD2: 600mV ... 1500mV
TWL5030 (SWCS030E) : VDD1: 600mV ... 1450mV, VDD2: 600mV ... 1500mV
TWL6030 (SWCS045A) : 0V ... 2100mV
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/omap_twl.c | 27 ++-
1 files changed, 10 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index dca1d66..188f210 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -145,8 +145,8 @@ static struct omap_voltdm_pmic omap3_mpu_pmic = {
.vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP3_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP3_VP_VSTEPMAX_VSTEPMAX,
- .vddmin = OMAP3430_VP1_VLIMITTO_VDDMIN,
- .vddmax = OMAP3430_VP1_VLIMITTO_VDDMAX,
+ .vddmin = 60,
+ .vddmax = 145,
.vp_timeout_us = OMAP3_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP3_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP3_VDD_MPU_SR_CONTROL_REG,
@@ -162,8 +162,8 @@ static struct omap_voltdm_pmic omap3_core_pmic = {
.vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP3_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP3_VP_VSTEPMAX_VSTEPMAX,
- .vddmin = OMAP3430_VP2_VLIMITTO_VDDMIN,
- .vddmax = OMAP3430_VP2_VLIMITTO_VDDMAX,
+ .vddmin = 60,
+ .vddmax = 145,
.vp_timeout_us = OMAP3_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP3_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP3_VDD_CORE_SR_CONTROL_REG,
@@ -179,8 +179,8 @@ static struct omap_voltdm_pmic omap4_mpu_pmic = {
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP4_VP_VSTEPMAX_VSTEPMAX,
- .vddmin = OMAP4_VP_MPU_VLIMITTO_VDDMIN,
- .vddmax = OMAP4_VP_MPU_VLIMITTO_VDDMAX,
+ .vddmin = 0,
+ .vddmax = 210,
.vp_timeout_us = OMAP4_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP4_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP4_VDD_MPU_SR_VOLT_REG,
@@ -197,8 +197,8 @@ static struct omap_voltdm_pmic omap4_iva_pmic = {
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP4_VP_VSTEPMAX_VSTEPMAX,
- .vddmin = OMAP4_VP_IVA_VLIMITTO_VDDMIN,
- .vddmax = OMAP4_VP_IVA_VLIMITTO_VDDMAX,
+ .vddmin = 0,
+ .vddmax = 210,
.vp_timeout_us = OMAP4_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP4_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP4_VDD_IVA_SR_VOLT_REG,
@@ -215,8 +215,8 @@ static struct omap_voltdm_pmic omap4_core_pmic = {
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP4_VP_VSTEPMAX_VSTEPMAX,
- .vddmin = OMAP4_VP_CORE_VLIMITTO_VDDMIN,
- .vddmax = OMAP4_VP_CORE_VLIMITTO_VDDMAX,
+ .vddmin = 0,
+ .vddmax = 210,
.vp_timeout_us = OMAP4_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP4_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP4_VDD_CORE_SR_VOLT_REG,
@@ -251,13 +251,6 @@ int __init omap3_twl_init(void)
if (!cpu_is_omap34xx())
return -ENODEV;
- if (cpu_is_omap3630()) {
- omap3_mpu_pmic.vddmin = OMAP3630_VP1_VLIMITTO_VDDMIN;
- omap3_mpu_pmic.vddmax = OMAP3630_VP1_VLIMITTO_VDDMAX;
- omap3_core_pmic.vddmin = OMAP3630_VP2_VLIMITTO_VDDMIN;
- omap3_core_pmic.vddmax = OMAP3630_VP2_VLIMITTO_VDDMAX;
- }
-
/*
* The smartreflex bit on twl4030 specifies if the setting of voltage
* is done over the I2C_SR path. Since this setting is independent of
--
1.7.4.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
[PATCHv7 12/21] ARM: OMAP: beagle: set oscillator startup time to 10ms for rev c4
Based on the oscillator datasheet for this device. Signed-off-by: Tero Kristo --- arch/arm/mach-omap2/board-omap3beagle.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c index 0d2a45f..304fc48 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -486,6 +486,9 @@ static void __init beagle_opp_init(void) opp_disable(mpu_dev, 72000); opp_disable(iva_dev, 52000); } + + /* Set oscillator startup time to 10ms, shutdown not used */ + omap_pm_setup_oscillator(1, ULONG_MAX); } /* Custom OPP enabled for all xM versions */ -- 1.7.4.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
[PATCHv7 15/21] ARM: OMAP4: vc: fix channel configuration
RACEN bit should only be set if the voltage and command register addresses are the same. Signed-off-by: Tero Kristo --- arch/arm/mach-omap2/vc.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c index 2ca00bc..a63c53a 100644 --- a/arch/arm/mach-omap2/vc.c +++ b/arch/arm/mach-omap2/vc.c @@ -695,9 +695,12 @@ void __init omap_vc_init_channel(struct voltagedomain *voltdm) voltdm->rmw(vc->smps_cmdra_mask, vc->cmd_reg_addr << __ffs(vc->smps_cmdra_mask), vc->smps_cmdra_reg); - vc->cfg_channel |= vc_cfg_bits->rac | vc_cfg_bits->racen; + vc->cfg_channel |= vc_cfg_bits->rac; } + if (vc->cmd_reg_addr == vc->volt_reg_addr) + vc->cfg_channel |= vc_cfg_bits->racen; + /* Set up the on, inactive, retention and off voltage */ on_vsel = omap_vc_calc_vsel(voltdm, voltdm->vc_param->on); onlp_vsel = omap_vc_calc_vsel(voltdm, voltdm->vc_param->onlp); -- 1.7.4.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
[PATCHv7 14/21] ARM: OMAP3+: voltage: remove unused volt_setup_time parameter
This is no longer needed as the ramp times are calculated from
voltage deltas + slew rates.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/omap_twl.c |5 -
arch/arm/mach-omap2/voltage.h |1 -
2 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index 188f210..ecae989 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -141,7 +141,6 @@ static u8 twl6030_uv_to_vsel(unsigned long uv)
static struct omap_voltdm_pmic omap3_mpu_pmic = {
.slew_rate = 4000,
.step_size = 12500,
- .volt_setup_time= 0xfff,
.vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP3_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP3_VP_VSTEPMAX_VSTEPMAX,
@@ -158,7 +157,6 @@ static struct omap_voltdm_pmic omap3_mpu_pmic = {
static struct omap_voltdm_pmic omap3_core_pmic = {
.slew_rate = 4000,
.step_size = 12500,
- .volt_setup_time= 0xfff,
.vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP3_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP3_VP_VSTEPMAX_VSTEPMAX,
@@ -175,7 +173,6 @@ static struct omap_voltdm_pmic omap3_core_pmic = {
static struct omap_voltdm_pmic omap4_mpu_pmic = {
.slew_rate = 4000,
.step_size = 12660,
- .volt_setup_time= 0,
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP4_VP_VSTEPMAX_VSTEPMAX,
@@ -193,7 +190,6 @@ static struct omap_voltdm_pmic omap4_mpu_pmic = {
static struct omap_voltdm_pmic omap4_iva_pmic = {
.slew_rate = 4000,
.step_size = 12660,
- .volt_setup_time= 0,
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP4_VP_VSTEPMAX_VSTEPMAX,
@@ -211,7 +207,6 @@ static struct omap_voltdm_pmic omap4_iva_pmic = {
static struct omap_voltdm_pmic omap4_core_pmic = {
.slew_rate = 4000,
.step_size = 12660,
- .volt_setup_time= 0,
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP4_VP_VSTEPMAX_VSTEPMAX,
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 01ab2e5..106a240 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -140,7 +140,6 @@ struct voltagedomain {
struct omap_voltdm_pmic {
int slew_rate;
int step_size;
- u16 volt_setup_time;
u16 i2c_slave_addr;
u16 volt_reg_addr;
u16 cmd_reg_addr;
--
1.7.4.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
[PATCHv7 16/21] ARM: OMAP4: VC: setup I2C parameters based on board data
VC code now provides a table of pre-calculated I2C setup parameters,
which will be used based on the capacitance value calculated for the I2C
trace on the PCB. A default trace length of 6.3cm is used unless board
defines its own value during init. The parameters set will be the I2C
internal pull setup and the I2C timing parameters for high speed use
mode. Full speed mode is not supported as of now.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/omap_twl.c |3 +
arch/arm/mach-omap2/pm.h |2 +
arch/arm/mach-omap2/vc.c | 149 +--
arch/arm/mach-omap2/voltage.h |1 +
4 files changed, 147 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index ecae989..611cb63 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -183,6 +183,7 @@ static struct omap_voltdm_pmic omap4_mpu_pmic = {
.volt_reg_addr = OMAP4_VDD_MPU_SR_VOLT_REG,
.cmd_reg_addr = OMAP4_VDD_MPU_SR_CMD_REG,
.i2c_high_speed = true,
+ .i2c_pad_load = 3,
.vsel_to_uv = twl6030_vsel_to_uv,
.uv_to_vsel = twl6030_uv_to_vsel,
};
@@ -200,6 +201,7 @@ static struct omap_voltdm_pmic omap4_iva_pmic = {
.volt_reg_addr = OMAP4_VDD_IVA_SR_VOLT_REG,
.cmd_reg_addr = OMAP4_VDD_IVA_SR_CMD_REG,
.i2c_high_speed = true,
+ .i2c_pad_load = 3,
.vsel_to_uv = twl6030_vsel_to_uv,
.uv_to_vsel = twl6030_uv_to_vsel,
};
@@ -216,6 +218,7 @@ static struct omap_voltdm_pmic omap4_core_pmic = {
.i2c_slave_addr = OMAP4_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP4_VDD_CORE_SR_VOLT_REG,
.cmd_reg_addr = OMAP4_VDD_CORE_SR_CMD_REG,
+ .i2c_pad_load = 3,
.vsel_to_uv = twl6030_vsel_to_uv,
.uv_to_vsel = twl6030_uv_to_vsel,
};
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 583b40f..d070ac6 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -139,9 +139,11 @@ static inline int omap4_twl_init(void)
#ifdef CONFIG_PM
extern void omap_pm_setup_oscillator(u32 tstart, u32 tshut);
extern void omap_pm_get_oscillator(u32 *tstart, u32 *tshut);
+extern void omap_pm_setup_sr_i2c_pcb_length(u32 mm);
#else
static inline void omap_pm_setup_oscillator(u32 tstart, u32 tshut) { }
static inline void omap_pm_get_oscillator(u32 *tstart, u32 *tshut) { }
+static inline void omap_pm_setup_sr_i2c_pcb_length(u32 mm) { }
#endif
#endif
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index a63c53a..d217bbf 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -26,6 +26,7 @@
#include "prm44xx.h"
#include "pm.h"
#include "scrm44xx.h"
+#include "control.h"
/**
* struct omap_vc_channel_cfg - describe the cfg_channel bitfield
@@ -71,6 +72,9 @@ static struct omap_vc_channel_cfg vc_mutant_channel_cfg = {
};
static struct omap_vc_channel_cfg *vc_cfg_bits;
+
+/* Default I2C trace length on pcb, 6.3cm. Used for capacitance calculations.
*/
+static u32 sr_i2c_pcb_length = 63;
#define CFG_CHANNEL_MASK 0x1f
/**
@@ -567,22 +571,135 @@ static void omap4_set_timings(struct voltagedomain
*voltdm, bool off_mode)
/* OMAP4 specific voltage init functions */
static void __init omap4_vc_init_channel(struct voltagedomain *voltdm)
{
- static bool is_initialized;
- u32 vc_val;
-
omap4_set_timings(voltdm, true);
omap4_set_timings(voltdm, false);
+}
+
+struct i2c_init_data {
+ u8 loadbits;
+ u8 load;
+ u8 hsscll_38_4;
+ u8 hsscll_26;
+ u8 hsscll_19_2;
+ u8 hsscll_16_8;
+ u8 hsscll_12;
+};
+
+static const __initdata struct i2c_init_data omap4_i2c_timing_data[] = {
+ {
+ .load = 50,
+ .loadbits = 0x3,
+ .hsscll_38_4 = 13,
+ .hsscll_26 = 11,
+ .hsscll_19_2 = 9,
+ .hsscll_16_8 = 9,
+ .hsscll_12 = 8,
+ },
+ {
+ .load = 25,
+ .loadbits = 0x2,
+ .hsscll_38_4 = 13,
+ .hsscll_26 = 11,
+ .hsscll_19_2 = 9,
+ .hsscll_16_8 = 9,
+ .hsscll_12 = 8,
+ },
+ {
+ .load = 12,
+ .loadbits = 0x1,
+ .hsscll_38_4 = 11,
+ .hsscll_26 = 10,
+ .hsscll_19_2 = 9,
+ .hsscll_16_8 = 9,
+ .hsscll_12 = 8,
+ },
+ {
+ .load = 0,
+ .loadbits = 0x0,
+ .hsscll_38_4 = 12,
+ .hsscll_26 = 10,
+ .hsscll_19_2 = 9,
+ .hsscll_16_8 = 8,
+ .hsscll_12 = 8,
+ },
+};
+
+/**
+ * omap4_vc_i2c_timing_init - sets up board I2C timing paramet
[PATCHv7 17/21] ARM: OMAP4: TWL: enable high speed mode for PMIC communication
With the new parameters, I2C can now be put to high speed mode for
better performance.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/omap_twl.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index 611cb63..7ff9667 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -218,6 +218,7 @@ static struct omap_voltdm_pmic omap4_core_pmic = {
.i2c_slave_addr = OMAP4_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP4_VDD_CORE_SR_VOLT_REG,
.cmd_reg_addr = OMAP4_VDD_CORE_SR_CMD_REG,
+ .i2c_high_speed = true,
.i2c_pad_load = 3,
.vsel_to_uv = twl6030_vsel_to_uv,
.uv_to_vsel = twl6030_uv_to_vsel,
--
1.7.4.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
[PATCHv7 13/21] ARM: OMAP3: vc: auto_ret / auto_off support
Voltage code will now enable / disable auto_ret / auto_off dynamically
according to the voltagedomain usecounts. This is accomplished via
the usage of the voltdm callback functions for sleep / wakeup.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/vc.c | 139 +++--
1 files changed, 120 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index a587506..2ca00bc 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
@@ -240,12 +241,6 @@ static void omap3_set_i2c_timings(struct voltagedomain
*voltdm, bool off_mode)
unsigned long voltsetup1;
u32 tgt_volt;
- /*
-* Oscillator is shut down only if we are using sys_off_mode pad,
-* thus we set a minimal setup time here
-*/
- omap3_set_clksetup(1, voltdm);
-
if (off_mode)
tgt_volt = voltdm->vc_param->off;
else
@@ -259,12 +254,6 @@ static void omap3_set_i2c_timings(struct voltagedomain
*voltdm, bool off_mode)
voltdm->rmw(voltdm->vfsm->voltsetup_mask,
voltsetup1 << __ffs(voltdm->vfsm->voltsetup_mask),
voltdm->vfsm->voltsetup_reg);
-
- /*
-* pmic is not controlling the voltage scaling during retention,
-* thus set voltsetup2 to 0
-*/
- voltdm->write(0, OMAP3_PRM_VOLTSETUP2_OFFSET);
}
/**
@@ -286,7 +275,6 @@ static void omap3_set_off_timings(struct voltagedomain
*voltdm)
unsigned long voltsetup2;
unsigned long voltsetup2_old;
u32 val;
- u32 tstart, tshut;
/* check if sys_off_mode is used to control off-mode voltages */
val = voltdm->read(OMAP3_PRM_VOLTCTRL_OFFSET);
@@ -296,9 +284,6 @@ static void omap3_set_off_timings(struct voltagedomain
*voltdm)
return;
}
- omap_pm_get_oscillator(&tstart, &tshut);
- omap3_set_clksetup(tstart, voltdm);
-
clksetup = voltdm->read(OMAP3_PRM_CLKSETUP_OFFSET);
/* voltsetup 2 in us */
@@ -328,17 +313,133 @@ static void omap3_set_off_timings(struct voltagedomain
*voltdm)
*/
voltdm->rmw(voltdm->vfsm->voltsetup_mask, 0,
voltdm->vfsm->voltsetup_reg);
+}
+
+/**
+ * omap3_set_core_ret_timings - set retention timings for core domain
+ * @voltdm: pointer for core voltagedomain struct
+ *
+ * This function is called once core domain is ready to enter
+ * retention. This sets the values for the global setup variables like
+ * oscillator setup time, and the ramp times for voltages.
+ */
+static void omap3_set_core_ret_timings(struct voltagedomain *voltdm)
+{
+ /*
+* Oscillator is not shut down in retention, thus set minimal
+* clock setup time
+*/
+ omap3_set_clksetup(1, voltdm);
- /* voltoffset must be clksetup minus voltsetup2 according to TRM */
- voltdm->write(clksetup - voltsetup2, OMAP3_PRM_VOLTOFFSET_OFFSET);
+ /*
+* Reset voltsetup 2 and voltoffset when entering retention
+* as they are only used when pmic is controlling voltages
+*/
+ voltdm->write(0, OMAP3_PRM_VOLTSETUP2_OFFSET);
+ voltdm->write(0, OMAP3_PRM_VOLTOFFSET_OFFSET);
+ omap3_set_i2c_timings(voltdm, false);
}
-static void __init omap3_vc_init_channel(struct voltagedomain *voltdm)
+/**
+ * omap3_set_core_off_timings - set off timings for core domain
+ * @voltdm: pointer for core voltagedomain struct
+ *
+ * This function is called once core domain is ready to enter off-mode.
+ * This sets the values for the global setup variables like oscillator
+ * setup time, and the ramp times for voltages.
+ */
+static void omap3_set_core_off_timings(struct voltagedomain *voltdm)
{
+ u32 tstart, tshut;
+
+ omap_pm_get_oscillator(&tstart, &tshut);
+ omap3_set_clksetup(tstart, voltdm);
omap3_set_off_timings(voltdm);
}
/**
+ * omap3_vc_channel_sleep - idle callback for a voltagedomain
+ * @voltdm: voltage channel that is entering idle
+ *
+ * Prepares voltage channel for entering idle. This gets called from
+ * the voltagedomain code once the usecount for the domain reaches zero.
+ * Function checks the target sleep mode and configures the channel
+ * accordingly.
+ */
+static void omap3_vc_channel_sleep(struct voltagedomain *voltdm)
+{
+ /* Set off timings if entering off */
+ if (voltdm->target_state == PWRDM_POWER_OFF)
+ omap3_set_off_timings(voltdm);
+ else
+ omap3_set_i2c_timings(voltdm, false);
+}
+
+/**
+ * omap3_vc_core_sleep - idle callback for core voltagedomain
+ * @voltdm: pointer to core voltagedomain struct
+ *
+ * Prepares core voltagedomain for idle. This checks the target sleep
+ * mode of the device (highest sleep mode of all powerdomains), and
+ * sets up the device according to this either for retention, sleep
+ * or off-m
[PATCHv7 06/21] ARM: OMAP4: VC: calculate ramp times
OMAP4 VC code now uses voltage deltas + slew rates for calculating
actual ramp times for voltage changes. Both retention / sleep +
off mode voltage ramp times are setup at the same time during
initialization.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/vc.c | 94 ++
1 files changed, 94 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index bba0d7c..26750fe 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -310,12 +310,106 @@ static void __init omap3_vc_init_channel(struct
voltagedomain *voltdm)
omap3_set_off_timings(voltdm);
}
+/**
+ * omap4_calc_volt_ramp - calculates voltage ramping delays on omap4
+ * @voltdm: channel to calculate values for
+ * @voltage_diff: voltage difference in microvolts
+ *
+ * Calculates voltage ramp prescaler + counter values for a voltage
+ * difference on omap4. Returns a field value suitable for writing to
+ * VOLTSETUP register for a channel in following format:
+ * bits[8:9] prescaler ... bits[0:5] counter. See OMAP4 TRM for reference.
+ */
+static u32 omap4_calc_volt_ramp(struct voltagedomain *voltdm, u32 voltage_diff)
+{
+ u32 prescaler;
+ u32 cycles;
+ u32 time;
+
+ time = voltage_diff / voltdm->pmic->slew_rate;
+
+ cycles = voltdm->sys_clk.rate / 1000 * time / 1000;
+
+ cycles /= 64;
+ prescaler = 0;
+
+ /* shift to next prescaler until no overflow */
+
+ /* scale for div 256 = 64 * 4 */
+ if (cycles > 63) {
+ cycles /= 4;
+ prescaler++;
+ }
+
+ /* scale for div 512 = 256 * 2 */
+ if (cycles > 63) {
+ cycles /= 2;
+ prescaler++;
+ }
+
+ /* scale for div 2048 = 512 * 4 */
+ if (cycles > 63) {
+ cycles /= 4;
+ prescaler++;
+ }
+
+ /* check for overflow => invalid ramp time */
+ if (cycles > 63) {
+ pr_warn("%s: invalid setuptime for vdd_%s\n", __func__,
+ voltdm->name);
+ return 0;
+ }
+
+ cycles++;
+
+ return (prescaler << OMAP4430_RAMP_UP_PRESCAL_SHIFT) |
+ (cycles << OMAP4430_RAMP_UP_COUNT_SHIFT);
+}
+
+/**
+ * omap4_set_timings - set voltage ramp timings for a channel
+ * @voltdm: channel to configure
+ * @off_mode: whether off-mode values are used
+ *
+ * Calculates and sets the voltage ramp up / down values for a channel.
+ */
+static void omap4_set_timings(struct voltagedomain *voltdm, bool off_mode)
+{
+ u32 val;
+ u32 ramp;
+ int offset;
+
+ if (off_mode) {
+ ramp = omap4_calc_volt_ramp(voltdm,
+ voltdm->vc_param->on - voltdm->vc_param->off);
+ offset = voltdm->vfsm->voltsetup_off_reg;
+ } else {
+ ramp = omap4_calc_volt_ramp(voltdm,
+ voltdm->vc_param->on - voltdm->vc_param->ret);
+ offset = voltdm->vfsm->voltsetup_reg;
+ }
+
+ if (!ramp)
+ return;
+
+ val = voltdm->read(offset);
+
+ val |= ramp << OMAP4430_RAMP_DOWN_COUNT_SHIFT;
+
+ val |= ramp << OMAP4430_RAMP_UP_COUNT_SHIFT;
+
+ voltdm->write(val, offset);
+}
+
/* OMAP4 specific voltage init functions */
static void __init omap4_vc_init_channel(struct voltagedomain *voltdm)
{
static bool is_initialized;
u32 vc_val;
+ omap4_set_timings(voltdm, true);
+ omap4_set_timings(voltdm, false);
+
if (is_initialized)
return;
--
1.7.4.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
[PATCHv7 19/21] ARM: OMAP3+: PM: introduce a central pmic control
From: Nishanth Menon
Since we are starting to use multiple PMICs in various combinations,
use the existing .omap_chip = OMAP_CHIP_INIT() to mark the
structures we are interested in using per OMAP device we
are currently running on. This mapping is based on the default
device recommendations from TI. Boards using custom PMICs now
have an opportunity to register their own custom mapping.
With this we no longer need omap4_twl_init and omap3_twl_int
instead we introduce a registration mechanism which is PMIC
generic and move twl implementation to use the same. This allows
for future OMAP4460 support where there is a mixture of
PMIC combinations used.
Signed-off-by: Nishanth Menon
[t-kri...@ti.com: moved code under twl-common, other minor cleanups]
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/omap_twl.c | 81 ++
arch/arm/mach-omap2/pm.h |9 +---
arch/arm/mach-omap2/twl-common.c | 58 +--
arch/arm/mach-omap2/twl-common.h | 27 +
4 files changed, 129 insertions(+), 46 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index 7ff9667..f6ee038 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -19,8 +19,8 @@
#include
#include "voltage.h"
-
#include "pm.h"
+#include "twl-common.h"
#define OMAP3_SRI2C_SLAVE_ADDR 0x12
#define OMAP3_VDD_MPU_SR_CONTROL_REG 0x00
@@ -170,7 +170,7 @@ static struct omap_voltdm_pmic omap3_core_pmic = {
.uv_to_vsel = twl4030_uv_to_vsel,
};
-static struct omap_voltdm_pmic omap4_mpu_pmic = {
+static struct omap_voltdm_pmic twl6030_vcore1_pmic = {
.slew_rate = 4000,
.step_size = 12660,
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
@@ -188,7 +188,7 @@ static struct omap_voltdm_pmic omap4_mpu_pmic = {
.uv_to_vsel = twl6030_uv_to_vsel,
};
-static struct omap_voltdm_pmic omap4_iva_pmic = {
+static struct omap_voltdm_pmic twl6030_vcore2_pmic = {
.slew_rate = 4000,
.step_size = 12660,
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
@@ -206,7 +206,7 @@ static struct omap_voltdm_pmic omap4_iva_pmic = {
.uv_to_vsel = twl6030_uv_to_vsel,
};
-static struct omap_voltdm_pmic omap4_core_pmic = {
+static struct omap_voltdm_pmic twl6030_vcore3_pmic = {
.slew_rate = 4000,
.step_size = 12660,
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
@@ -224,31 +224,9 @@ static struct omap_voltdm_pmic omap4_core_pmic = {
.uv_to_vsel = twl6030_uv_to_vsel,
};
-int __init omap4_twl_init(void)
+static int __init twl_set_sr(struct voltagedomain *voltdm)
{
- struct voltagedomain *voltdm;
-
- if (!cpu_is_omap44xx())
- return -ENODEV;
-
- voltdm = voltdm_lookup("mpu");
- omap_voltage_register_pmic(voltdm, &omap4_mpu_pmic);
-
- voltdm = voltdm_lookup("iva");
- omap_voltage_register_pmic(voltdm, &omap4_iva_pmic);
-
- voltdm = voltdm_lookup("core");
- omap_voltage_register_pmic(voltdm, &omap4_core_pmic);
-
- return 0;
-}
-
-int __init omap3_twl_init(void)
-{
- struct voltagedomain *voltdm;
-
- if (!cpu_is_omap34xx())
- return -ENODEV;
+ int r = 0;
/*
* The smartreflex bit on twl4030 specifies if the setting of voltage
@@ -260,15 +238,50 @@ int __init omap3_twl_init(void)
* voltage scaling will not function on TWL over I2C_SR.
*/
if (!twl_sr_enable_autoinit)
- omap3_twl_set_sr_bit(true);
+ r = omap3_twl_set_sr_bit(true);
- voltdm = voltdm_lookup("mpu_iva");
- omap_voltage_register_pmic(voltdm, &omap3_mpu_pmic);
+ return r;
+}
- voltdm = voltdm_lookup("core");
- omap_voltage_register_pmic(voltdm, &omap3_core_pmic);
+static __initdata struct omap_pmic_map omap_twl_map[] = {
+ {
+ .name = "mpu_iva",
+ .cpu = PMIC_CPU_OMAP3,
+ .pmic_data = &omap3_mpu_pmic,
+ .special_action = twl_set_sr,
+ },
+ {
+ .name = "core",
+ .cpu = PMIC_CPU_OMAP3,
+ .pmic_data = &omap3_core_pmic,
+ },
+ {
+ .name = "mpu",
+ .cpu = PMIC_CPU_OMAP4430,
+ .pmic_data = &twl6030_vcore1_pmic,
+ },
+ {
+ .name = "core",
+ .cpu = PMIC_CPU_OMAP4430,
+ .pmic_data = &twl6030_vcore3_pmic,
+ },
+ {
+ .name = "core",
+ .cpu = PMIC_CPU_OMAP4460,
+ .pmic_data = &twl6030_vcore1_pmic,
+ },
+ {
+ .name = "iva",
+ .cpu = PMIC_CPU_OMAP44XX,
+ .pmic_data = &twl6030_vcore2_pmic,
+ },
+ /* Termi
[PATCHv7 18/21] ARM: OMAP4: OPP: add OMAP4460 definitions
From: Vishwanath Sripathy
Add OMAP4460 OPP definitions for voltage and frequencies based on
OMAP4460 ES1.0 DM Operating Condition Addendum Version 0.1
The following exceptions are present:
* Smartreflex support is still on experimental mode: the gains and min
limits are currently pending characterization data. Currently OMAP4430 values
are used.
* Efuse offset for core OPP100-OV setting is not clear in documentation.
* IVA OPPs beyond OPP100 are disabled due to the delta between max OMAP4460
current requirements and Phoenix Max supply on VCORE2 in the default
configuration - boards which have supply which can support this should
explicitly call opp_enable and enable the same.
* MPU OPPs > OPPTURBO can easily be detected using a efuse burnt - currently
disabled pending clock changes to support DCC feature.
[n...@ti.com: cleanups and updates from Datamanual]
Signed-off-by: Nishanth Menon
Signed-off-by: Vishwanath BS
[t-kri...@ti.com: rebased to linux-3.6-rc5]
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/control.h |1 +
arch/arm/mach-omap2/omap_opp_data.h |9 ++-
arch/arm/mach-omap2/opp4xxx_data.c| 98 ++---
arch/arm/mach-omap2/voltagedomains44xx_data.c | 12 ++-
4 files changed, 103 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index b8cdc85..6f97eae 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -201,6 +201,7 @@
#define OMAP44XX_CONTROL_FUSE_MPU_OPPNITRO 0x249
#define OMAP44XX_CONTROL_FUSE_CORE_OPP50 0x254
#define OMAP44XX_CONTROL_FUSE_CORE_OPP100 0x257
+#define OMAP44XX_CONTROL_FUSE_CORE_OPP100OV0x25A
/* AM35XX only CONTROL_GENERAL register offsets */
#define AM35XX_CONTROL_MSUSPENDMUX_6(OMAP2_CONTROL_GENERAL + 0x0038)
diff --git a/arch/arm/mach-omap2/omap_opp_data.h
b/arch/arm/mach-omap2/omap_opp_data.h
index c784c12..18a750e 100644
--- a/arch/arm/mach-omap2/omap_opp_data.h
+++ b/arch/arm/mach-omap2/omap_opp_data.h
@@ -89,8 +89,11 @@ extern struct omap_volt_data omap34xx_vddcore_volt_data[];
extern struct omap_volt_data omap36xx_vddmpu_volt_data[];
extern struct omap_volt_data omap36xx_vddcore_volt_data[];
-extern struct omap_volt_data omap44xx_vdd_mpu_volt_data[];
-extern struct omap_volt_data omap44xx_vdd_iva_volt_data[];
-extern struct omap_volt_data omap44xx_vdd_core_volt_data[];
+extern struct omap_volt_data omap443x_vdd_mpu_volt_data[];
+extern struct omap_volt_data omap443x_vdd_iva_volt_data[];
+extern struct omap_volt_data omap443x_vdd_core_volt_data[];
+extern struct omap_volt_data omap446x_vdd_mpu_volt_data[];
+extern struct omap_volt_data omap446x_vdd_iva_volt_data[];
+extern struct omap_volt_data omap446x_vdd_core_volt_data[];
#endif /* __ARCH_ARM_MACH_OMAP2_OMAP_OPP_DATA_H */
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c
b/arch/arm/mach-omap2/opp4xxx_data.c
index c95415d..4054849 100644
--- a/arch/arm/mach-omap2/opp4xxx_data.c
+++ b/arch/arm/mach-omap2/opp4xxx_data.c
@@ -1,7 +1,7 @@
/*
* OMAP4 OPP table definitions.
*
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2010-2012 Texas Instruments Incorporated - http://www.ti.com/
* Nishanth Menon
* Kevin Hilman
* Thara Gopinath
@@ -36,7 +36,7 @@
#define OMAP4430_VDD_MPU_OPPTURBO_UV 1313000
#define OMAP4430_VDD_MPU_OPPNITRO_UV 1375000
-struct omap_volt_data omap44xx_vdd_mpu_volt_data[] = {
+struct omap_volt_data omap443x_vdd_mpu_volt_data[] = {
VOLT_DATA_DEFINE(OMAP4430_VDD_MPU_OPP50_UV,
OMAP44XX_CONTROL_FUSE_MPU_OPP50, 0xf4, 0x0c),
VOLT_DATA_DEFINE(OMAP4430_VDD_MPU_OPP100_UV,
OMAP44XX_CONTROL_FUSE_MPU_OPP100, 0xf9, 0x16),
VOLT_DATA_DEFINE(OMAP4430_VDD_MPU_OPPTURBO_UV,
OMAP44XX_CONTROL_FUSE_MPU_OPPTURBO, 0xfa, 0x23),
@@ -48,7 +48,7 @@ struct omap_volt_data omap44xx_vdd_mpu_volt_data[] = {
#define OMAP4430_VDD_IVA_OPP100_UV 1188000
#define OMAP4430_VDD_IVA_OPPTURBO_UV 130
-struct omap_volt_data omap44xx_vdd_iva_volt_data[] = {
+struct omap_volt_data omap443x_vdd_iva_volt_data[] = {
VOLT_DATA_DEFINE(OMAP4430_VDD_IVA_OPP50_UV,
OMAP44XX_CONTROL_FUSE_IVA_OPP50, 0xf4, 0x0c),
VOLT_DATA_DEFINE(OMAP4430_VDD_IVA_OPP100_UV,
OMAP44XX_CONTROL_FUSE_IVA_OPP100, 0xf9, 0x16),
VOLT_DATA_DEFINE(OMAP4430_VDD_IVA_OPPTURBO_UV,
OMAP44XX_CONTROL_FUSE_IVA_OPPTURBO, 0xfa, 0x23),
@@ -58,14 +58,14 @@ struct omap_volt_data omap44xx_vdd_iva_volt_data[] = {
#define OMAP4430_VDD_CORE_OPP50_UV 1025000
#define OMAP4430_VDD_CORE_OPP100_UV120
-struct omap_volt_data omap44xx_vdd_core_volt_data[] = {
+struct omap_volt_data omap443x_vdd_core_volt_data[] = {
VOLT_DATA_DEFINE(OMAP4430_VDD_CORE_OPP50_UV,
OMAP44XX_CONTROL_FUSE_CORE_OPP50, 0xf4, 0x0c),
VOLT_DATA_DEFINE(OMAP4430_VDD_CORE_OPP100_UV,
OMAP44XX_CONTROL_FUSE_CORE_OPP100,
[PATCHv7 21/21] ARM: OMAP4: vc: auto retention support
This patch adds callbacks for the voltdm sleep / wakeups, which are now
used for enabling / disabling auto retention voltage control. Once a
voltage domain is ready to idle, its auto retention mode is enabled.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/prm-regbits-44xx.h |5 +++
arch/arm/mach-omap2/vc.c | 52
arch/arm/mach-omap2/vc.h |4 ++
arch/arm/mach-omap2/vc44xx_data.c |6
4 files changed, 67 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/prm-regbits-44xx.h
b/arch/arm/mach-omap2/prm-regbits-44xx.h
index 3cb247b..15b9599 100644
--- a/arch/arm/mach-omap2/prm-regbits-44xx.h
+++ b/arch/arm/mach-omap2/prm-regbits-44xx.h
@@ -81,6 +81,11 @@
#define OMAP4430_AIPOFF_MASK (1 << 8)
/* Used by PRM_VOLTCTRL */
+#define OMAP4430_AUTO_CTRL_VDD_DISABLED0
+#define OMAP4430_AUTO_CTRL_VDD_SLEEP 1
+#define OMAP4430_AUTO_CTRL_VDD_RET 2
+
+/* Used by PRM_VOLTCTRL */
#define OMAP4430_AUTO_CTRL_VDD_CORE_L_SHIFT0
#define OMAP4430_AUTO_CTRL_VDD_CORE_L_MASK (0x3 <<
0)
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index d217bbf..c607a0c 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -568,11 +568,63 @@ static void omap4_set_timings(struct voltagedomain
*voltdm, bool off_mode)
__raw_writel(val, OMAP4_SCRM_CLKSETUPTIME);
}
+/**
+ * omap4_vc_sleep - voltagedomain sleep entry callback
+ * @voltdm: domain which is entering idle
+ *
+ * This function is called once a voltagedomain is ready to enter idle.
+ * Sets up AUTO_RET / AUTO_SLEEP command to be sent through the I2C
+ * to the PMIC.
+ */
+static void omap4_vc_sleep(struct voltagedomain *voltdm)
+{
+ u32 val;
+ u32 voltctrl;
+
+ switch (voltdm->target_state) {
+ case PWRDM_POWER_OFF:
+ case PWRDM_POWER_RET:
+ val = OMAP4430_AUTO_CTRL_VDD_RET;
+ break;
+ default:
+ val = OMAP4430_AUTO_CTRL_VDD_SLEEP;
+ break;
+ }
+ voltctrl = voltdm->read(OMAP4_PRM_VOLTCTRL_OFFSET);
+
+ voltctrl &= ~(u32)voltdm->vc->voltctrl_mask;
+
+ voltctrl |= val << voltdm->vc->voltctrl_shift;
+
+ voltdm->write(voltctrl, OMAP4_PRM_VOLTCTRL_OFFSET);
+}
+
+/**
+ * omap4_vc_wakeup - voltagedomain wakeup callback
+ * @voltdm: domain which is leaving idle
+ *
+ * This function is called once a voltagedomain is becoming active.
+ * Disables AUTO_RET / AUTO_SLEEP for the domain.
+ */
+static void omap4_vc_wakeup(struct voltagedomain *voltdm)
+{
+ u32 voltctrl;
+
+ voltctrl = voltdm->read(OMAP4_PRM_VOLTCTRL_OFFSET);
+
+ voltctrl &= ~(u32)voltdm->vc->voltctrl_mask;
+
+ voltdm->write(voltctrl, OMAP4_PRM_VOLTCTRL_OFFSET);
+}
+
/* OMAP4 specific voltage init functions */
static void __init omap4_vc_init_channel(struct voltagedomain *voltdm)
{
omap4_set_timings(voltdm, true);
omap4_set_timings(voltdm, false);
+
+ voltdm->sleep = omap4_vc_sleep;
+ voltdm->wakeup = omap4_vc_wakeup;
}
struct i2c_init_data {
diff --git a/arch/arm/mach-omap2/vc.h b/arch/arm/mach-omap2/vc.h
index 91c8d75..8357d57 100644
--- a/arch/arm/mach-omap2/vc.h
+++ b/arch/arm/mach-omap2/vc.h
@@ -79,6 +79,8 @@ struct omap_vc_common {
* @smps_cmdra_reg: Offset of PRM_VC_SMPS_CMD_RA reg from PRM start
* @cfg_channel_reg: VC channel configuration register
* @cfg_channel_sa_shift: bit shift for slave address cfg_channel register
+ * @voltctrl_shift: bit shift for voltctrl register field
+ * @voltctrl_mask: bit mask for voltctrl register field
* @flags: VC channel-specific flags (optional)
*/
struct omap_vc_channel {
@@ -100,6 +102,8 @@ struct omap_vc_channel {
u8 smps_cmdra_reg;
u8 cfg_channel_reg;
u8 cfg_channel_sa_shift;
+ u8 voltctrl_shift;
+ u8 voltctrl_mask;
u8 flags;
};
diff --git a/arch/arm/mach-omap2/vc44xx_data.c
b/arch/arm/mach-omap2/vc44xx_data.c
index 085e5d6..a003a1f 100644
--- a/arch/arm/mach-omap2/vc44xx_data.c
+++ b/arch/arm/mach-omap2/vc44xx_data.c
@@ -59,6 +59,8 @@ struct omap_vc_channel omap4_vc_mpu = {
.smps_volra_mask = OMAP4430_VOLRA_VDD_MPU_L_MASK,
.smps_cmdra_mask = OMAP4430_CMDRA_VDD_MPU_L_MASK,
.cfg_channel_sa_shift = OMAP4430_SA_VDD_MPU_L_SHIFT,
+ .voltctrl_shift = OMAP4430_AUTO_CTRL_VDD_MPU_L_SHIFT,
+ .voltctrl_mask = OMAP4430_AUTO_CTRL_VDD_MPU_L_MASK,
};
struct omap_vc_channel omap4_vc_iva = {
@@ -72,6 +74,8 @@ struct omap_vc_channel omap4_vc_iva = {
.smps_volra_mask = OMAP4430_VOLRA_VDD_IVA_L_MASK,
.smps_cmdra_mask = OMAP4430_CMDRA_VDD_IVA_L_MASK,
.cfg_channel_sa_shift = OMAP4430_SA_VDD_IVA_L_SHIFT,
+ .voltctrl_shift = OMAP4430_AUTO_CTRL_VDD_IVA_L_S
[PATCHv7 20/21] ARM: OMAP2+ PM: Add support for TPS62361
From: Vishwanath BS
TPS62361 is a new PMIC used with OMAP4460 on SDP4430 platform
and panda board ES to supply MPU VDD.
Rest of the VDDs continue to be supplied via TWL6030.
As part of this, the following have been moved to common
location in voltage.h
OMAP4_VP_CONFIG_ERROROFFSET, OMAP4_VP_VSTEPMIN_VSTEPMIN,
OMAP4_VP_VSTEPMAX_VSTEPMAX, OMAP4_VP_VLIMITTO_TIMEOUT_US
[n...@ti.com: cleaned up TPS to handle board variations]
Signed-off-by: Nishanth Menon
Signed-off-by: Vishwanath BS
[t-kri...@ti.com: minor cleanup, added panda board support, dropped
some unused code from the patch]
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/Kconfig|9 ++
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-4430sdp.c| 10 ++
arch/arm/mach-omap2/board-omap4panda.c |8 ++
arch/arm/mach-omap2/omap_tps6236x.c| 214
arch/arm/mach-omap2/omap_twl.c |5 -
arch/arm/mach-omap2/twl-common.c |1 +
arch/arm/mach-omap2/twl-common.h | 16 +++
arch/arm/mach-omap2/voltage.h |5 +
9 files changed, 264 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap_tps6236x.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index fcd4e85..be65336 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -352,6 +352,7 @@ config MACH_OMAP_4430SDP
select OMAP_PACKAGE_CBL
select OMAP_PACKAGE_CBS
select REGULATOR_FIXED_VOLTAGE if REGULATOR
+ select OMAP_TPS6236X
config MACH_OMAP4_PANDA
bool "OMAP4 Panda Board"
@@ -360,6 +361,7 @@ config MACH_OMAP4_PANDA
select OMAP_PACKAGE_CBL
select OMAP_PACKAGE_CBS
select REGULATOR_FIXED_VOLTAGE if REGULATOR
+ select OMAP_TPS6236X
config OMAP3_EMU
bool "OMAP3 debugging peripherals"
@@ -402,6 +404,13 @@ config OMAP4_ERRATA_I688
In MPU case, L3 T2ASYNC FIFO and DDR T2ASYNC FIFO needs to be drained.
IO barrier ensure that there is no synchronisation loss on initiators
operating on both interconnect port simultaneously.
+
+config OMAP_TPS6236X
+ bool "OMAP4 support for TPS6236X power IC"
+ help
+ TPS62361 is a PMIC used with OMAP4460 to supply MPU VDD voltage.
+ Rest of the VDDs continue to be supplied via TWL6030.
+
endmenu
endif
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index f6a24b3..0e183a1 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -24,6 +24,7 @@ obj-y += mcbsp.o
endif
obj-$(CONFIG_TWL4030_CORE) += omap_twl.o
+obj-$(CONFIG_OMAP_TPS6236X)+= omap_tps6236x.o
obj-$(CONFIG_SOC_HAS_OMAP2_SDRC) += sdrc.o
# SMP support ONLY available for OMAP4
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index ad8a7d9..bebef07 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -64,6 +64,8 @@
#define GPIO_WIFI_PMENA54
#define GPIO_WIFI_IRQ 53
+#define TPS62361_GPIO 7
+
static const int sdp4430_keymap[] = {
KEY(0, 0, KEY_E),
KEY(0, 1, KEY_R),
@@ -904,6 +906,14 @@ static void __init omap_4430sdp_init(void)
pr_err("Keypad initialization failed: %d\n", status);
omap_4430sdp_display_init();
+
+ if (cpu_is_omap446x()) {
+ /* Vsel0 = gpio, vsel1 = gnd */
+ status = omap_tps6236x_board_setup(true, TPS62361_GPIO, -1,
+ -1, 0);
+ if (status)
+ pr_err("TPS62361 initialization failed: %d\n", status);
+ }
}
MACHINE_START(OMAP_4430SDP, "OMAP4430 4430SDP board")
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 70f6d1d..57431e0 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -57,6 +57,7 @@
#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
#define HDMI_GPIO_HPD 63 /* Hotplug detect */
+#define TPS62361_GPIO 7 /* Vsel0 control for TPS62361 */
/* wl127x BT, FM, GPS connectivity chip */
static struct ti_st_plat_data wilink_platform_data = {
@@ -513,6 +514,13 @@ static void __init omap4_panda_init(void)
omap4_ehci_init();
usb_musb_init(&musb_board_data);
omap4_panda_display_init();
+ if (cpu_is_omap446x()) {
+ /* vsel0 = gpio, vsel1 = gnd */
+ ret = omap_tps6236x_board_setup(true, TPS62361_GPIO, -1,
+ -1, 0);
+ if (ret)
+ pr_err("TPS62361 initialization failed: %d\n", ret);
+ }
}
MACHINE_START(OMAP4_PANDA, "OMAP4 Panda board")
diff --git a/arch/arm/mach-omap2/omap_tps6236x.c
b/arch/arm/mach-omap2/omap_tps6236x.c
new file mode
Re: Powering OMAP's pins
On Tue, 2012-09-25 at 08:38 -0700, Tony Lindgren wrote: > * Tomi Valkeinen [120925 03:22]: > > Hi Tony, > > > > Each pin of OMAP requires a particular power to be enabled for the pin > > to function (Ball Characteristics table from data manual). Is there a > > plan how this is managed with pinctrl? Currently each driver needs to > > make sure the correct regulators are enabled for the pins it uses, which > > is platform specific and messy. > > > > As a driver maintainer, I would wish that the pins would just get > > enabled automatically when I call pm_runtime_get()... > > Hmm can you clarify a bit what exactly do you want to do there > with pm_runtime_get()? Call the regulator framework? Well, I'm not very familiar with pinctrl, but if I've understood right, a set of pins are assigned to a driver in DT data (or wherever, that's not relevant). Those pins should be automatically configured and enabled when the driver uses pm_runtime_get() to enable its hardware. And if I've also understood right, the pinctrl discussions related to omap have only dealt with pin muxing itself. But that's not enough to get the pin functional, but the relevant regulator needs to be enabled also. So when I call pm_runtime_get in the omapdss driver, I imagine that the runtime PM and pinctrl would together handle muxing the pins for omapdss's use, and also enable the relevant regulators to make the pins usable. Tomi signature.asc Description: This is a digitally signed message part
Re: tidspbridge build fails
Hi ! Here what's happening when applying the patch : sli@SLI-V420:~/developpement/INTERNE/BEAGLEBOARD/logiciel/linux-omap$ git apply --check ../../archive/10-17-staging-tidspbridge-Prepare-for-irqs.h-removal.patch error: patch failed: drivers/staging/tidspbridge/core/wdt.c:25 error: drivers/staging/tidspbridge/core/wdt.c: patch does not apply newbie question : Where is the staging-next rep ? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
On Wed, Sep 05, 2012 at 05:06:04PM +0530, Sourav Poddar wrote:
> +static struct regmap_config smsc_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = SMSC_MAX_REGISTER - 1;
> + .cache_type = REGCACHE_COMPRESSED,
> +};
That definition of max_register looks wrong - why are we subtracting 1
from a macro called MAX_REGISTER to get it?
Indentation here is a bit odd too.
> +static int smsc_i2c_remove(struct i2c_client *i2c)
> +{
> + return 0;
> +}
Remove empty functions.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
Hi,
On Tue, Sep 25, 2012 at 11:22 PM, Mark Brown
wrote:
> On Wed, Sep 05, 2012 at 05:06:04PM +0530, Sourav Poddar wrote:
>
>> +static struct regmap_config smsc_regmap_config = {
>> + .reg_bits = 8,
>> + .val_bits = 8,
>> + .max_register = SMSC_MAX_REGISTER - 1;
>> + .cache_type = REGCACHE_COMPRESSED,
>> +};
>
> That definition of max_register looks wrong - why are we subtracting 1
> from a macro called MAX_REGISTER to get it?
>
Yes, my bad.
Actually, I have define in .h file something like this..
#define SMSC_MAX_REG(SMSC_VEN_ID_H
+ 1) where
SMSC_VEN_ID_H is the last register address which this chip supports.
I think I should directly assign max_address to SMSC_VEN_ID_H. ?
+
+
> Indentation here is a bit odd too.
>
Will rectify.
>> +static int smsc_i2c_remove(struct i2c_client *i2c)
>> +{
>> + return 0;
>> +}
>
> Remove empty functions.
Ok.
--
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] of: dma: fix potential deadlock when requesting a slave channel
In the latest version of the OF dma handlers I added support (rather hastily)
to exhaustively search for an available dma slave channel, for the use-case
where we have alternative slave channels that can be used. In the current
implementation a deadlock scenario can occur causing the CPU to loop forever.
The scenario is as follows ...
1. There are alternative channels avaialble
2. The first channel that is found by calling of_dma_find_channel() is not
available and so the call to the xlate function returns NULL. In this case
we will call of_dma_find_channel() again but we will return the same channel
that we found the first time and hence, again the xlate will return NULL and
we will loop here forever.
Fix this potential deadlock by just using a single for-loop and not a for-loop
nested in a do-while loop. This change also replaces the function
of_dma_find_channel() with of_dma_match_channel() which performs a simple check
to see if a DMA channel matches the name specified.
I have tested this implementation on an OMAP4 panda board by adding a dummy
DMA specifier, that will cause the xlate function to return NULL, to the
beginning of a list of DMA specifiers for a DMA client.
Cc: Nicolas Ferre
Cc: Benoit Cousson
Cc: Stephen Warren
Cc: Grant Likely
Cc: Russell King
Cc: Rob Herring
Cc: Arnd Bergmann
Cc: Vinod Koul
Cc: Dan Williams
Signed-off-by: Jon Hunter
---
drivers/of/dma.c | 60 +++---
1 file changed, 30 insertions(+), 30 deletions(-)
diff --git a/drivers/of/dma.c b/drivers/of/dma.c
index 19ad37c..4bed490 100644
--- a/drivers/of/dma.c
+++ b/drivers/of/dma.c
@@ -108,37 +108,32 @@ void of_dma_controller_free(struct device_node *np)
EXPORT_SYMBOL_GPL(of_dma_controller_free);
/**
- * of_dma_find_channel - Find a DMA channel by name
+ * of_dma_match_channel - Check if a DMA specifier matches name
* @np:device node to look for DMA channels
- * @name: name of desired channel
+ * @name: channel name to be matched
+ * @index: index of DMA specifier in list of DMA specifiers
* @dma_spec: pointer to DMA specifier as found in the device tree
*
- * Find a DMA channel by the name. Returns 0 on success or appropriate
- * errno value on error.
+ * Check if the DMA specifier pointed to by the index in a list of DMA
+ * specifiers, matches the name provided. Returns 0 if the name matches and
+ * a valid pointer to the DMA specifier is found. Otherwise returns -ENODEV.
*/
-static int of_dma_find_channel(struct device_node *np, char *name,
- struct of_phandle_args *dma_spec)
+static int of_dma_match_channel(struct device_node *np, char *name, int index,
+ struct of_phandle_args *dma_spec)
{
- int count, i;
const char *s;
- count = of_property_count_strings(np, "dma-names");
- if (count < 0)
- return count;
+ if (of_property_read_string_index(np, "dma-names", index, &s))
+ return -ENODEV;
- for (i = 0; i < count; i++) {
- if (of_property_read_string_index(np, "dma-names", i, &s))
- continue;
+ if (strcmp(name, s))
+ return -ENODEV;
- if (strcmp(name, s))
- continue;
+ if (of_parse_phandle_with_args(np, "dmas", "#dma-cells", index,
+ dma_spec))
+ return -ENODEV;
- if (!of_parse_phandle_with_args(np, "dmas", "#dma-cells", i,
- dma_spec))
- return 0;
- }
-
- return -ENODEV;
+ return 0;
}
/**
@@ -154,19 +149,22 @@ struct dma_chan *of_dma_request_slave_channel(struct
device_node *np,
struct of_phandle_args dma_spec;
struct of_dma *ofdma;
struct dma_chan *chan;
- int r;
+ int count, i;
if (!np || !name) {
pr_err("%s: not enough information provided\n", __func__);
return NULL;
}
- do {
- r = of_dma_find_channel(np, name, &dma_spec);
- if (r) {
- pr_err("%s: can't find DMA channel\n", np->full_name);
- return NULL;
- }
+ count = of_property_count_strings(np, "dma-names");
+ if (count < 0) {
+ pr_err("%s: dma-names property missing or empty\n", __func__);
+ return NULL;
+ }
+
+ for (i = 0; i < count; i++) {
+ if (of_dma_match_channel(np, name, i, &dma_spec))
+ continue;
ofdma = of_dma_find_controller(dma_spec.np);
if (!ofdma) {
@@ -185,9 +183,11 @@ struct dma_chan *of_dma_request_slave_channel(struct
device_node *np,
of_node_put(dma_spec.np);
- } while (
Re: Powering OMAP's pins
* Tomi Valkeinen [120925 10:06]: > On Tue, 2012-09-25 at 08:38 -0700, Tony Lindgren wrote: > > * Tomi Valkeinen [120925 03:22]: > > > Hi Tony, > > > > > > Each pin of OMAP requires a particular power to be enabled for the pin > > > to function (Ball Characteristics table from data manual). Is there a > > > plan how this is managed with pinctrl? Currently each driver needs to > > > make sure the correct regulators are enabled for the pins it uses, which > > > is platform specific and messy. > > > > > > As a driver maintainer, I would wish that the pins would just get > > > enabled automatically when I call pm_runtime_get()... > > > > Hmm can you clarify a bit what exactly do you want to do there > > with pm_runtime_get()? Call the regulator framework? > > Well, I'm not very familiar with pinctrl, but if I've understood right, > a set of pins are assigned to a driver in DT data (or wherever, that's > not relevant). Those pins should be automatically configured and enabled > when the driver uses pm_runtime_get() to enable its hardware. > > And if I've also understood right, the pinctrl discussions related to > omap have only dealt with pin muxing itself. But that's not enough to > get the pin functional, but the relevant regulator needs to be enabled > also. > > So when I call pm_runtime_get in the omapdss driver, I imagine that the > runtime PM and pinctrl would together handle muxing the pins for > omapdss's use, and also enable the relevant regulators to make the pins > usable. But aren't these regulators something that potentially are dynamically configured by the driver? For example, vdds_(sd)mmc1 depends on which card is plugged in. So to me it seesm that it's best to define the regulators and claim them by the driver using them rather than try to use automatically. It's sort of the same situation as with GPIO pins? 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: CPU_IDLE causes random reboots on custom 4430
On 09/23/2012 06:11 PM, Shilimkar, Santosh wrote: On Sat, Sep 22, 2012 at 10:41 PM, Chris Hoffmann wrote: On 09/22/2012 07:45 AM, Shilimkar, Santosh wrote: On Sat, Sep 22, 2012 at 4:19 AM, Chris Hoffmann wrote: Hi, We're trying to get a custom 4430 board (aka. nook tablet with OMAP4430 ES2.3 HS TWL6030 ES2.1) working with p-android-omap-3.0 on android jelly bean. The board works quite well, but we experience random hangs and the watchdog kicks the board to reboot. On the same kernel, you should have support for the persistent log. You might want to check the output. That should give you pointers on what CPU was doing before the freeze which resulted in reboot. Hi, I have some problems to provide logs. If I add -DDEBUG to cpuidle44xx.o the problem doesn't seem to occur. It could be that printk-ing alleviates the issue. Also the watchdog seems to shutdown the device rather than rebooting it (or it hangs?) and then I can't provide /proc/last_kmsg. How could I provide more info? Check if you have "/sys/kernel/debug/persistent_trace" available on your kernel. This generally helps whenever there are hangs, the last call stack is stored on memory and on the reboot it can be cat'ed to see if some useful information about hang is available. Hi Santosh, all, the p-android-omap-3.0 doesn't have the persistent_trace but I was able to backport it from 3.4 without major issues (only tricky part is that in p-android-3.4 there's no apparent user of that device in omapzoom kernel). The problem is now that the omap-watchdog doesn't kick the device to reboot but rather to shutdown, so I still have no trace. Soft-rebooting shows that I can get persistent_trace. Switching the persistent tracer to ecc=true does not help as it seems to overload the device completely when activating the tracing. Rgds, Chris -- 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: tidspbridge build fails
Hi, On Tue, Sep 25, 2012 at 12:39 PM, Selso LIBERADO wrote: > Hi ! > > Here what's happening when applying the patch : > > sli@SLI-V420:~/developpement/INTERNE/BEAGLEBOARD/logiciel/linux-omap$ git > apply > --check > ../../archive/10-17-staging-tidspbridge-Prepare-for-irqs.h-removal.patch > error: patch failed: drivers/staging/tidspbridge/core/wdt.c:25 > error: drivers/staging/tidspbridge/core/wdt.c: patch does not apply Yes, got the same had to rework the patch to apply. If you have the time, you could try: git am --3way Then resolve the conflicts[1]. > newbie question : Where is the staging-next rep ? http://git.kernel.org/?p=linux/kernel/git/gregkh/staging.git;a=summary Regards, Omar --- [1] http://www.kernel.org/pub/software/scm/git/docs/v1.7.3/user-manual.html#resolving-a-merge -- 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
