On 02/05/2024 16:27, Doug Anderson wrote:
Hi,
On Thu, May 2, 2024 at 12:48 AM Neil Armstrong
<neil.armstrong@xxxxxxxxxx> 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. ;-)
Yes you assume right
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. :-)
Yes let's wait 2 weeks and apply them
Neil
[0] https://lore.kernel.org/r/20240424023010.2099949-1-yangcong5@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
[1] https://lore.kernel.org/r/20240418081548.12160-3-lvzhaoxiong@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
