From: Daniel Vetter <daniel@ffwll.ch>
To: Stefan Schake <stschake@gmail.com>
Cc: David Airlie <airlied@linux.ie>,
dri-devel <dri-devel@lists.freedesktop.org>,
linux-rpi-kernel@lists.infradead.org
Subject: Re: [PATCH v2 4/4] drm/vc4: Restrict active CTM to one CRTC
Date: Mon, 26 Mar 2018 10:29:19 +0200 [thread overview]
Message-ID: <20180326082919.GR14155@phenom.ffwll.local> (raw)
In-Reply-To: <CAOZHkRy65yJ=_uvjVsW8fsWvaPxH6hVs+MytTq98SRhaRaVXhw@mail.gmail.com>
On Sun, Mar 25, 2018 at 08:14:35PM +0200, Stefan Schake wrote:
> Hey Daniel,
>
> On Sun, Mar 25, 2018 at 10:01 AM, Daniel Stone <daniel@fooishbar.org> wrote:
> > Hi Stefan,
> >
> > On 25 March 2018 at 02:52, Stefan Schake <stschake@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.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-03-26 8:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-25 1:52 [PATCH v2 0/4] drm/vc4: Atomic color management support Stefan Schake
2018-03-25 1:52 ` [PATCH v2 1/4] drm/vc4: Add some missing HVS register definitions Stefan Schake
2018-03-25 1:52 ` [PATCH v2 1/3] drm/vc4: Expose gamma as atomic property Stefan Schake
2018-03-30 16:05 ` Eric Anholt
2018-03-25 1:52 ` [PATCH v2 3/4] drm/vc4: Add color transformation matrix (CTM) support Stefan Schake
2018-03-30 16:11 ` Eric Anholt
2018-03-25 1:52 ` [PATCH v2 4/4] drm/vc4: Restrict active CTM to one CRTC Stefan Schake
2018-03-25 8:01 ` Daniel Stone
2018-03-25 18:14 ` Stefan Schake
2018-03-26 8:29 ` Daniel Vetter [this message]
2018-03-26 10:52 ` Daniel Stone
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=20180326082919.GR14155@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=stschake@gmail.com \
/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.