Re: [PATCH] omap: hwmod: add syss reset done flags to omap2, omap3 hwmods

["Cousson, Benoit" <b-cousson@ti.com>]

On 3/31/2011 5:51 PM, Mahadeva, Avinash wrote:
>>> The problem is the FCLK isn't enabled for these gpios(2..6) while
>>> resetting.  So the GPIO's are not resetting properly. Once i enable FCLK
>>> for them and then set the SYSCONFIG.SOFTRESET, then they are resetting
>>> and it is reflected in RESETDONE bit.
>>
>> What do you mean by fclk here.  GPIO doesn't have an fclk.  The
>> interface clock provides the functional clock, and the optional debounce
>> clock (dbclk) is needed only when GPIO debounce is enabled.
>>
>> I suggest you look at the "integration" sub chapter of the TRM for the
>> GPIO module.
>
> Hi Kevin ,
>
> I looked at this section. Now i am clear about the code. I meant fclk as
> functional clocks which is described by register CM_FCLKEN_PER, bit 12
> to bit 17. These bits are described as they control 'GPIO x functional
> clock'.
>
> Looking at the GPIO chapter, i understood that this is same as the gpio
> dbck. This was confirmed by section 'PER Power Domain Clock Controls'
> where he says CM_FCLKEN_PER[12-17] control PER_32K_ALWON_FCLK which is
> routed as GPIOx_DBCLK.
>
> [...]
>
>>
>> There are no GPIO fclks.
>>
>>> Also 'fclk' is structured as 'gpio2_dbck' and made as an optional
>>> clock.  I wasn't very sure, why the name 'dbck'?
>>
>> dbck == debounce clock
>
> I got it. Thanks for the clarification.
>
> Looks like without this clock, GPIO module isn't resetting even on
> writing to SYSCONFIG register. Should we provide a seperate reset
> function for gpio, like the way it was suggested for i2c ?

No need for that, it is already working like that on OMAP4.
We have a nice flag that handle that clock during reset.

	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,

Regards,
Benoit