From: Heiko Stuebner <heiko@sntech.de>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: thierry.reding@gmail.com, mark.rutland@arm.com,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, robh+dt@kernel.org,
christoph.muellner@theobroma-systems.com
Subject: Re: [PATCH 3/3] drm/panel: add panel driver for Xinpeng XPP055C272 panels
Date: Sun, 15 Dec 2019 10:13:29 +0100 [thread overview]
Message-ID: <1744285.zQlJhejOUX@phil> (raw)
In-Reply-To: <20191215082916.GA25772@ravnborg.org>
Hi Sam,
Am Sonntag, 15. Dezember 2019, 09:29:16 CET schrieb Sam Ravnborg:
> Hi Heiko.
>
> > Am Samstag, 14. Dezember 2019, 09:17:30 CET schrieb Sam Ravnborg:
> > > > +#define dsi_generic_write_seq(dsi, cmd, seq...) do { \
> > > > + static const u8 d[] = { seq }; \
> > > > + int ret; \
> > > > + ret = mipi_dsi_dcs_write(dsi, cmd, d, ARRAY_SIZE(d)); \
> > > > + if (ret < 0) \
> > > > + return ret; \
> > > > + } while (0)
> > > This macro return an error code if a write fails.
> > >
> > > > +
> > > > +static int xpp055c272_init_sequence(struct xpp055c272 *ctx)
> > > > +{
> > > > + struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> > > > + struct device *dev = ctx->dev;
> > > > + int ret;
> > > > +
> > > > + /*
> > > > + * Init sequence was supplied by the panel vendor without much
> > > > + * documentation.
> > > > + */
> > > > + dsi_generic_write_seq(dsi, XPP055C272_CMD_SETEXTC, 0xf1, 0x12, 0x83);
> > > But all uses of the macro here ignore the error.
> >
> > hmm, am I way off track here?
> >
> > dsi_generic_write_seq(dsi, XPP055C272_CMD_SETEXTC, 0xf1, 0x12, 0x83);
> > dsi_generic_write_seq(dsi, XPP055C272_CMD_SETMIPI,
> > 0x33, 0x81, 0x05, 0xf9, 0x0e, 0x0e, 0x00, 0x00,
> > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x44, 0x25,
> > 0x00, 0x91, 0x0a, 0x00, 0x00, 0x02, 0x4f, 0x01,
> > 0x00, 0x00, 0x37);
> > ...
> >
> > should just expand to
> >
> > do {
> > static const u8 d[] = { 0xf1, 0x12, 0x83 };
> > int ret;
> > ret = mipi_dsi_dcs_write(dsi, XPP055C272_CMD_SETEXTC, d, ARRAY_SIZE(d));
> > if (ret < 0)
> > return ret;
> > } while (0)
> > do {
> > static const u8 d[] = { 0x33, 0x81, 0x05, 0xf9, 0x0e, 0x0e, 0x00, 0x00,
> > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x44, 0x25,
> > 0x00, 0x91, 0x0a, 0x00, 0x00, 0x02, 0x4f, 0x01,
> > 0x00, 0x00, 0x37 };
> > int ret;
> > ret = mipi_dsi_dcs_write(dsi, XPP055C272_CMD_SETMIPI, d, ARRAY_SIZE(d));
> > if (ret < 0)
> > return ret;
> > } while (0)
> > ...
> >
> > so every write instance will actually return an error if it happens and not
> > continue on with the next init item.
> The idea was that if a write returned an error then do not even attempt
> more writes. So if a write fails we do not loose the original error
> code, assuming subsequent write would also fail.
Shouldn't the code above do exactly that? ... Because it's like
ret = dcs_write(...)
if (ret <0)
return ret;
So if any of the dcs_writes goes wrong it should just return the
error code from that write from the function and not try any more
writes. (or I'm blind and do not see something ;-) )
Heiko
> I have looked through all the panel drivers now, and the majority does
> not check if the write goes wrong.
> So following the pattern on the other panels you can also decide to just
> ignore the return value of mipi_dsi_dcs_write() rahter than trying to
> invent the check I tried to explain.
>
> Sam
>
WARNING: multiple messages have this Message-ID (diff)
From: Heiko Stuebner <heiko@sntech.de>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
robh+dt@kernel.org, thierry.reding@gmail.com,
christoph.muellner@theobroma-systems.com
Subject: Re: [PATCH 3/3] drm/panel: add panel driver for Xinpeng XPP055C272 panels
Date: Sun, 15 Dec 2019 10:13:29 +0100 [thread overview]
Message-ID: <1744285.zQlJhejOUX@phil> (raw)
In-Reply-To: <20191215082916.GA25772@ravnborg.org>
Hi Sam,
Am Sonntag, 15. Dezember 2019, 09:29:16 CET schrieb Sam Ravnborg:
> Hi Heiko.
>
> > Am Samstag, 14. Dezember 2019, 09:17:30 CET schrieb Sam Ravnborg:
> > > > +#define dsi_generic_write_seq(dsi, cmd, seq...) do { \
> > > > + static const u8 d[] = { seq }; \
> > > > + int ret; \
> > > > + ret = mipi_dsi_dcs_write(dsi, cmd, d, ARRAY_SIZE(d)); \
> > > > + if (ret < 0) \
> > > > + return ret; \
> > > > + } while (0)
> > > This macro return an error code if a write fails.
> > >
> > > > +
> > > > +static int xpp055c272_init_sequence(struct xpp055c272 *ctx)
> > > > +{
> > > > + struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> > > > + struct device *dev = ctx->dev;
> > > > + int ret;
> > > > +
> > > > + /*
> > > > + * Init sequence was supplied by the panel vendor without much
> > > > + * documentation.
> > > > + */
> > > > + dsi_generic_write_seq(dsi, XPP055C272_CMD_SETEXTC, 0xf1, 0x12, 0x83);
> > > But all uses of the macro here ignore the error.
> >
> > hmm, am I way off track here?
> >
> > dsi_generic_write_seq(dsi, XPP055C272_CMD_SETEXTC, 0xf1, 0x12, 0x83);
> > dsi_generic_write_seq(dsi, XPP055C272_CMD_SETMIPI,
> > 0x33, 0x81, 0x05, 0xf9, 0x0e, 0x0e, 0x00, 0x00,
> > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x44, 0x25,
> > 0x00, 0x91, 0x0a, 0x00, 0x00, 0x02, 0x4f, 0x01,
> > 0x00, 0x00, 0x37);
> > ...
> >
> > should just expand to
> >
> > do {
> > static const u8 d[] = { 0xf1, 0x12, 0x83 };
> > int ret;
> > ret = mipi_dsi_dcs_write(dsi, XPP055C272_CMD_SETEXTC, d, ARRAY_SIZE(d));
> > if (ret < 0)
> > return ret;
> > } while (0)
> > do {
> > static const u8 d[] = { 0x33, 0x81, 0x05, 0xf9, 0x0e, 0x0e, 0x00, 0x00,
> > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x44, 0x25,
> > 0x00, 0x91, 0x0a, 0x00, 0x00, 0x02, 0x4f, 0x01,
> > 0x00, 0x00, 0x37 };
> > int ret;
> > ret = mipi_dsi_dcs_write(dsi, XPP055C272_CMD_SETMIPI, d, ARRAY_SIZE(d));
> > if (ret < 0)
> > return ret;
> > } while (0)
> > ...
> >
> > so every write instance will actually return an error if it happens and not
> > continue on with the next init item.
> The idea was that if a write returned an error then do not even attempt
> more writes. So if a write fails we do not loose the original error
> code, assuming subsequent write would also fail.
Shouldn't the code above do exactly that? ... Because it's like
ret = dcs_write(...)
if (ret <0)
return ret;
So if any of the dcs_writes goes wrong it should just return the
error code from that write from the function and not try any more
writes. (or I'm blind and do not see something ;-) )
Heiko
> I have looked through all the panel drivers now, and the majority does
> not check if the write goes wrong.
> So following the pattern on the other panels you can also decide to just
> ignore the return value of mipi_dsi_dcs_write() rahter than trying to
> invent the check I tried to explain.
>
> Sam
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-12-15 9:13 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-09 14:42 [PATCH 1/3] dt-bindings: Add vendor prefix for Xinpeng Technology Heiko Stuebner
2019-12-09 14:42 ` Heiko Stuebner
2019-12-09 14:42 ` [PATCH 2/3] dt-bindings: display: panel: Add binding document for Xinpeng XPP055C272 Heiko Stuebner
2019-12-09 14:42 ` Heiko Stuebner
2019-12-14 7:54 ` Sam Ravnborg
2019-12-14 7:54 ` Sam Ravnborg
2019-12-09 14:42 ` [PATCH 3/3] drm/panel: add panel driver for Xinpeng XPP055C272 panels Heiko Stuebner
2019-12-09 14:42 ` Heiko Stuebner
2019-12-14 8:17 ` Sam Ravnborg
2019-12-14 8:17 ` Sam Ravnborg
2019-12-14 23:07 ` Heiko Stübner
2019-12-14 23:07 ` Heiko Stübner
2019-12-15 8:29 ` Sam Ravnborg
2019-12-15 8:29 ` Sam Ravnborg
2019-12-15 9:13 ` Heiko Stuebner [this message]
2019-12-15 9:13 ` Heiko Stuebner
2019-12-15 9:40 ` Sam Ravnborg
2019-12-15 9:40 ` Sam Ravnborg
2019-12-14 7:50 ` [PATCH 1/3] dt-bindings: Add vendor prefix for Xinpeng Technology Sam Ravnborg
2019-12-14 7:50 ` Sam Ravnborg
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=1744285.zQlJhejOUX@phil \
--to=heiko@sntech.de \
--cc=christoph.muellner@theobroma-systems.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=sam@ravnborg.org \
--cc=thierry.reding@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.