Re: reset handling in am335x hwmod data

[Nishanth Menon <nm@ti.com>]

On 07/01/2013 11:37 PM, Hiremath, Vaibhav wrote:
>
>> -----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-
>>>> omap@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 <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.
>>>>
>>> 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.

Nope. I am not working on this.

-- 
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