Re: reset handling in am335x hwmod data

[Nishanth Menon <nm@ti.com>]

On 12:47-20130520, Hiremath, Vaibhav wrote:
[...]
> > > > >
> > > > > On 20:10-20130517, Peter Korsgaard wrote:
> > > > > > >>>>> "Kevin" == Kevin Hilman <khilman@linaro.org> writes:
> > > > > >
> > > > > >  >> In this case, we cannot reset that bank, otherwise Starter
> > Kit
> > > > > will
> > > > > >  >> never boot in mainline. Bad PCB design, I know, but it's
> > not
> > > > > something
> > > > > >  >> we can change now :-)
> > > > > >
> > > > > >  Kevin> FWIW, we've seen this before (GPIO connected to PMIC
> > reset
> > > > is
> > > > > a
> > > > > >  Kevin> fun one), and this is why we have
> > > > > omap_hwmod_no_setup_reset().
> > > > > >
> > > > > > Yes, but there's no dts bindings for this, and from a quick
> > test
> > > > the
> > > > > > reset handling happens before the device tree is probed.
> > > > > I have the same issue with TPS62361 on Palmas -> GPIO controls
> > the
> > > > > voltage register supplying MPU, without any driver setting things
> > up,
> > > > > GPIO gets reset and obviously voltage value switches to an
> > voltage
> > > > > where
> > > > > device does not function.
> > > > >
> > > > > Solution I am working on to solve this is [1]: snippet is part of
> > a
> > > > > patch that I am working on atm.
> > > > >
> > > > > This is the right way to do it IMHO. Will allow the driver to
> > exist
> > > > > when
> > > > > HWMOD will be eventually replaced by some other framework.
> > > > >
> > > > >
> > > > > [1]: http://pastebin.com/XPmAB1Zb
> > > > >
> > > > >
> > > >
> > > > Both seems to be different to me. What we need is to
> > > > Avoid reset of whole GPIO bank during kernel boot.
> > Yes - that is what the above does - as long as the GPIO is requested
> > and
> > set to the right level by the relevant driver, it is not "unused" and
> > hence not reset at late_init.
> > 
> 
> May be I am missing something here,
> 
> Isn't _setup_reset() function asserts ocp_reset? And it is core_initcall.
Hmm.. You are right, I missed that :(
> 
> > I am a little unclear as to why this needs to have anything to do with
> > the precise under-lying mechanism (hwmod or something else). May be
> > "both seem to be different to me" needs a little further elaboration?
> > 
> 
> GPIO is connected to the DDR VTT control pin, and we have observed that
> Due to GPIO bank reset as part of hwmod init during bootup.
> 
> > Is this because there is no need for an EMIF driver to handle DDR? and
> > reset of the GPIO will occur as EMIF is configured at bootloader and
> > there is no need to do that in kernel, correspondingly there is no
> > "driver" to hold the gpio?
> > > >
> > > > Ideally, it would have been much better if drivers starts handling
> > > > Idle, ocp reset and standby on their own (killing dependency on
> > hwmod
> > > > init layer).
> > > >
> > > > But looking at current state,
> > > > I agree we need to use DT property here, so how about
> > > > Adding DT property  to GPIO node itself. But we have to parse
> > I believe you mean at OMAP specific  DT property for hwmod?
> > something like ti,hwmod-no-init-reset?
> 
> That’s the idea.
> 
> > > > It early during hwmod init stage. We should read all DT nodes
> > > > Inside function __setup() function, that way can get rid of
> > > > HWMOD_INIT_NO_RESET flag completely. Also, this will handle
> > > > Both ocp_reset and domain reset.
> > > >
> > >
> > > Forgot to mention,
> > >
> > > Since this is kernel boot failure issue, I think,
> > > By the time we reach to conclusion, another approach is to
> > > set "HWMOD_INIT_NO_RESET" flag For GPIO0 bank.
> > a) if the GPIO gets moved over to some other GPIO bank on another
> > platform,
> > this wont work
> 
> Yes that’s true, but such schematic interface is not recommended.
> And we have not seen any known side-effect of not resetting GPIO0 bank.
unless you mark the GPIO as taken, another driver could in-adverantly
take over the GPIO and set it to a wrong level (we had a similar story
with LED gpio between Panda Vs Panda-ES).

> 
> > b) for platforms that dont use gpio to hold DDR power, maybe this is
> > not
> > even relevant and the GPIO bank can safely be reset?
> > >
> 
> As I mentioned, there is no known side-effect of not resetting GPIO bank 0.
It should depend on the platform.

There are other uses for hwmod-no-reset -> Eg. boot logo displayed by
bootloader - if there is a reset of DSS block and re-configuration, we'd
notice a blank-out, which is not desirable either. There could be a few
other usage based on no-reset.

In all cases, you'd prefer to make this:
a) platform dependent (board dts)
b) reserve GPIO as well so that no other driver'd take it - if they
attempt ther'd at least be some form of warning.

-- 
Regards,
Nishanth Menon
--
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