On Mon, 2011-08-08 at 17:13 +0530, Archit Taneja wrote: > Hi, > > On Monday 08 August 2011 02:45 PM, Valkeinen, Tomi wrote: > > Second try with the DSS HWMODs > > > > This set fixes the DSS clocks in HWMOD data, and implements a new reset > > mechanism for dss_core. > > > > The new dss_reset function doesn't actually do a reset, it just enables all > > DSS > > clocks and waits for the reset to complete. This should be better approach > > than > > actually doing a reset, because: > > > > OMAP4 - dss_core HW doesn't contain a SW reset bit so doing a reset is > > impossible. But after power-on we need to enable all DSS clocks and wait for > > the power-on reset to complete. > > > > OMAP2/3 - dss_core does have a SW reset bit, but resetting dss_core also > > resets > > all the other DSS modules. This means that the other modules could be left > > uninitialized, as the hwmod code handles all modules independently, and in > > this > > case initializes only dss_core's registers. Thus dss_core's reset shouldn't > > be > > used, and we should only verify that the power-on reset has completed. > > If the bootloader enables DSS, we need to do a reset so that DSS2 driver > can start with DSS HW in a clean state. With this patch set, how do we > take care of such a scenario?
We don't. That should be done in a future patch. I think we should extend this reset function, and disable the LCD outputs and reset the clock switches there. I didn't want to do that yet as I wanted to fix the current problem with the reset first and I don't have an environment where to test it. I hope you can help here =). Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
