On 2013-11-25 03:29, Archit Taneja wrote: > On Monday 18 November 2013 06:20 PM, Tomi Valkeinen wrote: >> Use runtime PM's autosuspend support with delay of 100ms. >> >> This will prevent the driver from turning the DSS modules off and on >> multiple times e.g. when loading the module. > > Could you explain this a bit more? First of all, I'm not quite sure if this is even needed. Things are probably simpler without autosuspend, and we don't have much on/off cycles going on in DSS, so I don't think autosuspend helps much. Maybe it's even bad if somebody wants to enable/disable the DSS HW very quickly. So in the minimum, autosuspend should be made configurable. For now, I think I'll just leave it out. > Are you saying that when we insert the omapdss module, we have a lot of > runtime_get/put pairs in probe, which leads to us excessive writing of > DISPC the registers during resume, and the autosuspend feature would > delay the effect of runtime_put() for a while? For example, first DSS is probed. the dss.c driver will enable dss_core (i.e. the whole DSS hw block), do some register reads/writes, and disable dss_core. Then DISPC is probed, and things go very much like with DSS. And so on. Each submodule will enable and disable the whole DSS, because nothing is keeping the DSS enabled between the probes. With autosuspend, the DSS HW block will stay enabled long enough so the next probe gets ran. > Also, do we need to do this for all the platform devices? Could we use > autosuspend only for the parent platform device, and the children > platform devices don't use it? Or am I understanding things wrongly here? In theory, yes. In practice, if I'm not mistaken, no. When a device is enabled, it'll enable the parent device. When the device is disabled, its parent device will be immediately disabled (if nothing is using it), so autosuspend doesn't have an effect there. So we need to use autosuspend for the child devices. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
