On Tue, Jul 12, 2016 at 9:38 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: > On Fri, Jul 01, 2016 at 02:00:00PM -0400, Sean Paul wrote: >> On Fri, Jul 1, 2016 at 5:19 AM, Yakir Yang <ykk@xxxxxxxxxxxxxx> wrote: >> > The PSR driver have exported four symbols for specific device driver: >> > - rockchip_drm_psr_register() >> > - rockchip_drm_psr_unregister() >> > - rockchip_drm_psr_enable() >> > - rockchip_drm_psr_disable() >> > - rockchip_drm_psr_flush() >> > >> > Encoder driver should call the register/unregister interfaces to hook >> > itself into common PSR driver, encoder have implement the 'psr_set' >> > callback which use the set PSR state in hardware side. >> > >> > Crtc driver would call the enable/disable interfaces when vblank is >> > enable/disable, after that the common PSR driver would call the encoder >> > registered callback to set the PSR state. >> > >> >> This feels overly complicated. It seems like you could cut out a bunch >> of code by just coding the psr functions into vop and >> analogix_dp-rockchip. I suppose the only reason to keep it abstracted >> would be if you plan on supporting psr in a different encoder or crtc >> in rockchip, or if you're planning on moving this into drm core. > > Agreed on the layers of indirection. Also, you end up with 3 delayed > timers in total: > - defio timer from fbdev emulation > - timer in this abstraction > - delayed work in the psr backend driver Maybe I'm missing something obvious (don't know how the PSR is implemented in hardware or in other drivers), but why do we need all these timers? Couldn't we just trigger a fake page flip on fb dirty call? Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |