[PATCH] drm/sun4i: fix build failure with CONFIG_DRM_SUN8I_MIXER=m

[Daniel Vetter]

On Wed, Sep 12, 2018 at 11:53 AM, Maxime Ripard
<maxime.ripard at bootlin.com> wrote:
> On Tue, Sep 11, 2018 at 10:17:02PM +0200, Daniel Vetter wrote:
>> On Tue, Sep 11, 2018 at 01:33:25PM +0200, Maxime Ripard wrote:
>> > Having DRM_SUN4I built-in but DRM_SUN8I_MIXER as a loadable module results in
>> > a link error, as we try to access a symbol from the sun8i_tcon_top.ko module:
>> >
>> > ERROR: "sun8i_tcon_top_de_config" [drivers/gpu/drm/sun4i/sun4i-tcon.ko] undefined!
>> > ERROR: "sun8i_tcon_top_set_hdmi_src" [drivers/gpu/drm/sun4i/sun4i-tcon.ko] undefined!
>> > ERROR: "sun8i_tcon_top_of_table" [drivers/gpu/drm/sun4i/sun4i-tcon.ko] undefined!
>> >
>> > This solves the problem by adding a silent symbol for the tcon_top module,
>> > building it as a separate module in exactly the cases that we need it,
>> > but in a way that it is reachable by the other modules.
>> >
>> > Fixes: cf77d79b4e29 ("drm/sun4i: tcon: Add another way for matching mixers with tcon")
>> > Fixes: 0305189afb32 ("drm/sun4i: tcon: Add support for R40 TCON")
>> > Tested-by: Jon Hunter <jonathanh at nvidia.com>
>> > Signed-off-by: Maxime Ripard <maxime.ripard at bootlin.com>
>>
>> Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>
>>
>> But I can't help myself and drop the usual questions when I see a small
>> soc driver with more Kconfigs than anything else ... is all this pain
>> worth it? I know that maybe the desktop approach of stuffing half a
>> million lines of driver code into one .ko might be a bit too much for
>> socs, but this seems overkill.
>>
>> I'm also pretty sure it's not justified by any real data, compared to
>> overall code size of a drm stack, that shows it's a substantial enough
>> saving that it's worth it.
>
> I'm currently running on a project where the boot time to a qt
> application from power off should be less than a second. You want to
> remove anything you can spare in some situations. And yeah, DRM is the
> biggest thing in the way to do that.

Oh I know all about the 1s people. But is binary size really that
important figure? I know it's a bit more to load&decompress, but it
shouldn't have any impact on anything running at runtime.

>> Imo, if you really care about building a minimal driver, stuff everything
>> into one .ko and then LTO out the uneeded bits. We've done these
>> experiments for i915, that _actually_ saves a ton of binary size, with
>> fairly minimal code and maintenance impact. Still, we decided the payoff
>> is simply too small to bother making it a production thing.
>
> LTO isn't enabled yet in mainline, is it?

Unfortunately not :-/ We've done the analysis and reported to the
internal people who asked for this that "lto is what you want", but
nothing thus far. I guess the price tag of making LTO work is a bit
too much. Ofc doesn't just need LTO, but also needs some trickery to
make sure all the optional paths are statically determined to never
run. But (at least for us) that's just a few changes to the pci table,
and hard-coding the device info structure. OF/DT would probably need
some work, but should be doable too.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch