From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxime Ripard Subject: Re: [PATCH] drm/sun4i: fix build failure with CONFIG_DRM_SUN8I_MIXER=m Date: Wed, 12 Sep 2018 11:53:39 +0200 Message-ID: <20180912095339.l6fez5xqkxsokxft@flea> References: <20180911113325.11024-1-maxime.ripard@bootlin.com> <20180911201702.GN19774@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0394003580==" Return-path: Received: from mail.bootlin.com (mail.bootlin.com [62.4.15.54]) by gabe.freedesktop.org (Postfix) with ESMTP id CA61F890DF for ; Wed, 12 Sep 2018 09:53:50 +0000 (UTC) In-Reply-To: <20180911201702.GN19774@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Daniel Vetter Cc: Jernej Skrabec , Arnd Bergmann , Naresh Kamboju , dri-devel@lists.freedesktop.org, Jon Hunter , Chen-Yu Tsai List-Id: dri-devel@lists.freedesktop.org --===============0394003580== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4hmbrab7ioysjeix" Content-Disposition: inline --4hmbrab7ioysjeix Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 resu= lts in > > a link error, as we try to access a symbol from the sun8i_tcon_top.ko m= odule: > >=20 > > 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! > >=20 > > This solves the problem by adding a silent symbol for the tcon_top modu= le, > > 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. > >=20 > > Fixes: cf77d79b4e29 ("drm/sun4i: tcon: Add another way for matching mix= ers with tcon") > > Fixes: 0305189afb32 ("drm/sun4i: tcon: Add support for R40 TCON") > > Tested-by: Jon Hunter > > Signed-off-by: Maxime Ripard >=20 > Reviewed-by: Daniel Vetter >=20 > 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. >=20 > 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 --=20 Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com --4hmbrab7ioysjeix Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE0VqZU19dR2zEVaqr0rTAlCFNr3QFAluY4iIACgkQ0rTAlCFN r3TBvw/+P8NKx2umergLCMTkIcVgoIYMycQgY/4J2lq7KRVkcsfzcIKpzkTE4i9C ojOttExUY1uYLp/lABggSZLmVW3DgD0JzCmAWcEFTscQ2k3/CQ5Jh7P6v0qZRomE +GSEQYhJcZbguJXwmwoNeyElgaqzJJUQ4DRqrnBhOrutARYpxPS6rEpU0QhpVwLa Cg1VH4f6p74NhAAoSGiJnffOUuGQHqShbpF4JABB4dwxTRb9m8Tbvh8YhyGcAj8S Efl5l60QivjqFMTe5pqyeTJ0d0lbv4jdArgJQ23K3tmFV1YBYW15WvKe35KEx9Gl KMSEmTn6TS0wOrm9vc546mX5KJ33Ja1nrwgl3qpP52GyE6A0wBzs2uE7qBpE1o2c Wf+5tS9uUV14D3HAjzYV/OMnFZRjrXJCDpQhzNj9OqO/kJdLYE3lBFmBBhze0a+X 1TQJgsG0e/kEB4JItAQj0qiI6DNfEsx+VLdA3Lzrv6+va8ND0Ei90d8FsTPOtw1B m7u/jEgisJDzqWH/7H/lWJZQP/k64AoqjLk9DOxnTO39EyuvZIU431guJU3c9VwU KY3H0mRPJbN7Y/NvVFpzsXeD5Lg7W4nxZ/7toazksuWLcyFxxMgsY4p6H0mxIeZm flU/jSwBrKh/N+kkDWnMfwbY84X0oKl+C07obt2EnlRLISXp+iY= =ZheR -----END PGP SIGNATURE----- --4hmbrab7ioysjeix-- --===============0394003580== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0394003580==--