> -----Original Message----- > From: Balbi, Felipe > Sent: Friday, June 28, 2013 4:24 PM > To: Hiremath, Vaibhav > Cc: Menon, Nishanth; Peter Korsgaard; Kevin Hilman; Balbi, Felipe; Paul > Walmsley; linux-omap@vger.kernel.org; Tony Lindgren; Sebastian Andrzej > Siewior > Subject: Re: reset handling in am335x hwmod data > > Hi, > > On Mon, May 20, 2013 at 08:20:29PM +0200, Hiremath, Vaibhav wrote: > > > > > -----Original Message----- > > > From: Menon, Nishanth > > > Sent: Monday, May 20, 2013 11:34 PM > > > To: Hiremath, Vaibhav > > > Cc: Peter Korsgaard; Kevin Hilman; Balbi, Felipe; Paul Walmsley; > linux- > > > o...@vger.kernel.org; Tony Lindgren > > > Subject: Re: reset handling in am335x hwmod data > > > > > > On 12:47-20130520, Hiremath, Vaibhav wrote: > > > [...] > > > > > > > > > > > > > > > > On 20:10-20130517, Peter Korsgaard wrote: > > > > > > > > > >>>>> "Kevin" == Kevin Hilman <khil...@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. > > > > > Completely agree with you on both the points, and my point and all my > comments > > Were more related to option 'a' above. > > so, what happened here ? Will we not have AM335x-SK working in mainline > just because of the GPIO block being reset ? >
Nishant started implementing on this, not sure what state it is in. Thanks, Vaibhav
