Hi Rajendra, On Thu, 12 Apr 2012, Rajendra Nayak wrote: > On Thursday 12 April 2012 12:29 AM, Paul Walmsley wrote: > > That approach sounds fine to me, but I don't think Fernando's patch will > > help with I2C.. Since it uses a custom reset function omap_i2c_reset(), > > the delay will actually need to go there. > > While working on fixing this I stumbled upon a couple of other > things which don't seem right. > > The i2c custom reset funtion (omap_i2c_reset) uses a hwmod exposed > api to set the SOFTRESET bit, however it then accesses the hwmod > internal structure to poll on RESETDONE status bit. Should there be > another function exposed to poll on RESETDONE too? Sure, something like that would make sense for 3.5. > _reset() function documents its return value to be -ETIMEDOUT, if the > module fails to reset in time, and hence expects the custom reset > function to return the same in such cases. The omap_i2c_reset() function > seems to return 0 even in cases of timeout. However looking more closely > the return value from _reset() does not seem to be used in the framework > today. > > The comment in _ocp_softreset() suggests the intent was to add a new > state to the hwmod state machine. > > /* > * XXX add _HWMOD_STATE_WEDGED for modules that don't come back from > * _wait_target_ready() or _reset() > */ > > is it still the case, or should _reset() just return a void? There's a patch queued to pass along the return status from _reset(): http://marc.info/?l=linux-omap&m=133417544011862&w=2 As far as the new state goes, if you'd like to add a new state to indicate an IP block that fails _reset()/_wait_target_ready() and should be blocked from further use, that sounds good to me... regards, - Paul -- 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
