> -----Original Message----- > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > owner@xxxxxxxxxxxxxxx] 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@xxxxxxxxxxxxxxx; Tony Lindgren > Subject: RE: reset handling in am335x hwmod data > > > > -----Original Message----- > > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > > owner@xxxxxxxxxxxxxxx] 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@xxxxxxxxxxxxxxx; Tony Lindgren > > Subject: Re: reset handling in am335x hwmod data > > > > On 20:10-20130517, Peter Korsgaard wrote: > > > >>>>> "Kevin" == Kevin Hilman <khilman@xxxxxxxxxx> 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. > > 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 > 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. Thanks, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
