From: Doug Anderson <dianders@chromium.org>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: dri-devel@lists.freedesktop.org,
Linus Walleij <linus.walleij@linaro.org>,
lvzhaoxiong@huaqin.corp-partner.google.com,
Jani Nikula <jani.nikula@linux.intel.com>,
Hsin-Yi Wang <hsinyi@google.com>,
Javier Martinez Canillas <javierm@redhat.com>,
Neil Armstrong <neil.armstrong@linaro.org>,
Joel Selvaraj <jo@jsfamily.in>,
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
Cong Yang <yangcong5@huaqin.corp-partner.google.com>,
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 07:13:08 -0700 [thread overview]
Message-ID: <CAD=FV=UN5tWqQvnLRGtk+EVqjEqO6vqtEfaYONkCsze2+539Xw@mail.gmail.com> (raw)
In-Reply-To: <20240427063250.GB1137299@ravnborg.org>
Hi,
On Fri, Apr 26, 2024 at 11:33 PM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> > ---
> > Right now this patch introduces two new functions in
> > drm_mipi_dsi.c. Alternatively we could have changed the prototype of
> > the "chatty" functions and made the deprecated macros adapt to the new
> > prototype. While this sounds nice, it bloated callers of the
> > deprecated functioin a bit because it caused the compiler to emit less
> > optimal code. It doesn't seem terrible to add two more functions, so I
> > went that way.
> The concern here is when it will be cleaned up. As a minimum please
> consider adding an item to todo.rst that details what should be done
> to get rid of the now obsolete chatty functions so someone can pick it
> up.
Sure, I can add something to do TODO. Do folks agree that's the
preferred way to do things? A few thoughts I had:
1. In theory it could be useful to keep _both_ the "chatty" and
"multi" variants of the functions. In at least a few places the
"multi" variant was awkward. The resulting auo_kd101n80_45na_init()
[1] looked awkward. If I was writing just this function I would have
chosen an API more like the "chatty" one, but since I was trying to
make all the init functions similar I kept them all using the "multi"
API. Does it make sense to keep both long term?
[1] https://lore.kernel.org/all/20240426165839.v2.7.Ib5030ab5cd41b4e08b1958bd7e51571725723008@changeid/
2. Going completely the opposite direction, we could also not bother
saving as much space today and _force_ everyone to move to the new
"multi" API to get the full space savings.
So I guess three options: a) leave my patches the way they are and add
a TODO, b) Keep the "chatty" variants long term and remove my
"after-the-cut", or c) Don't get as much space savings today but don't
introduce a new exported function. Opinions?
> > @@ -792,6 +792,34 @@ int mipi_dsi_generic_write_chatty(struct mipi_dsi_device *dsi,
> > }
> > EXPORT_SYMBOL(mipi_dsi_generic_write_chatty);
> >
> > +/**
> > + * mipi_dsi_generic_write_multi() - mipi_dsi_generic_write_chatty() w/ accum_err
> > + * @ctx: Context for multiple DSI transactions
> > + * @payload: buffer containing the payload
> > + * @size: size of payload buffer
> > + *
> > + * Like mipi_dsi_generic_write_chatty() but deals with errors in a way that
> > + * makes it convenient to make several calls in a row.
> > + */
> > +void mipi_dsi_generic_write_multi(struct mipi_dsi_multi_context *ctx,
> > + const void *payload, size_t size)
> > +{
> > + struct mipi_dsi_device *dsi = ctx->dsi;
> > + struct device *dev = &dsi->dev;
> > + ssize_t ret;
> > +
> > + if (ctx->accum_err)
> > + return;
> > +
> > + ret = mipi_dsi_generic_write(dsi, payload, size);
> > + if (ret < 0) {
> > + ctx->accum_err = ret;
> > + dev_err_ratelimited(dev, "sending generic data %*ph failed: %d\n",
> > + (int)size, payload, ctx->accum_err);
> > + }
> I see no point in using ratelimited and then change it in the next
> patch.
Sure, I'll re-order patches.
> > @@ -197,6 +197,22 @@ struct mipi_dsi_device {
> > struct drm_dsc_config *dsc;
> > };
> >
> > +/**
> > + * 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;
> > +};
> Inline comments is - I think - preferred.
Sure, I'll update in the next version.
next prev parent reply other threads:[~2024-04-29 14:13 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 [this message]
2024-04-29 9:38 ` Neil Armstrong
2024-04-29 14:26 ` Doug Anderson
2024-04-29 15:39 ` Jani Nikula
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='CAD=FV=UN5tWqQvnLRGtk+EVqjEqO6vqtEfaYONkCsze2+539Xw@mail.gmail.com' \
--to=dianders@chromium.org \
--cc=airlied@gmail.com \
--cc=daniel@ffwll.ch \
--cc=dmitry.baryshkov@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=hsinyi@google.com \
--cc=jani.nikula@linux.intel.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).