RE: reset handling in am335x hwmod data

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----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@xxxxxxxxxxxxxxx; 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-
> > > omap@xxxxxxxxxxxxxxx; 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 <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.
> > > > > 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
��.n��������+%������w��{.n�����{�������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f





[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux