On Mon, Oct 06, 2014 at 05:11:57PM +0100, Tvrtko Ursulin wrote: > > Hi all, > > We need to refactor the current code a bit to allow parameters like > plane rotation and framebuffer tiling mode be taken into account when > calculating display watermarks. > > I looked into this code a bit and am at the moment a bit confused with > what is where and why. > > For example the purpose of plane_config in intel_crtc seems a bit thin, > or why it is created once on driver init. That thing is only used for the BIOS fb takesover. Probably should be renamed since it's basically just some kind of duplicated fb structure rather than a full plane config. And I don't want to extend that duplication into the structure we use to track the plane config otherwise. We now have intel_plane_state (or something like that) that's going to form the basis of the plane config tracking. > Then again watermark > parameters are embedded in intel_plane, which is separate from > plane_config. The per-plane watermark stuff should get moved into the intel_plane_state. But that requires that I find the time to get back to the watermark code and actually finish off whatever patches I have still pending. So the current state of the watermark code was just meant to be a short lived thing while it continues to evolve. Sadly the remaining stuff didn't get in when I had the time to work on it and now I can't seem to find any time for it. But hopefully soon I'll have some time for this again (famous last words). > And where is the link between intel_crtc and intel_plane, > or why intel_crtc has a plane field - is it not that there are multiple > planes per pipe/crtc? That's the primary plane used by the drm crtc. We now expose the primary planes as drm_planes as well, but we still need to keep the "crtc can do scanout" idea around since it's part of the current user space API. The atomic modeset API won't have such silly notions any more. > Part one would be trying to understand how things are. Then part two > would be coming up with a design, if justified by the extent of work > required, to implement this requirement. > > Thanks, > > Tvrtko > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
