Re: Taking tiling and rotation into account in watermark computations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux