Re: [PATCH] drm/i915/skl: Bypass debug message if scalers are not requested

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

 





On 08/05/2015 03:19 PM, Tvrtko Ursulin wrote:
[snip]
Atomic is really complicated, but doing fully diagnostics for each
frame
is also way too noisy. For that reason we've add a DRM_DEBUG_ATOMIC
which
can be used for all these state tracking debug lines.

We didn't do anything here and I just noticed kernel is still too
spammy
with regards to this issue.

Should we just merge my patch? Still looks completely safe to me...

doesn't seem to apply any more:(

Yeah only some months have passed, who would have thought. :)

But I realized that would be only one of the three log lines per cursor
update - there is a code path calling skl_detach_scaler two times as
well. Looks like this overall, per update:

[drm:intel_atomic_setup_scalers] crtc_state = ffff880074b55c00 need = 0
avail = 2 scaler_users = 0x0
[drm:skl_detach_scaler] CRTC:21 Disabled scaler id 0.0
[drm:skl_detach_scaler] CRTC:21 Disabled scaler id 0.1

I'll rebase this patch for a start.

Sent it as a new thread but forgot v2 in the subject.

Other source of spam is probably intel_begin_crtc_commit ->
skl_detach_scalers.

Don't know what the right fix would be there. Looks like it is not
tracking transitions in scaler use so it would be able to act and log
when something interesting happens, but rather does it every time. I
defer to Chandra. :)

Ok I've sent something named "[PATCH] drm/i915/skl: Only disable scalers once".

It was only compile tested due my current lack of suitable hardware for testing. And I don't pretend to be confident in the world of atomic states etc. so it may well be completely wrong.

So either scrutinize it a lot please, or let it be a motivator to come up with a proper fix of your own. :)

Regards,

Tvrtko
_______________________________________________
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