[PATCH v2 4/4] drm/vc4: Restrict active CTM to one CRTC
Daniel Stone
daniel at fooishbar.org
Mon Mar 26 03:52:50 PDT 2018
On 26 March 2018 at 09:29, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Sun, Mar 25, 2018 at 08:14:35PM +0200, Stefan Schake wrote:
>> On Sun, Mar 25, 2018 at 10:01 AM, Daniel Stone <daniel at fooishbar.org> wrote:
>> > On 25 March 2018 at 02:52, Stefan Schake <stschake at gmail.com> wrote:
>> >> +static int vc4_crtc_get_ctm_fifo(struct vc4_dev *vc4)
>> >> +{
>> >> + return VC4_GET_FIELD(HVS_READ(SCALER_OLEDOFFS),
>> >> + SCALER_OLEDOFFS_DISPFIFO);
>> >> +}
>> >
>> > This needs to be managed as a global resource through atomic state
>> > objects, rather than checking the current hardware state.
>>
>> Do you mean as a property or some such that is accessible to userland
>> or merely that this could be raced?
>>
>> I haven't had much luck finding examples for resources shared between CRTCs
>> in the current tree. My understanding here was that if userland commits
>> on CRTC B after a check-only on A, we are no longer bound by the earlier
>> result for the check-only. Otherwise, I would have to already commit my
>> CTM block to one CRTC at check (possibly check only) time.
>
> https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#handling-driver-private-state
>
> since you only have one CTM it's a shared resource which internally needs
> to be tracked as a driver private thing.
Indeed, the above is exactly what I meant. Checking based on the
hardware status will falsely succeed if you go from having zero CRTCs
using CTM, to multiple CRTCs using CTM, in a single atomic commit, as
the hardware status won't have changed in time.
Cheers,
Daniel
More information about the linux-rpi-kernel
mailing list