Hi, On Mon, Oct 9, 2023 at 2:02 PM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > > On Mon, Oct 9, 2023 at 10:53 PM Doug Anderson <dianders@xxxxxxxxxx> wrote: > > > Also: just as a heads up, Hsin-Yi measured the impact of removing the > > "command table" for init and replacing it with a whole pile of direct > > function calls. She found that it added over 100K to the driver (!!!). > > I believe it went from a 45K driver to a 152K driver. Something to > > keep in mind. ;-) > > Sounds like Aarch64 code. I would love a comparison of the same > driver compiled to ARMv7t thumb code. Just for the academic > interest. Because I have heard about people running ARM32 > kernels on Aarch64 hardware for this exact reason: so they can > have thumb, which is compact. Yeah, thumb2 was the best. I suspect that in addition to the aarch64 vs thumb2 part of the problem is that mipi_dsi_dcs_write_seq() is a macro, so this wasn't just a whole ton of function calls, but a whole ton of inline function calls. ;-) Still, even if we fixed that, I'm not sure it we'll ever be able to beat the space efficiency of command sequence tables. > OK OK we definitely need command sequence tables in the core, > what we have now is each driver rolling its own which is looking bad. Agreed. I'd love to see someone tackle this (though not blocking Cong's series on it). Hsin-Yi took a quick look at it and noticed that some drivers have slightly different cases for how they handle command sequences, which is a bit annoying. For instance, at least one driver had an extra NOP between commands and said it was important not to remove that. ...so we'd have to figure out how to abstract some of these differences without it getting too ugly... -Doug
