On Fri, 2012-03-30 at 13:51 +0530, Shilimkar, Santosh wrote: > On Fri, Mar 30, 2012 at 1:37 PM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > > All OMAP4 versions seem to be affected. I couldn't find a mention about > > this in the mainline kernel. Any ideas how and where this should be > > fixed? > > > It's not patched for mainline. Generally clock-domain code > is abstracted from drivers but considering the errata and affected > modules, I guees it should be handled by DSS driver > since that is where the state of DSS or ISS will be known. Note > ISS will be automatically taken care since it will always use disaplay. > > In internal tree's this was handled as part of DSS early suspend/resume That version doesn't work as it uses functions that are not exported to drivers. I don't know much about the clock domain code, but I hope there's a way to handle it there. Otherwise I guess I need to add a new set of platform callback functions, so that the dss driver can call arch/arm/mach-omap2 code to enable and disable the work-around. I dislike that because I'm currently trying to remove those kinds of hacks to make dss work better with DT =). Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
