From: Doug Anderson <dianders@chromium.org>
To: neil.armstrong@linaro.org
Cc: dri-devel@lists.freedesktop.org,
Linus Walleij <linus.walleij@linaro.org>,
Jani Nikula <jani.nikula@linux.intel.com>,
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
Cong Yang <yangcong5@huaqin.corp-partner.google.com>,
Hsin-Yi Wang <hsinyi@google.com>,
Brian Norris <briannorris@chromium.org>,
Sam Ravnborg <sam@ravnborg.org>,
Javier Martinez Canillas <javierm@redhat.com>,
Joel Selvaraj <jo@jsfamily.in>,
lvzhaoxiong@huaqin.corp-partner.google.com,
Daniel Vetter <daniel@ffwll.ch>,
David Airlie <airlied@gmail.com>,
Jessica Zhang <quic_jesszhan@quicinc.com>,
Jonathan Corbet <corbet@lwn.net>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 0/9] drm/mipi-dsi: Reduce bloat and add funcs for cleaner init seqs
Date: Thu, 2 May 2024 07:27:59 -0700 [thread overview]
Message-ID: <CAD=FV=VciR5UEQpvizrUNYR7mhE2P4ESvM2T7v4mUT3UpdX3bg@mail.gmail.com> (raw)
In-Reply-To: <a8a73fc4-7699-4c47-8970-cd68be0fe1d9@linaro.org>
Hi,
On Thu, May 2, 2024 at 12:48 AM Neil Armstrong
<neil.armstrong@linaro.org> wrote:
>
> Hi,
>
> On 01/05/2024 17:41, Douglas Anderson wrote:
> > The consensus of many DRM folks is that we want to move away from DSI
> > drivers defining tables of init commands. Instead, we want to move to
> > init functions that can use common DRM functions. The issue thus far
> > has been that using the macros mipi_dsi_generic_write_seq() and
> > mipi_dsi_dcs_write_seq() bloats the driver using them.
> >
> > While trying to solve bloat, we realized that the majority of the it
> > was easy to solve. This series solves the bloat for existing drivers
> > by moving the printout outside of the macro.
> >
> > During discussion of my v1 patch to fix the bloat [1], we also decided
> > that we really want to change the way that drivers deal with init
> > sequences to make it clearer. In addition to being cleaner, a side
> > effect of moving drivers to the new style reduces bloat _even more_.
> >
> > This series also contains a few minor fixes / cleanups that I found
> > along the way.
> >
> > This series converts four drivers over to the new
> > mipi_dsi_dcs_write_seq_multi() function. Not all conversions have been
> > tested, but hopefully they are straightforward enough. I'd appreciate
> > testing.
> >
> > NOTE: In v3 I tried to incorporate the feedback from v2. I also
> > converted the other two panels I could find that used table-based
> > initialization.
> >
> > [1] https://lore.kernel.org/r/20240424172017.1.Id15fae80582bc74a0d4f1338987fa375738f45b9@changeid
> >
> > Changes in v3:
> > - ("mipi_dsi_*_write functions don't need to ratelimit...") moved earlier.
> > - Add a TODO item for cleaning up the deprecated macros/functions.
> > - Fix spacing of init function.
> > - Inline kerneldoc comments for struct mipi_dsi_multi_context.
> > - Rebased upon patch to remove ratelimit of prints.
> > - Remove an unneeded error print.
> > - Squash boe-tv101wum-nl6 lowercase patch into main patch
> > - Use %zd in print instead of casting errors to int.
> > - drm/panel: ili9882t: Don't use a table for initting panels
> > - drm/panel: innolux-p079zca: Don't use a table for initting panels
> >
> > Changes in v2:
> > - Add some comments to the macros about printing and returning.
> > - Change the way err value is handled in prep for next patch.
> > - Modify commit message now that this is part of a series.
> > - Rebased upon patches to avoid theoretical int overflow.
> > - drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_dcs_write_seq()
> > - drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_generic_write_seq()
> > - drm/mipi-dsi: Introduce mipi_dsi_*_write_seq_multi()
> > - drm/mipi-dsi: mipi_dsi_*_write functions don't need to ratelimit prints
> > - drm/panel: boe-tv101wum-nl6: Convert hex to lowercase
> > - drm/panel: boe-tv101wum-nl6: Don't use a table for initting commands
> > - drm/panel: novatek-nt36672e: Switch to mipi_dsi_dcs_write_seq_multi()
> >
> > Douglas Anderson (9):
> > drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_dcs_write_seq()
> > drm/mipi-dsi: Fix theoretical int overflow in
> > mipi_dsi_generic_write_seq()
> > drm/mipi-dsi: mipi_dsi_*_write functions don't need to ratelimit
> > prints
> > drm/mipi-dsi: Reduce driver bloat of mipi_dsi_*_write_seq()
> > drm/mipi-dsi: Introduce mipi_dsi_*_write_seq_multi()
> > drm/panel: novatek-nt36672e: Switch to mipi_dsi_dcs_write_seq_multi()
> > drm/panel: boe-tv101wum-nl6: Don't use a table for initting panels
> > drm/panel: ili9882t: Don't use a table for initting panels
> > drm/panel: innolux-p079zca: Don't use a table for initting panels
>
> Thanks Doug!
>
> I think we all agree on the core changes, now I think we can wait a few weeks
> and try to get some test feedbacks on the indirectly and directly affected
> panels, drm-misc-next won't be merged into linux-next until v6.10-rc1 anyway
> so we have some time to test on our boards.
Great!
Just to be clear, are you suggesting that we leave these patches on
the lists for a few weeks before landing in drm-misc-next, or are you
suggesting that it's safe to land them in drm-misc-next because it
won't make it to linuxnext for a while anyway? I assume the former
(AKA leave it on the lists for a while) but just want to be clear. ;-)
There's nothing terribly urgent about these patches except that they
are blocking Cong Yang's patch series [0] and lvzhaoxiong's patch
series [1]. I think it would be fine for them to send out their patch
series with mine marked as a dependency so we can finish reviewing
their series and then when mine lands theirs will be good to go too.
Maybe we can aim for 2 weeks of stewing on the list if there are no
issues during that time? I know landing in drm-misc during this time
won't help get into mainline faster, but with ChromeOS's "upstream
first" policy it saves us a bunch of headache if we can land things in
our tree from a maintainer tree with stable git hashes (like
drm-misc-next) instead of landing from a mailing list. Certainly that
doesn't mean we want to rush patches in before they're ready, but I
just want to say that there is still some benefit in getting the
patches landed sooner rather than later. :-)
[0] https://lore.kernel.org/r/20240424023010.2099949-1-yangcong5@huaqin.corp-partner.google.com
[1] https://lore.kernel.org/r/20240418081548.12160-3-lvzhaoxiong@huaqin.corp-partner.google.com
next prev parent reply other threads:[~2024-05-02 14:28 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-01 15:41 [PATCH v3 0/9] drm/mipi-dsi: Reduce bloat and add funcs for cleaner init seqs Douglas Anderson
2024-05-01 15:41 ` [PATCH v3 1/9] drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_dcs_write_seq() Douglas Anderson
2024-05-02 7:26 ` Neil Armstrong
2024-05-02 8:15 ` Linus Walleij
2024-05-01 15:41 ` [PATCH v3 2/9] drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_generic_write_seq() Douglas Anderson
2024-05-02 7:26 ` Neil Armstrong
2024-05-02 8:15 ` Linus Walleij
2024-05-01 15:41 ` [PATCH v3 3/9] drm/mipi-dsi: mipi_dsi_*_write functions don't need to ratelimit prints Douglas Anderson
2024-05-02 7:27 ` Neil Armstrong
2024-05-02 8:16 ` Linus Walleij
2024-05-01 15:41 ` [PATCH v3 4/9] drm/mipi-dsi: Reduce driver bloat of mipi_dsi_*_write_seq() Douglas Anderson
2024-05-02 7:27 ` Neil Armstrong
2024-05-02 8:23 ` Linus Walleij
2024-05-02 16:59 ` Doug Anderson
2024-05-01 15:41 ` [PATCH v3 5/9] drm/mipi-dsi: Introduce mipi_dsi_*_write_seq_multi() Douglas Anderson
2024-05-02 7:28 ` Neil Armstrong
2024-05-06 6:22 ` Linus Walleij
2024-05-01 15:41 ` [PATCH v3 6/9] drm/panel: novatek-nt36672e: Switch to mipi_dsi_dcs_write_seq_multi() Douglas Anderson
2024-05-01 15:41 ` [PATCH v3 7/9] drm/panel: boe-tv101wum-nl6: Don't use a table for initting panels Douglas Anderson
2024-05-02 13:41 ` Linus Walleij
2024-05-02 16:40 ` Doug Anderson
2024-05-01 15:41 ` [PATCH v3 8/9] drm/panel: ili9882t: " Douglas Anderson
2024-05-06 6:19 ` Linus Walleij
2024-05-01 15:41 ` [PATCH v3 9/9] drm/panel: innolux-p079zca: " Douglas Anderson
2024-05-03 16:32 ` Doug Anderson
2024-05-06 6:45 ` Linus Walleij
2024-05-02 7:48 ` [PATCH v3 0/9] drm/mipi-dsi: Reduce bloat and add funcs for cleaner init seqs Neil Armstrong
2024-05-02 14:27 ` Doug Anderson [this message]
2024-05-02 16:05 ` neil.armstrong
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=VciR5UEQpvizrUNYR7mhE2P4ESvM2T7v4mUT3UpdX3bg@mail.gmail.com' \
--to=dianders@chromium.org \
--cc=airlied@gmail.com \
--cc=briannorris@chromium.org \
--cc=corbet@lwn.net \
--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-doc@vger.kernel.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=quic_jesszhan@quicinc.com \
--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).