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 17:47:42 +0200 Message-ID: <20180912154742.j4hjgzdyymmlxw3r@flea> References: <20180911113325.11024-1-maxime.ripard@bootlin.com> <20180911201702.GN19774@phenom.ffwll.local> <20180912095339.l6fez5xqkxsokxft@flea> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0512210583==" Return-path: Received: from mail.bootlin.com (mail.bootlin.com [62.4.15.54]) by gabe.freedesktop.org (Postfix) with ESMTP id B893D8972C for ; Wed, 12 Sep 2018 15:47:43 +0000 (UTC) In-Reply-To: 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 , Jon Hunter , Chen-Yu Tsai List-Id: dri-devel@lists.freedesktop.org --===============0512210583== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pwpq3vlho34jntcc" Content-Disposition: inline --pwpq3vlho34jntcc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 12, 2018 at 04:25:36PM +0200, Daniel Vetter wrote: > On Wed, Sep 12, 2018 at 11:53 AM, Maxime Ripard > 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 r= esults in > >> > a link error, as we try to access a symbol from the sun8i_tcon_top.k= o 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-tc= on.ko] undefined! > >> > ERROR: "sun8i_tcon_top_of_table" [drivers/gpu/drm/sun4i/sun4i-tcon.k= o] undefined! > >> > > >> > This solves the problem by adding a silent symbol for the tcon_top m= odule, > >> > building it as a separate module in exactly the cases that we need i= t, > >> > 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 > >> > Signed-off-by: Maxime Ripard > >> > >> Reviewed-by: Daniel Vetter > >> > >> 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. >=20 > 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 --=20 Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com --pwpq3vlho34jntcc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE0VqZU19dR2zEVaqr0rTAlCFNr3QFAluZNR0ACgkQ0rTAlCFN r3Rxsg/8D1Wyy7pJCUjod90CLuQzFNxLKk58y5UgdniLbIa80i9bEpZZVsogH0b5 Ww7LkuxebqbLlHEGzk9u/gdQELQqMRoSg4pdAM/0eN9J34JSNxB1fFUYaEauuyIV DZxgRIKHUZG22vQDuMWDCGJnTuadBSmL/XdMgfBjxWFhM6fD+EDDOu6K8JS+uhTD /yuLXiD9z7yci/dblhEmGmMDJ4R4pEXk1egH8O4NasNinJqQgajHDVIAlVgZv00K CUNJwkGdHv0DX+VSrAZ9L4f0DYKKtku2tKFJmXtCY2BoToHAMnlmF0E9KZqIFztT LbtsLbl8QqAehvNj3EGeMHPA/grHqnAV1amo+bAdMcZ3nlNmz7X3a2nmke2o6UMr q/GwP/uwxdY2Dexf1IimcuCGttTZ1zCNNKpgEWcJl7MvHUP8dOwzd3FxD5KlU+An 540o2Jr6iv2lVVJfca4gsi9vocZ0ogGDtl2xt78i663CPCcr4+pBKPEq3PG73xx8 B9mye0SQE3JCZclmPqaUDa1prNOuF4D967owEdilIEaWRoqQ8Ltd6pwf2vWQ2MaV Bfrw9KWB8IlHKmxLh+DC5DcCeWNy/fNdENA92blSCe0qtRjtv2zvGrgEW3jdsQgC mvDZEpYbgI5NMGUyxYaBkfABR+DkKxa0wvLTctsxaYeEvZDm0CU= =J/dZ -----END PGP SIGNATURE----- --pwpq3vlho34jntcc-- --===============0512210583== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0512210583==--