linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: shawnguo@kernel.org (Shawn Guo)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 3/3] drm: zte: add overlay plane support
Date: Mon, 9 Jan 2017 22:23:46 +0800	[thread overview]
Message-ID: <20170109142345.GN20956@dragon> (raw)
In-Reply-To: <CAOw6vbLz0ueNsXXPuDtrHkL_Mac5w_jjD9nVUzy+9zbaR-iBmg@mail.gmail.com>

On Thu, Jan 05, 2017 at 02:26:30AM -0500, Sean Paul wrote:
> > +static u32 zx_vl_get_fmt(uint32_t format)
> > +{
> > +       u32 val = 0;
> > +
> > +       switch (format) {
> > +       case DRM_FORMAT_NV12:
> > +               val = VL_FMT_YUV420;
> > +               break;
> > +       case DRM_FORMAT_YUV420:
> > +               val = VL_YUV420_PLANAR | VL_FMT_YUV420;
> > +               break;
> > +       case DRM_FORMAT_YUYV:
> > +               val = VL_YUV422_YUYV | VL_FMT_YUV422;
> > +               break;
> > +       case DRM_FORMAT_YVYU:
> > +               val = VL_YUV422_YVYU | VL_FMT_YUV422;
> > +               break;
> > +       case DRM_FORMAT_UYVY:
> > +               val = VL_YUV422_UYVY | VL_FMT_YUV422;
> > +               break;
> > +       case DRM_FORMAT_VYUY:
> > +               val = VL_YUV422_VYUY | VL_FMT_YUV422;
> > +               break;
> > +       case DRM_FORMAT_YUV444:
> > +               val = VL_FMT_YUV444_8BIT;
> 
> Minor nit: You could have eliminated val and just returned directly
> from all of the cases. Seems like there are a few other functions this
> is also true for.

Okay.  I will change zx_vl_get_fmt() and zx_vl_rsz_get_fmt()
accordingly.

> 
> > +               break;
> > +       default:
> > +               WARN_ONCE(1, "invalid pixel format %d\n", format);
> > +       }
> > +
> > +       return val;
> > +}

<snip>

> > +static void zx_vl_rsz_setup(struct zx_plane *zplane, uint32_t format,
> > +                           u32 src_w, u32 src_h, u32 dst_w, u32 dst_h)
> > +{
> > +       void __iomem *rsz = zplane->rsz;
> > +       u32 src_chroma_w = src_w;
> > +       u32 src_chroma_h = src_h;
> > +       u32 fmt;
> > +
> > +       /* Set up source and destination resolution */
> > +       zx_writel(rsz + RSZ_SRC_CFG, RSZ_VER(src_h - 1) | RSZ_HOR(src_w - 1));
> > +       zx_writel(rsz + RSZ_DEST_CFG, RSZ_VER(dst_h - 1) | RSZ_HOR(dst_w - 1));
> > +
> > +       /* Configure data format for VL RSZ */
> > +       fmt = zx_vl_rsz_get_fmt(format);
> > +       zx_writel_mask(rsz + RSZ_VL_CTRL_CFG, RSZ_VL_FMT_MASK, fmt);
> > +
> > +       /* Calculate Chroma heigth and width */
> 
> s/heigth/height/

Thanks for spotting it.

> 
> > +       if (fmt == RSZ_VL_FMT_YCBCR420) {
> > +               src_chroma_w = src_w >> 1;
> > +               src_chroma_h = src_h >> 1;
> > +       } else if (fmt == RSZ_VL_FMT_YCBCR422) {
> > +               src_chroma_w = src_w >> 1;
> > +       }
> > +
> > +       /* Set up Luma and Chroma step registers */
> > +       zx_writel(rsz + RSZ_VL_LUMA_HOR, rsz_step_value(src_w, dst_w));
> > +       zx_writel(rsz + RSZ_VL_LUMA_VER, rsz_step_value(src_h, dst_h));
> > +       zx_writel(rsz + RSZ_VL_CHROMA_HOR, rsz_step_value(src_chroma_w, dst_w));
> > +       zx_writel(rsz + RSZ_VL_CHROMA_VER, rsz_step_value(src_chroma_h, dst_h));
> > +
> > +       zx_vl_rsz_set_update(zplane);
> > +}

<snip>

> > diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.c
> > index 3fb4fc04e693..e832c2ec3156 100644
> > --- a/drivers/gpu/drm/zte/zx_vou.c
> > +++ b/drivers/gpu/drm/zte/zx_vou.c
> > @@ -84,6 +84,8 @@ struct zx_crtc_bits {
> >  struct zx_crtc {
> >         struct drm_crtc crtc;
> >         struct drm_plane *primary;
> > +       struct drm_plane *overlay_active[VL_NUM];
> > +       unsigned int overlay_active_num;
> 
> I don't think this belongs here. You can instead add an active (or
> enabled) bool to the zx_plane struct and keep track of it via
> atomic_plane_update/disable. This allows you to call
> zx_plane_set_update unconditionally in the vou irq handler and check
> active/enabled in zx_plane_set_update.

It's a truly great suggestion.  How did I not think of it :)  The v4 is
coming for that.

Thanks a lot for the review effort, Sean.

Shawn

      reply	other threads:[~2017-01-09 14:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-29  2:37 [PATCH v3 0/3] Add overlay plane support for ZTE drm driver Shawn Guo
2016-12-29  2:37 ` [PATCH v3 1/3] drm: zte: make zx_plane accessible from zx_vou driver Shawn Guo
2017-01-05  7:26   ` Sean Paul
2016-12-29  2:37 ` [PATCH v3 2/3] drm: zte: add .atomic_disable hook to disable graphic layer Shawn Guo
2017-01-05  7:26   ` Sean Paul
2016-12-29  2:37 ` [PATCH v3 3/3] drm: zte: add overlay plane support Shawn Guo
2017-01-05  7:26   ` Sean Paul
2017-01-09 14:23     ` Shawn Guo [this message]

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=20170109142345.GN20956@dragon \
    --to=shawnguo@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.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).