[Intel-gfx] linux-firmware-i915 pull request (bxt dmc, kbl dmc)

[Daniel Vetter]

On Wed, Aug 3, 2016 at 5:06 PM, Vivi, Rodrigo <rodrigo.vivi at intel.com> wrote:
> So, issues like https://bugs.freedesktop.org/show_bug.cgi?id=97182
>
> will appear with frequency now...
>
> should we just close all as wontfix?

It sounds like we should fix that by restoring 1.23. Certainly not
WONTFIX. WONTIFXing regression is pretty much the only guaranteed way
to terminally piss of Dave&Linus.
-Daniel

>
> On Wed, 2016-08-03 at 17:02 +0200, Daniel Vetter wrote:
>> On Wed, Aug 3, 2016 at 11:08 AM, Jani Nikula
>> <jani.nikula at linux.intel.com> wrote:
>> >
>> > >
>> > > >
>> > > > I believe this is another point in favor of bringing the sym
>> > > > links
>> > > > back.
>> > > >
>> > > > But also because we need to remove any firmware that we know it
>> > > > is bad
>> > > > and that would break the user. If it was blacklisted it was
>> > > > removed
>> > > > from repo.
>> > > >
>> > > > Yet another reason for symbolic link. If we know the firmware
>> > > > is bad it
>> > > > is bad for previous versions as well, but if we stay with the
>> > > > version
>> > > > hardcoded we are forcing the user to stay with a firmware that
>> > > > we know
>> > > > it is bad.
>> > > Indeed.  Please don't put a full version number in the filenames
>> > > requested by drivers.  Where it's not possible to maintain ABI
>> > > compatibility between driver and firmware indefinitely then
>> > > include an
>> > > ABI version in the filename, but not the full version.
>> > I'm starting to sound like a broken record, but here goes again.
>> >
>> > We do not have the bandwidth to test all combinations of kernel and
>> > firmware versions.
>> >
>> > If we update linux-firmware to change the firmware blob to use
>> > (either
>> > by changing where the symlink points or by replacing the file) we
>> > roll
>> > out untested firmware/kernel combinations to stable kernel users.
>> >
>> > IMO we should be specific which firmware version(s) to accept in
>> > the
>> > kernel, limiting to known good and tested combinations. If there's
>> > a
>> > need to update the firmware to use for stable kernels, it's a
>> > matter of
>> > backporting the commit accepting another firmware version. This can
>> > be
>> > done by us or an OSV.
>> >
>> > Even when there's supposed to be ABI compatibility, I wouldn't
>> > liberally
>> > roll out firmware updates across all past stable kernels without
>> > testing. Anyone suggesting that obviously doesn't have to be in the
>> > receiving end of the bug reports when things go wrong in mysterious
>> > and
>> > non-bisectable ways.
>> >
>> > I don't think it's a good idea to give the control of firmware
>> > version
>> > selection to the user space and linux-firmware.
>> +1
>>
>> We discussed why symlinks are not a great pick for gpus at length,
>> all
>> those reasons are still valid. Mostly it boils down to that the
>> actual
>> interface between gpu components is _extremely_ wide, and includes
>> all
>> kinds of fun things like minute timing details, w/a settings and
>> really just everything.
>>
>> I'd say for the same reasons we only support open source userspace
>> drivers (anything else can't be audited when it breaks and debugged)
>> we need to restrict the combinatorial interaction madness with
>> firmware. If that makes gpus special in yet another way, so be it.
>> -Daniel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch