On Thu, Sep 13, 2018 at 10:02 AM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Wed, Sep 12, 2018 at 05:53:39PM +0200, Daniel Vetter wrote:
On Wed, Sep 12, 2018 at 5:47 PM, Maxime Ripard maxime.ripard@bootlin.com wrote:
On Wed, Sep 12, 2018 at 04:25:36PM +0200, Daniel Vetter wrote:
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.
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.
I have spent a few weeks on getting ARM kernels to build with LTO, based on earlier work from Nico and others. This requires a couple of patches for the common cases, but gets increasingly complex when you add in some other options (thumb2 kernel, XIP_KERNEL, MTD_XIP, OABI, ftrace, gcov, multi-cpu, ...) that each add their own conflicting requirements. I gave up in the end, before even trying to run any of those kernels.
I think for x86-64 and arm64, we have a realistic chance of making it work in general, on arm32 the best case I can think of would be to support some of the common configurations.
Arnd