On Wed, May 13, 2020 at 10:15:25AM +0100, Emil Velikov wrote: > On Tue, 12 May 2020 at 19:47, Thomas Zimmermann <tzimmermann@xxxxxxx> wrote: > > > > Hi > > > > Am 12.05.20 um 12:14 schrieb Emil Velikov: > > > Hi Thomas, > > > > > > On Tue, 12 May 2020 at 09:43, Thomas Zimmermann <tzimmermann@xxxxxxx> wrote: > > >> > > >> The suspend/resume helpers are unused. Also remove associated state > > >> from struct mga_device. > > >> > > > Although DPMS in it's traditional sense is no longer a thing, would it > > > make sense to keep this around for documentation purposes? > > > In particular, the pci magic and associated PLL/DAC/pixel clock could > > > be used for dynamic PM. > > > > That patch is not about DPMS. The DPMS code is still there. The > > suspend/resume helpers were outcommented and I don't know if they ever > > worked. Let's remove them. > > > Seems like the idea is to suspend/resume the device on DPMS off/on. A > rather moot point IMHO. > As the DPMS semantics and the whole modeset, got more subtle with > atomic modeset, the idea gets even more moot. With atomic it's actually a lot easier to do runtime pm in your modesetting code, since the flow is a lot more structured. There's even a helper function for that with drm_atomic_helper_commit_tail_rpm, since the default is optimized for max compatability with old legacy helpers. Maybe we should switch that around actually. -Daniel > If the documentation has that process - sure nuke it. Although for > dynPM, this code is essential. > Considering a) one has interest in dynPM and b) the code is (close to) working. > > The last two are very big ifs so I'll leave it there. > > -Emil -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
