[Intel-gfx] Correct DMC version for Skylake (1.23 vs 1.26)

Daniel Vetter daniel at ffwll.ch
Wed Aug 10 10:26:48 UTC 2016


On Tue, Aug 09, 2016 at 10:57:13PM -0700, Rodrigo Vivi wrote:
> On Tue, Aug 9, 2016 at 1:48 AM, Jani Nikula <jani.nikula at linux.intel.com> wrote:
> > On Tue, 09 Aug 2016, Daniel Klaffenbach <danielklaffenbach at gmail.com> wrote:
> >> Hi,
> >>
> >> which one is the correct DMC version to load for Linux 4.8-rc1? The
> >> binary blob in linux-firmware.git is v1.26, which is also the latest
> >> version available for download at the linuxgraphics website.
> >>
> >> Version 1.26 used to load just fine on Kernels 4.6 and 4.7. Commit
> >> 4aa7fb9c introduced version pinning for v1.26 (both in
> >> drm-intel-nightly and the current for-linux-next branch). Later an
> >> older commit was pushed (a4a027a8), which lowered the
> >> required DMC firmware to v1.23 again, without removing the
> >> pinning.
> >>
> >> Now the situation is that v1.23 is pinned ATM, but v1.26 has been
> >> released through linux-firmware.git and is being rolled out to end
> >> users right now.
> >>
> >> What to do now? Is this a bug or a feature?
> 
> It is a bug, I'm sending a patch right now.
> 
> >
> > You should use whichever version the kernel asks. The bug is that v1.23
> > was dropped from linux-firmware.
> 
> 1.23 was intentionally dropped from linux-firmware since 1.26 was
> already the required one by our driver.
> 
> Some merge probably failed and overwrote what Patrik had properly done
> in commit  4aa7fb9c ("drm/i915/dmc: Step away from symbolic
> links")
> 
> > We may later upgrade the firmware the
> > kernel asks, and even backport said upgrade to stable kernels after
> > ensuring it works.
> >
> > Rodrigo, please fix linux-firmware.
> 
> No, I'm going to fix our driver.
> 
> Well, I can restore the 1.23 there if you tell me there is no way we
> can make sure this patch that I'm about to send will land and be
> backported on time, but this is not the ideal since we know 1.23 will
> cause bugs.

Backporting right now takes more than 1 month until it's in users hands.
We need _both_ because we've screwed up :(

Also really, if there's a regression and it's more than 1 week just push
the revert, to whichever repo it needs to be pushed to. Here this means
reverting on linux-firmware. Talking for weeks about simple bisected
regressions is one of the reasons why it's sooooooooo expensive for us to
fix bugs, and in turn why we're totally not in control of the situation.

So in case of doubt: Revert first, ask questions later pls.
-Daniel

> 
> Thanks,
> Rodrigo
> 
> >
> > BR,
> > Jani.
> >
> >>
> >>
> >> Regards,
> >>  Dan
> >> _______________________________________________
> >> Intel-gfx mailing list
> >> Intel-gfx at lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> > --
> > Jani Nikula, Intel Open Source Technology Center
> 
> 
> 
> -- 
> Rodrigo Vivi
> Blog: http://blog.vivi.eng.br
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the Intel-gfx mailing list