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