On Sat, 27 Apr 2024 at 02:59, Douglas Anderson <dianders@xxxxxxxxxxxx> wrote: > > Through a cooperative effort between Hsin-Yi Wang and Dmitry > Baryshkov, we have realized the dev_err_ratelimited() in the > mipi_dsi_*_write_seq() macros was causing quite a bit of bloat to the > kernel. Let's hoist this call into drm_mipi_dsi.c by adding a "chatty" > version of the functions that includes the print. While doing this, > add a bit more comments to these macros making it clear that they > print errors and also that they return out of _the caller's_ function. > > Without any changes to clients this gives a dramatic savings. Building > with my build system shows one example: > > $ scripts/bloat-o-meter \ > .../before/panel-novatek-nt36672e.ko \ > .../after/panel-novatek-nt36672e.ko > > add/remove: 0/1 grow/shrink: 0/1 up/down: 0/-21496 (-21496) > Function old new delta > nt36672e_1080x2408_60hz_init._rs 10320 - -10320 > nt36672e_1080x2408_60hz_init 17412 6236 -11176 > Total: Before=32147, After=10651, chg -66.87% > > Note that given the change in location of the print it's harder to > include the "cmd" in the printout for mipi_dsi_dcs_write_seq() since, > theoretically, someone could call the new chatty function with a > zero-size array and it would be illegal to dereference data[0]. > There's a printk format to print the whole buffer and this is probably > more useful for debugging anyway. Given that we're doing this for > mipi_dsi_dcs_write_seq(), let's also print the buffer for > mipi_dsi_generic_write_seq() in the error case. > > It should be noted that the current consensus of DRM folks is that the > mipi_dsi_*_write_seq() should be deprecated due to the non-intuitive > return behavior. A future patch will formally mark them as deprecated > and provide an alternative. > > Signed-off-by: Douglas Anderson <dianders@xxxxxxxxxxxx> > --- > > Changes in v2: > - Add some comments to the macros about printing and returning. > - Modify commit message now that this is part of a series. > - Change the way err value is handled in prep for next patch. > - Rebased upon patches to avoid theoretical int overflow. > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> -- With best wishes Dmitry