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

[Maxime Ripard]

On Wed, Sep 12, 2018 at 04:25:36PM +0200, Daniel Vetter wrote:
> 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.

It really depends on the combination of the CPU speed, the storage
speed, and the compression algorithm. To give you a figure, a quite
good storage device in our case has a bandwith of 10MB/s. If you add a
MB, you lose a tenth of your budget, decompression excluded.

The sole edid_cea_modes, drm_dmt_modes and edid_est_modes, combined,
already take around 50kB. That's around .5% of our time budget just
dedicated to loading structures we will never need, without the option
to compile them out.

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/ce4c2bfc/attachment.sig>