On 26 March 2018 at 09:29, Daniel Vetter <daniel@xxxxxxxx> 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@xxxxxxxxxxxxx> wrote:
>> > On 25 March 2018 at 02:52, Stefan Schake <stschake@xxxxxxxxx> 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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
