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: Thu, 13 Sep 2018 10:02:13 +0200 Message-ID: <20180913080213.flot5eohd4k6edjm@flea> References: <20180911113325.11024-1-maxime.ripard@bootlin.com> <20180911201702.GN19774@phenom.ffwll.local> <20180912095339.l6fez5xqkxsokxft@flea> <20180912154742.j4hjgzdyymmlxw3r@flea> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0415756934==" Return-path: Received: from mail.bootlin.com (mail.bootlin.com [62.4.15.54]) by gabe.freedesktop.org (Postfix) with ESMTP id 3B8006E140 for ; Thu, 13 Sep 2018 08:02:14 +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 --===============0415756934== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tikjtogubmqq3d6o" Content-Disposition: inline --tikjtogubmqq3d6o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 12, 2018 at 05:53:39PM +0200, Daniel Vetter wrote: > On Wed, Sep 12, 2018 at 5:47 PM, Maxime Ripard > wrote: > > 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 modul= e results in > >> >> > a link error, as we try to access a symbol from the sun8i_tcon_to= p.ko module: > >> >> > > >> >> > ERROR: "sun8i_tcon_top_de_config" [drivers/gpu/drm/sun4i/sun4i-tc= on.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-tco= n.ko] undefined! > >> >> > > >> >> > This solves the problem by adding a silent symbol for the tcon_to= p module, > >> >> > building it as a separate module in exactly the cases that we nee= d it, > >> >> > but in a way that it is reachable by the other modules. > >> >> > > >> >> > Fixes: cf77d79b4e29 ("drm/sun4i: tcon: Add another way for matchi= ng 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 s= mall > >> >> soc driver with more Kconfigs than anything else ... is all this pa= in > >> >> 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 f= or > >> >> 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 eno= ugh > >> >> 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 t= he > >> > 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. >=20 > Yup, if you want to make drm_edid.c optional, you need LTO. Because I > think we've already gone way overboard with making stuff optional in > the drm core, there's lots of silly little Kconfigs with imo > questionable value. Also, 50kb ... what does that look like > compressed? Should compress exceedingly well. >=20 > But that's not what I asked about really, I asked about all the > Kconfigs in su4i. Are those worth it? Especially compared to fixing > this for real, using something like LTO (plus making a few things > hard-coded, per machine configuration, so that gcc can figure it all > out). You're asking whether a 5 minutes effort is worth it compared to a 5 weeks one (at best) to port the LTO patches, making it sure it works ok on ARM, and then debugging whether some entry point has been removed or not. Plus, given that it's a driver that could or couldn't be loaded depending on the device tree, you would have to keep that driver in even with LTO, even though you know you have zero chance to execute that code at runtime. Maxime --=20 Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com --tikjtogubmqq3d6o Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE0VqZU19dR2zEVaqr0rTAlCFNr3QFAluaGYQACgkQ0rTAlCFN r3QwrxAAga90dgsp9EOAnxYqkY6vbwsyLrMu0W0NQ9shP+aLBrTxsmEWM6tTIfLv xmPaKiVXx+9c1K3tTKkFF6S7V6YRu0b2S/1CL/IJ9n6W7nEtptAmgiMfA+kidxvo hTKGFz/rO9DRrwgnnKCizpZXtMFqh2pi5Xqqbi2s+rW/f6Sn1dAipxxwVUrHuQEE yjuZihCJppxu5eHskSoYgIn6AixB6rzt/v4yrkoaotVTgh1qDbIpVpU9zGWjhxJu jMVjUhOjSJGZGQkgCvmOBYaHlA8MwxFt5Y7+zOE4gsByIDNpaNPn9lbVbb5kKMAV 5IZj1h4R8AoXg/tSIUsbKzLHPmHTj2eGNY4cGHeiT1tFgLA05MCTaMw8cMorq1uq /CLJcJkYVmQuOSaMn74w6pLiLORO/v2qADNbtTWPKny+NZwBTp14Jc9LK89E+ida RbYcEScChyQqYi73M0Ckq3Q3ZSC2Gx7xODL2UtpECvwf2M8lf8StdZS7Bv7y7PWZ opP7lSJEO/aASOw5CduWrnaeKTWOQv7aGbO0/y1T0brV+RittMSj2CaGMC4zZLsl +gLR8kLjH22wZufC8400F18w16WC7kmkgsxHiMUnPKfbPaMDSGtRPdifH65VyMrK OB0RGWmwB2LH3tQmN5d1ZTDA8MXfkziqWCRotjM9fnsUoUI7jnM= =USrO -----END PGP SIGNATURE----- --tikjtogubmqq3d6o-- --===============0415756934== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0415756934==--