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@xxxxxxxxxxx> 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@xxxxxxxxxx>
> >> > Signed-off-by: Maxime Ripard <maxime.ripard@xxxxxxxxxxx>
> >>
> >> Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
> >>
> >> 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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
