From: Ezequiel Garcia <ezequiel@collabora.com>
To: Doug Anderson <dianders@chromium.org>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
"open list:ARM/Rockchip SoC..."
<linux-rockchip@lists.infradead.org>,
"Heiko Stübner" <heiko@sntech.de>,
"Sandy Huang" <hjc@rock-chips.com>,
kernel@collabora.com, "Sean Paul" <seanpaul@chromium.org>,
"Boris Brezillon" <boris.brezillon@collabora.com>,
"Jacopo Mondi" <jacopo@jmondi.org>,
"Ilia Mirkin" <imirkin@alum.mit.edu>,
"Rob Herring" <robh+dt@kernel.org>,
"Mark Rutland" <mark.rutland@arm.com>,
devicetree@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/3] drm/rockchip: Add optional support for CRTC gamma LUT
Date: Fri, 21 Jun 2019 12:52:51 -0300 [thread overview]
Message-ID: <33068f355edfaabb1c60d5e16a219a058a489531.camel@collabora.com> (raw)
In-Reply-To: <CAD=FV=XoKNA4aW2LT7g8K2t+ABwgt=QJGAyiet1-Gyz3CgWmvg@mail.gmail.com>
On Thu, 2019-06-20 at 10:25 -0700, Doug Anderson wrote:
> Hi,
>
> On Tue, Jun 18, 2019 at 2:43 PM Ezequiel Garcia <ezequiel@collabora.com> wrote:
> > +static void vop_crtc_gamma_set(struct vop *vop, struct drm_crtc *crtc,
> > + struct drm_crtc_state *old_state)
> > +{
> > + int idle, ret, i;
> > +
> > + spin_lock(&vop->reg_lock);
> > + VOP_REG_SET(vop, common, dsp_lut_en, 0);
> > + vop_cfg_done(vop);
> > + spin_unlock(&vop->reg_lock);
> > +
> > + ret = readx_poll_timeout(vop_dsp_lut_is_enable, vop,
> > + idle, !idle, 5, 30 * 1000);
> > + if (ret)
>
> Worth an error message?
>
Sure.
>
> > @@ -1205,6 +1294,7 @@ static void vop_crtc_atomic_flush(struct drm_crtc *crtc,
> >
> > static const struct drm_crtc_helper_funcs vop_crtc_helper_funcs = {
> > .mode_fixup = vop_crtc_mode_fixup,
> > + .atomic_check = vop_crtc_atomic_check,
>
> At first I was worried that there was a bug here since in the context
> of dw_hdmi (an encoder) adding ".atomic_check" caused ".mode_fixup" to
> stop getting called as per mode_fixup() in
> "drivers/gpu/drm/drm_atomic_helper.c".
>
> ...but it seems like it's OK for CRTCs, so I think we're fine.
>
>
> > @@ -1323,6 +1413,7 @@ static const struct drm_crtc_funcs vop_crtc_funcs = {
> > .disable_vblank = vop_crtc_disable_vblank,
> > .set_crc_source = vop_crtc_set_crc_source,
> > .verify_crc_source = vop_crtc_verify_crc_source,
> > + .gamma_set = drm_atomic_helper_legacy_gamma_set,
>
> Are there any issues in adding this ".gamma_set" property even though
> we may or may not actually have the ability to set the gamma
> (depending on whether or not the LUT register range was provided in
> the device tree)? I am a DRM noob but
> drm_atomic_helper_legacy_gamma_set() is not a trivial little function
> and now we'll be running it in some cases where we don't actually have
> gamma.
>
> I also notice that there's at least one bit of code that seems to
> check if ".gamma_set" is NULL. ...and if it is, it'll return -ENOSYS
> right away. Do we still properly return -ENOSYS on devices that don't
> have the register range?
>
> It seems like the absolute safest would be to have two copies of this
> struct: one used for VOPs that have the range and one for VOPs that
> don't.
>
> ...but possibly I'm just paranoid and as I've said I'm a clueless
> noob. If someone says it's fine to always provide the .gamma_set
> property that's fine too.
>
Provided we do the suggestion below (setting gamma_size and enabling
color management) when lut_regs is set, then I think we are fine.
Before this change:
* GAMMA_LUT property doesn't exist, and so can't be set.
* DRM_IOCTL_MODE_SETGAMMA (legacy) return ENOSYS.
After this change, on platforms that doesn't support this:
* GAMMA_LUT property doesn't exist, and so can't be set.
* DRM_IOCTL_MODE_SETGAMMA (legacy) return EINVAL.
The only difference is the ENOSYS/EINVAL errno, which I doubt
will regress anything.
I don't think this difference deserves assigning (the legacy)
.gamma_set hook conditionally, which would make the
implementation too ugly.
>
> > static void vop_fb_unref_worker(struct drm_flip_work *work, void *val)
> > @@ -1480,6 +1571,10 @@ static int vop_create_crtc(struct vop *vop)
> > goto err_cleanup_planes;
> >
> > drm_crtc_helper_add(crtc, &vop_crtc_helper_funcs);
> > + if (vop_data->lut_size) {
> > + drm_mode_crtc_set_gamma_size(crtc, vop_data->lut_size);
> > + drm_crtc_enable_color_mgmt(crtc, 0, false, vop_data->lut_size);
>
> Should we only do the above calls if we successfully mapped the resources?
>
Yes, totally. See above.
>
> > @@ -1776,6 +1871,17 @@ static int vop_bind(struct device *dev, struct device *master, void *data)
> > if (IS_ERR(vop->regs))
> > return PTR_ERR(vop->regs);
> >
> > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "lut");
>
> As per comments in the bindings, shouldn't use the name "lut" but
> should just pick resource #1.
Yes.
Thanks a lot for the review,
Ezequiel
next prev parent reply other threads:[~2019-06-21 15:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-18 21:34 [PATCH 0/3] RK3288 Gamma LUT Ezequiel Garcia
2019-06-18 21:34 ` [PATCH 1/3] dt-bindings: display: rockchip: document VOP gamma LUT address Ezequiel Garcia
2019-06-20 16:43 ` Doug Anderson
2019-06-20 16:56 ` Ezequiel Garcia
2019-06-18 21:34 ` [PATCH 2/3] drm/rockchip: Add optional support for CRTC gamma LUT Ezequiel Garcia
2019-06-18 21:47 ` Ilia Mirkin
2019-06-18 22:09 ` Ezequiel Garcia
2019-06-18 22:18 ` Heiko Stübner
2019-06-20 16:02 ` Ezequiel Garcia
2019-06-20 17:25 ` Doug Anderson
2019-06-21 15:52 ` Ezequiel Garcia [this message]
2019-06-21 8:22 ` Jacopo Mondi
2019-06-21 15:59 ` Ezequiel Garcia
2019-06-18 21:34 ` [PATCH 3/3] ARM: dts: rockchip: Add RK3288 VOP gamma LUT address Ezequiel Garcia
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=33068f355edfaabb1c60d5e16a219a058a489531.camel@collabora.com \
--to=ezequiel@collabora.com \
--cc=boris.brezillon@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=heiko@sntech.de \
--cc=hjc@rock-chips.com \
--cc=imirkin@alum.mit.edu \
--cc=jacopo@jmondi.org \
--cc=kernel@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=seanpaul@chromium.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).