[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151202013805.GA23396@atomide.com>
Date: Tue, 1 Dec 2015 17:38:05 -0800
From: Tony Lindgren <tony@...mide.com>
To: Matthijs van Duin <matthijsvanduin@...il.com>
Cc: lkml <linux-kernel@...r.kernel.org>,
"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Brian Hutchinson <b.hutchman@...il.com>,
Delio Brignoli <dbrignoli@...ioscience.com>,
Neil Armstrong <narmstrong@...libre.com>,
Philipp Rosenberger <ilu@...utronix.de>,
Paul Walmsley <paul@...an.com>
Subject: Re: [PATCH 05/10] ARM: OMAP2+: Disable GPIO softreset for dm81xx
* Tony Lindgren <tony@...mide.com> [151201 16:56]:
> * Tony Lindgren <tony@...mide.com> [151201 16:42]:
> > * Matthijs van Duin <matthijsvanduin@...il.com> [151201 16:11]:
> > > On 2 December 2015 at 00:38, Tony Lindgren <tony@...mide.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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists