Re: reset handling in am335x hwmod data

[Nishanth Menon <nm@ti.com>]

On 01:55-20130520, Hiremath, Vaibhav wrote:
> 
> > -----Original Message-----
> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > owner@vger.kernel.org] On Behalf Of Hiremath, Vaibhav
> > Sent: Monday, May 20, 2013 12:09 PM
> > To: Menon, Nishanth; Peter Korsgaard
> > Cc: Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux-
> > omap@vger.kernel.org; Tony Lindgren
> > Subject: RE: reset handling in am335x hwmod data
> > 
> > 
> > > -----Original Message-----
> > > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > > owner@vger.kernel.org] On Behalf Of Menon, Nishanth
> > > Sent: Friday, May 17, 2013 11:49 PM
> > > To: Peter Korsgaard
> > > Cc: Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux-
> > > omap@vger.kernel.org; Tony Lindgren
> > > Subject: Re: reset handling in am335x hwmod data
> > >
> > > 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.

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?

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?
> > 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
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?
> 
> Thanks,
> Vaibhav

-- 
Regards,
Nishanth Menon