| Message ID | 1449013103-23238-6-git-send-email-tony@atomide.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 2 December 2015 at 00:38, Tony Lindgren <tony@atomide.com> wrote: > Looks like GPIO softreset status bit on both dm8168 and dm8148 > is broken and only goes high initially. After writing to sysc > softreset bit, the resetdone bit never goes high again. The resetdone bit works fine, but it needs all clocks active to come up. You're neglecting to enable the debounce clock to the GPIO module: > # mw.l 0x4818155c 0x2 That should write 0x102 instead. You can disable the debounce clock after resetting the module if you don't need it, though I doubt there's any significant power savings there. (More likely it exists as a separate bit to allow it to stay enabled even if the module isn't, for wakeup on debounced inputs.) Matthijs -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Matthijs van Duin <matthijsvanduin@gmail.com> [151201 16:11]: > On 2 December 2015 at 00:38, Tony Lindgren <tony@atomide.com> wrote: > > Looks like GPIO softreset status bit on both dm8168 and dm8148 > > is broken and only goes high initially. After writing to sysc > > softreset bit, the resetdone bit never goes high again. > > The resetdone bit works fine, but it needs all clocks active to come > up. You're neglecting to enable the debounce clock to the GPIO module: > > > # mw.l 0x4818155c 0x2 > > That should write 0x102 instead. It seems to work only once based on what I've seen :) If you try it after it's powered it never works. Could be I'm doing something wrong of course.. > You can disable the debounce clock after resetting the module if you > don't need it, though I doubt there's any significant power savings > there. (More likely it exists as a separate bit to allow it to stay > enabled even if the module isn't, for wakeup on debounced inputs.) Hmm I tried setting HWMOD_CONTROL_OPT_CLKS_IN_RESET flag like we have for many SoCs to enable also sysclk18_ck but no luck. I can recheck that. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Tony Lindgren <tony@atomide.com> [151201 16:42]: > * Matthijs van Duin <matthijsvanduin@gmail.com> [151201 16:11]: > > On 2 December 2015 at 00:38, Tony Lindgren <tony@atomide.com> wrote: > > > Looks like GPIO softreset status bit on both dm8168 and dm8148 > > > is broken and only goes high initially. After writing to sysc > > > softreset bit, the resetdone bit never goes high again. > > > > The resetdone bit works fine, but it needs all clocks active to come > > up. You're neglecting to enable the debounce clock to the GPIO module: > > > > > # mw.l 0x4818155c 0x2 > > > > That should write 0x102 instead. > > It seems to work only once based on what I've seen :) If you try it > after it's powered it never works. Could be I'm doing something wrong > of course.. > > > You can disable the debounce clock after resetting the module if you > > don't need it, though I doubt there's any significant power savings > > there. (More likely it exists as a separate bit to allow it to stay > > enabled even if the module isn't, for wakeup on debounced inputs.) > > Hmm I tried setting HWMOD_CONTROL_OPT_CLKS_IN_RESET flag like we > have for many SoCs to enable also sysclk18_ck but no luck. I can > recheck that. You're right with 0x102 it works, need to debug further. Thanks, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Tony Lindgren <tony@atomide.com> [151201 16:56]: > * Tony Lindgren <tony@atomide.com> [151201 16:42]: > > * Matthijs van Duin <matthijsvanduin@gmail.com> [151201 16:11]: > > > On 2 December 2015 at 00:38, Tony Lindgren <tony@atomide.com> wrote: > > > > Looks like GPIO softreset status bit on both dm8168 and dm8148 > > > > is broken and only goes high initially. After writing to sysc > > > > softreset bit, the resetdone bit never goes high again. > > > > > > The resetdone bit works fine, but it needs all clocks active to come > > > up. You're neglecting to enable the debounce clock to the GPIO module: > > > > > > > # mw.l 0x4818155c 0x2 > > > > > > That should write 0x102 instead. > > > > It seems to work only once based on what I've seen :) If you try it > > after it's powered it never works. Could be I'm doing something wrong > > of course.. > > > > > You can disable the debounce clock after resetting the module if you > > > don't need it, though I doubt there's any significant power savings > > > there. (More likely it exists as a separate bit to allow it to stay > > > enabled even if the module isn't, for wakeup on debounced inputs.) > > > > Hmm I tried setting HWMOD_CONTROL_OPT_CLKS_IN_RESET flag like we > > have for many SoCs to enable also sysclk18_ck but no luck. I can > > recheck that. > > You're right with 0x102 it works, need to debug further. Looks like also am33xx has opt clocks gate bit 18. Probably the best way to deal with this in the long run is to set up the clkctrl and optfclken as gate clocks with the clock framework. This is also needed as we have some devices sharing a single clkctrl register. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c index 1b96cdf..440fd6c 100644 --- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c @@ -432,6 +432,7 @@ static struct omap_hwmod_ocp_if dm81xx_l4_ls__elm = { .user = OCP_USER_MPU, }; +/* On dm81xx RESETDONE bit seems to never goes high again after SOFTRESET */ static struct omap_hwmod_class_sysconfig dm81xx_gpio_sysc = { .rev_offs = 0x0000, .sysc_offs = 0x0010, @@ -463,6 +464,7 @@ static struct omap_hwmod dm81xx_gpio1_hwmod = { .name = "gpio1", .clkdm_name = "alwon_l3s_clkdm", .class = &dm81xx_gpio_hwmod_class, + .flags = HWMOD_INIT_NO_RESET, .main_clk = "sysclk6_ck", .prcm = { .omap4 = { @@ -490,6 +492,7 @@ static struct omap_hwmod dm81xx_gpio2_hwmod = { .clkdm_name = "alwon_l3s_clkdm", .class = &dm81xx_gpio_hwmod_class, .main_clk = "sysclk6_ck", + .flags = HWMOD_INIT_NO_RESET, .prcm = { .omap4 = { .clkctrl_offs = DM81XX_CM_ALWON_GPIO_1_CLKCTRL,
Looks like GPIO softreset status bit on both dm8168 and dm8148 is broken and only goes high initially. After writing to sysc softreset bit, the resetdone bit never goes high again. I noticed this as GPIOs are enabled from u-boot at least on t410. And this can be tested easliy with the following commands in u-boot: # mw.l 0x4818155c 0x2 # md.l 0x48032114 1 48032114: 00000001 .... # mw.l 0x48032010 0x2 # md.l 0x48032114 1 48032114: 00000000 .... Looks like the GPIO module is functional even with the resetdone bit down. Let's just tag the GPIOs for dm81xx with HWMOD_INIT_NO_RESET. Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com> --- arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 3 +++ 1 file changed, 3 insertions(+)