Re: [PATCH 2/4] PM: Workaround for taking care of gpio clocks
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [080821 14:08]: > > > >-Original Message- > >From: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED] On Behalf Of ext > >Tony Lindgren > >Sent: 20 August, 2008 14:37 > >To: Hogander Jouni (Nokia-D/Tampere) > >Cc: linux-omap@vger.kernel.org > >Subject: Re: [PATCH 2/4] PM: Workaround for taking care of gpio clocks > > > >* Jouni Hogander <[EMAIL PROTECTED]> [080815 10:47]: > >> In omap3 gpios 2-6 are in per domain. Functional clocks for these > >> should be disabled. This patch is needed until gpio driver disables > >> gpio clocks. > >> > >> GPIO modules in PER domain are not able to act as a wake up > >source if > >> PER domain is in retention. PER domain sleep transition > >before MPU is > >> prevented by leaving icks active. PER domain still enters retention > >> together with MPU. When this happens IOPAD wake up mechanism is used > >> for gpios. > > > >As we talked offline.. Should we pass the GPIO wake-up > >configuration from board-*.c files? Or can we always > >automatically do this safely on 34xx? > > After some investigation it seems that we can configure wake-up events > for almost every GPIO from the padconfigs. There are only 2 pins that do > not seem to have this functionality, however I am not sure if this is a > documentation bug or what because it is strange that only 2 pins lack > this capability. GPIOs 32 and 187 are missing wake-up capability from > padconfig. > > Because of this, our proposal would be to make GPIO clock switching > global, but this would be enabled from a sysfs entry pretty much like > how it is in the patches now. However, this would be separated from UART > clock switching. So, we would introduce two new sysfs files: > uart_clocks_off_while_idle and gpio_clocks_off_while_idle. This would > avoid introducing new complexity in to the idle loop. > > How does this sound like? Sounds good to me. Then we may be able to remove both sysfs files eventually. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/4] PM: Workaround for taking care of gpio clocks
>-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of ext >Tony Lindgren >Sent: 20 August, 2008 14:37 >To: Hogander Jouni (Nokia-D/Tampere) >Cc: linux-omap@vger.kernel.org >Subject: Re: [PATCH 2/4] PM: Workaround for taking care of gpio clocks > >* Jouni Hogander <[EMAIL PROTECTED]> [080815 10:47]: >> In omap3 gpios 2-6 are in per domain. Functional clocks for these >> should be disabled. This patch is needed until gpio driver disables >> gpio clocks. >> >> GPIO modules in PER domain are not able to act as a wake up >source if >> PER domain is in retention. PER domain sleep transition >before MPU is >> prevented by leaving icks active. PER domain still enters retention >> together with MPU. When this happens IOPAD wake up mechanism is used >> for gpios. > >As we talked offline.. Should we pass the GPIO wake-up >configuration from board-*.c files? Or can we always >automatically do this safely on 34xx? After some investigation it seems that we can configure wake-up events for almost every GPIO from the padconfigs. There are only 2 pins that do not seem to have this functionality, however I am not sure if this is a documentation bug or what because it is strange that only 2 pins lack this capability. GPIOs 32 and 187 are missing wake-up capability from padconfig. Because of this, our proposal would be to make GPIO clock switching global, but this would be enabled from a sysfs entry pretty much like how it is in the patches now. However, this would be separated from UART clock switching. So, we would introduce two new sysfs files: uart_clocks_off_while_idle and gpio_clocks_off_while_idle. This would avoid introducing new complexity in to the idle loop. How does this sound like? -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] PM: Workaround for taking care of gpio clocks
* Jouni Hogander <[EMAIL PROTECTED]> [080815 10:47]:
> In omap3 gpios 2-6 are in per domain. Functional clocks for these
> should be disabled. This patch is needed until gpio driver disables
> gpio clocks.
>
> GPIO modules in PER domain are not able to act as a wake up source if
> PER domain is in retention. PER domain sleep transition before MPU is
> prevented by leaving icks active. PER domain still enters retention
> together with MPU. When this happens IOPAD wake up mechanism is used
> for gpios.
As we talked offline.. Should we pass the GPIO wake-up configuration
from board-*.c files? Or can we always automatically do this safely
on 34xx?
Tony
> Signed-off-by: Jouni Hogander <[EMAIL PROTECTED]>
> ---
> arch/arm/mach-omap2/pm34xx.c | 54
> +-
> 1 files changed, 53 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index f30fa9e..7d5d461 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -53,6 +53,36 @@ static void (*saved_idle)(void);
>
> static struct powerdomain *mpu_pwrdm;
>
> +/* XXX This is for gpio fclk hack. Will be removed as gpio driver
> + * handles fcks correctly */
> +#define NUM_OF_PERGPIOS 5
> +static struct clk *gpio_fcks[NUM_OF_PERGPIOS];
> +
> +/* XXX This is for gpio fclk hack. Will be removed as gpio driver
> + * handles fcks correctly */
> +static void per_gpio_clk_enable(void)
> +{
> + int i;
> + for (i = 1; i < NUM_OF_PERGPIOS + 1; i++)
> + clk_enable(gpio_fcks[i-1]);
> +}
> +
> +/* XXX This is for gpio fclk hack. Will be removed as gpio driver
> + * handles fcks correctly */
> +static void per_gpio_clk_disable(void)
> +{
> + int i;
> + for (i = 1; i < NUM_OF_PERGPIOS + 1; i++)
> + clk_disable(gpio_fcks[i-1]);
> +}
> +
> +/* XXX This is for gpio fclk hack. Will be removed as gpio driver
> + * handles fcks correctly */
> +static void gpio_fclk_mask(u32 *fclk)
> +{
> + *fclk &= ~(0x1f << 13);
> +}
> +
> /* PRCM Interrupt Handler for wakeups */
> static irqreturn_t prcm_interrupt_handler (int irq, void *dev_id)
> {
> @@ -169,8 +199,18 @@ static void omap_sram_idle(void)
>
> omap2_gpio_prepare_for_retention();
>
> + /* XXX This is for gpio fclk hack. Will be removed as gpio driver
> + * handles fcks correctly */
> + if (clocks_off_while_idle)
> + per_gpio_clk_disable();
> +
> _omap_sram_idle(NULL, save_state);
>
> + /* XXX This is for gpio fclk hack. Will be removed as gpio driver
> + * handles fcks correctly */
> + if (clocks_off_while_idle)
> + per_gpio_clk_enable();
> +
> omap2_gpio_resume_after_retention();
> }
>
> @@ -200,6 +240,10 @@ static int omap3_fclks_active(void)
> CM_FCLKEN);
> fck_per = cm_read_mod_reg(OMAP3430_PER_MOD,
> CM_FCLKEN);
> +
> + if (clocks_off_while_idle)
> + gpio_fclk_mask(&fck_per);
> +
> if (fck_core1 | fck_core3 | fck_sgx | fck_dss |
> fck_cam | fck_per | fck_usbhost)
> return 1;
> @@ -418,7 +462,8 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm)
> int __init omap3_pm_init(void)
> {
> struct power_state *pwrst;
> - int ret;
> + char clk_name[11];
> + int ret, i;
>
> printk(KERN_ERR "Power Management for TI OMAP3.\n");
>
> @@ -454,6 +499,13 @@ int __init omap3_pm_init(void)
>
> pm_idle = omap3_pm_idle;
>
> + /* XXX This is for gpio fclk hack. Will be removed as gpio driver
> + * handles fcks correctly */
> + for (i = 1; i < NUM_OF_PERGPIOS + 1; i++) {
> + sprintf(clk_name, "gpio%d_fck", i + 1);
> + gpio_fcks[i-1] = clk_get(NULL, clk_name);
> + }
> +
> err1:
> return ret;
> err2:
> --
> 1.5.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
