linux-kernel - Re: [v1 0/2] Break out as separate driver from boe-tv101wum-nl6 panel driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAD=FV=U5mX49s5yp+5uy+OfnkNrQgTJPf6E8fGHf=_Nn6M5f9A@mail.gmail.com>
Date:   Mon, 9 Oct 2023 14:12:45 -0700
From:   Doug Anderson <dianders@...gle.com>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Cong Yang <yangcong5@...qin.corp-partner.google.com>,
        sam@...nborg.org, neil.armstrong@...aro.org, daniel@...ll.ch,
        hsinyi@...gle.com, swboyd@...omium.org, airlied@...il.com,
        dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [v1 0/2] Break out as separate driver from boe-tv101wum-nl6 panel driver

Hi,

On Mon, Oct 9, 2023 at 2:02 PM Linus Walleij <linus.walleij@...aro.org> wrote:
>
> On Mon, Oct 9, 2023 at 10:53 PM Doug Anderson <dianders@...gle.com> 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