+ Kevin On Friday 30 March 2012 01:56 PM, Tomi Valkeinen wrote: > 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 =). > I agree. In fact I faced similar issue when I briefly tried moving OMAP cpuidle code to drivers/idle/*. That time me and Kevin concluded that till we move the powerdomain, clockdomain code to drivers/* and export it, the cpuidle movement needs to be deferred. Regards Santosh -- 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
