linux-firmware-i915 pull request (bxt dmc, kbl dmc)

linux-firmware-i915 pull request (bxt dmc, kbl dmc)

[Vivi, Rodrigo]

Hi,

Please consider pulling i915 updates to linux-firmware.git


The following changes since commit
040c24514b94fcdbd6308d986d1bde59a704a21a:

  linux-firmware: intel: Update Broxton audio firmware (2016-06-29
14:20:20 +0530)

are available in the git repository at:

  git://people.freedesktop.org/~vivijim/linux-firmware-i915 master

for you to fetch changes up to
19b71af5326bf28fe62ac2b1607b5e18d4b0eeb6:

  linux-firmware/i915: Step away from symbolic links and clean up repo.
(2016-07-01 16:07:52 -0700)

----------------------------------------------------------------
Rodrigo Vivi (3):
      linux-firmware: New minor DMC release for Broxton - ver1_07
      linux-firmware: First DMC image for Kabylake.
      linux-firmware/i915: Step away from symbolic links and clean up
repo.

 WHENCE                                            |  14 +++++---------
 i915/bxt_dmc_ver1.bin                             |   2 +-
 i915/bxt_dmc_ver1_04.bin                          | Bin 5872 -> 0
bytes
 i915/bxt_dmc_ver1_05.bin                          | Bin 5872 -> 0
bytes
 i915/{bxt_dmc_ver1_06.bin => bxt_dmc_ver1_07.bin} | Bin 8380 -> 8380
bytes
 i915/kbl_dmc_ver1.bin                             |   1 +
 i915/kbl_dmc_ver1_01.bin                          | Bin 0 -> 8616
bytes
 i915/skl_dmc_ver1_23.bin                          | Bin 8824 -> 0
bytes
 i915/skl_guc_ver1.bin                             | Bin 21 -> 109636
bytes
 i915/skl_guc_ver1_1059.bin                        | Bin 109636 -> 0
bytes
 i915/skl_guc_ver4.bin                             | Bin 18 -> 128320
bytes
 i915/skl_guc_ver4_3.bin                           | Bin 128320 -> 0
bytes
 12 files changed, 7 insertions(+), 10 deletions(-)
 delete mode 100644 i915/bxt_dmc_ver1_04.bin
 delete mode 100644 i915/bxt_dmc_ver1_05.bin
 rename i915/{bxt_dmc_ver1_06.bin => bxt_dmc_ver1_07.bin} (64%)
 create mode 120000 i915/kbl_dmc_ver1.bin
 create mode 100644 i915/kbl_dmc_ver1_01.bin
 delete mode 100644 i915/skl_dmc_ver1_23.bin
 mode change 120000 => 100644 i915/skl_guc_ver1.bin
 delete mode 100644 i915/skl_guc_ver1_1059.bin
 mode change 120000 => 100644 i915/skl_guc_ver4.bin
 delete mode 100644 i915/skl_guc_ver4_3.bin

Thanks,
Rodrigo.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: linux-firmware-i915 pull request (bxt dmc, kbl dmc)

[Kyle McMartin]

On Fri, Jul 01, 2016 at 11:20:09PM +0000, Vivi, Rodrigo wrote:
> Hi,
> 
> Please consider pulling i915 updates to linux-firmware.git
> 
> 
> The following changes since commit
> 040c24514b94fcdbd6308d986d1bde59a704a21a:
> 
>   linux-firmware: intel: Update Broxton audio firmware (2016-06-29
> 14:20:20 +0530)
> 
> are available in the git repository at:
> 
>   git://people.freedesktop.org/~vivijim/linux-firmware-i915 master
> 

Pulled, thanks Rodrigo.

cheers, --Kyle

> for you to fetch changes up to
> 19b71af5326bf28fe62ac2b1607b5e18d4b0eeb6:
> 
>   linux-firmware/i915: Step away from symbolic links and clean up repo.
> (2016-07-01 16:07:52 -0700)
> 
> ----------------------------------------------------------------
> Rodrigo Vivi (3):
>       linux-firmware: New minor DMC release for Broxton - ver1_07
>       linux-firmware: First DMC image for Kabylake.
>       linux-firmware/i915: Step away from symbolic links and clean up
> repo.
> 
>  WHENCE                                            |  14 +++++---------
>  i915/bxt_dmc_ver1.bin                             |   2 +-
>  i915/bxt_dmc_ver1_04.bin                          | Bin 5872 -> 0
> bytes
>  i915/bxt_dmc_ver1_05.bin                          | Bin 5872 -> 0
> bytes
>  i915/{bxt_dmc_ver1_06.bin => bxt_dmc_ver1_07.bin} | Bin 8380 -> 8380
> bytes
>  i915/kbl_dmc_ver1.bin                             |   1 +
>  i915/kbl_dmc_ver1_01.bin                          | Bin 0 -> 8616
> bytes
>  i915/skl_dmc_ver1_23.bin                          | Bin 8824 -> 0
> bytes
>  i915/skl_guc_ver1.bin                             | Bin 21 -> 109636
> bytes
>  i915/skl_guc_ver1_1059.bin                        | Bin 109636 -> 0
> bytes
>  i915/skl_guc_ver4.bin                             | Bin 18 -> 128320
> bytes
>  i915/skl_guc_ver4_3.bin                           | Bin 128320 -> 0
> bytes
>  12 files changed, 7 insertions(+), 10 deletions(-)
>  delete mode 100644 i915/bxt_dmc_ver1_04.bin
>  delete mode 100644 i915/bxt_dmc_ver1_05.bin
>  rename i915/{bxt_dmc_ver1_06.bin => bxt_dmc_ver1_07.bin} (64%)
>  create mode 120000 i915/kbl_dmc_ver1.bin
>  create mode 100644 i915/kbl_dmc_ver1_01.bin
>  delete mode 100644 i915/skl_dmc_ver1_23.bin
>  mode change 120000 => 100644 i915/skl_guc_ver1.bin
>  delete mode 100644 i915/skl_guc_ver1_1059.bin
>  mode change 120000 => 100644 i915/skl_guc_ver4.bin
>  delete mode 100644 i915/skl_guc_ver4_3.bin
> 
> Thanks,
> Rodrigo.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: linux-firmware-i915 pull request (bxt dmc, kbl dmc)

[Vivi, Rodrigo]

Hi Kyle,

I don't see this propagated yet to http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/

What am I missing?

Thanks,
Rodrigo.

-----Original Message-----
From: Kyle McMartin [mailto:kyle@infradead.org] 
Sent: Tuesday, July 05, 2016 6:44 AM
To: Vivi, Rodrigo
Cc: intel-gfx@lists.freedesktop.org; kyle@infradead.org; linux-firmware@kernel.org
Subject: Re: linux-firmware-i915 pull request (bxt dmc, kbl dmc)

On Fri, Jul 01, 2016 at 11:20:09PM +0000, Vivi, Rodrigo wrote:
> Hi,
> 
> Please consider pulling i915 updates to linux-firmware.git
> 
> 
> The following changes since commit
> 040c24514b94fcdbd6308d986d1bde59a704a21a:
> 
>   linux-firmware: intel: Update Broxton audio firmware (2016-06-29
> 14:20:20 +0530)
> 
> are available in the git repository at:
> 
>   git://people.freedesktop.org/~vivijim/linux-firmware-i915 master
> 

Pulled, thanks Rodrigo.

cheers, --Kyle

> for you to fetch changes up to
> 19b71af5326bf28fe62ac2b1607b5e18d4b0eeb6:
> 
>   linux-firmware/i915: Step away from symbolic links and clean up repo.
> (2016-07-01 16:07:52 -0700)
> 
> ----------------------------------------------------------------
> Rodrigo Vivi (3):
>       linux-firmware: New minor DMC release for Broxton - ver1_07
>       linux-firmware: First DMC image for Kabylake.
>       linux-firmware/i915: Step away from symbolic links and clean up 
> repo.
> 
>  WHENCE                                            |  14 
> +++++---------
>  i915/bxt_dmc_ver1.bin                             |   2 +-
>  i915/bxt_dmc_ver1_04.bin                          | Bin 5872 -> 0 
> bytes
>  i915/bxt_dmc_ver1_05.bin                          | Bin 5872 -> 0 
> bytes
>  i915/{bxt_dmc_ver1_06.bin => bxt_dmc_ver1_07.bin} | Bin 8380 -> 8380 
> bytes
>  i915/kbl_dmc_ver1.bin                             |   1 +
>  i915/kbl_dmc_ver1_01.bin                          | Bin 0 -> 8616 
> bytes
>  i915/skl_dmc_ver1_23.bin                          | Bin 8824 -> 0 
> bytes
>  i915/skl_guc_ver1.bin                             | Bin 21 -> 109636 
> bytes
>  i915/skl_guc_ver1_1059.bin                        | Bin 109636 -> 0 
> bytes
>  i915/skl_guc_ver4.bin                             | Bin 18 -> 128320 
> bytes
>  i915/skl_guc_ver4_3.bin                           | Bin 128320 -> 0 
> bytes
>  12 files changed, 7 insertions(+), 10 deletions(-)
>  delete mode 100644 i915/bxt_dmc_ver1_04.bin
>  delete mode 100644 i915/bxt_dmc_ver1_05.bin
>  rename i915/{bxt_dmc_ver1_06.bin => bxt_dmc_ver1_07.bin} (64%)
>  create mode 120000 i915/kbl_dmc_ver1.bin
>  create mode 100644 i915/kbl_dmc_ver1_01.bin
>  delete mode 100644 i915/skl_dmc_ver1_23.bin
>  mode change 120000 => 100644 i915/skl_guc_ver1.bin
>  delete mode 100644 i915/skl_guc_ver1_1059.bin
>  mode change 120000 => 100644 i915/skl_guc_ver4.bin
>  delete mode 100644 i915/skl_guc_ver4_3.bin
> 
> Thanks,
> Rodrigo.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: linux-firmware-i915 pull request (bxt dmc, kbl dmc)

[Jani Nikula]

On Sat, 02 Jul 2016, "Vivi, Rodrigo" <rodrigo.vivi@intel.com> wrote:
> Hi,
>
> Please consider pulling i915 updates to linux-firmware.git
>
>
> The following changes since commit
> 040c24514b94fcdbd6308d986d1bde59a704a21a:
>
>   linux-firmware: intel: Update Broxton audio firmware (2016-06-29
> 14:20:20 +0530)
>
> are available in the git repository at:
>
>   git://people.freedesktop.org/~vivijim/linux-firmware-i915 master
>
> for you to fetch changes up to
> 19b71af5326bf28fe62ac2b1607b5e18d4b0eeb6:
>
>   linux-firmware/i915: Step away from symbolic links and clean up repo.
> (2016-07-01 16:07:52 -0700)
>
> ----------------------------------------------------------------
> Rodrigo Vivi (3):
>       linux-firmware: New minor DMC release for Broxton - ver1_07
>       linux-firmware: First DMC image for Kabylake.
>       linux-firmware/i915: Step away from symbolic links and clean up
> repo.
>
>  WHENCE                                            |  14 +++++---------
>  i915/bxt_dmc_ver1.bin                             |   2 +-
>  i915/bxt_dmc_ver1_04.bin                          | Bin 5872 -> 0
> bytes
>  i915/bxt_dmc_ver1_05.bin                          | Bin 5872 -> 0
> bytes
>  i915/{bxt_dmc_ver1_06.bin => bxt_dmc_ver1_07.bin} | Bin 8380 -> 8380
> bytes
>  i915/kbl_dmc_ver1.bin                             |   1 +
>  i915/kbl_dmc_ver1_01.bin                          | Bin 0 -> 8616
> bytes
>  i915/skl_dmc_ver1_23.bin                          | Bin 8824 -> 0
> bytes
>  i915/skl_guc_ver1.bin                             | Bin 21 -> 109636
> bytes
>  i915/skl_guc_ver1_1059.bin                        | Bin 109636 -> 0
> bytes
>  i915/skl_guc_ver4.bin                             | Bin 18 -> 128320
> bytes
>  i915/skl_guc_ver4_3.bin                           | Bin 128320 -> 0
> bytes
>  12 files changed, 7 insertions(+), 10 deletions(-)
>  delete mode 100644 i915/bxt_dmc_ver1_04.bin
>  delete mode 100644 i915/bxt_dmc_ver1_05.bin
>  rename i915/{bxt_dmc_ver1_06.bin => bxt_dmc_ver1_07.bin} (64%)
>  create mode 120000 i915/kbl_dmc_ver1.bin
>  create mode 100644 i915/kbl_dmc_ver1_01.bin
>  delete mode 100644 i915/skl_dmc_ver1_23.bin
>  mode change 120000 => 100644 i915/skl_guc_ver1.bin
>  delete mode 100644 i915/skl_guc_ver1_1059.bin
>  mode change 120000 => 100644 i915/skl_guc_ver4.bin
>  delete mode 100644 i915/skl_guc_ver4_3.bin

Why are you deleting old versions?

BR,
Jani.

>
> Thanks,
> Rodrigo.
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: linux-firmware-i915 pull request (bxt dmc, kbl dmc)

[Vivi, Rodrigo]

On Tue, 2016-08-02 at 14:04 +0300, Jani Nikula wrote:
> On Sat, 02 Jul 2016, "Vivi, Rodrigo" <rodrigo.vivi@intel.com> wrote:
> > 
> > Hi,
> > 
> > Please consider pulling i915 updates to linux-firmware.git
> > 
> > 
> > The following changes since commit
> > 040c24514b94fcdbd6308d986d1bde59a704a21a:
> > 
> >   linux-firmware: intel: Update Broxton audio firmware (2016-06-29
> > 14:20:20 +0530)
> > 
> > are available in the git repository at:
> > 
> >   git://people.freedesktop.org/~vivijim/linux-firmware-i915 master
> > 
> > for you to fetch changes up to
> > 19b71af5326bf28fe62ac2b1607b5e18d4b0eeb6:
> > 
> >   linux-firmware/i915: Step away from symbolic links and clean up
> > repo.
> > (2016-07-01 16:07:52 -0700)
> > 
> > ----------------------------------------------------------------
> > Rodrigo Vivi (3):
> >       linux-firmware: New minor DMC release for Broxton - ver1_07
> >       linux-firmware: First DMC image for Kabylake.
> >       linux-firmware/i915: Step away from symbolic links and clean
> > up
> > repo.
> > 
> >  WHENCE                                            |  14 +++++-----
> > ----
> >  i915/bxt_dmc_ver1.bin                             |   2 +-
> >  i915/bxt_dmc_ver1_04.bin                          | Bin 5872 -> 0
> > bytes
> >  i915/bxt_dmc_ver1_05.bin                          | Bin 5872 -> 0
> > bytes
> >  i915/{bxt_dmc_ver1_06.bin => bxt_dmc_ver1_07.bin} | Bin 8380 ->
> > 8380
> > bytes
> >  i915/kbl_dmc_ver1.bin                             |   1 +
> >  i915/kbl_dmc_ver1_01.bin                          | Bin 0 -> 8616
> > bytes
> >  i915/skl_dmc_ver1_23.bin                          | Bin 8824 -> 0
> > bytes
> >  i915/skl_guc_ver1.bin                             | Bin 21 ->
> > 109636
> > bytes
> >  i915/skl_guc_ver1_1059.bin                        | Bin 109636 ->
> > 0
> > bytes
> >  i915/skl_guc_ver4.bin                             | Bin 18 ->
> > 128320
> > bytes
> >  i915/skl_guc_ver4_3.bin                           | Bin 128320 ->
> > 0
> > bytes
> >  12 files changed, 7 insertions(+), 10 deletions(-)
> >  delete mode 100644 i915/bxt_dmc_ver1_04.bin
> >  delete mode 100644 i915/bxt_dmc_ver1_05.bin
> >  rename i915/{bxt_dmc_ver1_06.bin => bxt_dmc_ver1_07.bin} (64%)
> >  create mode 120000 i915/kbl_dmc_ver1.bin
> >  create mode 100644 i915/kbl_dmc_ver1_01.bin
> >  delete mode 100644 i915/skl_dmc_ver1_23.bin
> >  mode change 120000 => 100644 i915/skl_guc_ver1.bin
> >  delete mode 100644 i915/skl_guc_ver1_1059.bin
> >  mode change 120000 => 100644 i915/skl_guc_ver4.bin
> >  delete mode 100644 i915/skl_guc_ver4_3.bin
> Why are you deleting old versions?

Mainly to keep it clean. OSVs pack that entire repo, I don't want i915
taking unnecessary space from final users.

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.

> 
> BR,
> Jani.
> 
> > 
> > 
> > Thanks,
> > Rodrigo.
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> -- 
> Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: linux-firmware-i915 pull request (bxt dmc, kbl dmc)

[Ben Hutchings]

[-- Attachment #1.1: Type: text/plain, Size: 1575 bytes --]

On Tue, 2016-08-02 at 20:48 +0000, Vivi, Rodrigo wrote:
> On Tue, 2016-08-02 at 14:04 +0300, Jani Nikula wrote:
[...]
> > Why are you deleting old versions?
> 
> Mainly to keep it clean. OSVs pack that entire repo, I don't want i915
> taking unnecessary space from final users.

Any filename requested by a driver in a stable release of Linux should
not be removed from linux-firmware.git.  If it's buggy then it should
be replaced it with a fixed version.  I can envisage extreme cases
where we might make an exception but AFAIK this has not happened yet.

The OS vendor knows which kernel versions they want to support and
which files can therefore be dropped.  I do that for Debian
periodically.

> 
> 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.

Ben.

-- 

Ben Hutchings
Nothing is ever a complete failure; it can always serve as a bad
example.

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: linux-firmware-i915 pull request (bxt dmc, kbl dmc)

[Jani Nikula]

On Wed, 03 Aug 2016, Ben Hutchings <ben@decadent.org.uk> wrote:
> [ Unknown signature status ]
> On Tue, 2016-08-02 at 20:48 +0000, Vivi, Rodrigo wrote:
>> On Tue, 2016-08-02 at 14:04 +0300, Jani Nikula wrote:
> [...]
>> > Why are you deleting old versions?
>> 
>> Mainly to keep it clean. OSVs pack that entire repo, I don't want i915
>> taking unnecessary space from final users.
>
> Any filename requested by a driver in a stable release of Linux should
> not be removed from linux-firmware.git.  If it's buggy then it should
> be replaced it with a fixed version.  I can envisage extreme cases
> where we might make an exception but AFAIK this has not happened yet.

Rodrigo, https://bugs.freedesktop.org/show_bug.cgi?id=97182

> The OS vendor knows which kernel versions they want to support and
> which files can therefore be dropped.  I do that for Debian
> periodically.
>
>> 
>> 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.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: linux-firmware-i915 pull request (bxt dmc, kbl dmc)

[Daniel Vetter]

On Wed, Aug 3, 2016 at 11:08 AM, Jani Nikula
<jani.nikula@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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: linux-firmware-i915 pull request (bxt dmc, kbl dmc)

[Vivi, Rodrigo]

So, issues like https://bugs.freedesktop.org/show_bug.cgi?id=97182

will appear with frequency now...

should we just close all as wontfix?

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@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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: linux-firmware-i915 pull request (bxt dmc, kbl dmc)

[Daniel Vetter]

On Wed, Aug 3, 2016 at 5:06 PM, Vivi, Rodrigo <rodrigo.vivi@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@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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: linux-firmware-i915 pull request (bxt dmc, kbl dmc)

[Vivi, Rodrigo]

But we know that 1.23 is bad and cause issues regardless the kernel
version. And please keep in mind this is the most common case.
Usually a previous minor version was dropped in favor of a new one
because we found a bug that got fixed in a following minor version.
This is the minor version idea. So regardless the kernel version, the
newest minor is probably safest than the previous one.

So, I don't want to keep all versions in linux-firmware.git, specially
those that we know that cause bad issues.

And here is the case were only symbolic link would help imho.

On Wed, 2016-08-03 at 17:08 +0200, Daniel Vetter wrote:
> On Wed, Aug 3, 2016 at 5:06 PM, Vivi, Rodrigo <rodrigo.vivi@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@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
> 
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: linux-firmware-i915 pull request (bxt dmc, kbl dmc)

[Daniel Vetter]

On Wed, Aug 3, 2016 at 5:12 PM, Vivi, Rodrigo <rodrigo.vivi@intel.com> wrote:
>
> But we know that 1.23 is bad and cause issues regardless the kernel
> version. And please keep in mind this is the most common case.
> Usually a previous minor version was dropped in favor of a new one
> because we found a bug that got fixed in a following minor version.
> This is the minor version idea. So regardless the kernel version, the
> newest minor is probably safest than the previous one.
>
> So, I don't want to keep all versions in linux-firmware.git, specially
> those that we know that cause bad issues.
>
> And here is the case were only symbolic link would help imho.

If a system goes from "mostly works" to "fails because DMC isn't there
any more" then that's a regression. Which means we _must_ resstore
1.23.

Of course it's not great that it's just "mostly works" and not "works
really well", and for that we need to make sure a fixed DMC is in
linux-firmware, and once that has landed we can backport the
kernel-side bugfixes plus allow the kernel to either load the new
fixed dmc, or if that's not there fall back to 1.23. Because if we
don't do that, then it goes again boom.

Jani's point (which I fully support) is that we should do that
backporting of the support for the new/fixed dmc firmware explicitly,
and not automatically through a symlink. Because it could be that the
new firmware also needs some (small) kernel changes to work well. And
we definitely want to be able to test with the new firmware, and have
the ability to revert the backport on stable kernels again in case it
blows up for some reason that we don't understand and don't have the
resources to debug. Since again all these cases would be regressions.

So definitely don't want to let people hung out there with bad dmc
versions. We just need to be careful that we don't regress anything,
and that we can make sure that we can revert again if some backport
does blow up.

I hope that explains.

Cheers, Daniel


>
> On Wed, 2016-08-03 at 17:08 +0200, Daniel Vetter wrote:
>> On Wed, Aug 3, 2016 at 5:06 PM, Vivi, Rodrigo <rodrigo.vivi@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@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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: linux-firmware-i915 pull request (bxt dmc, kbl dmc)

[Vivi, Rodrigo]

On Wed, 2016-08-03 at 17:26 +0200, Daniel Vetter wrote:
> On Wed, Aug 3, 2016 at 5:12 PM, Vivi, Rodrigo <rodrigo.vivi@intel.com
> > wrote:
> > 
> > 
> > But we know that 1.23 is bad and cause issues regardless the kernel
> > version. And please keep in mind this is the most common case.
> > Usually a previous minor version was dropped in favor of a new one
> > because we found a bug that got fixed in a following minor version.
> > This is the minor version idea. So regardless the kernel version,
> > the
> > newest minor is probably safest than the previous one.
> > 
> > So, I don't want to keep all versions in linux-firmware.git,
> > specially
> > those that we know that cause bad issues.
> > 
> > And here is the case were only symbolic link would help imho.
> If a system goes from "mostly works" to "fails because DMC isn't
> there
> any more" then that's a regression. Which means we _must_ resstore
> 1.23.

From what I can remember it causes GPU Hangs depending on what you are
running on the GPU.



> Of course it's not great that it's just "mostly works" and not "works
> really well", and for that we need to make sure a fixed DMC is in
> linux-firmware, and once that has landed we can backport the
> kernel-side bugfixes plus allow the kernel to either load the new
> fixed dmc, or if that's not there fall back to 1.23. Because if we
> don't do that, then it goes again boom.

What also highlights that we will never be testing with all combination
of possible userspace graphical environments and versions out there.
So
it is lame to tell that we just support combinations we tested and we
are sure because we are not testing with all combinations out there
anyway.

> 
> Jani's point (which I fully support) is that we should do that
> backporting of the support for the new/fixed dmc firmware explicitly,
> and not automatically through a symlink. Because it could be that the
> new firmware also needs some (small) kernel changes to work well. 

The rule is that if any software change is required we should bump the
major version. The only accepted patch that shouldn't bump the major
are the one touching the recommended version or blacklisting known bad
firmware versions.

> And
> we definitely want to be able to test with the new firmware, and have
> the ability to revert the backport on stable kernels again in case it
> blows up for some reason that we don't understand and don't have the
> resources to debug. Since again all these cases would be regressions.

This is another thing Chris had pointed already also. Without
installing all firmware blobs possible in the system we won't be able
to bisect anyway.

> 
> So definitely don't want to let people hung out there with bad dmc
> versions. We just need to be careful that we don't regress anything,
> and that we can make sure that we can revert again if some backport
> does blow up.

But what I also don't want is to be blamed by blowing up the size of
the linux-firmware.git packages in all OSV's distros because we decided
to keep all versions there.

We are the only linux-firmware.git user that keeps multiple versions
and with this new rule of having to let old blobs there, it will blow
up soon.

> 
> I hope that explains.
> 

It does. I just don't agree. Well, not anymore actually ;) 

But this is a maintainer call so I will get 1.23 back and keep all old
versions now on.

Thanks,
Rodrigo.

> Cheers, Daniel
> 
> 
> > 
> > 
> > On Wed, 2016-08-03 at 17:08 +0200, Daniel Vetter wrote:
> > > 
> > > On Wed, Aug 3, 2016 at 5:06 PM, Vivi, Rodrigo <rodrigo.vivi@intel
> > > .com
> > > > 
> > > > wrote:
> > > > 
> > > > So, issues like https://bugs.freedesktop.org/show_bug.cgi?id=97
> > > > 182
> > > > 
> > > > 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@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
> > > 
> 
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: linux-firmware-i915 pull request (bxt dmc, kbl dmc)

[David Weinehall]

On Wed, Aug 03, 2016 at 03:48:02PM +0000, Vivi, Rodrigo wrote:
> On Wed, 2016-08-03 at 17:26 +0200, Daniel Vetter wrote:
> > On Wed, Aug 3, 2016 at 5:12 PM, Vivi, Rodrigo <rodrigo.vivi@intel.com
> > > wrote:
> > > 
> > > 
> > > But we know that 1.23 is bad and cause issues regardless the kernel
> > > version. And please keep in mind this is the most common case.
> > > Usually a previous minor version was dropped in favor of a new one
> > > because we found a bug that got fixed in a following minor version.
> > > This is the minor version idea. So regardless the kernel version,
> > > the
> > > newest minor is probably safest than the previous one.
> > > 
> > > So, I don't want to keep all versions in linux-firmware.git,
> > > specially
> > > those that we know that cause bad issues.
> > > 
> > > And here is the case were only symbolic link would help imho.
> > If a system goes from "mostly works" to "fails because DMC isn't
> > there
> > any more" then that's a regression. Which means we _must_ resstore
> > 1.23.
> 
> From what I can remember it causes GPU Hangs depending on what you are
> running on the GPU.

Sounds like we should submit a fix to stable that makes the minimum
required version 1.26 if that's indeed the case. I wonder if this
the cause of all the hangs I've seen on my Skylake laptop lately;
I have both 1.23 and 1.26 installed, so I hadn't noticed that it's
loading 1.23 instead of 1.26.


Kind regards, David Weinehall
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx