From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>,
"Konduru, Chandra" <chandra.konduru@intel.com>
Cc: "Intel-gfx@lists.freedesktop.org" <Intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/i915/skl: Bypass debug message if scalers are not requested
Date: Wed, 05 Aug 2015 14:20:17 +0100 [thread overview]
Message-ID: <55C20D91.5000907@linux.intel.com> (raw)
In-Reply-To: <20150504142936.GK30184@phenom.ffwll.local>
On 05/04/2015 03:29 PM, Daniel Vetter wrote:
> On Fri, Apr 24, 2015 at 06:07:05PM +0000, Konduru, Chandra wrote:
>>
>>
>>> -----Original Message-----
>>> From: Konduru, Chandra
>>> Sent: Friday, April 24, 2015 10:53 AM
>>> To: 'Tvrtko Ursulin'; Intel-gfx@lists.freedesktop.org
>>> Cc: Ursulin, Tvrtko
>>> Subject: RE: [PATCH] drm/i915/skl: Bypass debug message if scalers are not
>>> requested
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Tvrtko Ursulin [mailto:tvrtko.ursulin@linux.intel.com]
>>>> Sent: Friday, April 24, 2015 9:34 AM
>>>> To: Konduru, Chandra; Intel-gfx@lists.freedesktop.org
>>>> Cc: Ursulin, Tvrtko
>>>> Subject: Re: [PATCH] drm/i915/skl: Bypass debug message if scalers are
>>>> not requested
>>>>
>>>>
>>>> On 04/24/2015 05:30 PM, Konduru, Chandra wrote:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Tvrtko Ursulin [mailto:tvrtko.ursulin@linux.intel.com]
>>>>>> Sent: Friday, April 24, 2015 9:08 AM
>>>>>> To: Intel-gfx@lists.freedesktop.org
>>>>>> Cc: Ursulin, Tvrtko; Konduru, Chandra
>>>>>> Subject: [PATCH] drm/i915/skl: Bypass debug message if scalers are
>>>>>> not requested
>>>>>>
>>>>>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>>>>
>>>>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>>>> Cc: Chandra Konduru <chandra.konduru@intel.com>
>>>>>> ---
>>>>>> Up for discussion I suppose, but like it is, with typical drm.debug
>>>>>> = 0xe, it logs one line per cursor movement while the log would
>>>>>> otherwise be
>>>> quiet.
>>>>>> ---
>>>>>> drivers/gpu/drm/i915/intel_atomic.c | 3 +++
>>>>>> 1 file changed, 3 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
>>>>>> b/drivers/gpu/drm/i915/intel_atomic.c
>>>>>> index 3c4b7cd..7284c6d 100644
>>>>>> --- a/drivers/gpu/drm/i915/intel_atomic.c
>>>>>> +++ b/drivers/gpu/drm/i915/intel_atomic.c
>>>>>> @@ -302,6 +302,9 @@ int intel_atomic_setup_scalers(struct
>>>>>> drm_device
>>>> *dev,
>>>>>> scaler_state = &crtc_state->scaler_state;
>>>>>> drm_state = crtc_state->base.state;
>>>>>>
>>>>>> + if (!scaler_state->scaler_users)
>>>>>> + return 0;
>>>>>
>>>>> This will cause issue because scalers will never get freed if they
>>>>> are in use
>>>> before and no more required now.
>>>>> I put the debug print to help debug variety of state related issues
>>>>> while we are in development, but perhaps debug print can be deleted.
>>>>
>>>> Doesn't the loop below skip everything anyway when no bits are set in
>>>> scaler_state->scaler_users ?
>>> Oh, that's right, ignore my prev comment (with updated scaler design above
>>> shouldn't cause issues).
>>> By the way, can you pls run kms_panel_fit and kms_plane_scaling to make sure
>>> they pass and there are no related warnings or errors in kernel log?
>>> For kms_plane_scaling, pls apply two pending patches that aren't merged:
>>> v5 [PATCH 13/14] drm/i915: skylake primary plane scaling using shared scalers
>>> v5 [PATCH 14/14] drm/i915: skylake sprite plane scaling using shared scalers
>>>
>> One more: This change address logs when no scaler is required,
>> but might comeback when a scaler is active (panel fitting or plane scaling is enabled).
>> I don't know general policy in these kind of situations, but perhaps debug print
>> can be deleted.
>
> 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...
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-08-05 13:20 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-24 16:08 [PATCH] drm/i915/skl: Bypass debug message if scalers are not requested Tvrtko Ursulin
2015-04-24 16:30 ` Konduru, Chandra
2015-04-24 16:33 ` Tvrtko Ursulin
2015-04-24 17:52 ` Konduru, Chandra
2015-04-24 18:07 ` Konduru, Chandra
2015-05-04 14:29 ` Daniel Vetter
2015-08-05 13:20 ` Tvrtko Ursulin [this message]
2015-08-05 13:58 ` Daniel Vetter
2015-08-05 14:12 ` Tvrtko Ursulin
2015-08-05 14:19 ` Tvrtko Ursulin
2015-08-05 15:02 ` Tvrtko Ursulin
2015-04-28 8:24 ` shuang.he
-- strict thread matches above, loose matches on Subject: below --
2015-08-05 14:14 Tvrtko Ursulin
2015-08-12 5:49 ` shuang.he
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55C20D91.5000907@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=Intel-gfx@lists.freedesktop.org \
--cc=chandra.konduru@intel.com \
--cc=daniel@ffwll.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.