On Wed, Mar 2, 2011 at 19:00, Lesly A M <leslyam@xxxxxx> wrote:
[...]
> diff --git a/arch/arm/mach-omap2/twl4030.c b/arch/arm/mach-omap2/twl4030.c
> new file mode 100644
> index 0000000..ff344b3
> --- /dev/null
> +++ b/arch/arm/mach-omap2/twl4030.c
> @@ -0,0 +1,145 @@
> +/*
> + * OMAP power script for PMIC TWL4030
> + *
> + * Author: Lesly A M <leslyam@xxxxxx>
> + *
> + * Copyright (C) 2010 Texas Instruments, Inc.
> + * Lesly A M <leslyam@xxxxxx>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifdef CONFIG_TWL4030_POWER
Why?
> +
> +#include "twl4030.h"
> +
> +/*
> + * Sequence to control the TRITON Power resources,
> + * when the system goes into sleep.
> + * Executed upon P1_P2/P3 transition for sleep.
> + */
try this:
./scripts/kernel-doc --text arch/arm/mach-omap2/twl4030.c
Warning(arch/arm/mach-omap2/twl4030.c): no structured comments found
err... mebbe we need kernel doc styled comments here?
> +static struct twl4030_ins __initdata sleep_on_seq[] = {
does this sequence get triggered for RET or OFF from OMAP perspective?
> + /* Broadcast message to put res to sleep */
> + {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R1,
> + RES_STATE_SLEEP), 2},
At this point - we expect .type=0 and .type2=1 to go to sleep rt?
NRESPWRON is the only one that matched this criteria.
> + {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
> + RES_STATE_SLEEP), 2},
At this point - we expect .type=0 and .type2=1 to go to sleep rt?
HFCLKOUT, VINTANA2 matches this criteria
Which rails are impacted by this? I tried mapping to a spread sheet
and may be lost :(
mebbe documenting it with reasoning why they are chosen will help
reviewers and future
code users understand this better.
> +};
> +
> +static struct twl4030_script sleep_on_script __initdata = {
> + .script = sleep_on_seq,
> + .size = ARRAY_SIZE(sleep_on_seq),
> + .flags = TWL4030_SLEEP_SCRIPT,
> +};
> +
> +/*
> + * Sequence to control the TRITON Power resources,
> + * when the system wakeup from sleep.
> + * Executed upon P1_P2 transition for wakeup.
> + */
> +static struct twl4030_ins wakeup_p12_seq[] __initdata = {
> + /* Broadcast message to put res to active */
> + {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R1,
> + RES_STATE_ACTIVE), 2},
.type=0 and .type2=1 are woken up rt?
NRESPWRON wokeup but we put HFCLKOUT and VINTANA2 to sleep - no wakeup
for those?
> +};
> +
> +static struct twl4030_script wakeup_p12_script __initdata = {
> + .script = wakeup_p12_seq,
> + .size = ARRAY_SIZE(wakeup_p12_seq),
> + .flags = TWL4030_WAKEUP12_SCRIPT,
> +};
> +
> +/*
> + * Sequence to control the TRITON Power resources,
> + * when the system wakeup from sleep.
> + * Executed upon P3 transition for wakeup.
I need a bit of dumbing it down here - what is P3 transition? is it
waking from OFF/RET? is it follow on from P12 then P3?
> + */
> +static struct twl4030_ins wakeup_p3_seq[] __initdata = {
> + /* Broadcast message to put res to active */
> + {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
> + RES_STATE_ACTIVE), 2},
ok - so we wakeup HFCLKOUT and VINTANA2 here - makes me wonder why we
chose VINTANA2 and not VINTANA1.
> +};
> +
> +static struct twl4030_script wakeup_p3_script __initdata = {
> + .script = wakeup_p3_seq,
> + .size = ARRAY_SIZE(wakeup_p3_seq),
> + .flags = TWL4030_WAKEUP3_SCRIPT,
> +};
> +
> +/*
> + * Sequence to reset the TRITON Power resources,
> + * when the system gets warm reset.
> + * Executed upon warm reset signal.
this one makes sense to me thanks.
> + */
> +static struct twl4030_ins wrst_seq[] __initdata = {
> +/*
> + * Reset twl4030.
Why should I reset twl4030 on warm reset? cant I just let the scripts
sit there while I detect (using some mechanism) that i have already
programmed the scripts, hence dont need to reprogram them again?
> + * Reset Main_Ref.
> + * Reset All type2_group2.
> + * Reset VUSB_3v1.
> + * Reset All type2_group1.
> + * Reset RC.
what is RC?
> + * Reenable twl4030.
re-enable?
but, I dont understand: why are these rails chosen? are *all*
platforms having the same rails? would there be variances?
> + */
> + {MSG_SINGULAR(DEV_GRP_NULL, RES_RESET, RES_STATE_OFF), 2},
> + {MSG_SINGULAR(DEV_GRP_NULL, RES_Main_Ref, RES_STATE_WRST), 2},
s/RES_Main_Ref/RES_MAIN_REF ?
> + {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
> + RES_STATE_WRST), 2},
> + {MSG_SINGULAR(DEV_GRP_NULL, RES_VUSB_3V1, RES_STATE_WRST), 2},
> + {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R1,
> + RES_STATE_WRST), 2},
> + {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_RC, RES_TYPE_ALL, RES_TYPE2_R0,
> + RES_STATE_WRST), 2},
> + {MSG_SINGULAR(DEV_GRP_NULL, RES_RESET, RES_STATE_ACTIVE), 2},
I dont understand this sequence unfortunately. need documentation to
help me here.
> +};
> +
> +static struct twl4030_script wrst_script __initdata = {
> + .script = wrst_seq,
> + .size = ARRAY_SIZE(wrst_seq),
> + .flags = TWL4030_WRST_SCRIPT,
> +};
> +
> +/* TRITON script for sleep, wakeup & warm_reset */
> +static struct twl4030_script *twl4030_scripts[] __initdata = {
> + &wakeup_p12_script,
> + &wakeup_p3_script,
> + &sleep_on_script,
> + &wrst_script,
> +};
> +
> +static struct twl4030_resconfig twl4030_rconfig[] = {
overall, I recommend being explicit for the rails -I believe VPLLs
are an example of that. rationale: imagine doing a OTA update: you'd
have the old scripts programmed in by the previous kernel, then the
new kernel starts up since we do a OMAP restart and not really a TWL
restart, we'd end up with a mixture of scripts in the system. - this
is definitely a scenario to avoid - things like broadcast events like
those above going through to rails in the wrong groups can have
havoc..
> + { .resource = RES_VPLL1, .devgroup = DEV_GRP_P1, .type = 3,
> + .type2 = 1, .remap_sleep = RES_STATE_OFF },
> + { .resource = RES_VINTANA1, .devgroup = DEV_GRP_ALL, .type = 1,
> + .type2 = 2, .remap_sleep = RES_STATE_SLEEP },
> + { .resource = RES_VINTANA2, .devgroup = DEV_GRP_ALL, .type = 0,
> + .type2 = 2, .remap_sleep = RES_STATE_SLEEP },
> + { .resource = RES_VINTDIG, .devgroup = DEV_GRP_ALL, .type = 1,
> + .type2 = 2, .remap_sleep = RES_STATE_SLEEP },
> + { .resource = RES_VIO, .devgroup = DEV_GRP_ALL, .type = 2,
> + .type2 = 2, .remap_sleep = RES_STATE_SLEEP },
> + { .resource = RES_VDD1, .devgroup = DEV_GRP_P1,
> + .type = 4, .type2 = 1, .remap_sleep = RES_STATE_OFF },
> + { .resource = RES_VDD2, .devgroup = DEV_GRP_P1,
> + .type = 3, .type2 = 1, .remap_sleep = RES_STATE_OFF },
> + { .resource = RES_REGEN, .devgroup = DEV_GRP_ALL, .type = 2,
> + .type2 = 1, .remap_sleep = RES_STATE_SLEEP },
> + { .resource = RES_NRES_PWRON, .devgroup = DEV_GRP_ALL, .type = 0,
> + .type2 = 1, .remap_sleep = RES_STATE_SLEEP },
> + { .resource = RES_CLKEN, .devgroup = DEV_GRP_ALL, .type = 3,
> + .type2 = 2, .remap_sleep = RES_STATE_SLEEP },
> + { .resource = RES_SYSEN, .devgroup = DEV_GRP_ALL, .type = 6,
> + .type2 = 1, .remap_sleep = RES_STATE_SLEEP },
> + { .resource = RES_HFCLKOUT, .devgroup = DEV_GRP_P3,
> + .type = 0, .type2 = 2, .remap_sleep = RES_STATE_SLEEP },
> + { 0, 0},
Dumb q: vpll2, vaux1-3, vmmc1-2,vsim,vdac,vsub1.5,1.8,3.1, regen,
32KHzclk, triton_ref and main_ref are other resources not covered in
the sequence? I think you either need to cover them OR document why
not and probably stuff like vaux, vmmc1-2 are responsibility of
drivers needs to be clearly stated.
> +};
> +
> +struct twl4030_power_data __initdata twl4030_generic_script = {
> + .scripts = twl4030_scripts,
> + .num = ARRAY_SIZE(twl4030_scripts),
> + .resource_config = twl4030_rconfig,
> +};
> +#endif
> diff --git a/arch/arm/mach-omap2/twl4030.h b/arch/arm/mach-omap2/twl4030.h
> new file mode 100644
> index 0000000..ee66e7d
> --- /dev/null
> +++ b/arch/arm/mach-omap2/twl4030.h
> @@ -0,0 +1,20 @@
> +/*
> + * OMAP TWL4030 power scripts header file
> + *
> + * Author: Lesly A M <x0080970@xxxxxx>
> + *
> + * Copyright (C) 2010 Texas Instruments, Inc.
> + * Lesly A M <x0080970@xxxxxx>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef __ARCH_ARM_MACH_OMAP3_TWL4030_SCRIPT_H
> +#define __ARCH_ARM_MACH_OMAP3_TWL4030_SCRIPT_H
> +
> +#include <linux/i2c/twl.h>
mebbe Kevin can comment if including header in header file is a good idea..
> +
> +extern struct twl4030_power_data twl4030_generic_script;
what if TWL4030 was disabled?
> +#endif
> diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
> index 61b9609..f4bd475 100644
> --- a/include/linux/i2c/twl.h
> +++ b/include/linux/i2c/twl.h
> @@ -436,9 +436,23 @@ static inline int twl6030_mmc_card_detect(struct device *dev, int slot)
>
> /* Power bus message definitions */
>
> -/* The TWL4030/5030 splits its power-management resources (the various
> - * regulators, clock and reset lines) into 3 processor groups - P1, P2 and
> - * P3. These groups can then be configured to transition between sleep, wait-on
> +/*
> + * The TWL4030/5030 splits its power-management resources (the various
> + * regulators, clock and reset lines) into 3 processor groups - P1, P2 and P3.
> + *
> + * Resources attached to device group P1 is managed depending on the state of
> + * NSLEEP1 pin of TRITON, which is connected to sys_off signal from OMAP
> + *
> + * Resources attached to device group P2 is managed depending on the state of
> + * NSLEEP2 pin of TRITON, which is can be connected to a modem or
> + * some other processor
how do these map to OMAP - remember - most of us are familiar with
OMAP and not TWL4030 :(
> + *
> + * Resources attached to device group P3 is managed depending on the state of
> + * CLKREQ pin of TRITON, which is connected to clk request signal from OMAP
> + *
> + * If required these resources can be attached to combination of P1/P2/P3.
> + *
> + * These groups can then be configured to transition between sleep, wait-on
> * and active states by sending messages to the power bus. See Section 5.4.2
> * Power Resources of TWL4030 TRM
> */
> @@ -448,7 +462,17 @@ static inline int twl6030_mmc_card_detect(struct device *dev, int slot)
> #define DEV_GRP_P1 0x1 /* P1: all OMAP devices */
> #define DEV_GRP_P2 0x2 /* P2: all Modem devices */
> #define DEV_GRP_P3 0x4 /* P3: all peripheral devices */
> +#define DEV_GRP_ALL 0x7 /* P1/P2/P3: all devices */
>
> +/*
> + * The 27 power resources in TRITON is again divided into
> + * analog resources:
> + * Power Providers - LDO regulators, dc-to-dc regulators
> + * Power Reference - analog reference
> + *
> + * and digital resources:
> + * Reset & Clock - reset and clock signals.
> + */
> /* Resource groups */
> #define RES_GRP_RES 0x0 /* Reserved */
> #define RES_GRP_PP 0x1 /* Power providers */
> @@ -460,7 +484,10 @@ static inline int twl6030_mmc_card_detect(struct device *dev, int slot)
> #define RES_GRP_ALL 0x7 /* All resource groups */
>
> #define RES_TYPE2_R0 0x0
> +#define RES_TYPE2_R1 0x1
> +#define RES_TYPE2_R2 0x2
>
> +#define RES_TYPE_R0 0x0
> #define RES_TYPE_ALL 0x7
>
> /* Resource states */
> --
> 1.7.1
>
>
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
