Hi Daniel, On Fri, 26 Oct 2018 12:33:37 +0200 Daniel Vetter <daniel@xxxxxxxx> wrote: > On Thu, Oct 25, 2018 at 02:45:44PM +0200, Boris Brezillon wrote: > > Display controllers usually provide a lot features like overlay planes, > > hardware scalers, hardware rotations, ... > > Most of the time those features work just fine when enabled > > independently, but activating all of them at the same time tend to > > show other limitations like the limited memory bus or scaler > > bandwidth. > > > > This sort of bandwidth estimation is hard to get right, and we > > sometimes fail to predict that a specific workload will not pass, > > which will most likely result in underrun errors somewhere in the > > display pipeline (most of the time at the CRTC level). > > > > This path aims at making underrun error tracking generic and exposing > > underrun errors to userspace through a debugfs file. > > > > This way, CI tools like IGT, can try to enable a bunch of features and > > if such underrun errors are reported after the settings have been > > accepted and applied by the KMS infrastructure. When that happens it > > means the load tracking algorithm needs some tweaking/fixing. > > > > Signed-off-by: Boris Brezillon <boris.brezillon@xxxxxxxxxxx> > > --- > > Changes in v2: > > - New patch > > Hm, not what I thought off. This is definitely not going to be reusable > for i915, the only other driver with underrun reporting, since we have > tons of underrun sources (not just one). And we need to mask/unmask them > individually. I agree it's not perfect, but I did it this way so that hopefully we'll be able to use drm_atomic_helper_commit_tail() at some point instead of having our own implementation. If there's a way to add pre/post_commit() hooks (maybe they already exist?) at various levels of the display pipeline that get called even when the associated state has *not* changed, then I might be able to place my mask/unmask/clear operations there. I really need that to properly unmask the underrun interrupt, otherwise underruns might not be detected after the first modeset if nothing changed in sub-parts of the pipeline. > > It's also midlayer mistake, since you're stuff your callbacks into the > drm_mode_config_funcs core structure (which should only be used for uapi > interfaces, not helper stuff). Okay. > > What I had in mind is just a simple function which spews into dmesg (so > that i915 could use it) and increments the underrun counter in debugfs. > Everything else needs to be handled in drivers I think. E.g. > > drm_mode_config_report_underrun(struct drm_device *dev, > const char *source); > > and then rolling it out for i915 too (otherwise there's really no point in > the common infrastructure). Modifying the i915 driver was a bit premature since I didn't have your feedback on the general approach. And given your review, I'm glad I didn't start this conversion :-P. Anyway, I was not convinced having a generic infrastructure to report underrun errors was needed in the first place. The fact that these errors are very HW-specific, and that data attached to such events might be useful to understand what actually happened makes me think we don't really need this generic underrun reporting helper. Also note that IGT tests are likely to be HW specific too, because the workload needed to trigger underrun errors is likely to depend on the platform you're running on. And if you already have to write your own tests, I don't see clear benefit in exposing underrun errors generically. Anyway, this is just my opinion, and if you think we actually need the drm_mode_config_report_underrun() function, I'll implement it. Regards, Boris _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
