devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Emil Velikov <emil.l.velikov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	devicetree <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Daniel Vetter <daniel.vetter-/w4YWyX8dFk@public.gmane.org>,
	Baoyou Xie <xie.baoyou-Th6q7B73Y6EnDS1+zs4M5A@public.gmane.org>,
	ML dri-devel
	<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Jun Nie <jun.nie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	LAKML
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH v2 2/2] drm: zte: add initial vou drm driver
Date: Fri, 30 Sep 2016 17:22:31 -0700	[thread overview]
Message-ID: <20161001002228.GA2989@x250> (raw)
In-Reply-To: <CACvgo51feNJYrHaKT+M06Z7kOUqzYo1Uv_TAHdLhNXPtRUwsvw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Hi Emil,

On Fri, Sep 30, 2016 at 01:34:14PM +0100, Emil Velikov wrote:
> Hi Shawn,
> 
> A couple of fly-by suggestions, which I hope you'll find useful :-)

Thanks for the suggestions.

> On 24 September 2016 at 15:26, Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> 
> > +
>  > +       val = ((vm.hsync_len - 1) << SYNC_WIDE_SHIFT) & SYNC_WIDE_MASK;
> To save some writing/minimise the chances to typos getting, in you can
> have single/collection to static inline functions similar to msm [1].
> On a similar note inline wrappers zte_read/write/mask (around
> writel/readl) will provide quite useful for debugging/tracing :-)
> 
> [1] drivers/gpu/drm/msm/adreno/a4xx.xml.h

I would not add a header file with hundreds or thousands of defines
while only tens of them are actually used.  For debugging, I prefer
to print particular registers than every single read/write, which
might not be easy to check what I want to check.

> > +       if (IS_ERR(zcrtc->pixclk))
> > +               return ERR_PTR(PTR_ERR(zcrtc->pixclk));
> You might want to s/ERR_PTR(PTR_ERR// or s/ERR_PTR(PTR_ERR/ERR_CAST/
> through the patch.

Aha, yes.

> > +static int zx_drm_bind(struct device *dev)
> > +{
> > +       struct drm_device *drm;
> > +       struct zx_drm_private *priv;
> > +       int ret;
> > +
> > +       priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > +       if (!priv)
> > +               return -ENOMEM;
> > +
> > +       drm = drm_dev_alloc(&zx_drm_driver, dev);
> > +       if (!drm)
> > +               return -ENOMEM;
> > +
> > +       drm->dev_private = priv;
> > +       dev_set_drvdata(dev, drm);
> > +
> > +       drm_mode_config_init(drm);
> > +       drm->mode_config.min_width = 16;
> > +       drm->mode_config.min_height = 16;
> > +       drm->mode_config.max_width = 4096;
> > +       drm->mode_config.max_height = 4096;
> > +       drm->mode_config.funcs = &zx_drm_mode_config_funcs;
> > +
> > +       ret = drm_dev_register(drm, 0);
> The documentation states that drm_dev_register() should be called
> after the hardware is setup. which some drivers seems to interpret as
> ...
> 
> > +       if (ret)
> > +               goto out_free;
> > +
> > +       ret = component_bind_all(dev, drm);
> > +       if (ret) {
> > +               DRM_ERROR("Failed to bind all components\n");
> > +               goto out_unregister;
> > +       }
> > +
> > +       ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
> > +       if (ret < 0) {
> > +               DRM_ERROR("failed to initialise vblank\n");
> > +               goto out_unbind;
> > +       }
> > +
> > +       /*
> > +        * We will manage irq handler on our own.  In this case, irq_enabled
> > +        * need to be true for using vblank core support.
> > +        */
> > +       drm->irq_enabled = true;
> > +
> > +       drm_mode_config_reset(drm);
> > +       drm_kms_helper_poll_init(drm);
> > +
> > +       priv->fbdev = drm_fbdev_cma_init(drm, 32, drm->mode_config.num_crtc,
> > +                                        drm->mode_config.num_connector);
> ... calling it after these. If that's the correct case - perhaps we
> can throw a WARN or similar within the above functions to catch
> present/future misuse ?

Yes.  Daniel also pointed it out in his review of the patch.

> > +       if (IS_ERR(priv->fbdev)) {
> > +               ret = PTR_ERR(priv->fbdev);
> > +               priv->fbdev = NULL;
> > +               goto out_fini;
> > +       }
> > +
> > +       return 0;
> > +
> > +out_fini:
> > +       drm_kms_helper_poll_fini(drm);
> > +       drm_mode_config_cleanup(drm);
> > +       drm_vblank_cleanup(drm);
> > +out_unbind:
> > +       component_unbind_all(dev, drm);
> > +out_unregister:
> > +       drm_dev_unregister(drm);
> > +out_free:
> > +       dev_set_drvdata(dev, NULL);
> > +       drm_dev_unref(drm);
> > +       return ret;
> > +}
> > +
> > +static void zx_drm_unbind(struct device *dev)
> > +{
> > +       struct drm_device *drm = dev_get_drvdata(dev);
> > +       struct zx_drm_private *priv = drm->dev_private;
> > +
> > +       if (priv->fbdev) {
> > +               drm_fbdev_cma_fini(priv->fbdev);
> > +               priv->fbdev = NULL;
> > +       }
> > +       drm_kms_helper_poll_fini(drm);
> > +       component_unbind_all(dev, drm);
> > +       drm_vblank_cleanup(drm);
> > +       drm_mode_config_cleanup(drm);
> > +       drm_dev_unregister(drm);
> > +       drm_dev_unref(drm);
> > +       drm->dev_private = NULL;
> > +       dev_set_drvdata(dev, NULL);
> This and the teardown path in bind() are asymmetrical. Furthermore you
> want to call drm_dev_unregister() first, according to its
> documentation.
> As mentioned above - perhaps it's worth providing feedback for drivers
> which get the order wrong ?
> 
> 
> 
> > +static int zx_hdmi_bind(struct device *dev, struct device *master, void *data)
> > +{
> 
> 
> > +
> > +       clk_prepare_enable(hdmi->cec_clk);
> > +       clk_prepare_enable(hdmi->osc_clk);
> > +       clk_prepare_enable(hdmi->xclk);
> > +
> > +       ret = zx_hdmi_register(drm, hdmi);
> > +       if (ret)
> > +               return ret;
> > +
> 
> > +       return 0;
> > +}
> > +
> > +static void zx_hdmi_unbind(struct device *dev, struct device *master,
> > +                          void *data)
> > +{
> > +       struct zx_hdmi *hdmi = dev_get_drvdata(dev);
> > +
> > +       clk_disable_unprepare(hdmi->cec_clk);
> > +       clk_disable_unprepare(hdmi->osc_clk);
> > +       clk_disable_unprepare(hdmi->xclk);
> Nit: you want the teardown to happen in reverse order of the setup. I
> might have missed a few similar cases within the patch, so please
> double-check.

Okay, I will give it a check through the patch.

> > +static int zx_gl_get_fmt(uint32_t format)
> > +{
> > +       switch (format) {
> > +       case DRM_FORMAT_ARGB8888:
> > +       case DRM_FORMAT_XRGB8888:
> > +               return GL_FMT_ARGB8888;
> > +       case DRM_FORMAT_RGB888:
> > +               return GL_FMT_RGB888;
> > +       case DRM_FORMAT_RGB565:
> > +               return GL_FMT_RGB565;
> > +       case DRM_FORMAT_ARGB1555:
> > +               return GL_FMT_ARGB1555;
> > +       case DRM_FORMAT_ARGB4444:
> > +               return GL_FMT_ARGB4444;
> > +       default:
> > +               WARN_ONCE(1, "invalid pixel format %d\n", format);
> > +               return -EINVAL;
> Afaics the only user of this is atomic_update() and that function
> cannot fail. You might want to move this to the _check() function.
> Same logic goes for the rest of the driver, in case I've missed any.

The function does the conversion from DRM format values to the ones that
hardware accepts.  And I need to set up hardware register with the
converted value.

I suppose that the error case in 'default' should never be hit, since
all valid format have been reported to DRM core by gl_formats?  In that
case, I can simply drop the WARN and return a sane default format
instead?

Shawn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2016-10-01  0:22 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-24 14:26 [PATCH v2 0/2] Add initial ZTE VOU DRM/KMS driver Shawn Guo
2016-09-24 14:26 ` [PATCH v2 1/2] dt-bindings: add bindings doc for ZTE VOU display controller Shawn Guo
     [not found]   ` <1474727185-24180-2-git-send-email-shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-10-03 17:44     ` Rob Herring
2016-10-09  7:49       ` Shawn Guo
2016-10-10 21:48         ` Rob Herring
2016-09-24 14:26 ` [PATCH v2 2/2] drm: zte: add initial vou drm driver Shawn Guo
2016-09-25 20:58   ` Daniel Vetter
     [not found]     ` <20160925205809.GR20761-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2016-09-29 23:42       ` Shawn Guo
2016-09-27 15:48   ` Sean Paul
2016-09-30  1:43     ` Shawn Guo
     [not found]   ` <1474727185-24180-3-git-send-email-shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-09-30 12:34     ` Emil Velikov
     [not found]       ` <CACvgo51feNJYrHaKT+M06Z7kOUqzYo1Uv_TAHdLhNXPtRUwsvw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-10-01  0:22         ` Shawn Guo [this message]
2016-10-03 10:36           ` Emil Velikov
     [not found]             ` <CACvgo53A7BpVWHgkFrZsjWnw_uW6xDmKRsrxF=46HOEWQ43BxA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-10-03 13:49               ` Daniel Vetter

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=20161001002228.GA2989@x250 \
    --to=shawnguo-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
    --cc=daniel.vetter-/w4YWyX8dFk@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=emil.l.velikov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=jun.nie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
    --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=xie.baoyou-Th6q7B73Y6EnDS1+zs4M5A@public.gmane.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).