On Thu, Sep 13, 2018 at 10:02 AM Maxime Ripard
<maxime.ripard@xxxxxxxxxxx> 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@xxxxxxxxxxx> 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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
