Op 29-07-16 om 22:33 schreef Matt Roper:
On Fri, Jul 29, 2016 at 12:39:05PM +0300, Ville Syrjälä wrote:
On Thu, Jul 28, 2016 at 05:03:52PM -0700, Matt Roper wrote:
This is completely untested (and probably horribly broken/buggy), but here's a quick mockup of the general approach I was thinking for ensuring DDB & WM's can be updated together while ensuring the three-step pipe flushing process is honored:
https://github.com/mattrope/kernel/commits/experimental/lyude_ddbBasically the idea is to take note of what's happening to the pipe's DDB allocation (shrinking, growing, unchanged, etc.) during the atomic check phase;
Didn't look too closely, but I think you can't actually do that unless you lock all the crtcs whenever the number of active pipes is goind to change. Meaning we'd essentially be back to the one-big-modeset-lock apporach, which will cause missed flips and whanot on the other pipes.
The alternative I think would consist of:
- make sure level 0 watermark never exceeds total_ddb_size/max_pipes, so that a modeset doesn't have to care about the wms for the other pipes not fitting in
Unfortunately this part is the problem. You might get away with doing this on SKL/KBL which only have three planes max per pipe and a large (896 block) DDB, but on BXT you have up to four planes (we don't actually enable the topmost plane in a full-featured manner just yet, but need to soon), yet the total DDB is only 512 blocks. Sadly, the platform with more planes was given a smaller DDB... :-( We're already in trouble because users that are running setups like 3x 4K with most/all planes in use at large sizes can't find level 0 watermarks that satisfy their needs and we have to reject the whole configuration. If we further limit each pipe's usage to total/maxpipes (i.e., 170 blocks per pipe on BXT), then we're going to hit similar issues when only driving one or two displays with with all of the planes in use, even though we should have had more DDB space to work with.
I guess serious plane usage isn't too common in desktop setups today, but it's a very critical feature in the embedded world; we can't really afford to cripple plane usage further. Unfortunately, as you point out above, this means that we have to follow the bspec's DDB allocation method, which in turn means we need to grab _all_ CRTC locks any time _any_ CRTC is being turned on or turned off which is a BKL-style way of doing things.
Meh, I'm running into a similar issue on vlv/chv. I don't see a way around it. :( Only thing we could do is split up the state to make the non-modeset crtc's complete early.