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

[Maxime Ripard]

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.

> 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?

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20180912/5c58fe56/attachment.sig>