From: Jani Nikula <jani.nikula@linux.intel.com>
To: Doug Anderson <dianders@chromium.org>, neil.armstrong@linaro.org
Cc: dri-devel@lists.freedesktop.org,
Linus Walleij <linus.walleij@linaro.org>,
lvzhaoxiong@huaqin.corp-partner.google.com,
Hsin-Yi Wang <hsinyi@google.com>,
Javier Martinez Canillas <javierm@redhat.com>,
Joel Selvaraj <jo@jsfamily.in>,
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
Cong Yang <yangcong5@huaqin.corp-partner.google.com>,
Sam Ravnborg <sam@ravnborg.org>, Daniel Vetter <daniel@ffwll.ch>,
David Airlie <airlied@gmail.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 4/8] drm/mipi-dsi: Introduce mipi_dsi_*_write_seq_multi()
Date: Mon, 29 Apr 2024 18:39:18 +0300 [thread overview]
Message-ID: <87y18w2n6h.fsf@intel.com> (raw)
In-Reply-To: <CAD=FV=V=EvEGp4tGDd-UQ1R=XkAwDn04ftd8oWU=UE=3Gi7SLQ@mail.gmail.com>
On Mon, 29 Apr 2024, Doug Anderson <dianders@chromium.org> wrote:
> Hi,
>
> On Mon, Apr 29, 2024 at 2:38 AM Neil Armstrong
> <neil.armstrong@linaro.org> wrote:
>>
>> > +/**
>> > + * struct mipi_dsi_multi_context - Context to call multiple MIPI DSI funcs in a row
>> > + * @dsi: Pointer to the MIPI DSI device
>> > + * @accum_err: Storage for the accumulated error over the multiple calls. Init
>> > + * to 0. If a function encounters an error then the error code will be
>> > + * stored here. If you call a function and this points to a non-zero
>> > + * value then the function will be a noop. This allows calling a function
>> > + * many times in a row and just checking the error at the end to see if
>> > + * any of them failed.
>> > + */
>> > +
>> > +struct mipi_dsi_multi_context {
>> > + struct mipi_dsi_device *dsi;
>> > + int accum_err;
>> > +};
>>
>> I like the design, but having a context struct seems over-engineered while we could pass
>> a single int over without encapsulating it with mipi_dsi_multi_context.
>>
>> void mipi_dsi_dcs_write_buffer_multi(struct mipi_dsi_multi_context *ctx,
>> const void *data, size_t len);
>> vs
>> void mipi_dsi_dcs_write_buffer_multi(struct mipi_dsi_device *dsi, int *accum_err,
>> const void *data, size_t len);
>>
>> is the same, and it avoids having to declare a mipi_dsi_multi_context and set ctx->dsi,
>> and I'll find it much easier to migrate, just add a &ret and make sure ret is initialized to 0.
>
> Yeah, I had the same reaction when Jani suggested the context style
> [1] and I actually coded it up exactly as you suggest above. I then
> changed my mind and went with the context. My motivation was that when
> I tested it I found that using the context produced smaller code.
> Specifically, from the description of this patch we see we end up
> with:
>
> Total: Before=10651, After=9663, chg -9.28%
>
> ...when I didn't have the context and I had the accum_err then instead
> of getting ~9% smaller I believe it actually got ~0.5% bigger. This
> makes some sense as the caller has to pass 4 parameters to each call
> instead of 3.
>
> It's not a giant size difference but it was at least some motivation
> that helped push me in this direction. I'd also say that when I looked
> at the code in the end the style grew on me. It's really not too
> terrible to have one line in your functions that looks like:
>
> struct mipi_dsi_multi_context ctx = { .dsi = boe->dsi };
>
> ...and if that becomes the canonical way to do it then it's really
> hard to accidentally forget to initialize the error value. With the
> other API it's _very_ easy to forget to initialize the error value and
> the compiler won't yell at you. It also makes it very obvious to the
> caller that this function is doing something a little different than
> most Linux APIs with that error return.
>
> So I guess I'd say that I ended up being pretty happy with the
> "context" even if it does feel a little over engineered and I'd argue
> to keep it that way. That being said, if you feel strongly about it
> then we can perhaps get others to chime in to see which style they
> prefer? Let me know what you think.
>
>
> [1] https://lore.kernel.org/r/8734r85tcf.fsf@intel.com
FWIW, I don't feel strongly about this, and I could be persuaded either
way, but I've got this gut feeling that an extensible context parameter
might be benefitial future proofing in this case.
BR,
Jani.
--
Jani Nikula, Intel
next prev parent reply other threads:[~2024-04-29 15:39 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-26 23:58 [PATCH v2 0/8] drm/mipi-dsi: Reduce bloat and add funcs for cleaner init seqs Douglas Anderson
2024-04-26 23:58 ` [PATCH v2 1/8] drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_dcs_write_seq() Douglas Anderson
2024-04-27 1:44 ` Dmitry Baryshkov
2024-04-27 6:22 ` Sam Ravnborg
2024-04-29 21:42 ` Doug Anderson
2024-04-26 23:58 ` [PATCH v2 2/8] drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_generic_write_seq() Douglas Anderson
2024-04-26 23:58 ` [PATCH v2 3/8] drm/mipi-dsi: Reduce driver bloat of mipi_dsi_*_write_seq() Douglas Anderson
2024-04-27 2:05 ` Dmitry Baryshkov
2024-04-26 23:58 ` [PATCH v2 4/8] drm/mipi-dsi: Introduce mipi_dsi_*_write_seq_multi() Douglas Anderson
2024-04-27 6:32 ` Sam Ravnborg
2024-04-29 14:13 ` Doug Anderson
2024-04-29 9:38 ` Neil Armstrong
2024-04-29 14:26 ` Doug Anderson
2024-04-29 15:39 ` Jani Nikula [this message]
2024-05-01 15:49 ` Doug Anderson
2024-05-01 15:57 ` Dmitry Baryshkov
2024-05-06 6:21 ` Linus Walleij
2024-04-26 23:58 ` [PATCH v2 5/8] drm/mipi-dsi: mipi_dsi_*_write functions don't need to ratelimit prints Douglas Anderson
2024-04-26 23:58 ` [PATCH v2 6/8] drm/panel: novatek-nt36672e: Switch to mipi_dsi_dcs_write_seq_multi() Douglas Anderson
2024-04-26 23:58 ` [PATCH v2 7/8] drm/panel: boe-tv101wum-nl6: Don't use a table for initting commands Douglas Anderson
2024-04-26 23:58 ` [PATCH v2 8/8] drm/panel: boe-tv101wum-nl6: Convert hex to lowercase Douglas Anderson
2024-04-27 8:48 ` Dmitry Baryshkov
2024-04-29 9:20 ` [PATCH v2 0/8] drm/mipi-dsi: Reduce bloat and add funcs for cleaner init seqs Jani Nikula
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=87y18w2n6h.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=airlied@gmail.com \
--cc=daniel@ffwll.ch \
--cc=dianders@chromium.org \
--cc=dmitry.baryshkov@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=hsinyi@google.com \
--cc=javierm@redhat.com \
--cc=jo@jsfamily.in \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lvzhaoxiong@huaqin.corp-partner.google.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=sam@ravnborg.org \
--cc=tzimmermann@suse.de \
--cc=yangcong5@huaqin.corp-partner.google.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 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 read-only IMAP folder(s) and NNTP newsgroup(s).