Re: PR for BMG DMC v2.06

[Josh Boyer]

Merged and pushed out.

https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/210

josh

On Thu, May 9, 2024 at 1:47 PM Gustavo Sousa  wrote:
>
> The following changes since commit 93f329774542b9b7d57abb18ea8b6542f2d8feac:
>
>   Merge branch 'robot/pr-0-1709214990' into 'main' (2024-02-29 14:10:53 +)
>
> are available in the Git repository at:
>
>   https://gitlab.freedesktop.org/drm/firmware.git tags/intel-2024-05-09
>
> for you to fetch changes up to 8724b227b8999e11cf89601fec9f6f80795d8fa8:
>
>   i915: Add BMG DMC v2.06 (2024-05-09 15:10:44 -0300)
>
> 
> Intel DRM firmware intel-2024-05-09
>
> 
> Daniele Ceraolo Spurio (1):
>   i915: Add DG2 HuC 7.10.15
>
> Dnyaneshwar Bhadane (1):
>   i915: Update Xe2LPD DMC to v2.20
>
> Gustavo Sousa (1):
>   i915: Add BMG DMC v2.06
>
>  WHENCE   |   7 +--
>  i915/bmg_dmc.bin | Bin 0 -> 45964 bytes
>  i915/dg2_huc_gsc.bin | Bin 622592 -> 630784 bytes
>  i915/xe2lpd_dmc.bin  | Bin 61208 -> 59284 bytes
>  4 files changed, 5 insertions(+), 2 deletions(-)
>  create mode 100644 i915/bmg_dmc.bin
>  mode change 100755 => 100644 i915/dg2_huc_gsc.bin

Re: PR for Xe2LPD DMC v2.20

[Josh Boyer]

On Wed, Apr 24, 2024 at 4:05 PM Gustavo Sousa  wrote:
>
> The following changes since commit 93f329774542b9b7d57abb18ea8b6542f2d8feac:
>
>   Merge branch 'robot/pr-0-1709214990' into 'main' (2024-02-29 14:10:53 +)
>
> are available in the Git repository at:
>
>   https://gitlab.freedesktop.org/drm/firmware.git tags/intel-2024-04-24

Merged and pushed out.

https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/201

josh

>
> for you to fetch changes up to 8a52a94db5502d797864f5209c28739d2d9449d0:
>
>   i915: Update Xe2LPD DMC to v2.20 (2024-04-22 23:31:42 +0530)
>
> 
> Intel DRM firmware intel-2024-04-24
>
> 
> Daniele Ceraolo Spurio (1):
>   i915: Add DG2 HuC 7.10.15
>
> Dnyaneshwar Bhadane (1):
>   i915: Update Xe2LPD DMC to v2.20
>
>  WHENCE   |   4 ++--
>  i915/dg2_huc_gsc.bin | Bin 622592 -> 630784 bytes
>  i915/xe2lpd_dmc.bin  | Bin 61208 -> 59284 bytes
>  3 files changed, 2 insertions(+), 2 deletions(-)
>  mode change 100755 => 100644 i915/dg2_huc_gsc.bin

Re: [PATCH 2/6] drm/i915/dmc: define firmware URL locally

[Josh Boyer]

On Fri, Apr 5, 2024 at 4:29 PM Lucas De Marchi  wrote:
>
> On Fri, Apr 05, 2024 at 10:37:39PM +0300, Jani Nikula wrote:
> >Avoid the dependency on intel_uc_fw.h, and allow removal of xe compat
> >intel_uc_fw.h. If there needs to be duplication of the URL, at least
> >have the duplication in a sensible way.
> >
> >Cc: Lucas De Marchi 
> >Signed-off-by: Jani Nikula 
>
>
> Reviewed-by: Lucas De Marchi 
>
> but see below. +Josh
>
> >---
> > drivers/gpu/drm/i915/display/intel_dmc.c |  4 +++-
> > drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h|  1 -
> > drivers/gpu/drm/xe/compat-i915-headers/intel_uc_fw.h | 11 ---
> > 3 files changed, 3 insertions(+), 13 deletions(-)
> > delete mode 100644 drivers/gpu/drm/xe/compat-i915-headers/intel_uc_fw.h
> >
> >diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
> >b/drivers/gpu/drm/i915/display/intel_dmc.c
> >index 3fa851b5c7a6..e61e9c1b8947 100644
> >--- a/drivers/gpu/drm/i915/display/intel_dmc.c
> >+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> >@@ -38,6 +38,8 @@
> >  * low-power state and comes back to normal.
> >  */
> >
> >+#define INTEL_DMC_FIRMWARE_URL 
> >"https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git;
>
> repo recently moved to gitlab, but as far as I know the one on
> kernel.org will still work. Do we want to change it?
>
> https://gitlab.com/kernel-firmware/linux-firmware

I don't think there's a need to change it right now.  I can't see us
removing the kernel.org linux-firmware tree.  Given it's firmware, I
don't think the defined macro is really trying to point to a
contribution site either so pointing to gitlab probably isn't
worthwhile.

josh

> thanks
> Lucas De Marchi
>
> >+
> > enum intel_dmc_id {
> >   DMC_FW_MAIN = 0,
> >   DMC_FW_PIPEA,
> >@@ -953,7 +955,7 @@ static void dmc_load_work_fn(struct work_struct *work)
> >  " Disabling runtime power management.\n",
> >  dmc->fw_path);
> >   drm_notice(>drm, "DMC firmware homepage: %s",
> >- INTEL_UC_FIRMWARE_URL);
> >+ INTEL_DMC_FIRMWARE_URL);
> >   }
> >
> >   release_firmware(fw);
> >diff --git a/drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h 
> >b/drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h
> >index a01d1b869c2d..837e95e3604e 100644
> >--- a/drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h
> >+++ b/drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h
> >@@ -26,7 +26,6 @@
> > #include "i915_utils.h"
> > #include "intel_gt_types.h"
> > #include "intel_step.h"
> >-#include "intel_uc_fw.h"
> > #include "intel_uncore.h"
> > #include "intel_runtime_pm.h"
> > #include 
> >diff --git a/drivers/gpu/drm/xe/compat-i915-headers/intel_uc_fw.h 
> >b/drivers/gpu/drm/xe/compat-i915-headers/intel_uc_fw.h
> >deleted file mode 100644
> >index 009745328992..
> >--- a/drivers/gpu/drm/xe/compat-i915-headers/intel_uc_fw.h
> >+++ /dev/null
> >@@ -1,11 +0,0 @@
> >-/* SPDX-License-Identifier: MIT */
> >-/*
> >- * Copyright © 2023 Intel Corporation
> >- */
> >-
> >-#ifndef _INTEL_UC_FW_H_
> >-#define _INTEL_UC_FW_H_
> >-
> >-#define INTEL_UC_FIRMWARE_URL 
> >"https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git;
> >-
> >-#endif
> >--
> >2.39.2
> >
>

Re: [PR] i915: Add DG2 HuC to 7.10.15

[Josh Boyer]

On Mon, Apr 1, 2024 at 2:50 PM Daniele Ceraolo Spurio
 wrote:
>
> The following changes since commit 93f329774542b9b7d57abb18ea8b6542f2d8feac:
>
>   Merge branch 'robot/pr-0-1709214990' into 'main' (2024-02-29 14:10:53 +)
>
> are available in the Git repository at:
>
>   g...@gitlab.freedesktop.org:drm/firmware.git tags/intel-2024-04-01

Merged and pushed out.

https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/188

josh

>
> for you to fetch changes up to ab144168469a77f54ad539ac98dede7ce4c6a75d:
>
>   i915: Add DG2 HuC 7.10.15 (2024-03-28 13:45:41 -0700)
>
> 
> Daniele Ceraolo Spurio (1):
>   i915: Add DG2 HuC 7.10.15
>
>  WHENCE   |   2 +-
>  i915/dg2_huc_gsc.bin | Bin 622592 -> 630784 bytes
>  2 files changed, 1 insertion(+), 1 deletion(-)
>  mode change 100755 => 100644 i915/dg2_huc_gsc.bin

Re: PR for Xe2LPD DMC v2.18

[Josh Boyer]

On Thu, Feb 22, 2024 at 2:56 PM Gustavo Sousa  wrote:
>
> The following changes since commit 78b99e9ebad8e4e24dded99842f94a8a7db3a5e8:
>
>   Merge branch 'robot/pr-0-1708610465' into 'main' (2024-02-22 14:24:47 +)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware xe2lpd_dmc_2.18

Pulled and pushed out.

https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/160

josh

>
> for you to fetch changes up to 94d9a511a605cc0794bbe2d13328143e86df26e9:
>
>   i915: Add Xe2LPD DMC v2.18 (2024-02-22 16:54:31 -0300)
>
> 
> Gustavo Sousa (1):
>   i915: Add Xe2LPD DMC v2.18
>
>  WHENCE  |   3 +++
>  i915/xe2lpd_dmc.bin | Bin 0 -> 61208 bytes
>  2 files changed, 3 insertions(+)
>  create mode 100644 i915/xe2lpd_dmc.bin

Re: PR for MTL DMC v2.21

[Josh Boyer]

On Thu, Feb 22, 2024 at 8:58 AM Gustavo Sousa  wrote:
>
> The following changes since commit 97b693d243f0bb464819fa3f8326edd4091032e4:
>
>   Merge branch 'mediatek' into 'main' (2024-02-20 15:13:01 +)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware mtl_dmc_2.21

Pulled and pushed out.

https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/159

josh

>
> for you to fetch changes up to 98502ba83a6db0e4dc99aa1fa292e48b1dc8d0ce:
>
>   i915: Update MTL DMC v2.21 (2024-02-22 10:51:16 -0300)
>
> 
> Gustavo Sousa (1):
>   i915: Update MTL DMC v2.21
>
>  WHENCE   |   2 +-
>  i915/mtl_dmc.bin | Bin 52476 -> 52476 bytes
>  2 files changed, 1 insertion(+), 1 deletion(-)

Re: PR for new GuC v70.20.0 binaries

[Josh Boyer]

On Fri, Feb 16, 2024 at 4:16 PM  wrote:
>
> The following changes since commit fbef4d381e3d0143427e1a8c924be8e738c0fc2d:
>
>   Merge branch 'main' into 'main' (2024-02-08 12:24:01 +)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware guc_70.20.0

Merged and pushed out.

https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/156

josh

>
> for you to fetch changes up to 28c2472d37d089edb56c75e3af83511babaa756c:
>
>   xe: First GuC release for LNL and Xe (2024-02-14 16:28:32 -0800)
>
> 
> John Harrison (2):
>   i915: Add GuC v70.20.0 for ADL-P, DG1, DG2, MTL and TGL
>   xe: First GuC release for LNL and Xe
>
>  LICENSE.xe   |  39 +++
>  WHENCE   |  20 ++--
>  i915/adlp_guc_70.bin | Bin 342848 -> 347584 bytes
>  i915/dg1_guc_70.bin  | Bin 272512 -> 321472 bytes
>  i915/dg2_guc_70.bin  | Bin 443200 -> 410368 bytes
>  i915/mtl_guc_70.bin  | Bin 365376 -> 332544 bytes
>  i915/tgl_guc_70.bin  | Bin 330304 -> 335168 bytes
>  xe/lnl_guc_70.bin| Bin 0 -> 336640 bytes
>  8 files changed, 53 insertions(+), 6 deletions(-)
>  create mode 100644 LICENSE.xe
>  create mode 100644 xe/lnl_guc_70.bin

Re: [Intel-gfx] PR for MTL DMC v2.19

[Josh Boyer]

On Fri, Nov 17, 2023 at 10:07 AM Gustavo Sousa  wrote:
>
> The following changes since commit 6723a8d9092325d00a125a1b3ca058644f74d314:
>
>   Merge branch 'robot/pr-5-1700153542' into 'main' (2023-11-16 16:54:38 +)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware mtl_dmc_2.19

Pulled and pushed out.
https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/65

josh

>
> for you to fetch changes up to 451090149cecfae5e674d24944579a564afefe8a:
>
>   i915: Update MTL DMC to v2.19 (2023-11-17 11:03:16 -0300)
>
> 
> Gustavo Sousa (1):
>   i915: Update MTL DMC to v2.19
>
>  WHENCE   |   2 +-
>  i915/mtl_dmc.bin | Bin 52508 -> 52476 bytes
>  2 files changed, 1 insertion(+), 1 deletion(-)

Re: [Intel-gfx] [CI] PR for new GuC v70.13.1

[Josh Boyer]

Already merged.

josh

On Wed, Oct 18, 2023 at 3:11 PM John Harrison  wrote:
>
> Apologies, I sent this with the wrong subject. Please ignore. Will
> resend with the correct subject.
>
> John.
>
>
> On 10/18/2023 12:07, john.c.harri...@intel.com wrote:
> > The following changes since commit 7727f7e3b3358713c7c91c64a835e80c331a6b8b:
> >
> >Merge branch 'patch-1696561325' into 'main' (2023-10-06 03:04:57 +)
> >
> > are available in the Git repository at:
> >
> >git://anongit.freedesktop.org/drm/drm-firmware guc_70.13.1
> >
> > for you to fetch changes up to 44a9510c94ac0334931b6c89dd240ffe5bf1e5fa:
> >
> >i915: Add GuC v70.13.1 for DG2, TGL, ADL-P and MTL (2023-10-13 11:34:26 
> > -0700)
> >
> > 
> > John Harrison (1):
> >i915: Add GuC v70.13.1 for DG2, TGL, ADL-P and MTL
> >
> >   WHENCE   |   8 
> >   i915/adlp_guc_70.bin | Bin 297984 -> 342848 bytes
> >   i915/dg2_guc_70.bin  | Bin 385856 -> 443200 bytes
> >   i915/mtl_guc_70.bin  | Bin 308032 -> 365376 bytes
> >   i915/tgl_guc_70.bin  | Bin 285888 -> 330304 bytes
> >   5 files changed, 4 insertions(+), 4 deletions(-)
>

Re: [Intel-gfx] PR for MTL DMC v2.17

[Josh Boyer]

On Mon, Oct 2, 2023 at 8:59 AM Gustavo Sousa  wrote:
>
> The following changes since commit 8b855f3797e6b1d207b7a2b8dae0e9913f907e5b:
>
>   Merge branch 'main' into 'main' (2023-09-26 18:31:16 +)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware dmc-mtl_2.17

Pulled and pushed out.

josh

>
> for you to fetch changes up to 18b60f44e61c72eb5a5a36dc8e0381c77ba670b3:
>
>   i915: Update MTL DMC to v2.17 (2023-10-02 09:52:35 -0300)
>
> 
> Gustavo Sousa (1):
>   i915: Update MTL DMC to v2.17
>
>  WHENCE   |   2 +-
>  i915/mtl_dmc.bin | Bin 52388 -> 52508 bytes
>  2 files changed, 1 insertion(+), 1 deletion(-)

Re: [Intel-gfx] PR for HuC v8.5.4 for MTL

[Josh Boyer]

On Thu, Sep 14, 2023 at 11:49 AM Daniele Ceraolo Spurio
 wrote:
>
> The following changes since commit dfa11466cf000120d1551146fd5bf78c44941eda:
>
>   Merge branch 'main' into 'main' (2023-09-07 11:36:57 +)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware mtl_huc_8.5.4

Pulled and pushed out.

josh

>
> for you to fetch changes up to a5dbe400f776b0dc2d0a402ba76b4c16c231b38e:
>
>   i915: update MTL HuC to version 8.5.4 (2023-09-14 08:34:08 -0700)
>
> 
> Daniele Ceraolo Spurio (1):
>   i915: update MTL HuC to version 8.5.4
>
>  WHENCE   |   2 +-
>  i915/mtl_huc_gsc.bin | Bin 569344 -> 561152 bytes
>  2 files changed, 1 insertion(+), 1 deletion(-)

Re: [Intel-gfx] PR for MTL DMC v2.16

[Josh Boyer]

On Tue, Aug 29, 2023 at 8:56 AM Gustavo Sousa  wrote:
>
> The following changes since commit 659dfe6435b77a075d9896ff34250bcaab55d75b:
>
>   Merge tag 'amd-2023-08-25' of https://gitlab.freedesktop.org/drm/firmware 
> (2023-08-29 07:27:29 -0400)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware dmc-mtl_2.16

Pulled and pushed out.

josh

>
> for you to fetch changes up to 49f9e3479fb564ab96ebbfef327743b0ec2a7620:
>
>   i915: Update MTL DMC to v2.16 (2023-08-29 09:49:34 -0300)
>
> 
> Gustavo Sousa (1):
>   i915: Update MTL DMC to v2.16
>
>  WHENCE   |   2 +-
>  i915/mtl_dmc.bin | Bin 52164 -> 52388 bytes
>  2 files changed, 1 insertion(+), 1 deletion(-)

Re: [Intel-gfx] PR for GSC FW release 102.0.0.1655 for MTL

[Josh Boyer]

On Wed, Aug 23, 2023 at 2:43 PM Daniele Ceraolo Spurio
 wrote:
>
> The following changes since commit 0e048b061bde79ad735c7b7b5161ee1bd3400150:
>
>   Merge branch 'for-upstream' of 
> https://github.com/CirrusLogic/linux-firmware (2023-08-14 13:03:41 -0400)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware mtl_gsc_1655

Pulled and pushed out.

josh

>
> for you to fetch changes up to 81caac98eda1696fa057191ee969c377154a:
>
>   i915: add GSC 102.0.0.1655 for MTL (2023-08-21 14:13:11 -0700)
>
> 
> Daniele Ceraolo Spurio (1):
>   i915: add GSC 102.0.0.1655 for MTL
>
>  WHENCE |   3 +++
>  i915/mtl_gsc_1.bin | Bin 0 -> 1142784 bytes
>  2 files changed, 3 insertions(+)
>  create mode 100755 i915/mtl_gsc_1.bin

Re: [Intel-gfx] PR for ADLP DMC v2.20 and MTL DMC v2.13

[Josh Boyer]

On Wed, Jul 26, 2023 at 4:50 PM Gustavo Sousa  wrote:
>
> The following changes since commit b6ea35ff6b9869470a0c68813f1668acb3d356a8:
>
>   copy-firmware: Fix linking directories when using compression (2023-07-25 
> 06:53:30 -0400)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware dmc-adlp_2.20-mtl_2.13

Pulled and pushed out.

josh

>
> for you to fetch changes up to fd6e13ca2a1141aeede3666f72d2a006a3903fc0:
>
>   i915: Update MTL DMC to v2.13 (2023-07-26 13:59:54 -0300)
>
> 
> Gustavo Sousa (2):
>   i915: Update ADLP DMC to v2.20
>   i915: Update MTL DMC to v2.13
>
>  WHENCE|   4 ++--
>  i915/adlp_dmc.bin | Bin 79044 -> 79088 bytes
>  i915/mtl_dmc.bin  | Bin 49104 -> 52164 bytes
>  3 files changed, 2 insertions(+), 2 deletions(-)

Re: [Intel-gfx] [PR] GuC 70.8 for MTL and DG2 + HuC 8.5.1 for MTL

[Josh Boyer]

Pulled and pushed out.

josh

On Thu, Jul 20, 2023 at 1:35 PM Daniele Ceraolo Spurio
 wrote:
>
> The following changes since commit d3f66064cf43bd7338a79174bd0ff60c4ecbdf6d:
>
>   Partially revert "amdgpu: DMCUB updates for DCN 3.1.4 and 3.1.5" 
> (2023-07-07 15:24:32 -0400)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware dg2_mtl_guc_70.8
>
> for you to fetch changes up to 6f3a37f47d68d5e2108b98a900e4be910e8c7106:
>
>   i915: update DG2 GuC to v70.8.0 (2023-07-20 10:14:57 -0700)
>
> 
> Daniele Ceraolo Spurio (2):
>   i915: update to GuC 70.8.0 and HuC 8.5.1 for MTL
>   i915: update DG2 GuC to v70.8.0
>
>  WHENCE   |   6 +++---
>  i915/dg2_guc_70.bin  | Bin 369600 -> 385856 bytes
>  i915/mtl_guc_70.bin  | Bin 303936 -> 308032 bytes
>  i915/mtl_huc_gsc.bin | Bin 565248 -> 569344 bytes
>  4 files changed, 3 insertions(+), 3 deletions(-)

Re: [Intel-gfx] PR for HuC v8.5.0 for MTL

[Josh Boyer]

On Tue, Jun 6, 2023 at 12:33 PM Daniele Ceraolo Spurio
 wrote:
>
> The following changes since commit fc90c59beebd551dde5fe5eb3e76d36651ba08fb:
>
>   Merge branch 'db410c' of https://github.com/lumag/linux-firmware 
> (2023-05-31 07:35:15 -0400)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware mtl_huc_v8.5.0

Pulled and pushed out.

josh

>
> for you to fetch changes up to 5de33fb45cee8d83abfe17e9e85bd74d51a2653f:
>
>   i915: Add HuC v8.5.0 for MTL (2023-06-06 09:24:40 -0700)
>
> 
> Daniele Ceraolo Spurio (1):
>   i915: Add HuC v8.5.0 for MTL
>
>  WHENCE   |   3 +++
>  i915/mtl_huc_gsc.bin | Bin 0 -> 565248 bytes
>  2 files changed, 3 insertions(+)
>  create mode 100755 i915/mtl_huc_gsc.bin

Re: [Intel-gfx] PR for new GuC v70.6.6 for MTL

[Josh Boyer]

On Wed, May 3, 2023 at 12:58 PM  wrote:
>
> The following changes since commit 312c61f5a6c9c6a313383a8f0c2b02711ec15262:
>
>   amdgpu: update DCN 3.1.6 DMCUB firmware (2023-05-03 09:11:02 -0400)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware mtl_guc_70.6.6

Pulled and pushed out.

josh

>
> for you to fetch changes up to 192ee6d1a7806620eeb6f8478e6a3ec6ea44821c:
>
>   i915: Add GuC v70.6.6 for MTL (2023-05-03 06:45:11 -0700)
>
> 
> John Harrison (1):
>   i915: Add GuC v70.6.6 for MTL
>
>  WHENCE  |   3 +++
>  i915/mtl_guc_70.bin | Bin 0 -> 303936 bytes
>  2 files changed, 3 insertions(+)
>  create mode 100644 i915/mtl_guc_70.bin

Re: [Intel-gfx] PR for ADLP DMC v2.19 and MTL DMC v2.12

[Josh Boyer]

On Fri, Mar 17, 2023 at 1:12 PM Gustavo Sousa  wrote:
>
> The following changes since commit c761dbe804f903cc2df81f251d367cca285eca06:
>
>   Merge tag 'iwlwifi-fw-2023-03-13' of 
> http://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware 
> (2023-03-13 09:20:47 -0400)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware dmc-adlp_2.19-mtl_2.12

Pulled and pushed out.

josh

>
> for you to fetch changes up to a18a444bfbd6097515272f587b86856a6de15218:
>
>   i915: Update MTL DMC to v2.12 (2023-03-17 14:06:32 -0300)
>
> 
> Gustavo Sousa (2):
>   i915: Update ADLP DMC to v2.19
>   i915: Update MTL DMC to v2.12
>
>  WHENCE|   4 ++--
>  i915/adlp_dmc.bin | Bin 78500 -> 79044 bytes
>  i915/mtl_dmc.bin  | Bin 48512 -> 49104 bytes
>  3 files changed, 2 insertions(+), 2 deletions(-)

Re: [Intel-gfx] PR for MTL DMC v2.11

[Josh Boyer]

On Tue, Feb 7, 2023 at 9:07 AM Gustavo Sousa  wrote:
>
> The following changes since commit 5c11a3742947810ee8bffbd476eb5a1b0c7999f2:
>
>   amdgpu: Add VCN 4.0.2 firmware (2023-01-25 07:40:41 -0500)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware dmc-mtl_2.11

Pulled and pushed out.

josh

>
> for you to fetch changes up to c1181ae796970b6b48218bd2bdb9392fab0e070f:
>
>   i915: Add DMC v2.11 for MTL (2023-02-07 09:13:10 -0300)
>
> 
> Gustavo Sousa (1):
>   i915: Add DMC v2.11 for MTL
>
>  WHENCE   |   3 +++
>  i915/mtl_dmc.bin | Bin 0 -> 48512 bytes
>  2 files changed, 3 insertions(+)
>  create mode 100644 i915/mtl_dmc.bin

Re: [Intel-gfx] PR for ADLP DMC v2.18

[Josh Boyer]

On Thu, Feb 2, 2023 at 11:56 AM Gustavo Sousa  wrote:
>
> The following changes since commit 5c11a3742947810ee8bffbd476eb5a1b0c7999f2:
>
>   amdgpu: Add VCN 4.0.2 firmware (2023-01-25 07:40:41 -0500)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware.git dmc-adlp_2.18

Pulled and pushed out.

josh

> for you to fetch changes up to a5046f435699b88a20fe9f5803da2a5c2f604a7f:
>
>   i915: Add DMC v2.18 for ADLP (2023-02-02 12:58:28 -0300)
>
> 
> Gustavo Sousa (1):
>   i915: Add DMC v2.18 for ADLP
>
>  WHENCE|   3 +++
>  i915/adlp_dmc.bin | Bin 0 -> 78500 bytes
>  2 files changed, 3 insertions(+)
>  create mode 100644 i915/adlp_dmc.bin

Re: [Intel-gfx] PR for DG2 DMC v2.08

[Josh Boyer]

On Wed, Nov 23, 2022 at 9:03 AM Gustavo Sousa  wrote:
>
> The following changes since commit 391fb47caabaae8719fb72ba4891d1fc27ca1923:
>
>   amdgpu: update green sardine DMCUB firmware (2022-11-17 10:42:59 -0500)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware dg2_dmc_v2.8
>
> for you to fetch changes up to 7f6279b3dd76ff955278fcd9e517eab85a4c97d6:
>
>   i915: Add DMC v2.08 for DG2 (2022-11-21 16:38:26 -0300)

Pulled and pushed out.  Minor conflict in WHENCE fixed up.

josh

> 
> Gustavo Sousa (1):
>   i915: Add DMC v2.08 for DG2
>
>  WHENCE   |   3 +++
>  i915/dg2_dmc_ver2_08.bin | Bin 0 -> 22540 bytes
>  2 files changed, 3 insertions(+)
>  create mode 100644 i915/dg2_dmc_ver2_08.bin

Re: [Intel-gfx] i915 Updates: MTL DMC v2.10

[Josh Boyer]

On Mon, Nov 21, 2022 at 3:18 PM Tolakanahalli Pradeep, Madhumitha
 wrote:
>
> The following changes since commit daff40492bd0cd071c7f5521b339e12e4de718c1:
>
>   linux-firmware: update firmware for MT7986 (2022-11-16 08:53:28 -0500)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware mtl_dmc_v2.10

Pulled and pushed out.

josh

>
> for you to fetch changes up to de854c96df66be4a13f8bfbb1e78bd5d0cea2e8e:
>
>   i915: Add DMC v2.10 for MTL (2022-11-16 14:26:06 -0800)
>
> 
> Madhumitha Tolakanahalli Pradeep (1):
>   i915: Add DMC v2.10 for MTL
>
>  WHENCE   |   3 +++
>  i915/mtl_dmc_ver2_10.bin | Bin 0 -> 48112 bytes
>  2 files changed, 3 insertions(+)
>  create mode 100644 i915/mtl_dmc_ver2_10.bin
>

Re: [Intel-gfx] PR for HuC 7.10.3

[Josh Boyer]

On Tue, Oct 18, 2022 at 11:22 AM Daniele Ceraolo Spurio
 wrote:
>
> The following changes since commit 48407ffd7adb9511701547068b1e6f0956bd1c94:
>
>   cnm: update chips wave521c firmware. (2022-10-17 10:20:43 -0400)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware dg2_huc_7.10.3_pr
>
> for you to fetch changes up to 8f86b5ab3e051170ea240fc409d457e16e24bc21:
>
>   i915: Add HuC 7.10.3 for DG2 (2022-10-18 08:18:19 -0700)
>
> 
> Daniele Ceraolo Spurio (1):
>   i915: Add HuC 7.10.3 for DG2

Pulled and pushed out.

josh

Re: [Intel-gfx] PR for new GuC v70.5.1 and GuC/HuC with new names

[Josh Boyer]

Pulled and pushed out.

josh

On Tue, Sep 20, 2022 at 4:40 PM  wrote:
>
> The following changes since commit f09bebf31b0590bdc875d7236aa705279510cfd0:
>
>   amdgpu: update yellow carp DMCUB firmware (2022-09-13 08:02:23 -0400)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware guc_70.5.1_huc_nover
>
> for you to fetch changes up to 51fff4e69b4554dd3fee21e3c55a0f94937293e3:
>
>   i915: Add versionless HuC files for current platforms (2022-09-16 08:52:30 
> -0700)
>
> 
> John Harrison (2):
>   i915: Add GuC v70.5.1 for DG1, DG2, TGL and ADL-P
>   i915: Add versionless HuC files for current platforms
>
>  WHENCE   |  18 ++
>  i915/adlp_guc_70.bin | Bin 0 -> 297984 bytes
>  i915/dg1_guc_70.bin  | Bin 0 -> 272512 bytes
>  i915/dg1_huc.bin | Bin 0 -> 589888 bytes
>  i915/dg2_guc_70.bin  | Bin 0 -> 369600 bytes
>  i915/tgl_guc_70.bin  | Bin 0 -> 285888 bytes
>  i915/tgl_huc.bin | Bin 0 -> 589888 bytes
>  7 files changed, 18 insertions(+)
>  create mode 100644 i915/adlp_guc_70.bin
>  create mode 100644 i915/dg1_guc_70.bin
>  create mode 100644 i915/dg1_huc.bin
>  create mode 100644 i915/dg2_guc_70.bin
>  create mode 100644 i915/tgl_guc_70.bin
>  create mode 100644 i915/tgl_huc.bin

Re: [Intel-gfx] PR for new GuC v70.4.1 for DG2

[Josh Boyer]

On Mon, Aug 1, 2022 at 2:02 PM  wrote:
>
> The following changes since commit 150864a4d73e8c448eb1e2c68e65f07635fe1a66:
>
>   amdgpu partially revert "amdgpu: update beige goby to release 22.20" 
> (2022-07-25 14:16:04 -0400)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware dg2_guc_v70.4.1

Pulled and pushed out.  Thank you.

josh

>
> for you to fetch changes up to a4235e0aa4d4753119fd81f582eef84addf3f4a1:
>
>   i915: Add GuC v70.4.1 for DG2 (2022-07-27 18:03:49 -0700)
>
> 
> John Harrison (1):
>   i915: Add GuC v70.4.1 for DG2
>
>  WHENCE  |   3 +++
>  i915/dg2_guc_70.4.1.bin | Bin 0 -> 369600 bytes
>  2 files changed, 3 insertions(+)
>  create mode 100644 i915/dg2_guc_70.4.1.bin

Re: [Intel-gfx] i915 Updates: DG2 DMC v2.07

[Josh Boyer]

On Fri, Jul 29, 2022 at 1:25 PM Tolakanahalli Pradeep, Madhumitha
 wrote:
>
> Kindly add the below changes to linux-firmware:
>
> The following changes since commit 150864a4d73e8c448eb1e2c68e65f07635fe1a66:
>
>   amdgpu partially revert "amdgpu: update beige goby to release 22.20" 
> (2022-07-
> 25 14:16:04 -0400)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware dg2_dmc_2_07

Pulled and pushed out.

josh

>
> for you to fetch changes up to 3ab394af47ab6b0139a3fa6a7b39564a4d18cb25:
>
>   i915: Add DMC v2.07 for DG2 (2022-07-27 10:52:59 -0700)
>
> 
> Anusha Srivatsa (1):
>   i915: Add DMC v2.07 for DG2
>
>  WHENCE   |   3 +++
>  i915/dg2_dmc_ver2_07.bin | Bin 0 -> 22488 bytes
>  2 files changed, 3 insertions(+)
>  create mode 100644 i915/dg2_dmc_ver2_07.bin
>
> --
> 2.37.1
>
> Thanks!
> - Madhumitha

Re: [Intel-gfx] i915 Updates: DG2 DMC v2.06

[Josh Boyer]

On Mon, May 2, 2022 at 3:56 PM Tolakanahalli Pradeep, Madhumitha
 wrote:
>
> The following changes since commit c3624ebd67c68722e0fabc9cae01397b15310239:
>
>   Merge branch 'ath10k-20220423' of
> git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/linux-firmware into main
> (2022-05-02 08:31:40 -0400)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware dg2_dmc_v2.06_rebase
>
> for you to fetch changes up to b8bd6ccd9c409508a0b424492981721b45c55127:
>
>   i915: Add DMC v2.06 for DG2 (2022-05-02 22:53:23 +0530)
>
> 
> Madhumitha Tolakanahalli Pradeep (1):
>   i915: Add DMC v2.06 for DG2

Pulled and pushed out.

josh

>
>  WHENCE   |   3 +++
>  i915/dg2_dmc_ver2_06.bin | Bin 0 -> 22416 bytes
>  2 files changed, 3 insertions(+)
>  create mode 100644 i915/dg2_dmc_ver2_06.bin
>

Re: [Intel-gfx] PR for new GuC v70.1.2 for DG2

[Josh Boyer]

On Thu, Apr 28, 2022 at 3:07 PM  wrote:
>
> The following changes since commit ac21ab5d1de0de34201c90d32eee436f873d1e5b:
>
>   Mellanox: Add lc_ini_bundle for xx.2010.1006 (2022-04-25 07:36:16 -0400)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware guc_v70.1.2_dg2
>
> for you to fetch changes up to 89ae5eb20f65752db6a3e38b9a69144f19540567:
>
>   i915: Add GuC v70.1.2 for DG2 (2022-04-26 13:27:47 -0700)

Pulled and pushed out.

josh

>
> 
> John Harrison (1):
>   i915: Add GuC v70.1.2 for DG2
>
>  WHENCE  |   3 +++
>  i915/dg2_guc_70.1.2.bin | Bin 0 -> 365568 bytes
>  2 files changed, 3 insertions(+)
>  create mode 100644 i915/dg2_guc_70.1.2.bin

Re: [Intel-gfx] PR for new GuC v70.1.1

[Josh Boyer]

Pulled and pushed out.

josh

On Tue, Apr 19, 2022 at 7:46 PM  wrote:
>
> The following changes since commit 681281e49fb6778831370e5d94e6e1d97f0752d6:
>
>   amdgpu: update PSP 13.0.8 firmware (2022-03-18 07:35:54 -0400)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware guc_v70.1.1
>
> for you to fetch changes up to ab0d8c137d4235dbb09ac4c76dd5477719cd73f1:
>
>   i915: Add GuC v70.1.1 for all platforms (2022-04-07 13:14:24 -0700)
>
> 
> John Harrison (1):
>   i915: Add GuC v70.1.1 for all platforms
>
>  WHENCE   |  30 ++
>  i915/adlp_guc_70.1.1.bin | Bin 0 -> 289472 bytes
>  i915/bxt_guc_70.1.1.bin  | Bin 0 -> 206464 bytes
>  i915/cml_guc_70.1.1.bin  | Bin 0 -> 206976 bytes
>  i915/dg1_guc_70.1.1.bin  | Bin 0 -> 265152 bytes
>  i915/ehl_guc_70.1.1.bin  | Bin 0 -> 274496 bytes
>  i915/glk_guc_70.1.1.bin  | Bin 0 -> 206784 bytes
>  i915/icl_guc_70.1.1.bin  | Bin 0 -> 274496 bytes
>  i915/kbl_guc_70.1.1.bin  | Bin 0 -> 206976 bytes
>  i915/skl_guc_70.1.1.bin  | Bin 0 -> 206208 bytes
>  i915/tgl_guc_70.1.1.bin  | Bin 0 -> 277440 bytes
>  11 files changed, 30 insertions(+)
>  create mode 100644 i915/adlp_guc_70.1.1.bin
>  create mode 100644 i915/bxt_guc_70.1.1.bin
>  create mode 100644 i915/cml_guc_70.1.1.bin
>  create mode 100644 i915/dg1_guc_70.1.1.bin
>  create mode 100644 i915/ehl_guc_70.1.1.bin
>  create mode 100644 i915/glk_guc_70.1.1.bin
>  create mode 100644 i915/icl_guc_70.1.1.bin
>  create mode 100644 i915/kbl_guc_70.1.1.bin
>  create mode 100644 i915/skl_guc_70.1.1.bin
>  create mode 100644 i915/tgl_guc_70.1.1.bin

Re: [Intel-gfx] i915 Updates: ADL-P DMC v2.16

[Josh Boyer]

Pulled and pushed out.

josh

On Tue, Jan 25, 2022 at 7:50 PM Tolakanahalli Pradeep, Madhumitha
 wrote:
>
> Hi Ben, Josh, Kyle,
>
> The following changes since commit
> eb8ea1b46893c42edbd516f971a93b4d097730ab:
>
>   Merge branch 'v1.1.7' of https://github.com/irui-
> wang/linux_fw_vpu_v1.1.7 into main (2022-01-24 06:49:52 -0500)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware adlp_dmc_v2.16
>
> for you to fetch changes up to
> 847c6de09299b59bb6f8e641cfd500aa8d1c0a9a:
>
>   i915: Add DMC firmware v2.16 for ADL-P (2022-01-25 16:05:54 -0800)
>
> 
> Madhumitha Tolakanahalli Pradeep (1):
>   i915: Add DMC firmware v2.16 for ADL-P
>
>  WHENCE|   3 +++
>  i915/adlp_dmc_ver2_16.bin | Bin 0 -> 77084 bytes
>  2 files changed, 3 insertions(+)
>  create mode 100644 i915/adlp_dmc_ver2_16.bin
>
> Thanks!
> - Madhumitha
>

Re: [Intel-gfx] [CI] PR for new GuC v69.0.3

[Josh Boyer]

Pulled and pushed out.

josh

On Fri, Jan 14, 2022 at 7:03 PM  wrote:
>
> The following changes since commit b0e898fbaf377c99a36aac6fdeb7250003648ca4:
>
>   linux-firmware: Update firmware file for Intel Bluetooth 9462 (2021-11-23 
> 12:31:45 -0500)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware guc_v69.0.3
>
> for you to fetch changes up to 548b304a35b77cd43c1242e0eae68f775bd0df2a:
>
>   i915: Add GuC v69.0.3 for all platforms (2021-12-15 13:28:54 -0800)
>
> 
> John Harrison (1):
>   i915: Add GuC v69.0.3 for all platforms
>
>  WHENCE   |  30 ++
>  i915/adlp_guc_69.0.3.bin | Bin 0 -> 356416 bytes
>  i915/bxt_guc_69.0.3.bin  | Bin 0 -> 216768 bytes
>  i915/cml_guc_69.0.3.bin  | Bin 0 -> 217664 bytes
>  i915/dg1_guc_69.0.3.bin  | Bin 0 -> 323968 bytes
>  i915/ehl_guc_69.0.3.bin  | Bin 0 -> 343360 bytes
>  i915/glk_guc_69.0.3.bin  | Bin 0 -> 217216 bytes
>  i915/icl_guc_69.0.3.bin  | Bin 0 -> 343360 bytes
>  i915/kbl_guc_69.0.3.bin  | Bin 0 -> 217664 bytes
>  i915/skl_guc_69.0.3.bin  | Bin 0 -> 216704 bytes
>  i915/tgl_guc_69.0.3.bin  | Bin 0 -> 343296 bytes
>  11 files changed, 30 insertions(+)
>  create mode 100644 i915/adlp_guc_69.0.3.bin
>  create mode 100644 i915/bxt_guc_69.0.3.bin
>  create mode 100644 i915/cml_guc_69.0.3.bin
>  create mode 100644 i915/dg1_guc_69.0.3.bin
>  create mode 100644 i915/ehl_guc_69.0.3.bin
>  create mode 100644 i915/glk_guc_69.0.3.bin
>  create mode 100644 i915/icl_guc_69.0.3.bin
>  create mode 100644 i915/kbl_guc_69.0.3.bin
>  create mode 100644 i915/skl_guc_69.0.3.bin
>  create mode 100644 i915/tgl_guc_69.0.3.bin

Re: [Intel-gfx] i915 Updates: ADL-P DMC v2.14

[Josh Boyer]

Sincere apologies for the delay.  Pulled and pushed out.

josh

On Wed, Dec 15, 2021 at 6:41 PM Tolakanahalli Pradeep, Madhumitha
 wrote:
>
> Bump! :)
>
> Thanks,
> - Madhumitha
>
> On Wed, 2021-12-08 at 18:11 +, Srivatsa, Anusha wrote:
> > Ping :)
> > Can these updates be merged to linux-firmware?
> >
> >
> > Thanks,
> > Anusha
> >
> > > -Original Message-
> > > From: Tolakanahalli Pradeep, Madhumitha
> > > 
> > > Sent: Thursday, December 2, 2021 6:48 AM
> > > To: Hutchings, Ben ;
> > > intel-gfx@lists.freedesktop.org;
> > > k...@mcmartin.ca; jwbo...@kernel.org
> > > Cc: Srivatsa, Anusha ; linux-
> > > firmw...@kernel.org
> > > Subject: [Intel-gfx] i915 Updates: ADL-P DMC v2.14
> > >
> > > Hi Ben, Josh, Kyle,
> > >
> > > Kindly add the below i915 changes to linux-firmware:
> > >
> > > The following changes since commit
> > > b0e898fbaf377c99a36aac6fdeb7250003648ca4:
> > >
> > >   linux-firmware: Update firmware file for Intel Bluetooth 9462
> > > (2021-
> > > 11-23 12:31:45 -0500)
> > >
> > > are available in the Git repository at:
> > >
> > >   git://anongit.freedesktop.org/drm/drm-firmware
> > > adlp_dmc_v2.14_update
> > >
> > > for you to fetch changes up to
> > > 2a2aa410c2eaebe5807d1fd321e42b8f53288d91:
> > >
> > >   i915: Add DMC firmware v2.14 for ADL-P (2021-12-01 16:50:30 -
> > > 0800)
> > >
> > > 
> > > Madhumitha Tolakanahalli Pradeep (1):
> > >   i915: Add DMC firmware v2.14 for ADL-P
> > >
> > >  WHENCE|   3 +++
> > >  i915/adlp_dmc_ver2_14.bin | Bin 0 -> 77300 bytes
> > >  2 files changed, 3 insertions(+)
> > >  create mode 100644 i915/adlp_dmc_ver2_14.bin
> > >
> > > Thanks!
> > > - Madhumitha
> > >
> >
>

Re: [Intel-gfx] i915 Updates - ADLP DMC v2.12

[Josh Boyer]

On Mon, Sep 20, 2021 at 5:57 PM Srivatsa, Anusha
 wrote:
>
> Hi josh, Ben, Kyle
>
> Kindly add the below i915 changes to linux-firmware:
>
> linux-firmware: add frimware for mediatek bluetooth chip (MT7922) (2021-09-13 
> 11:35:49 -0400)
>
>
>
> are available in the Git repository at:
>
>
>
>   git://anongit.freedesktop.org/drm/drm-firmware adlp_dmc_2_12

Pulled and pushed out.

josh

Re: [Intel-gfx] i915 DMC Updates - TGL:v2.12 and RKL v2.03

[Josh Boyer]

Pulled and pushed out.

josh

On Wed, Jul 28, 2021 at 1:01 PM Srivatsa, Anusha
 wrote:
>
> Hi,
>
> Kindly pull these updates from i915.
>
>
>
> The following changes since commit 168452ee695b5edb9deb641059bc110b9c5e8fc7:
>
>
>
>   Merge tag 'iwlwifi-fw-2021-07-19' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware into 
> main (2021-07-19 14:35:47 -0400)
>
>
>
> are available in the Git repository at:
>
>
>
>   git://anongit.freedesktop.org/drm/drm-firmware tgl_rkl_dmc_updates
>
>
>
> for you to fetch changes up to 6c9fd94d41310443ea4ff782ce1545e49e74221c:
>
>
>
>   i915: Add v2.03 DMC for RKL (2021-07-28 09:45:27 -0700)
>
>
>
> 
>
> Anusha Srivatsa (2):
>
>   i915: Add v2.12 DMC for TGL
>
>  i915: Add v2.03 DMC for RKL
>
>
>
> WHENCE   |   6 ++
>
> i915/rkl_dmc_ver2_03.bin | Bin 0 -> 18476 bytes
>
> i915/tgl_dmc_ver2_12.bin | Bin 0 -> 19760 bytes
>
> 3 files changed, 6 insertions(+)
>
> create mode 100644 i915/rkl_dmc_ver2_03.bin
>
> create mode 100644 i915/tgl_dmc_ver2_12.bin
>
>
>
> Thanks,
>
> Anusha

Re: [Intel-gfx] PR for new GuC v62.0.3 and HuC v7.9.3 binaries

[Josh Boyer]

On Thu, Jul 8, 2021 at 1:50 PM  wrote:
>
> The following changes since commit d79c26779d459063b8052b7fe0a48bce4e08d0d9:
>
>   amdgpu: update vcn firmware for green sardine for 21.20 (2021-06-29 
> 07:26:03 -0400)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware guc_62.0_huc_7.9
>
> for you to fetch changes up to f4d897acd200190350a5f2148316c51c6c57bc9b:
>
>   firmware/i915/guc: Add HuC v7.9.3 for TGL & DG1 (2021-06-29 14:20:03 -0700)
>
> 
> John Harrison (3):
>   firmware/i915/guc: Add GuC v62.0.0 for all platforms
>   firmware/i915/guc: Add GuC v62.0.3 for ADL-P
>   firmware/i915/guc: Add HuC v7.9.3 for TGL & DG1

Pulled and pushed out.

josh

>
>  WHENCE   |  38 +-
>  i915/adlp_guc_62.0.3.bin | Bin 0 -> 336704 bytes
>  i915/bxt_guc_62.0.0.bin  | Bin 0 -> 199616 bytes
>  i915/cml_guc_62.0.0.bin  | Bin 0 -> 200448 bytes
>  i915/dg1_guc_62.0.0.bin  | Bin 0 -> 315648 bytes
>  i915/dg1_huc_7.9.3.bin   | Bin 0 -> 589888 bytes
>  i915/ehl_guc_62.0.0.bin  | Bin 0 -> 327488 bytes
>  i915/glk_guc_62.0.0.bin  | Bin 0 -> 20 bytes
>  i915/icl_guc_62.0.0.bin  | Bin 0 -> 327488 bytes
>  i915/kbl_guc_62.0.0.bin  | Bin 0 -> 200448 bytes
>  i915/skl_guc_62.0.0.bin  | Bin 0 -> 199552 bytes
>  i915/tgl_guc_62.0.0.bin  | Bin 0 -> 326016 bytes
>  i915/tgl_huc_7.9.3.bin   | Bin 0 -> 589888 bytes
>  13 files changed, 37 insertions(+), 1 deletion(-)
>  create mode 100644 i915/adlp_guc_62.0.3.bin
>  create mode 100644 i915/bxt_guc_62.0.0.bin
>  create mode 100644 i915/cml_guc_62.0.0.bin
>  create mode 100644 i915/dg1_guc_62.0.0.bin
>  create mode 100644 i915/dg1_huc_7.9.3.bin
>  create mode 100644 i915/ehl_guc_62.0.0.bin
>  create mode 100644 i915/glk_guc_62.0.0.bin
>  create mode 100644 i915/icl_guc_62.0.0.bin
>  create mode 100644 i915/kbl_guc_62.0.0.bin
>  create mode 100644 i915/skl_guc_62.0.0.bin
>  create mode 100644 i915/tgl_guc_62.0.0.bin
>  create mode 100644 i915/tgl_huc_7.9.3.bin
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] linux firmware PR for i915 GuC v49.0.1

[Josh Boyer]

On Mon, Nov 30, 2020 at 1:49 PM John Harrison  wrote:
>
> On 11/30/2020 06:26, Josh Boyer wrote:
> > On Tue, Nov 24, 2020 at 8:42 PM  wrote:
> >> Hi Josh, Kyle, Ben,
> >>
> >> Kindly add the below i915 changes to linux-firmware.git:
> >>
> >>
> >> The following changes since commit 
> >> b362fd4cb8963ad75517dbcf424974f65a29a60e:
> >>
> >>Mellanox: Add new mlxsw_spectrum firmware xx.2008.2018 (2020-11-24 
> >> 09:55:03 -0500)
> >>
> >> are available in the Git repository at:
> >>
> >>git://anongit.freedesktop.org/drm/drm-firmware FDO/guc_v49
> > This doesn't exist.  Git complains with:
> >
> > fatal: couldn't find remote ref FDO/guc_v49
> >
> > Did you just mean guc_v49?
> >
> > josh
> I guess. The FDO part is the name of the remote repo in my local .git.
> When I tried to create the pull request without that part it gave me an
> error.
>
> Do you need me to resend the email with the 'FDO/' part dropped?

No.  I pulled that tag and pushed it out.  Take a look at the mainline
repo and make sure it included the 2 commits you wanted.  Should be
good to go.

josh

> >> for you to fetch changes up to c487f7dadcd21116613441ed355b764003b3f57b:
> >>
> >>i915: Add GuC firmware v49.0.1 for all platforms (2020-11-24 17:04:17 
> >> -0800)
> >>
> >> 
> >> John Harrison (2):
> >>i915: Remove duplicate KBL DMC entry
> >>i915: Add GuC firmware v49.0.1 for all platforms
> >>
> >>   WHENCE  |  25 -
> >>   i915/bxt_guc_49.0.1.bin | Bin 0 -> 196224 bytes
> >>   i915/cml_guc_49.0.1.bin | Bin 0 -> 197184 bytes
> >>   i915/ehl_guc_49.0.1.bin | Bin 0 -> 324160 bytes
> >>   i915/glk_guc_49.0.1.bin | Bin 0 -> 196672 bytes
> >>   i915/icl_guc_49.0.1.bin | Bin 0 -> 324160 bytes
> >>   i915/kbl_guc_49.0.1.bin | Bin 0 -> 197184 bytes
> >>   i915/skl_guc_49.0.1.bin | Bin 0 -> 196288 bytes
> >>   i915/tgl_guc_49.0.1.bin | Bin 0 -> 321792 bytes
> >>   9 files changed, 24 insertions(+), 1 deletion(-)
> >>   create mode 100644 i915/bxt_guc_49.0.1.bin
> >>   create mode 100644 i915/cml_guc_49.0.1.bin
> >>   create mode 100644 i915/ehl_guc_49.0.1.bin
> >>   create mode 100644 i915/glk_guc_49.0.1.bin
> >>   create mode 100644 i915/icl_guc_49.0.1.bin
> >>   create mode 100644 i915/kbl_guc_49.0.1.bin
> >>   create mode 100644 i915/skl_guc_49.0.1.bin
> >>   create mode 100644 i915/tgl_guc_49.0.1.bin
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] linux firmware PR for i915 GuC v49.0.1

[Josh Boyer]

On Tue, Nov 24, 2020 at 8:42 PM  wrote:
>
> Hi Josh, Kyle, Ben,
>
> Kindly add the below i915 changes to linux-firmware.git:
>
>
> The following changes since commit b362fd4cb8963ad75517dbcf424974f65a29a60e:
>
>   Mellanox: Add new mlxsw_spectrum firmware xx.2008.2018 (2020-11-24 09:55:03 
> -0500)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware FDO/guc_v49

This doesn't exist.  Git complains with:

fatal: couldn't find remote ref FDO/guc_v49

Did you just mean guc_v49?

josh

>
> for you to fetch changes up to c487f7dadcd21116613441ed355b764003b3f57b:
>
>   i915: Add GuC firmware v49.0.1 for all platforms (2020-11-24 17:04:17 -0800)
>
> 
> John Harrison (2):
>   i915: Remove duplicate KBL DMC entry
>   i915: Add GuC firmware v49.0.1 for all platforms
>
>  WHENCE  |  25 -
>  i915/bxt_guc_49.0.1.bin | Bin 0 -> 196224 bytes
>  i915/cml_guc_49.0.1.bin | Bin 0 -> 197184 bytes
>  i915/ehl_guc_49.0.1.bin | Bin 0 -> 324160 bytes
>  i915/glk_guc_49.0.1.bin | Bin 0 -> 196672 bytes
>  i915/icl_guc_49.0.1.bin | Bin 0 -> 324160 bytes
>  i915/kbl_guc_49.0.1.bin | Bin 0 -> 197184 bytes
>  i915/skl_guc_49.0.1.bin | Bin 0 -> 196288 bytes
>  i915/tgl_guc_49.0.1.bin | Bin 0 -> 321792 bytes
>  9 files changed, 24 insertions(+), 1 deletion(-)
>  create mode 100644 i915/bxt_guc_49.0.1.bin
>  create mode 100644 i915/cml_guc_49.0.1.bin
>  create mode 100644 i915/ehl_guc_49.0.1.bin
>  create mode 100644 i915/glk_guc_49.0.1.bin
>  create mode 100644 i915/icl_guc_49.0.1.bin
>  create mode 100644 i915/kbl_guc_49.0.1.bin
>  create mode 100644 i915/skl_guc_49.0.1.bin
>  create mode 100644 i915/tgl_guc_49.0.1.bin
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] i915 Update : DG1 DMC

[Josh Boyer]

Pulled and pushed out.

josh

On Fri, Oct 9, 2020 at 2:41 PM Srivatsa, Anusha
 wrote:
>
> Hi Kyle, Ben,
>
>
>
> Please add the i915 updates to linux-firmware from branch dg1_dmc_v2_02
>
>
>
> The following changes since commit 58d41d0facca2478d3e45f6321224361519aee96:
>
>
>
>   ice: Add comms package file for Intel E800 series driver (2020-10-05 
> 08:09:03 -0400)
>
>
>
> are available in the Git repository at: dg1_dmc_v2_02
>
>
>
>   git://anongit.freedesktop.org/drm/drm-firmware dg1_dmc_v2_02
>
>
>
> for you to fetch changes up to a140ef3eb3746aba2c897db16e02ffb5ffa9e7a2:
>
>
>
>   i915: Add DG1 DMC v2.02 (2020-10-08 12:13:33 -0700)
>
>
>
> 
>
> Anusha Srivatsa (1):
>
>   i915: Add DG1 DMC v2.02
>
>
>
> WHENCE   |   2 ++
>
> i915/dg1_dmc_ver2_02.bin | Bin 0 -> 16624 bytes
>
> 2 files changed, 2 insertions(+)
>
> create mode 100644 i915/dg1_dmc_ver2_02.bin
>
>
>
> Thanks,
>
> Anusha
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] PR for new i915 firmware files

[Josh Boyer]

On Fri, Aug 14, 2020 at 8:45 PM José Roberto de Souza
 wrote:
>
> The following changes since commit c331aa9c49ce507d4e5a9a4f2f19115db8e15536:
>
>   amdgpu: update vega20 firmware for 20.30 (2020-08-07 08:16:21 -0400)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware i915-firmware-updates-08-2020

Pulled and pushed out.

josh


> for you to fetch changes up to 1b81373b52a86dadcfe70d4385e62bc6afc3963a:
>
>   i915: Add DMC firmware 2.02 for RKL (2020-08-13 11:04:08 -0700)
>
> 
> José Roberto de Souza (3):
>   i915: Add HuC firwmare v7.5.0 for TGL
>   i915: Add DMC firmware 2.08 for TGL
>   i915: Add DMC firmware 2.02 for RKL
>
>  WHENCE   |   9 +
>  i915/rkl_dmc_ver2_02.bin | Bin 0 -> 18204 bytes
>  i915/tgl_dmc_ver2_08.bin | Bin 0 -> 18932 bytes
>  i915/tgl_huc_7.5.0.bin   | Bin 0 -> 580736 bytes
>  4 files changed, 9 insertions(+)
>  create mode 100644 i915/rkl_dmc_ver2_02.bin
>  create mode 100644 i915/tgl_dmc_ver2_08.bin
>  create mode 100644 i915/tgl_huc_7.5.0.bin
>
> diff --git a/WHENCE b/WHENCE
> index be8c390..54c3714 100644
> --- a/WHENCE
> +++ b/WHENCE
> @@ -4124,6 +4124,9 @@ Version: DMC API/APB ver 2 release 4 for Tigerlake
>  File: i915/tgl_dmc_ver2_06.bin
>  Version: DMC API/APB ver 2 release 6 for Tigerlake
>
> +File: i915/tgl_dmc_ver2_08.bin
> +Version: DMC API/APB ver 2 release 8 for Tigerlake
> +
>  File: i915/icl_huc_9.0.0.bin
>  Version: Huc API/APB ver 9 release 0 for Icelake
>
> @@ -4142,6 +4145,12 @@ Version: Huc API/APB ver 7 release 0 for Tigerlake
>  File: i915/tgl_huc_7.0.12.bin
>  Version: Huc API/APB ver 7 release 0 for Tigerlake
>
> +File: i915/tgl_huc_7.5.0.bin
> +Version: Huc API/APB ver 7 release 5 for Tigerlake
> +
> +File: i915/rkl_dmc_ver2_02.bin
> +Version: DMC API/APB ver 2 release 2 for Rocketlake
> +
>  License: Redistributable. See LICENSE.i915 for details
>
>  --
> diff --git a/i915/rkl_dmc_ver2_02.bin b/i915/rkl_dmc_ver2_02.bin
> new file mode 100644
> index 000..e553fbc
> Binary files /dev/null and b/i915/rkl_dmc_ver2_02.bin differ
> diff --git a/i915/tgl_dmc_ver2_08.bin b/i915/tgl_dmc_ver2_08.bin
> new file mode 100644
> index 000..9db379c
> Binary files /dev/null and b/i915/tgl_dmc_ver2_08.bin differ
> diff --git a/i915/tgl_huc_7.5.0.bin b/i915/tgl_huc_7.5.0.bin
> new file mode 100644
> index 000..bed10f3
> Binary files /dev/null and b/i915/tgl_huc_7.5.0.bin differ
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] PR - i915 firmware updates (TGL HuC 7.0.12 and DMC 2.06)

[Josh Boyer]

On Wed, Mar 4, 2020 at 4:36 PM Daniele Ceraolo Spurio
 wrote:
>
> Hi,
>
> Kindly add the below i915 changes to linux-firmware.git
>
> The following changes since commit 0148cfefcbf98898ca65bb26d9d7d638b30e211d:
>
>   Merge https://github.com/rjliao-qca/qca-btfw (2020-03-02 08:08:15 -0500)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware tgl_huc_7.0.12_dmc_2.06

Pulled and pushed out.

josh

>
> for you to fetch changes up to fb83402c757034fd9adef083047390b3b2f54cb4:
>
>   i915: Add DMC firmware v2.06 for TGL (2020-03-04 13:19:07 -0800)
>
> 
> Daniele Ceraolo Spurio (1):
>   i915: add HuC firmware v7.0.12 for TGL
>
> José Roberto de Souza (1):
>   i915: Add DMC firmware v2.06 for TGL
>
>  WHENCE   |   6 ++
>  i915/tgl_dmc_ver2_06.bin | Bin 0 -> 18660 bytes
>  i915/tgl_huc_7.0.12.bin  | Bin 0 -> 530368 bytes
>  3 files changed, 6 insertions(+)
>  create mode 100644 i915/tgl_dmc_ver2_06.bin
>  create mode 100644 i915/tgl_huc_7.0.12.bin
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] PR - i915 firmware updates (GuC and HuC for EHL and TGL)

[Josh Boyer]

On Wed, Nov 6, 2019 at 5:15 PM Daniele Ceraolo Spurio
 wrote:
>
> Hi,
>
> Kindly add the below i915 changes to linux-firmware.git
>
> The following changes since commit 11bdc578ec861c7797ec614d60737a0448b68195:
>
>   rtw88: RTL8723D: add firmware file v48 (2019-11-04 06:37:16 -0500)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware ehl_tgl_guc_huc
>
> for you to fetch changes up to 4debf2173804396540d1890fa2347af7689c4420:
>
>   i915: Add HuC firmware v7.0.3 for TGL (2019-11-06 11:42:42 -0800)
>
> 
> Daniele Ceraolo Spurio (4):
>   i915: Add GuC firmware v33.0.4 for EHL
>   i915: Add HuC firmware v9.0.0 for EHL
>   i915: Add GuC firmware v35.2.0 for TGL
>   i915: Add HuC firmware v7.0.3 for TGL
>
>  WHENCE  |  12 
>  i915/ehl_guc_33.0.4.bin | Bin 0 -> 396288 bytes
>  i915/ehl_huc_9.0.0.bin  | Bin 0 -> 498880 bytes
>  i915/tgl_guc_35.2.0.bin | Bin 0 -> 417728 bytes
>  i915/tgl_huc_7.0.3.bin  | Bin 0 -> 521408 bytes
>  5 files changed, 12 insertions(+)
>  create mode 100644 i915/ehl_guc_33.0.4.bin
>  create mode 100644 i915/ehl_huc_9.0.0.bin
>  create mode 100644 i915/tgl_guc_35.2.0.bin
>  create mode 100644 i915/tgl_huc_7.0.3.bin

Pulled and pushed out.  Thanks!

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

Re: [Intel-gfx] i915 firmware updates (CMl- GuC,HuC; TGL-DMC,ICL-DMC, HuC Updates-SKL,BXT,KBL,GLK,ICL)

[Josh Boyer]

On Fri, Sep 13, 2019 at 6:30 PM Srivatsa, Anusha
 wrote:
>
> Hi,
> Kyle, Josh,Ben
>
> Ignore the previous PR and kindly consider this one. It has another new 
> update and is the latest one-
>
> The following changes since commit 6c6918ad8ae0dfb2cb591484eba525409980c16f:
>
>   linux-firmware: Update firmware file for Intel Bluetooth AX201 (2019-09-09 
> 04:22:42 -0400)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware cml_tgl-icl-dmc_huc_updates
>
> for you to fetch changes up to 3ea84e52306e7b78cc6d727d9a41c8449146d765:
>
>   drm/i915/firmware: Add v9.0.0 of HuC for Icelake (2019-09-13 14:48:47 -0700)
>
> 
> Anusha Srivatsa (9):
>   drm/i915/firmware: Add v1.09 of DMC for ICL
>   drm/i915/firmware: Add v2.04 of DMC for TGL
>   drm/i915/firmware: Add v33 of GuC for CML
>   drm/i915/firmware: Add v2.0.0 of HuC for Skylake
>   drm/i915/firmware: Add v4.0.0 of HuC for Kabylake
>   drm/i915/firmware: Add v2.0.0 of HuC for Broxton
>   drm/i915/firmware: Add v4.0.0 of HuC for Geminilake
>   drm/i915/firmware: Add v4.0.0 of HuC for Cometlake
>   drm/i915/firmware: Add v9.0.0 of HuC for Icelake
>
>  WHENCE   |  28 
>  i915/bxt_huc_2.0.0.bin   | Bin 0 -> 149824 bytes
>  i915/cml_guc_33.0.0.bin  | Bin 0 -> 182912 bytes
>  i915/cml_huc_4.0.0.bin   | Bin 0 -> 226048 bytes
>  i915/glk_huc_4.0.0.bin   | Bin 0 -> 226048 bytes
>  i915/icl_dmc_ver1_09.bin | Bin 0 -> 25952 bytes
>  i915/icl_huc_9.0.0.bin   | Bin 0 -> 498880 bytes
>  i915/kbl_huc_4.0.0.bin   | Bin 0 -> 226048 bytes
>  i915/skl_huc_2.0.0.bin   | Bin 0 -> 136320 bytes
>  i915/tgl_dmc_ver2_04.bin | Bin 0 -> 18436 bytes
>  10 files changed, 28 insertions(+)
>  create mode 100644 i915/bxt_huc_2.0.0.bin
>  create mode 100644 i915/cml_guc_33.0.0.bin
>  create mode 100644 i915/cml_huc_4.0.0.bin
>  create mode 100644 i915/glk_huc_4.0.0.bin
>  create mode 100644 i915/icl_dmc_ver1_09.bin
>  create mode 100644 i915/icl_huc_9.0.0.bin
>  create mode 100644 i915/kbl_huc_4.0.0.bin
>  create mode 100644 i915/skl_huc_2.0.0.bin
>  create mode 100644 i915/tgl_dmc_ver2_04.bin

Pulled and pushed out.

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

Re: [Intel-gfx] PR- GUC v33 (BXT,SKL,GLK.KBL,ICL)

[Josh Boyer]

On Mon, Jul 8, 2019 at 5:53 PM Srivatsa, Anusha
 wrote:
>
> Hi,
>
> Can these i915 changes be merged to the linux-firmware.git?
>
> The following changes since commit 70e43940b05e8d6e0c5f15b5e2d67760f1581ece:
>
>   linux-firmware: rsi: add firmware image for redpine 9116 chipset 
> (2019-06-28 07:41:20 -0400)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware guc_v33
>
> for you to fetch changes up to 05dbae6639f09c3e0a02e93de5f803db9aadedd1:
>
>   drm/i915/firmware: Add v33 of GuC for ICL (2019-07-08 14:40:55 -0700)
>
> 
> Anusha Srivatsa (5):
>   drm/i915/firmware: Add v33 of GuC for BXT
>   drm/i915/firmware: Add v33 of GuC for GLK
>   drm/i915/firmware: Add v33 of GuC for SKL
>   drm/i915/firmware: Add v33 of GuC for KBL
>   drm/i915/firmware: Add v33 of GuC for ICL

Pulled and pushed out.

josh

>
>  WHENCE  |  15 +++
>  i915/bxt_guc_33.0.0.bin | Bin 0 -> 181888 bytes
>  i915/glk_guc_33.0.0.bin | Bin 0 -> 182336 bytes
>  i915/icl_guc_33.0.0.bin | Bin 0 -> 385280 bytes
>  i915/kbl_guc_33.0.0.bin | Bin 0 -> 182912 bytes
>  i915/skl_guc_33.0.0.bin | Bin 0 -> 182080 bytes
>  6 files changed, 15 insertions(+)
>  create mode 100644 i915/bxt_guc_33.0.0.bin
>  create mode 100644 i915/glk_guc_33.0.0.bin
>  create mode 100644 i915/icl_guc_33.0.0.bin
>  create mode 100644 i915/kbl_guc_33.0.0.bin
>  create mode 100644 i915/skl_guc_33.0.0.bin
>
> Thanks,
> Anusha
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] PR - i915 updates

[Josh Boyer]

On Wed, Apr 24, 2019 at 1:40 PM Srivatsa, Anusha
 wrote:
>
> Hi,
>
> Requesting to have the below i915 changes merged-
>
>
>
> The following changes since commit 260cb35b11a968e7896f911565b75e411636ad69:
>
>
>   Merge branch 'for-upstream' of git://git.chelsio.net/pub/git/linux-firmware 
> (2019-04-09 06:41:10 -0400)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware guc_huc_updates
>
> for you to fetch changes up to 13d6bc8097de22cba94a319f4879fb5a43486b78:
>
>   drm/i915/firmware: Add ICL HuC v8.4.3238 (2019-04-18 11:40:01 -0700)
>
> 
> Anusha Srivatsa (7):
>   drm/i915/firmware: Add BXT GuC v32.0.3
>   drm/i915/firmware: Add SKL GuC v32.0.3
>   drm/i915/firmware: Add KBL GuC v32.0.3
>   drm/i915/firmware: Add GLK GuC v32.0.3
>   drm/i915/firmware: Add GLK HuC v03.01.2893
>   drm/i915/firmware: Add ICL GuC v32.0.3
>   drm/i915/firmware: Add ICL HuC v8.4.3238
>
>  WHENCE |  21 +
>  i915/bxt_guc_32.0.3.bin| Bin 0 -> 176256 bytes
>  i915/glk_guc_32.0.3.bin| Bin 0 -> 176640 bytes
>  i915/glk_huc_ver03_01_2893.bin | Bin 0 -> 222080 bytes
>  i915/icl_guc_32.0.3.bin| Bin 0 -> 380096 bytes
>  i915/icl_huc_ver8_4_3238.bin   | Bin 0 -> 488960 bytes
>  i915/kbl_guc_32.0.3.bin| Bin 0 -> 176448 bytes
>  i915/skl_guc_32.0.3.bin| Bin 0 -> 175552 bytes
>  8 files changed, 21 insertions(+)
>  create mode 100644 i915/bxt_guc_32.0.3.bin
>  create mode 100644 i915/glk_guc_32.0.3.bin
>  create mode 100644 i915/glk_huc_ver03_01_2893.bin
>  create mode 100644 i915/icl_guc_32.0.3.bin
>  create mode 100644 i915/icl_huc_ver8_4_3238.bin
>  create mode 100644 i915/kbl_guc_32.0.3.bin
>  create mode 100644 i915/skl_guc_32.0.3.bin

Thanks.  Pulled and pushed out.

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

Re: [Intel-gfx] linux-firmware PR for BXT HUC

[Josh Boyer]

On Fri, Dec 7, 2018 at 5:14 PM Srivatsa, Anusha
 wrote:
>
> Hi Josh, Kyle, Ben,
>
> Kindly add the below i915 changes to linux-firmware.git-
>
> The following changes since commit 1baa34868b2c0a004dc595b20678145e3fff83e7:
>
>   Merge branch 'nxp_mc' of https://github.com/NXP/linux-firmware (2018-10-26 
> 08:13:19 -0400)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware BXT_HUC
>
> for you to fetch changes up to 69f153bbc2c44eb581c1f8c7cecd4d878e4e727a:
>
>   firmware/huc/bxt: Add huC Update for BXT (2018-11-28 10:33:57 -0800)
>
> 
> Anusha Srivatsa (1):
>   firmware/huc/bxt: Add huC Update for BXT
>
>  WHENCE|   3 +++
>  i915/bxt_huc_ver01_8_2893.bin | Bin 0 -> 146880 bytes
>  2 files changed, 3 insertions(+)
>  create mode 100644 i915/bxt_huc_ver01_8_2893.bin

Pulled and pushed out.  Apologies for the delay.  This got filtered
into a weird folder in my inbox.  If you copy
linux-firmw...@kernel.org from now on, it might help me catch it.

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

Re: [Intel-gfx] linux-firmware pull request(ICL:DMC)

[Josh Boyer]

On Wed, Sep 26, 2018 at 3:11 PM Srivatsa, Anusha
 wrote:
>
> Josh ,
> Apologies about the previous one.
> Sending a new PR:
>
> The following changes since commit 44d4fca9922a252a0bd81f6307bcc072a78da54a:
>
>   Merge https://github.com/pmachata/linux-firmware (2018-09-13 11:45:40 -0400)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git 
> ICL_DMC

Guessing you meant
git://anongit.freedesktop.org/git/drm/drm-firmware.git/ ICL_DMC.

I've pulled and pushed that out.  Thanks for the cleanup.

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

Re: [Intel-gfx] linux-firmware pull request(ICL:DMC)

[Josh Boyer]

On Mon, Sep 17, 2018 at 5:10 PM Srivatsa, Anusha
 wrote:
>
> Ping -
>
> Can we have this blob merged to linux-firmware.git please?
>
>
>
> Anusha
>
>
>
> From: Srivatsa, Anusha
> Sent: Friday, September 7, 2018 10:02 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: FW: linux-firmware pull request(ICL:DMC)
>
>
>
> Adding ML.
>
>
>
> Anusha
>
>
>
> From: Srivatsa, Anusha
> Sent: Wednesday, September 5, 2018 1:40 PM
> To: jwbo...@kernel.org; b...@decadent.org.uk; k...@kernel.org
> Subject: linux-firmware pull request(ICL:DMC)
>
>
>
> Hi Josh,Ben,Kyle,
>
>
>
> Please consider pulling the following i915 updates to linux-firmware.git.
>
> The following changes since commit 85c5d90fc155d78531efa5d2b02e92aaef7e4b88:
>
>   nvidia: switch GP10[2467] to newer scrubber/ACR firmware (from GP108) 
> (2018-09-04 09:46:41 -0400)
>
> are available in the git repository at:
>
>   git://anongit.freedesktop.org/git/drm/drm-firmware.git/ master
>
> for you to fetch changes up to 218e3171e3f9390b26535fefc9d0936ec81919fd:
>
>   Revert "linux-firmware: Add HuC v3.00.2225 for geminilake" (2018-09-05 
> 13:03:55 -0700)
>
> 
> Anusha Srivatsa (4):
>
>   firmware/icl/dmc: Add DMC v1.07 for Icelake.
>   Merge remote-tracking branch 'official/master'
>   Revert "linux-firmware: Add GuC v11.98 for geminilake"
>   Revert "linux-firmware: Add HuC v3.00.2225 for geminilake"
>
>  WHENCE   |   3 +++
>  i915/icl_dmc_ver1_07.bin | Bin 0 -> 25716 bytes
>  2 files changed, 3 insertions(+)
>  create mode 100644 i915/icl_dmc_ver1_07.bin

Is there any way to clean up the branch you're asking us to pull from?
 There are a bunch of reverts and merge commits in here that wind up
adding and removing things, referencing commits that don't actually
exist in the linux-firmware repo.

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

Re: [Intel-gfx] linux-firmware Pull Request (CNL:DMC)

[Josh Boyer]

On Tue, Jan 2, 2018 at 2:10 PM, Anusha Srivatsa
 wrote:
> Hi Josh, Ben, Kyle,
>
> Please consider pulling i915 updates to linux-firmware.git.
> The following changes since commit 2567e092339cd3403d697dc2e0967c31b7acb989:
>
>   nvidia: add GP108 signed firmware (2017-12-21 08:08:05 -0500)
>
> are available in the git repository at:
>
>   https://cgit.freedesktop.org/drm/drm-firmware/ master
>
> for you to fetch changes up to 4a77cab4a02712fc7b37b55c120eec61fe7e3f32:
>
>   linux-firmware: DMC firmware for cannonlake v1.07 (2018-01-02 10:52:43 
> -0800)
>
> 
> Anusha Srivatsa (1):
>   linux-firmware: DMC firmware for cannonlake v1.07
>
>  WHENCE   |   2 ++
>  i915/cnl_dmc_ver1_07.bin | Bin 0 -> 11268 bytes
>  2 files changed, 2 insertions(+)
>  create mode 100644 i915/cnl_dmc_ver1_07.bin

Merged and pushed out.  Thanks.

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

Re: [Intel-gfx] linux-firmware pull request(SKL:DMC)

[Josh Boyer]

On Mon, Nov 27, 2017 at 6:13 PM, Anusha Srivatsa
 wrote:
> Hi Ben, Kyle,
>
> Please consider pulling i915 updates to linux-firmware.git.
>
> i915-firmware-2017-11-27
> The following changes since commit 17e6288135d4500f9fe60224dce2b46d850c346b:
>
>   brcm: update firmware for bcm4358 (2017-11-25 10:15:53 -0500)
>
> are available in the git repository at:
>
>   ssh://git.freedesktop.org/git/drm/drm-firmware.git master
>
> for you to fetch changes up to 02d857ee316f6f611b6622ef78892d38d0909700:
>
>   linux-firmware: DMC firmware for skylake v1.27 (2017-11-27 14:36:28 -0800)
>
> 
> Anusha Srivatsa (1):
>   linux-firmware: DMC firmware for skylake v1.27
>
>  WHENCE   |   3 ++-
>  i915/skl_dmc_ver1_27.bin | Bin 0 -> 8928 bytes
>  2 files changed, 2 insertions(+), 1 deletion(-)
>  create mode 100644 i915/skl_dmc_ver1_27.bin

Merged.  Thanks!

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

Re: [Intel-gfx] Autoselect patches for stable (Was: Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV)

[Josh Boyer]

On Tue, Nov 21, 2017 at 10:07 AM,   wrote:
> On Mon, Nov 20, 2017 at 11:21:52AM +, Emil Velikov wrote:
>> - Document the autoselect process
>>Information about about What, Why, and [ideally] How - analogous to
>>the normal stable nominations.
>>Insert reference to the process in the patch notification email.
>
> I agree with this one, and it'll definitely happen. The story behind
> this is that this is all based on Julia Lawall's work which is well
> documented in a published paper here:
>
> https://soarsmu.github.io/papers/icse12-patch.pdf
>
> I have modified inputs and process, but it essentially is very similar
> to what's described in that paper.
>
> While I have no problem with sharing what I have so far, this is
> still very much work in progress, and things keep constantly changing
> based on comments I receive from reviewers and Greg, so I want to
> reach a more stable point before trying to explain things and change
> my mind the day after :)
>
> If anyone is really interested in seeing the guts of this mess I
> currently have I can push it to github, but bear in mind that in it's
> current state it's very custom to the configuration I have, and is
> a borderline unreadable mix of bash scripts and LUA.
>
> Ideally it'll all get cleaned up and pushed anyways once I feel
> comfortable with the quality of the process.
>
>> - Make the autoselect nominations _more_ distinct than the normal stable 
>> ones.
>>Maintainers will want to put more cognitive effort into the patches.
>
> So this came up before, and the participants of that thread agreed
> that adding "AUTOSEL" in the patch prefix is sufficient. What else
> would you suggest adding?

The root of the concern seems to be around how the stable process
currently works and how auto-selection plays into that.  When Greg
sends out the RC, the default model of "if nobody objects, this patch
will get included in the next stable release" works because a human
already identified as that needing to be included.  So the review is
looking for a NAK, but that's overriding another human's explicit
decision with reasons.  For something that is auto-selected, people
seem concerned that the default should be flipped.  Perhaps they'd be
more comfortable if auto-selected packages required a human ACK before
they are included?

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: fix the SDE irq dmesg warnings properly

[Josh Boyer]

On Tue, Dec 15, 2015 at 10:26 AM, Chris Wilson  wrote:
> On Mon, Dec 14, 2015 at 04:54:02PM +0200, Ville Syrjälä wrote:
>> On Sun, Dec 13, 2015 at 12:49:45PM +, Chris Wilson wrote:
>> > i7-5557U nuc currently connected to HDMI.
>>
>> Sigh. Do those correcpond to AUX attempts by any chance? IIRC that was where
>> Jani saw the problem on his BDW.
>>
>> Oh and maybe you can try Jani's debug patch
>> https://bugs.freedesktop.org/show_bug.cgi?id=92084#c20
>> to show us what the hotplug register says during these fails?
>
> Sure, just only happens when plugged in, so likely be a while before I
> allow it back into the warmth.

Has there been any further progress on this issue?  I'm still seeing
this with 4.3.3 and we're looking to rebase Fedora to 4.3.y or 4.4
soon.  As far as I'm aware this remains unfixed upstream.

josh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Warning in intel_disable_pipe with v4.1-11235-gc63f887bdea8

[Josh Boyer]

Hi All,

More i915 WARN splats.  This one on a machine with Linus' latest tree
as of this morning.

josh

[7.906372] [drm] Replacing VGA console driver
[7.935724] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[7.942359] [drm] Driver supports precise vblank timestamp query.
[7.952024] vgaarb: device changed decodes:
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[7.953189] e1000e :00:19.0 enp0s25: renamed from eth0
[7.995333] [drm] Initialized i915 1.6.0 20150522 for :00:02.0 on minor 0
[8.024490] fbcon: inteldrmfb (fb0) is primary device
[8.132749] [ cut here ]
[8.132815] WARNING: CPU: 0 PID: 143 at
drivers/gpu/drm/i915/intel_display.c:1064
intel_disable_pipe+0x28d/0x2a0 [i915]()
[8.132816] pipe_off wait timed out
[8.132832] Modules linked in: i915 video i2c_algo_bit
drm_kms_helper e1000e drm ata_generic pata_acpi ptp pps_core
[8.132837] CPU: 0 PID: 143 Comm: kworker/u8:4 Not tainted
4.2.0-0.rc0.git2.1.fc23.x86_64 #1
[8.132839] Hardware name: Intel Corp. Intel(R) UDK2010 firmware
developer platform, BIOS SDV.TM.B10 Release Build (CSM Available)
01/01/2011
[8.132849] Workqueue: events_unbound async_run_entry_fn
[8.132855]   7f346c1b 880134887638
81856f03
[8.132861]   880134887690 880134887678
810ab456
[8.132866]  81e566c0 8800b301 00070008
fffb8601
[8.132867] Call Trace:
[8.132874]  [81856f03] dump_stack+0x4c/0x65
[8.132880]  [810ab456] warn_slowpath_common+0x86/0xc0
[8.132884]  [810ab4e5] warn_slowpath_fmt+0x55/0x70
[8.132935]  [a0158185] ? gen5_read32+0x1d5/0x200 [i915]
[8.132985]  [a016e07d] intel_disable_pipe+0x28d/0x2a0 [i915]
[8.133036]  [a016efd3] ironlake_crtc_disable+0x93/0x7f0 [i915]
[8.133087]  [a0183ce5] ? intel_frontbuffer_flush+0x65/0x70 [i915]
[8.133138]  [a017723e] __intel_set_mode+0x9de/0xbc0 [i915]
[8.133189]  [a017872f] ?
intel_modeset_compute_config+0x3af/0xb60 [i915]
[8.133241]  [a017e10c] intel_crtc_set_config+0x2cc/0x610 [i915]
[8.133263]  [a0039cf9]
drm_mode_set_config_internal+0x69/0x110 [drm]
[8.133274]  [a00ee6d2] restore_fbdev_mode+0xc2/0xf0
[drm_kms_helper]
[8.133284]  [a00f0579]
drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x70 [drm_kms_helper]
[8.133294]  [a00f05e2] drm_fb_helper_set_par+0x22/0x40
[drm_kms_helper]
[8.133345]  [a018d0fa] intel_fbdev_set_par+0x1a/0x60 [i915]
[8.133350]  [81494ad5] fbcon_init+0x545/0x5d0
[8.133355]  [8152ddac] visual_init+0xbc/0x120
[8.133359]  [8152fcb5] do_bind_con_driver+0x1c5/0x3b0
[8.133362]  [815301d9] do_take_over_console+0x149/0x1a0
[8.133366]  [81855c0d] ? printk+0x55/0x6b
[8.133370]  [814908e7] do_fbcon_takeover+0x57/0xb0
[8.133373]  [81495584] fbcon_event_notify+0x674/0x770
[8.133378]  [810d3b6e] notifier_call_chain+0x3e/0xb0
[8.133382]  [810d3d71] __blocking_notifier_call_chain+0x51/0x70
[8.133386]  [810d3da6] blocking_notifier_call_chain+0x16/0x20
[8.133389]  [8149b3bb] fb_notifier_call_chain+0x1b/0x20
[8.133392]  [8149d8f7] register_framebuffer+0x217/0x350
[8.133403]  [a00f0861]
drm_fb_helper_initial_config+0x261/0x430 [drm_kms_helper]
[8.133455]  [a018dbeb] intel_fbdev_initial_config+0x1b/0x20 [i915]
[8.133459]  [810d628a] async_run_entry_fn+0x4a/0x140
[8.133463]  [810cb3c2] process_one_work+0x232/0x840
[8.133467]  [810cb32b] ? process_one_work+0x19b/0x840
[8.133472]  [8112532d] ? debug_lockdep_rcu_enabled+0x1d/0x20
[8.133475]  [810cbaa5] ? worker_thread+0xd5/0x450
[8.133480]  [810cba1e] worker_thread+0x4e/0x450
[8.133484]  [810cb9d0] ? process_one_work+0x840/0x840
[8.133487]  [810d23e4] kthread+0x104/0x120
[8.133493]  [810d22e0] ? kthread_create_on_node+0x250/0x250
[8.133497]  [81860a5f] ret_from_fork+0x3f/0x70
[8.133500]  [810d22e0] ? kthread_create_on_node+0x250/0x250
[8.133503] ---[ end trace 94ef6cc929187b61 ]---
[8.174594] Console: switching to colour frame buffer device 240x67
[8.538116] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[8.538119] i915 :00:02.0: registered panic notifier
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/vblank: WARN_ON nested use of drm_vblank_on/off

[Josh Boyer]

On Mon, Jun 22, 2015 at 8:02 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
 We should never nest these since in theory kms drivers should know
 when a pipe is on/off and call the corresponding enable/disable
 functions for the vblank helper code only once. But for historical
 reasons (the shared-with-ums version of this code in modeset_pre/post
 needed to be able to cope with silly userspace that lost track of
 things) we still have this bit of robustness around.

 Enforce this with a WARN_ON, preparing to eventually rip out this
 special handling.

This doesn't really provide any context in the WARN_ON itself.  It
will just result in a splat that looks like a kernel oops, and end
users and distribution maintainers will be left scratching their
heads.

Could this be done with a printk warning instead, or could you at
least provide a pr_warn statement to help people understand why their
machine has an oops splat?

josh

 Cc: Yogesh Mohan Marimuthu yogesh.mohan.marimu...@intel.com
 Cc: Gaurav K Singh gaurav.k.si...@intel.com
 Cc: Michel Dänzer michel.daen...@amd.com
 Cc: Ville Syrjälä ville.syrj...@linux.intel.com
 Signed-off-by: Daniel Vetter daniel.vet...@intel.com
 ---
  drivers/gpu/drm/drm_irq.c | 4 
  1 file changed, 4 insertions(+)

 diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
 index f9cc68fbd2a3..3819465abe22 100644
 --- a/drivers/gpu/drm/drm_irq.c
 +++ b/drivers/gpu/drm/drm_irq.c
 @@ -1219,6 +1219,8 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
 vblank_disable_and_save(dev, crtc);
 wake_up(vblank-queue);

 +   WARN_ON(vblank-inmodeset);
 +
 /*
  * Prevent subsequent drm_vblank_get() from re-enabling
  * the vblank interrupt by bumping the refcount.
 @@ -1318,6 +1320,8 @@ void drm_vblank_on(struct drm_device *dev, int crtc)
 return;

 spin_lock_irqsave(dev-vbl_lock, irqflags);
 +   WARN_ON(!vblank-inmodeset);
 +
 /* Drop our private prevent drm_vblank_get refcount */
 if (vblank-inmodeset) {
 atomic_dec(vblank-refcount);
 --
 2.1.4

 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/vblank: WARN_ON nested use of drm_vblank_on/off

[Josh Boyer]

On Mon, Jun 22, 2015 at 9:27 AM, Jani Nikula
jani.nik...@linux.intel.com wrote:
 On Mon, 22 Jun 2015, Josh Boyer jwbo...@fedoraproject.org wrote:
 On Mon, Jun 22, 2015 at 8:02 AM, Daniel Vetter daniel.vet...@ffwll.ch 
 wrote:
 We should never nest these since in theory kms drivers should know
 when a pipe is on/off and call the corresponding enable/disable
 functions for the vblank helper code only once. But for historical
 reasons (the shared-with-ums version of this code in modeset_pre/post
 needed to be able to cope with silly userspace that lost track of
 things) we still have this bit of robustness around.

 Enforce this with a WARN_ON, preparing to eventually rip out this
 special handling.

 This doesn't really provide any context in the WARN_ON itself.  It
 will just result in a splat that looks like a kernel oops, and end
 users and distribution maintainers will be left scratching their
 heads.

 Could this be done with a printk warning instead, or could you at
 least provide a pr_warn statement to help people understand why their
 machine has an oops splat?

 FWIW i915_drv.h has

 #define WARN_ON(x) WARN((x), WARN_ON( #x ))

 which makes it a little better...

Only a little though, and only in i915.  This is in the generic DRM
code, isn't it?  I mean, a DRM developer is certainly helped by that.
But an end user seeing this won't know it is because of nested calls.
A simple:

dev_warn(Driver has nested vblank calls.  This works but should be
fixed soon.)

or something similar would at least help people understand what is
happening and that their machine isn't actually broken yet.

josh

 Cc: Yogesh Mohan Marimuthu yogesh.mohan.marimu...@intel.com
 Cc: Gaurav K Singh gaurav.k.si...@intel.com
 Cc: Michel Dänzer michel.daen...@amd.com
 Cc: Ville Syrjälä ville.syrj...@linux.intel.com
 Signed-off-by: Daniel Vetter daniel.vet...@intel.com
 ---
  drivers/gpu/drm/drm_irq.c | 4 
  1 file changed, 4 insertions(+)

 diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
 index f9cc68fbd2a3..3819465abe22 100644
 --- a/drivers/gpu/drm/drm_irq.c
 +++ b/drivers/gpu/drm/drm_irq.c
 @@ -1219,6 +1219,8 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
 vblank_disable_and_save(dev, crtc);
 wake_up(vblank-queue);

 +   WARN_ON(vblank-inmodeset);
 +
 /*
  * Prevent subsequent drm_vblank_get() from re-enabling
  * the vblank interrupt by bumping the refcount.
 @@ -1318,6 +1320,8 @@ void drm_vblank_on(struct drm_device *dev, int crtc)
 return;

 spin_lock_irqsave(dev-vbl_lock, irqflags);
 +   WARN_ON(!vblank-inmodeset);
 +
 /* Drop our private prevent drm_vblank_get refcount */
 if (vblank-inmodeset) {
 atomic_dec(vblank-refcount);
 --
 2.1.4

 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix ilk watermarks calculation when primary plane is disabled

[Josh Boyer]

On Thu, May 21, 2015 at 3:21 AM, Ander Conselvan De Oliveira
conselv...@gmail.com wrote:
 On Wed, 2015-05-20 at 16:53 +0300, Jani Nikula wrote:
 On Wed, 20 May 2015, Ander Conselvan de Oliveira 
 ander.conselvan.de.olive...@intel.com wrote:
  On Fedora 21 or 22, when the transition from the X server to the wayland
  compositor is done, the CRTC with the login screen is left active with a
  disabled fb. A cursor ioctl after the transition causes the watermarks
  to be updated, but due to the logic in intel_crtc_active() checking for
  the primary plane fb, the update considers all planes to be disabled,
  untimately setting the wrong watermark values and causing screen
  flicker. Since the crtc is active, a modeset done later is skipped and
  replaced with a flip, which doesn't update the watermarks.
 
  This regression was introduced somewhere between v3.16 and v3.17.
  Another issue prevented me from doing a full bisect, but the issue was
  introduced in one of the following skipped commits:
 
  commit 7707e6535f43328e05e4729ac96eee864b90e8a4
  Author: Rob Clark robdcl...@gmail.com
  Date:   Thu Jul 17 23:30:04 2014 -0400
 
  drm/i915: use helpers
 
  commit ca5a1b9ba0fb5291b555a23b76dbe5f6c30bfd7a
  Merge: c7dbc6c 3488229
  Author: Dave Airlie airl...@redhat.com
  Date:   Wed Jul 9 10:38:42 2014 +1000
 
  Merge tag 'drm-intel-next-2014-06-20' of 
  git://anongit.freedesktop.org/drm-intel into drm-next
 
  commit c51f71679042a5f388d9580ffbede14c897f1e86
  Merge: b957f45 7b3c29f
  Author: Dave Airlie airl...@redhat.com
  Date:   Sat Jul 19 16:43:41 2014 +1000
 
  Merge tag 'drm-intel-next-2014-07-11' of 
  git://anongit.freedesktop.org/drm-intel into drm-next
 
  This patch is a simplified version of the following commits:
 
  commit 3dd512fbda0d87d1c3fb44bf878b262baee98fb6
  Author: Matt Roper matthew.d.ro...@intel.com
  Date:   Fri Feb 27 10:12:00 2015 -0800
 
  drm/i915: Kill intel_crtc-cursor_{width, height} (v2)
 
  commit 54da691deb123c045259ebf4f5c67381244f58f1
  Author: Thomas Gummerer t.gumme...@gmail.com
  Date:   Thu May 14 09:16:39 2015 +0200
 
  drm/i915: fix screen flickering

 This is expected to land in v4.1-rc5, i.e. these are all upstream
 commits. And I assume none of them apply to stable kernels directly.

 A lot of cherry-pick and some amending would be necessary, because of
 the changes going on for the atomic conversion. Hence the approach here
 was to capture just the important changes into this small patch.

 
  commit 3ef00284e6a48f7deb0784ccca0478ebb7d4bcfc
  Author: Matt Roper matthew.d.ro...@intel.com
  Date:   Mon Mar 9 10:19:24 2015 -0700
 
  drm/i915: Use crtc-state-active in ilk/skl watermark 
  calculations (v3)
 
  Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90508
  Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1218688
  Cc: sta...@vger.kernel.org

 I (and most likely the stable team) would like to know which stable
 kernel versions this is targeting.

 This is for 4.0.

 Do you have Tested-bys against the stable versions you're targeting?

 Only my own testing so far. I guess Ray Strode's doesn't count since he
 tested on top of Fedora's kernel?

Fedora's F22 kernel is based on 4.0.4 right now.  We only have two
minor patches on top of i915 that we carry.  One converts a warning to
a debug, the other disables the verbose state checks by default.
Neither patch would impact this functionality.  I think Ray's testing
counts, but it's up to upstream I guess.

josh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix ilk watermarks calculation when primary plane is disabled

[Josh Boyer]

On Wed, May 20, 2015 at 9:53 AM, Jani Nikula jani.nik...@intel.com wrote:
 On Wed, 20 May 2015, Ander Conselvan de Oliveira 
 ander.conselvan.de.olive...@intel.com wrote:
 On Fedora 21 or 22, when the transition from the X server to the wayland
 compositor is done, the CRTC with the login screen is left active with a
 disabled fb. A cursor ioctl after the transition causes the watermarks
 to be updated, but due to the logic in intel_crtc_active() checking for
 the primary plane fb, the update considers all planes to be disabled,
 untimately setting the wrong watermark values and causing screen
 flicker. Since the crtc is active, a modeset done later is skipped and
 replaced with a flip, which doesn't update the watermarks.

 This regression was introduced somewhere between v3.16 and v3.17.
 Another issue prevented me from doing a full bisect, but the issue was
 introduced in one of the following skipped commits:

 commit 7707e6535f43328e05e4729ac96eee864b90e8a4
 Author: Rob Clark robdcl...@gmail.com
 Date:   Thu Jul 17 23:30:04 2014 -0400

 drm/i915: use helpers

 commit ca5a1b9ba0fb5291b555a23b76dbe5f6c30bfd7a
 Merge: c7dbc6c 3488229
 Author: Dave Airlie airl...@redhat.com
 Date:   Wed Jul 9 10:38:42 2014 +1000

 Merge tag 'drm-intel-next-2014-06-20' of 
 git://anongit.freedesktop.org/drm-intel into drm-next

 commit c51f71679042a5f388d9580ffbede14c897f1e86
 Merge: b957f45 7b3c29f
 Author: Dave Airlie airl...@redhat.com
 Date:   Sat Jul 19 16:43:41 2014 +1000

 Merge tag 'drm-intel-next-2014-07-11' of 
 git://anongit.freedesktop.org/drm-intel into drm-next

 This patch is a simplified version of the following commits:

 commit 3dd512fbda0d87d1c3fb44bf878b262baee98fb6
 Author: Matt Roper matthew.d.ro...@intel.com
 Date:   Fri Feb 27 10:12:00 2015 -0800

 drm/i915: Kill intel_crtc-cursor_{width, height} (v2)

 commit 54da691deb123c045259ebf4f5c67381244f58f1
 Author: Thomas Gummerer t.gumme...@gmail.com
 Date:   Thu May 14 09:16:39 2015 +0200

 drm/i915: fix screen flickering

 This is expected to land in v4.1-rc5, i.e. these are all upstream
 commits. And I assume none of them apply to stable kernels directly.


 commit 3ef00284e6a48f7deb0784ccca0478ebb7d4bcfc
 Author: Matt Roper matthew.d.ro...@intel.com
 Date:   Mon Mar 9 10:19:24 2015 -0700

 drm/i915: Use crtc-state-active in ilk/skl watermark calculations 
 (v3)

 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90508
 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1218688
 Cc: sta...@vger.kernel.org

 I (and most likely the stable team) would like to know which stable
 kernel versions this is targeting.

I would guess 4.0.y for now.  Both Fedora 21 and 22 are using that
stable release, and it is most noticeable on Fedora 22 where we use
Wayland for the GDM session.

 Do you have Tested-bys against the stable versions you're targeting?

I've pointed a few people that have machines that hit this issue at
this patch and they're now CC'd.  Hopefully we can get some tests in
this week.

 Anyway this is

 Acked-by: Jani Nikula jani.nik...@intel.com

Thanks for the Ack.  Hopefully Greg doesn't immediately formletter
this one :).

josh

 Cc: Dave Airlie airl...@gmail.com
 Cc: Jani Nikula jani.nik...@intel.com
 Signed-off-by: Ander Conselvan de Oliveira 
 ander.conselvan.de.olive...@intel.com
 ---
  drivers/gpu/drm/i915/intel_pm.c | 14 +++---
  1 file changed, 11 insertions(+), 3 deletions(-)

 diff --git a/drivers/gpu/drm/i915/intel_pm.c 
 b/drivers/gpu/drm/i915/intel_pm.c
 index 24d77dd..3d67f8e 100644
 --- a/drivers/gpu/drm/i915/intel_pm.c
 +++ b/drivers/gpu/drm/i915/intel_pm.c
 @@ -1898,16 +1898,24 @@ static void ilk_compute_wm_parameters(struct 
 drm_crtc *crtc,
   enum pipe pipe = intel_crtc-pipe;
   struct drm_plane *plane;

 - if (!intel_crtc_active(crtc))
 + if (!intel_crtc-active)
   return;

   p-active = true;
   p-pipe_htotal = intel_crtc-config-base.adjusted_mode.crtc_htotal;
   p-pixel_rate = ilk_pipe_pixel_rate(dev, crtc);
 - p-pri.bytes_per_pixel = crtc-primary-fb-bits_per_pixel / 8;
 +
 +
 + if (crtc-primary-fb)
 + p-pri.bytes_per_pixel = crtc-primary-fb-bits_per_pixel / 8;
 + else
 + p-pri.bytes_per_pixel = 4;
 +
   p-cur.bytes_per_pixel = 4;
 +
   p-pri.horiz_pixels = intel_crtc-config-pipe_src_w;
 - p-cur.horiz_pixels = intel_crtc-cursor_width;
 + p-cur.horiz_pixels = intel_crtc-base.cursor-state-crtc_w;
 +
   /* TODO: for now, assume primary and cursor planes are always enabled. 
 */
   p-pri.enabled = true;
   p-cur.enabled = true;
 --
 2.1.0


 --
 Jani Nikula, Intel Open Source Technology Center
 --
 To unsubscribe from this list: send the line unsubscribe stable in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Intel-gfx] [PATCH] drm/i915: Add checks to i915_bind_vma

[Josh Boyer]

On Wed, Apr 22, 2015 at 12:45 PM, Mika Kuoppala
mika.kuopp...@linux.intel.com wrote:
 The current aliasing ppgtt implementation allocates
 the page table structures on driver initialization
 for the entire vm address space. Earlier the page tables
 were allocated as array of struct pages, but introduction
 of dynamic allocation of page structures changed the page
 tables to be inside a page directory.

 We have a detailed bug report where traversing of tables and
 deferencing page_table[pte]-page oopses. This indicates that
 our pre allocation of page tables has failed or that we get
 corrupt vma which does not fit inside the vm area and throws
 pte  511.

 Add more checks to catch the latter. Warn and bail out if
 we get vma which is out of bounds for binding.

 v2: Check vma node early (Chris)

 Cc: Linus Torvalds torva...@linux-foundation.org
 Cc: Chris Wilson ch...@chris-wilson.co.uk
 Cc: Michel Thierry michel.thie...@intel.com
 Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
 ---
  drivers/gpu/drm/i915/i915_gem_gtt.c | 7 +++
  1 file changed, 7 insertions(+)

 diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
 b/drivers/gpu/drm/i915/i915_gem_gtt.c
 index 0239fbf..2ffa8f6 100644
 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
 +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
 @@ -2746,6 +2746,13 @@ i915_get_ggtt_vma_pages(struct i915_vma *vma)
  int i915_vma_bind(struct i915_vma *vma, enum i915_cache_level cache_level,
   u32 flags)
  {
 +
 +   if (WARN_ON(!drm_mm_node_allocated(vma-node)))
 +   return -EINVAL;
 +
 +   if (WARN_ON(vma-node.start  vma-vm-total - vma-node.size))
 +   return -EINVAL;
 +

Do you really need a full backtrace in these cases?  From an end user
perspective, they're going to get a popup saying they have a kernel
problem or an automated tool will file a bug for them and they will
have no idea what any of this means.

I understand the need for the check, but could it be done in a way
that doesn't splat an oops on a user's system?  The i915 driver has
tons of these kinds of WARN_ONs already and they don't seem to be
helping anything overall...

josh

 if (i915_is_ggtt(vma-vm)) {
 int ret = i915_get_ggtt_vma_pages(vma);

 --
 1.9.1

 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] stable 3.19 backport request

[Josh Boyer]

On Mon, Mar 2, 2015 at 4:30 AM, Jani Nikula jani.nik...@intel.com wrote:

 Stable team, please backport

 commit f9b61ff6bce9a44555324b29e593fdffc9a115bc
 Author: Daniel Vetter daniel.vet...@ffwll.ch
 Date:   Wed Jan 7 13:54:39 2015 +0100

 drm/i915: Push vblank enable/disable past encoder-enable/disable

 to 3.19.

 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89108

 Quite likely also

 References: http://mid.gmane.org/20150131211609.GA3710@yulia-desktop
 References: 
 http://mid.gmane.org/CA+55aFwCf+94-5E+axJNu3GdCTF=1tkda9d6gfm4sdovfnn...@mail.gmail.com

Did this request get missed or was there some further problem with the
patch that prevents it from being applicable for 3.19?

josh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter dan...@ffwll.ch wrote:
  commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
  Author: Damien Lespiau damien.lesp...@intel.com
  Date:   Thu Feb 5 18:30:20 2015 +
 
  drm/i915: Don't try to reference the fb in get_initial_plane_config()
 
  From linux-next?
 
  Yes, building now.  Will let you know as soon as I test it on both 
  machines.

 OK, with that commit applied I no longer get the kref.h splat and the
 NUC machine boots headless.  I still see the backtrace below on both
 the NUC and the macbook.  I have a copy of it with drm.debug=0xff from
 the NUC here:

 https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt

 Getting better at least :).

 On top of what you currently have please also cherry-pick

 commit fb9981aa675eb7b398849915364916fd98833cfa
 Author: Damien Lespiau damien.lesp...@intel.com
 Date:   Thu Feb 5 19:24:25 2015 +

 drm/i915: Fix atomic state when reusing the firmware fb

 from -next. Let's hope this terminates eventually ;-)

Hm.  That one doesn't apply cleanly.  I think because it needs:

From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
From: Damien Lespiau damien.lesp...@intel.com
Date: Thu, 5 Feb 2015 17:22:18 +
Subject: drm/i915: Store the initial framebuffer in initial_plane_config

first.  Do you want me to grab both, or should I try and figure out
how to backport fb9981aa67 without it?

josh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter dan...@ffwll.ch wrote:
 On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
 On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter dan...@ffwll.ch wrote:
   commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
   Author: Damien Lespiau damien.lesp...@intel.com
   Date:   Thu Feb 5 18:30:20 2015 +
  
   drm/i915: Don't try to reference the fb in 
   get_initial_plane_config()
  
   From linux-next?
  
   Yes, building now.  Will let you know as soon as I test it on both 
   machines.
 
  OK, with that commit applied I no longer get the kref.h splat and the
  NUC machine boots headless.  I still see the backtrace below on both
  the NUC and the macbook.  I have a copy of it with drm.debug=0xff from
  the NUC here:
 
  https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
 
  Getting better at least :).
 
  On top of what you currently have please also cherry-pick
 
  commit fb9981aa675eb7b398849915364916fd98833cfa
  Author: Damien Lespiau damien.lesp...@intel.com
  Date:   Thu Feb 5 19:24:25 2015 +
 
  drm/i915: Fix atomic state when reusing the firmware fb
 
  from -next. Let's hope this terminates eventually ;-)

 Hm.  That one doesn't apply cleanly.  I think because it needs:

 From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
 From: Damien Lespiau damien.lesp...@intel.com
 Date: Thu, 5 Feb 2015 17:22:18 +
 Subject: drm/i915: Store the initial framebuffer in initial_plane_config

 first.  Do you want me to grab both, or should I try and figure out
 how to backport fb9981aa67 without it?

 Oops missed that. The active ingredient is setting crtc-primary-state-crtc 
 like this:
 -Daniel


 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 1c12262029fb..bfc14a6046ea 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
 return;

 if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
 +   intel_crtc-base.primary-state-crtc = intel_crtc-base;
 update_state_fb(intel_crtc-base.primary);
 return;
 }
 @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,

 drm_framebuffer_reference(c-primary-fb);
 intel_crtc-base.primary-fb = c-primary-fb;
 +   intel_crtc-base.primary-state-crtc = 
 intel_crtc-base;
 obj-frontbuffer_bits |= 
 INTEL_FRONTBUFFER_PRIMARY(intel_crtc-pipe);
 break;
 }

Hm.  So I used your patch above.  The macbook boots fine and all the
oops/WARNS are gone except the audio one that was unrelated and
present before all of this.

However, the NUC is back to not booting without HDMI plugged in.  I
did the drm.debug=0xff+blacklist/insmod trick again and put the
results up here:

https://jwboyer.fedorapeople.org/pub/vetters.txt

The frontbuffer splat is back now.

I confirmed multiple times that the NUC boots fine with the kernel
that doesn't include the above patch but has the other two included
(albeit with the drm_atomic WARN still).

Not sure what to make of this one.

josh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Wed, Mar 25, 2015 at 11:50 AM, Daniel Vetter dan...@ffwll.ch wrote:
 On Wed, Mar 25, 2015 at 11:37:35AM -0400, Josh Boyer wrote:
 On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter dan...@ffwll.ch wrote:
  On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
  On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter dan...@ffwll.ch wrote:
commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
Author: Damien Lespiau damien.lesp...@intel.com
Date:   Thu Feb 5 18:30:20 2015 +
   
drm/i915: Don't try to reference the fb in 
get_initial_plane_config()
   
From linux-next?
   
Yes, building now.  Will let you know as soon as I test it on both 
machines.
  
   OK, with that commit applied I no longer get the kref.h splat and the
   NUC machine boots headless.  I still see the backtrace below on both
   the NUC and the macbook.  I have a copy of it with drm.debug=0xff from
   the NUC here:
  
   https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
  
   Getting better at least :).
  
   On top of what you currently have please also cherry-pick
  
   commit fb9981aa675eb7b398849915364916fd98833cfa
   Author: Damien Lespiau damien.lesp...@intel.com
   Date:   Thu Feb 5 19:24:25 2015 +
  
   drm/i915: Fix atomic state when reusing the firmware fb
  
   from -next. Let's hope this terminates eventually ;-)
 
  Hm.  That one doesn't apply cleanly.  I think because it needs:
 
  From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
  From: Damien Lespiau damien.lesp...@intel.com
  Date: Thu, 5 Feb 2015 17:22:18 +
  Subject: drm/i915: Store the initial framebuffer in initial_plane_config
 
  first.  Do you want me to grab both, or should I try and figure out
  how to backport fb9981aa67 without it?
 
  Oops missed that. The active ingredient is setting 
  crtc-primary-state-crtc like this:
  -Daniel
 
 
  diff --git a/drivers/gpu/drm/i915/intel_display.c 
  b/drivers/gpu/drm/i915/intel_display.c
  index 1c12262029fb..bfc14a6046ea 100644
  --- a/drivers/gpu/drm/i915/intel_display.c
  +++ b/drivers/gpu/drm/i915/intel_display.c
  @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
  return;
 
  if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
  +   intel_crtc-base.primary-state-crtc = intel_crtc-base;
  update_state_fb(intel_crtc-base.primary);
  return;
  }
  @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
 
  drm_framebuffer_reference(c-primary-fb);
  intel_crtc-base.primary-fb = c-primary-fb;
  +   intel_crtc-base.primary-state-crtc = 
  intel_crtc-base;
  obj-frontbuffer_bits |= 
  INTEL_FRONTBUFFER_PRIMARY(intel_crtc-pipe);
  break;
  }

 Hm.  So I used your patch above.  The macbook boots fine and all the
 oops/WARNS are gone except the audio one that was unrelated and
 present before all of this.

 However, the NUC is back to not booting without HDMI plugged in.  I
 did the drm.debug=0xff+blacklist/insmod trick again and put the
 results up here:

 https://jwboyer.fedorapeople.org/pub/vetters.txt

 The frontbuffer splat is back now.

 I confirmed multiple times that the NUC boots fine with the kernel
 that doesn't include the above patch but has the other two included
 (albeit with the drm_atomic WARN still).

 Not sure what to make of this one.

 Yeah that fail looks like we're freeing an fb that's still in use.
 Hilarity happens and since that happens under console_lock at boot-up your
 machine dies.

 Does that machine die the same way in drm-intel-nightly/linux-next?

I'll try that a bit later today.  Out of sheer curiosity, I folded
commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
update) into the patch above and kicked off a build.  The theory is
that we're picking up a bunch of other changes right in that range of
commits, why not try one more.  I'll let you know if that fixes
anything.  Otherwise, I'll try building drm-intel-nightly and/or
linux-next after that.

josh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Wed, Mar 25, 2015 at 11:53 AM, Josh Boyer jwbo...@fedoraproject.org wrote:
 On Wed, Mar 25, 2015 at 11:50 AM, Daniel Vetter dan...@ffwll.ch wrote:
 On Wed, Mar 25, 2015 at 11:37:35AM -0400, Josh Boyer wrote:
 On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter dan...@ffwll.ch wrote:
  On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
  On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter dan...@ffwll.ch wrote:
commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
Author: Damien Lespiau damien.lesp...@intel.com
Date:   Thu Feb 5 18:30:20 2015 +
   
drm/i915: Don't try to reference the fb in 
get_initial_plane_config()
   
From linux-next?
   
Yes, building now.  Will let you know as soon as I test it on both 
machines.
  
   OK, with that commit applied I no longer get the kref.h splat and the
   NUC machine boots headless.  I still see the backtrace below on both
   the NUC and the macbook.  I have a copy of it with drm.debug=0xff from
   the NUC here:
  
   https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
  
   Getting better at least :).
  
   On top of what you currently have please also cherry-pick
  
   commit fb9981aa675eb7b398849915364916fd98833cfa
   Author: Damien Lespiau damien.lesp...@intel.com
   Date:   Thu Feb 5 19:24:25 2015 +
  
   drm/i915: Fix atomic state when reusing the firmware fb
  
   from -next. Let's hope this terminates eventually ;-)
 
  Hm.  That one doesn't apply cleanly.  I think because it needs:
 
  From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
  From: Damien Lespiau damien.lesp...@intel.com
  Date: Thu, 5 Feb 2015 17:22:18 +
  Subject: drm/i915: Store the initial framebuffer in initial_plane_config
 
  first.  Do you want me to grab both, or should I try and figure out
  how to backport fb9981aa67 without it?
 
  Oops missed that. The active ingredient is setting 
  crtc-primary-state-crtc like this:
  -Daniel
 
 
  diff --git a/drivers/gpu/drm/i915/intel_display.c 
  b/drivers/gpu/drm/i915/intel_display.c
  index 1c12262029fb..bfc14a6046ea 100644
  --- a/drivers/gpu/drm/i915/intel_display.c
  +++ b/drivers/gpu/drm/i915/intel_display.c
  @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
  return;
 
  if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
  +   intel_crtc-base.primary-state-crtc = intel_crtc-base;
  update_state_fb(intel_crtc-base.primary);
  return;
  }
  @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
 
  drm_framebuffer_reference(c-primary-fb);
  intel_crtc-base.primary-fb = c-primary-fb;
  +   intel_crtc-base.primary-state-crtc = 
  intel_crtc-base;
  obj-frontbuffer_bits |= 
  INTEL_FRONTBUFFER_PRIMARY(intel_crtc-pipe);
  break;
  }

 Hm.  So I used your patch above.  The macbook boots fine and all the
 oops/WARNS are gone except the audio one that was unrelated and
 present before all of this.

 However, the NUC is back to not booting without HDMI plugged in.  I
 did the drm.debug=0xff+blacklist/insmod trick again and put the
 results up here:

 https://jwboyer.fedorapeople.org/pub/vetters.txt

 The frontbuffer splat is back now.

 I confirmed multiple times that the NUC boots fine with the kernel
 that doesn't include the above patch but has the other two included
 (albeit with the drm_atomic WARN still).

 Not sure what to make of this one.

 Yeah that fail looks like we're freeing an fb that's still in use.
 Hilarity happens and since that happens under console_lock at boot-up your
 machine dies.

 Does that machine die the same way in drm-intel-nightly/linux-next?

 I'll try that a bit later today.  Out of sheer curiosity, I folded
 commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
 update) into the patch above and kicked off a build.  The theory is
 that we're picking up a bunch of other changes right in that range of
 commits, why not try one more.  I'll let you know if that fixes
 anything.  Otherwise, I'll try building drm-intel-nightly and/or
 linux-next after that.

The drm-intel-nightly build finished first.  It boots without HDMI
plugged in, but it has pretty much the same splats as the previous
kernel.  Confused.  Full log here:

https://jwboyer.fedorapeople.org/pub/intel-nightly.txt

I don't have much hope for my other build.

josh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Wed, Mar 25, 2015 at 1:17 PM, Daniel Vetter dan...@ffwll.ch wrote:
 On Wed, Mar 25, 2015 at 12:42:46PM -0400, Josh Boyer wrote:
 On Wed, Mar 25, 2015 at 11:53 AM, Josh Boyer jwbo...@fedoraproject.org 
 wrote:
  On Wed, Mar 25, 2015 at 11:50 AM, Daniel Vetter dan...@ffwll.ch wrote:
  On Wed, Mar 25, 2015 at 11:37:35AM -0400, Josh Boyer wrote:
  On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter dan...@ffwll.ch wrote:
   On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
   On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter dan...@ffwll.ch 
   wrote:
 commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
 Author: Damien Lespiau damien.lesp...@intel.com
 Date:   Thu Feb 5 18:30:20 2015 +

 drm/i915: Don't try to reference the fb in 
 get_initial_plane_config()

 From linux-next?

 Yes, building now.  Will let you know as soon as I test it on 
 both machines.
   
OK, with that commit applied I no longer get the kref.h splat and 
the
NUC machine boots headless.  I still see the backtrace below on 
both
the NUC and the macbook.  I have a copy of it with drm.debug=0xff 
from
the NUC here:
   
https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
   
Getting better at least :).
   
On top of what you currently have please also cherry-pick
   
commit fb9981aa675eb7b398849915364916fd98833cfa
Author: Damien Lespiau damien.lesp...@intel.com
Date:   Thu Feb 5 19:24:25 2015 +
   
drm/i915: Fix atomic state when reusing the firmware fb
   
from -next. Let's hope this terminates eventually ;-)
  
   Hm.  That one doesn't apply cleanly.  I think because it needs:
  
   From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
   From: Damien Lespiau damien.lesp...@intel.com
   Date: Thu, 5 Feb 2015 17:22:18 +
   Subject: drm/i915: Store the initial framebuffer in 
   initial_plane_config
  
   first.  Do you want me to grab both, or should I try and figure out
   how to backport fb9981aa67 without it?
  
   Oops missed that. The active ingredient is setting 
   crtc-primary-state-crtc like this:
   -Daniel
  
  
   diff --git a/drivers/gpu/drm/i915/intel_display.c 
   b/drivers/gpu/drm/i915/intel_display.c
   index 1c12262029fb..bfc14a6046ea 100644
   --- a/drivers/gpu/drm/i915/intel_display.c
   +++ b/drivers/gpu/drm/i915/intel_display.c
   @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc 
   *intel_crtc,
   return;
  
   if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
   +   intel_crtc-base.primary-state-crtc = 
   intel_crtc-base;
   update_state_fb(intel_crtc-base.primary);
   return;
   }
   @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc 
   *intel_crtc,
  
   drm_framebuffer_reference(c-primary-fb);
   intel_crtc-base.primary-fb = c-primary-fb;
   +   intel_crtc-base.primary-state-crtc = 
   intel_crtc-base;
   obj-frontbuffer_bits |= 
   INTEL_FRONTBUFFER_PRIMARY(intel_crtc-pipe);
   break;
   }
 
  Hm.  So I used your patch above.  The macbook boots fine and all the
  oops/WARNS are gone except the audio one that was unrelated and
  present before all of this.
 
  However, the NUC is back to not booting without HDMI plugged in.  I
  did the drm.debug=0xff+blacklist/insmod trick again and put the
  results up here:
 
  https://jwboyer.fedorapeople.org/pub/vetters.txt
 
  The frontbuffer splat is back now.
 
  I confirmed multiple times that the NUC boots fine with the kernel
  that doesn't include the above patch but has the other two included
  (albeit with the drm_atomic WARN still).
 
  Not sure what to make of this one.
 
  Yeah that fail looks like we're freeing an fb that's still in use.
  Hilarity happens and since that happens under console_lock at boot-up your
  machine dies.
 
  Does that machine die the same way in drm-intel-nightly/linux-next?
 
  I'll try that a bit later today.  Out of sheer curiosity, I folded
  commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
  update) into the patch above and kicked off a build.  The theory is
  that we're picking up a bunch of other changes right in that range of
  commits, why not try one more.  I'll let you know if that fixes
  anything.  Otherwise, I'll try building drm-intel-nightly and/or
  linux-next after that.

 The drm-intel-nightly build finished first.  It boots without HDMI
 plugged in, but it has pretty much the same splats as the previous
 kernel.  Confused.  Full log here:

 https://jwboyer.fedorapeople.org/pub/intel-nightly.txt

 I don't have much hope for my other build.

 Yeah that's at least good news for the theory I've been cooking meanwhile.
 Can you try the below diff (on top of next/nightly)? For the current
 cherry-pick pile on top

Re: [Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Wed, Mar 25, 2015 at 01:37:41PM -0400, Josh Boyer wrote:
  Yeah that fail looks like we're freeing an fb that's still in use.
  Hilarity happens and since that happens under console_lock at boot-up 
  your
  machine dies.
 
  Does that machine die the same way in drm-intel-nightly/linux-next?
 
  I'll try that a bit later today.  Out of sheer curiosity, I folded
  commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
  update) into the patch above and kicked off a build.  The theory is
  that we're picking up a bunch of other changes right in that range of
  commits, why not try one more.  I'll let you know if that fixes
  anything.  Otherwise, I'll try building drm-intel-nightly and/or
  linux-next after that.

 The drm-intel-nightly build finished first.  It boots without HDMI
 plugged in, but it has pretty much the same splats as the previous
 kernel.  Confused.  Full log here:

 https://jwboyer.fedorapeople.org/pub/intel-nightly.txt

 I don't have much hope for my other build.

 Yeah that's at least good news for the theory I've been cooking meanwhile.
 Can you try the below diff (on top of next/nightly)? For the current
 cherry-pick pile on top of 4.0-rc you'd need to prepend intel_crtc-base.
 to primary-...

 Thanks, Daniel

 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index ceb2e61b4c91..cb508542c6ab 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,

 primary-fb = plane_config-fb-base;
 primary-state-crtc = intel_crtc-base;
 +   primary-crtc = intel_crtc-base;
 update_state_fb(primary);

 return;
 @@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
 drm_framebuffer_reference(c-primary-fb);
 primary-fb = c-primary-fb;
 primary-state-crtc = intel_crtc-base;
 +   primary-crtc = intel_crtc-base;
 update_state_fb(intel_crtc-base.primary);
 obj-frontbuffer_bits |= 
 INTEL_FRONTBUFFER_PRIMARY(intel_crtc-pipe);
 break;

Hey, that seems to do the trick on the NUC machine.  Boots without
HDMI connected and there are no backtraces.  Nice!

Let me go and munge it around for a backport on top of -rc5 with the
rest of the pile and see if both the macbook and NUC machines work
then.  Will be a bit for it to build.

OK, that helped on all my machines I have.  No backtraces and they all
boot again as I would expect.  For the record, here is what I have on
top of -rc5:

drm-Fixup-racy-refcounting-in-plane_force_disable.patch
drm-i915-Don-t-try-to-reference-the-fb-in-get_initia.patch

and this patch:

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 177714a9d778..778e7fa41c17 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2439,6 +2439,8 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
return;
 
if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
+   intel_crtc-base.primary-state-crtc = intel_crtc-base;
+   intel_crtc-base.primary-crtc = intel_crtc-base;
update_state_fb(intel_crtc-base.primary);
return;
}
@@ -2469,6 +2471,8 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
 
drm_framebuffer_reference(c-primary-fb);
intel_crtc-base.primary-fb = c-primary-fb;
+   intel_crtc-base.primary-state-crtc = 
intel_crtc-base;
+   intel_crtc-base.primary-crtc = intel_crtc-base;
obj-frontbuffer_bits |= 
INTEL_FRONTBUFFER_PRIMARY(intel_crtc-pipe);
break;
}

which is a mash-up of:

drm/i915: Fix atomic state when reusing the firmware fb

and

drm/i915: Fixup legacy plane-crtc link for initial fb config

which you just sent out.

I think that covers everything.

josh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter dan...@ffwll.ch wrote:
 On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
 On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter dan...@ffwll.ch wrote:
  On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
  On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer jwbo...@fedoraproject.org 
  wrote:
 
  snip
 
   Xi Ruoyao (1):
 drm/i915: Ensure plane-state-fb stays in sync with plane-fb
 
  Turns out to be that commit.
 
  git bisect start 'drivers/gpu/drm/i915/'
  # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
  'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
  git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
  # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
  git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
  # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
  plane-state-fb stays in sync with plane-fb
  git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
  # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
  drm/i915: Ensure plane-state-fb stays in sync with plane-fb
 
  Doing a straight revert on top of 4.0-rc5 makes things work again,
  albeit with the WARN_ON(obj-frontbuffer_bits) splat still being
  there.
 
  Can you please test the tip of drm-fixes:
 
  commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
  Author: Daniel Vetter daniel.vet...@ffwll.ch
  Date:   Fri Feb 27 12:58:13 2015 +0100
 
  drm: Fixup racy refcounting in plane_force_disable
 
  http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixesid=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
 
  Because fumble that patch didn't make it to drm-fixes a while ago and
  instead landed in drm-next.

 That seems to have helped with totally different issues a macbook I
 have was seeing.  However, it still doesn't fix the issue with the
 Celeron based NUC machine.

 I built a kernel based on Linus' latest tree as of this morning,
 without reverting 319c1d4 and adding the commit you pointed to.  The
 NUC still won't boot without HDMI connected.  With HDMI connected I
 still see the trace below.  If I do the blacklist and then insmod
 dance with HDMI unplugged it shows the same spew I reported yesterday
 which starts with the same backtrace.

 I'll try building a kernel with 319c1d4 reverted + your patch.  I
 suspect things will work fine with that combination because the two
 issues are unrelated.

 Can you please boot with drm.debug=0xff for the below case and grab
 complete dmesg? There'll be a lot of crap in the logs, you might need to
 blow up the logbuf size massively. But that log should contain everything
 I need to figure out where that framebuffer we're blowing up on is going.

I provided both with HDMI attached and without (via insmod).  If you
want them emailed directly let me know, but they were large.

Boot with drm.debug=0xff and HDMI connected:

https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt

Boot with drm.debug=0xff without HDMI connected and i915 loaded via
manual insmod after boot:

https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt

josh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter dan...@ffwll.ch wrote:
 On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
 On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer jwbo...@fedoraproject.org 
 wrote:

 snip

  Xi Ruoyao (1):
drm/i915: Ensure plane-state-fb stays in sync with plane-fb

 Turns out to be that commit.

 git bisect start 'drivers/gpu/drm/i915/'
 # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
 git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
 # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
 git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
 # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
 plane-state-fb stays in sync with plane-fb
 git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
 # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
 drm/i915: Ensure plane-state-fb stays in sync with plane-fb

 Doing a straight revert on top of 4.0-rc5 makes things work again,
 albeit with the WARN_ON(obj-frontbuffer_bits) splat still being
 there.

 Can you please test the tip of drm-fixes:

 commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
 Author: Daniel Vetter daniel.vet...@ffwll.ch
 Date:   Fri Feb 27 12:58:13 2015 +0100

 drm: Fixup racy refcounting in plane_force_disable

 http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixesid=8218c3f4df3bb1c637c17552405039a6dd3c1ee1

 Because fumble that patch didn't make it to drm-fixes a while ago and
 instead landed in drm-next.

That seems to have helped with totally different issues a macbook I
have was seeing.  However, it still doesn't fix the issue with the
Celeron based NUC machine.

I built a kernel based on Linus' latest tree as of this morning,
without reverting 319c1d4 and adding the commit you pointed to.  The
NUC still won't boot without HDMI connected.  With HDMI connected I
still see the trace below.  If I do the blacklist and then insmod
dance with HDMI unplugged it shows the same spew I reported yesterday
which starts with the same backtrace.

I'll try building a kernel with 319c1d4 reverted + your patch.  I
suspect things will work fine with that combination because the two
issues are unrelated.

josh

[  +0.27] WARNING: CPU: 1 PID: 144 at include/linux/kref.h:47
drm_framebuffer_reference+0x7a/0x90 [drm]()
[  +0.03] Modules linked in: i915(+) i2c_algo_bit drm_kms_helper
drm sdhci_acpi sdhci mmc_core video
[  +0.12] CPU: 1 PID: 144 Comm: systemd-udevd Not tainted
4.0.0-0.rc5.git1.1.fc23.x86_64 #1
[  +0.03] Hardware name:
\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x
\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x/DN2820FYK,
BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
[  +0.03]   b82c27d6 88003f98f688
8177ada9
[  +0.04]    88003f98f6c8
8109c78a
[  +0.04]  8802345c91a8 880234b0bd80 880234b923c0
88003fae
[  +0.04] Call Trace:
[  +0.10]  [8177ada9] dump_stack+0x45/0x57
[  +0.05]  [8109c78a] warn_slowpath_common+0x8a/0xc0
[  +0.04]  [8109c8ba] warn_slowpath_null+0x1a/0x20
[  +0.12]  [a00a822a] drm_framebuffer_reference+0x7a/0x90 [drm]
[  +0.16]  [a00ba6ad] drm_atomic_set_fb_for_plane+0x2d/0x90 [drm]
[  +0.48]  [a014e8c5]
i9xx_get_initial_plane_config+0x295/0x3e0 [i915]
[  +0.15]  [a00b8ed6] ? drm_modeset_unlock_all+0x36/0x70 [drm]
[  +0.31]  [a015f721] intel_modeset_init+0x9f1/0x1a40 [i915]
[  +0.27]  [a0128f5b] ?
valleyview_irq_postinstall+0x3b/0x50 [i915]
[  +0.34]  [a01943ef] i915_driver_load+0xe5f/0x10f0 [i915]
[  +0.05]  [8169654b] ? netlink_broadcast_filtered+0x12b/0x380
[  +0.06]  [8139b730] ? kobj_ns_drop+0x50/0x50
[  +0.04]  [8139bae8] ? kobject_uevent_env+0x178/0x540
[  +0.06]  [814d98d9] ? devtmpfs_create_node+0x109/0x140
[  +0.04]  [814cde27] ? get_device+0x17/0x30
[  +0.05]  [814d3ce5] ? klist_class_dev_get+0x15/0x20
[  +0.05]  [81770bc2] ? klist_add_tail+0x32/0x40
[  +0.04]  [814cf85f] ? device_add+0x19f/0x6a0
[  +0.12]  [a00a2825] drm_dev_register+0xb5/0x110 [drm]
[  +0.11]  [a00a59bd] drm_get_pci_dev+0x8d/0x200 [drm

Re: [Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer jwbo...@fedoraproject.org wrote:
 On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter dan...@ffwll.ch wrote:
 On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
 On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter dan...@ffwll.ch wrote:
  On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
  On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer jwbo...@fedoraproject.org 
  wrote:
 
  snip
 
   Xi Ruoyao (1):
 drm/i915: Ensure plane-state-fb stays in sync with plane-fb
 
  Turns out to be that commit.
 
  git bisect start 'drivers/gpu/drm/i915/'
  # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
  'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
  git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
  # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
  git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
  # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
  plane-state-fb stays in sync with plane-fb
  git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
  # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
  drm/i915: Ensure plane-state-fb stays in sync with plane-fb
 
  Doing a straight revert on top of 4.0-rc5 makes things work again,
  albeit with the WARN_ON(obj-frontbuffer_bits) splat still being
  there.
 
  Can you please test the tip of drm-fixes:
 
  commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
  Author: Daniel Vetter daniel.vet...@ffwll.ch
  Date:   Fri Feb 27 12:58:13 2015 +0100
 
  drm: Fixup racy refcounting in plane_force_disable
 
  http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixesid=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
 
  Because fumble that patch didn't make it to drm-fixes a while ago and
  instead landed in drm-next.

 That seems to have helped with totally different issues a macbook I
 have was seeing.  However, it still doesn't fix the issue with the
 Celeron based NUC machine.

 I built a kernel based on Linus' latest tree as of this morning,
 without reverting 319c1d4 and adding the commit you pointed to.  The
 NUC still won't boot without HDMI connected.  With HDMI connected I
 still see the trace below.  If I do the blacklist and then insmod
 dance with HDMI unplugged it shows the same spew I reported yesterday
 which starts with the same backtrace.

 I'll try building a kernel with 319c1d4 reverted + your patch.  I
 suspect things will work fine with that combination because the two
 issues are unrelated.

 Can you please boot with drm.debug=0xff for the below case and grab
 complete dmesg? There'll be a lot of crap in the logs, you might need to
 blow up the logbuf size massively. But that log should contain everything
 I need to figure out where that framebuffer we're blowing up on is going.

 I provided both with HDMI attached and without (via insmod).  If you
 want them emailed directly let me know, but they were large.

 Boot with drm.debug=0xff and HDMI connected:

 https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt

 Boot with drm.debug=0xff without HDMI connected and i915 loaded via
 manual insmod after boot:

 https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt

Here's one more from the macbook I mentioned.  It's showing the same
kref.h splat:

https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt

josh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter dan...@ffwll.ch wrote:
 On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote:
 On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer jwbo...@fedoraproject.org 
 wrote:
  On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter dan...@ffwll.ch wrote:
  On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
  On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter dan...@ffwll.ch wrote:
   On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
   On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer 
   jwbo...@fedoraproject.org wrote:
  
   snip
  
Xi Ruoyao (1):
  drm/i915: Ensure plane-state-fb stays in sync with 
plane-fb
  
   Turns out to be that commit.
  
   git bisect start 'drivers/gpu/drm/i915/'
   # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
   'for-linus' of 
   git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
   git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
   # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
   git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
   # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
   plane-state-fb stays in sync with plane-fb
   git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
   # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
   drm/i915: Ensure plane-state-fb stays in sync with plane-fb
  
   Doing a straight revert on top of 4.0-rc5 makes things work again,
   albeit with the WARN_ON(obj-frontbuffer_bits) splat still being
   there.
  
   Can you please test the tip of drm-fixes:
  
   commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
   Author: Daniel Vetter daniel.vet...@ffwll.ch
   Date:   Fri Feb 27 12:58:13 2015 +0100
  
   drm: Fixup racy refcounting in plane_force_disable
  
   http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixesid=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
  
   Because fumble that patch didn't make it to drm-fixes a while ago and
   instead landed in drm-next.
 
  That seems to have helped with totally different issues a macbook I
  have was seeing.  However, it still doesn't fix the issue with the
  Celeron based NUC machine.
 
  I built a kernel based on Linus' latest tree as of this morning,
  without reverting 319c1d4 and adding the commit you pointed to.  The
  NUC still won't boot without HDMI connected.  With HDMI connected I
  still see the trace below.  If I do the blacklist and then insmod
  dance with HDMI unplugged it shows the same spew I reported yesterday
  which starts with the same backtrace.
 
  I'll try building a kernel with 319c1d4 reverted + your patch.  I
  suspect things will work fine with that combination because the two
  issues are unrelated.
 
  Can you please boot with drm.debug=0xff for the below case and grab
  complete dmesg? There'll be a lot of crap in the logs, you might need to
  blow up the logbuf size massively. But that log should contain everything
  I need to figure out where that framebuffer we're blowing up on is going.
 
  I provided both with HDMI attached and without (via insmod).  If you
  want them emailed directly let me know, but they were large.
 
  Boot with drm.debug=0xff and HDMI connected:
 
  https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
 
  Boot with drm.debug=0xff without HDMI connected and i915 loaded via
  manual insmod after boot:
 
  https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt

 Here's one more from the macbook I mentioned.  It's showing the same
 kref.h splat:

 https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt

 Ok there's at least one fixup for which we've failed to apply when porting
 the fb refcounting fix from -next. Can you please cherry-pick

 commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
 Author: Damien Lespiau damien.lesp...@intel.com
 Date:   Thu Feb 5 18:30:20 2015 +

 drm/i915: Don't try to reference the fb in get_initial_plane_config()

 From linux-next?

Yes, building now.  Will let you know as soon as I test it on both machines.

josh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Tue, Mar 24, 2015 at 10:46 AM, Josh Boyer jwbo...@fedoraproject.org wrote:
 On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter dan...@ffwll.ch wrote:
 On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote:
 On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer jwbo...@fedoraproject.org 
 wrote:
  On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter dan...@ffwll.ch wrote:
  On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
  On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter dan...@ffwll.ch wrote:
   On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
   On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer 
   jwbo...@fedoraproject.org wrote:
  
   snip
  
Xi Ruoyao (1):
  drm/i915: Ensure plane-state-fb stays in sync with 
plane-fb
  
   Turns out to be that commit.
  
   git bisect start 'drivers/gpu/drm/i915/'
   # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
   'for-linus' of 
   git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
   git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
   # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
   git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
   # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
   plane-state-fb stays in sync with plane-fb
   git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
   # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
   drm/i915: Ensure plane-state-fb stays in sync with plane-fb
  
   Doing a straight revert on top of 4.0-rc5 makes things work again,
   albeit with the WARN_ON(obj-frontbuffer_bits) splat still being
   there.
  
   Can you please test the tip of drm-fixes:
  
   commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
   Author: Daniel Vetter daniel.vet...@ffwll.ch
   Date:   Fri Feb 27 12:58:13 2015 +0100
  
   drm: Fixup racy refcounting in plane_force_disable
  
   http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixesid=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
  
   Because fumble that patch didn't make it to drm-fixes a while ago and
   instead landed in drm-next.
 
  That seems to have helped with totally different issues a macbook I
  have was seeing.  However, it still doesn't fix the issue with the
  Celeron based NUC machine.
 
  I built a kernel based on Linus' latest tree as of this morning,
  without reverting 319c1d4 and adding the commit you pointed to.  The
  NUC still won't boot without HDMI connected.  With HDMI connected I
  still see the trace below.  If I do the blacklist and then insmod
  dance with HDMI unplugged it shows the same spew I reported yesterday
  which starts with the same backtrace.
 
  I'll try building a kernel with 319c1d4 reverted + your patch.  I
  suspect things will work fine with that combination because the two
  issues are unrelated.
 
  Can you please boot with drm.debug=0xff for the below case and grab
  complete dmesg? There'll be a lot of crap in the logs, you might need to
  blow up the logbuf size massively. But that log should contain everything
  I need to figure out where that framebuffer we're blowing up on is going.
 
  I provided both with HDMI attached and without (via insmod).  If you
  want them emailed directly let me know, but they were large.
 
  Boot with drm.debug=0xff and HDMI connected:
 
  https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
 
  Boot with drm.debug=0xff without HDMI connected and i915 loaded via
  manual insmod after boot:
 
  https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt

 Here's one more from the macbook I mentioned.  It's showing the same
 kref.h splat:

 https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt

 Ok there's at least one fixup for which we've failed to apply when porting
 the fb refcounting fix from -next. Can you please cherry-pick

 commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
 Author: Damien Lespiau damien.lesp...@intel.com
 Date:   Thu Feb 5 18:30:20 2015 +

 drm/i915: Don't try to reference the fb in get_initial_plane_config()

 From linux-next?

 Yes, building now.  Will let you know as soon as I test it on both machines.

OK, with that commit applied I no longer get the kref.h splat and the
NUC machine boots headless.  I still see the backtrace below on both
the NUC and the macbook.  I have a copy of it with drm.debug=0xff from
the NUC here:

https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt

Getting better at least :).

josh

[  +0.000372] [drm] Initialized i915 1.6.0 20150130 for :00:02.0 on minor 0
[  +0.059774] [drm] GMBUS [i915 gmbus vga] timed out, falling back to
bit banging on pin 2
[  +0.012442] fbcon: inteldrmfb (fb0) is primary device
[  +0.000103] [ cut here ]
[  +0.24] WARNING: CPU: 1 PID: 109 at
drivers/gpu/drm/drm_atomic.c:482 drm_atomic_check_only+0x33d/0x500
[drm]()
[  +0.06] Modules linked in: i915 i2c_algo_bit drm_kms_helper drm
sdhci_pci sdhci mmc_core video
[  +0.04] CPU: 1 PID: 109 Comm: kworker/u16:7

Re: [Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Tue, Mar 24, 2015 at 12:49 PM, Daniel Vetter dan...@ffwll.ch wrote:
 On Tue, Mar 24, 2015 at 05:48:31PM +0100, Daniel Vetter wrote:
 On Tue, Mar 24, 2015 at 12:10:28PM -0400, Josh Boyer wrote:
  On Tue, Mar 24, 2015 at 10:46 AM, Josh Boyer jwbo...@fedoraproject.org 
  wrote:
   On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter dan...@ffwll.ch wrote:
   On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote:
   On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer 
   jwbo...@fedoraproject.org wrote:
On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter dan...@ffwll.ch 
wrote:
On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter dan...@ffwll.ch 
wrote:
 On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
 On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer 
 jwbo...@fedoraproject.org wrote:

 snip

  Xi Ruoyao (1):
drm/i915: Ensure plane-state-fb stays in sync with 
  plane-fb

 Turns out to be that commit.

 git bisect start 'drivers/gpu/drm/i915/'
 # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
 'for-linus' of 
 git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
 git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
 # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
 git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
 # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: 
 Ensure
 plane-state-fb stays in sync with plane-fb
 git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
 # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
 drm/i915: Ensure plane-state-fb stays in sync with plane-fb

 Doing a straight revert on top of 4.0-rc5 makes things work 
 again,
 albeit with the WARN_ON(obj-frontbuffer_bits) splat still being
 there.

 Can you please test the tip of drm-fixes:

 commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
 Author: Daniel Vetter daniel.vet...@ffwll.ch
 Date:   Fri Feb 27 12:58:13 2015 +0100

 drm: Fixup racy refcounting in plane_force_disable

 http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixesid=8218c3f4df3bb1c637c17552405039a6dd3c1ee1

 Because fumble that patch didn't make it to drm-fixes a while 
 ago and
 instead landed in drm-next.
   
That seems to have helped with totally different issues a macbook I
have was seeing.  However, it still doesn't fix the issue with the
Celeron based NUC machine.
   
I built a kernel based on Linus' latest tree as of this morning,
without reverting 319c1d4 and adding the commit you pointed to.  
The
NUC still won't boot without HDMI connected.  With HDMI connected I
still see the trace below.  If I do the blacklist and then insmod
dance with HDMI unplugged it shows the same spew I reported 
yesterday
which starts with the same backtrace.
   
I'll try building a kernel with 319c1d4 reverted + your patch.  I
suspect things will work fine with that combination because the two
issues are unrelated.
   
Can you please boot with drm.debug=0xff for the below case and grab
complete dmesg? There'll be a lot of crap in the logs, you might 
need to
blow up the logbuf size massively. But that log should contain 
everything
I need to figure out where that framebuffer we're blowing up on is 
going.
   
I provided both with HDMI attached and without (via insmod).  If you
want them emailed directly let me know, but they were large.
   
Boot with drm.debug=0xff and HDMI connected:
   
https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
   
Boot with drm.debug=0xff without HDMI connected and i915 loaded via
manual insmod after boot:
   
https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt
  
   Here's one more from the macbook I mentioned.  It's showing the same
   kref.h splat:
  
   https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt
  
   Ok there's at least one fixup for which we've failed to apply when 
   porting
   the fb refcounting fix from -next. Can you please cherry-pick
  
   commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
   Author: Damien Lespiau damien.lesp...@intel.com
   Date:   Thu Feb 5 18:30:20 2015 +
  
   drm/i915: Don't try to reference the fb in 
   get_initial_plane_config()
  
   From linux-next?
  
   Yes, building now.  Will let you know as soon as I test it on both 
   machines.
 
  OK, with that commit applied I no longer get the kref.h splat and the
  NUC machine boots headless.  I still see the backtrace below on both
  the NUC and the macbook.  I have a copy of it with drm.debug=0xff from
  the NUC here:
 
  https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
 
  Getting better at least :).

 Ok thanks for testing. I'll look at that one tomorrow, wasted too much

Re: [Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Fri, Mar 20, 2015 at 5:49 PM, Dave Airlie airl...@linux.ie wrote:

 Hi Linus,

 a bunch of fixes across drivers,
 radeon: disable two ended allocation for now, it breaks some stuff
 amdkfd: misc fixes
 nouveau: fix irq loop problem, add basic support for GM206 (new hw)
 i915: fix some WARNs people were seeing
 exynos: fix some iommu interactions causing boot failures

 In other news I've some problem with my git tree and git request-pull
 [airlied@dreadlord-bne-redhat-com linux]$ git request-pull linus/master origin
 warn: No match for commit 8265d4486d5c2448a1c645fdc20d4e62873d9c3d found at 
 origin
 warn: Are you sure you pushed 'HEAD' there?

 is happening when I just had my branch on drm-fixes, I've made it master
 to generate this pull request so the branch name isn't missing, this
 might be due to my attempt to remove my own master branch, using
 git symbolic-ref HEAD refs/heads/drm-next, so I'll have to regen it next
 week I suppose.

snip


 Damien Lespiau (1):
   drm/i915: Make sure the primary plane is enabled before reading out the 
 fb state

 Xi Ruoyao (1):
   drm/i915: Ensure plane-state-fb stays in sync with plane-fb

I have a machine that no longer boots in a headless manner with -rc5.
It's an Celeron based NUC device.  I blacklisted the i915 driver and
it boots fine, then I ran insmod manually and got the backtrace below.
This machine only has HDMI output on it.  If I have it connected (even
if the monitor is set to display some other input) it will boot fine,
but the backtrace is still present.  I'm going to guess the machine
hangs in headless because X causes some further issues in the
headless case.

Linux v4.0-rc4-199-gb314acaccd7e gets this splat in the headless state:

[  +0.39] WARNING: CPU: 0 PID: 63 at
drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object+0x2e5/0x320
[i915]()
[  +0.02] WARN_ON(obj-frontbuffer_bits)

which is what I thought one of these commits was supposed to fix.  I
don't see that in -rc5, but then we have these other issues.

josh

Backtrace via 'insmod i915.ko.xz' in headless state with 4.0-rc5:

[  +0.063764] vgaarb: device changed decodes:
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[  +0.007099] [ cut here ]
[  +0.37] WARNING: CPU: 1 PID: 1486 at include/linux/kref.h:47
drm_framebuffer_reference+0x7a/0x90 [drm]()
[  +0.03] Modules linked in: i915(+) ip6t_rpfilter ip6t_REJECT
nf_reject_ipv6 xt_conntrack bnep iTCO_wdt iTCO_vendor_support
ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
ip6table_mangle ip6table_security ip6table_raw ip6table_filter
ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4
nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw arc4
iwlmvm mac80211 intel_rapl coretemp kvm_intel kvm iwlwifi btusb
bluetooth i2c_algo_bit cfg80211 drm_kms_helper crct10dif_pclmul
snd_hda_codec_hdmi crc32_pclmul crc32c_intel ghash_clmulni_intel
snd_hda_codec_realtek vfat snd_hda_codec_generic snd_intel_sst_acpi
fat serio_raw snd_intel_sst_core snd_hda_intel i2c_i801 drm
snd_soc_sst_mfld_platform snd_hda_controller
[  +0.46]  r8169 lpc_ich snd_soc_rt5640 snd_hda_codec mfd_core
snd_soc_rl6231 mii mei_txe ir_lirc_codec ir_xmp_decoder
ir_mce_kbd_decoder lirc_dev snd_soc_core ir_sharp_decoder shpchp
ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder mei ir_rc6_decoder
ir_rc5_decoder ir_nec_decoder snd_compress snd_pcm_dmaengine snd_hwdep
snd_seq snd_seq_device iosf_mbi rc_rc6_mce snd_pcm ite_cir snd_timer
rc_core dw_dmac snd dw_dmac_core regmap_i2c i2c_hid
i2c_designware_platform soundcore rfkill_gpio i2c_designware_core
rfkill snd_soc_sst_acpi nfsd auth_rpcgss nfs_acl lockd grace sunrpc
sdhci_acpi video sdhci mmc_core
[  +0.51] CPU: 1 PID: 1486 Comm: insmod Not tainted
4.0.0-0.rc5.git0.1.fc23.x86_64 #1
[  +0.04] Hardware name:
\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x
\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x/DN2820FYK,
BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
[  +0.03]   ee312e2f 8800b7e03688
8177ac09
[  +0.04]    8800b7e036c8
8109c78a
[  +0.04]  8800b7e036b8 880234b46d80 880228ef4f00
88021a54
[  +0.05] Call Trace:
[  +0.09]  [8177ac09] dump_stack+0x45/0x57
[  +0.06]  

Re: [Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer jwbo...@fedoraproject.org wrote:

snip

 Xi Ruoyao (1):
   drm/i915: Ensure plane-state-fb stays in sync with plane-fb

Turns out to be that commit.

git bisect start 'drivers/gpu/drm/i915/'
# good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
# bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
# bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
plane-state-fb stays in sync with plane-fb
git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
# first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
drm/i915: Ensure plane-state-fb stays in sync with plane-fb

Doing a straight revert on top of 4.0-rc5 makes things work again,
albeit with the WARN_ON(obj-frontbuffer_bits) splat still being
there.

josh

 I have a machine that no longer boots in a headless manner with -rc5.
 It's an Celeron based NUC device.  I blacklisted the i915 driver and
 it boots fine, then I ran insmod manually and got the backtrace below.
 This machine only has HDMI output on it.  If I have it connected (even
 if the monitor is set to display some other input) it will boot fine,
 but the backtrace is still present.  I'm going to guess the machine
 hangs in headless because X causes some further issues in the
 headless case.

 Linux v4.0-rc4-199-gb314acaccd7e gets this splat in the headless state:

 [  +0.39] WARNING: CPU: 0 PID: 63 at
 drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object+0x2e5/0x320
 [i915]()
 [  +0.02] WARN_ON(obj-frontbuffer_bits)

 which is what I thought one of these commits was supposed to fix.  I
 don't see that in -rc5, but then we have these other issues.

 josh

 Backtrace via 'insmod i915.ko.xz' in headless state with 4.0-rc5:

 [  +0.063764] vgaarb: device changed decodes:
 PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
 [  +0.007099] [ cut here ]
 [  +0.37] WARNING: CPU: 1 PID: 1486 at include/linux/kref.h:47
 drm_framebuffer_reference+0x7a/0x90 [drm]()
 [  +0.03] Modules linked in: i915(+) ip6t_rpfilter ip6t_REJECT
 nf_reject_ipv6 xt_conntrack bnep iTCO_wdt iTCO_vendor_support
 ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables
 ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
 ip6table_mangle ip6table_security ip6table_raw ip6table_filter
 ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4
 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw arc4
 iwlmvm mac80211 intel_rapl coretemp kvm_intel kvm iwlwifi btusb
 bluetooth i2c_algo_bit cfg80211 drm_kms_helper crct10dif_pclmul
 snd_hda_codec_hdmi crc32_pclmul crc32c_intel ghash_clmulni_intel
 snd_hda_codec_realtek vfat snd_hda_codec_generic snd_intel_sst_acpi
 fat serio_raw snd_intel_sst_core snd_hda_intel i2c_i801 drm
 snd_soc_sst_mfld_platform snd_hda_controller
 [  +0.46]  r8169 lpc_ich snd_soc_rt5640 snd_hda_codec mfd_core
 snd_soc_rl6231 mii mei_txe ir_lirc_codec ir_xmp_decoder
 ir_mce_kbd_decoder lirc_dev snd_soc_core ir_sharp_decoder shpchp
 ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder mei ir_rc6_decoder
 ir_rc5_decoder ir_nec_decoder snd_compress snd_pcm_dmaengine snd_hwdep
 snd_seq snd_seq_device iosf_mbi rc_rc6_mce snd_pcm ite_cir snd_timer
 rc_core dw_dmac snd dw_dmac_core regmap_i2c i2c_hid
 i2c_designware_platform soundcore rfkill_gpio i2c_designware_core
 rfkill snd_soc_sst_acpi nfsd auth_rpcgss nfs_acl lockd grace sunrpc
 sdhci_acpi video sdhci mmc_core
 [  +0.51] CPU: 1 PID: 1486 Comm: insmod Not tainted
 4.0.0-0.rc5.git0.1.fc23.x86_64 #1
 [  +0.04] Hardware name:
 \x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x
 \x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x/DN2820FYK,
 BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
 [  +0.03]   ee312e2f 8800b7e03688
 8177ac09
 [  +0.04]    8800b7e036c8
 8109c78a
 [  +0.04]  8800b7e036b8 880234b46d80 880228ef4f00
 88021a54
 [  +0.05] Call Trace:
 [  +0.09]  [8177ac09] dump_stack+0x45/0x57
 [  +0.06]  [8109c78a] warn_slowpath_common+0x8a/0xc0
 [  +0.04]  [8109c8ba] warn_slowpath_null+0x1a/0x20

Re: [Intel-gfx] 3.14.3 i915 dead display under X11

[Josh Boyer]

On Wed, May 14, 2014 at 3:33 PM, Greg KH gre...@linuxfoundation.org wrote:
 On Wed, May 14, 2014 at 09:19:32PM +0200, Daniel Vetter wrote:
 On Wed, May 14, 2014 at 08:47:38PM +0200, Bruno Prémont wrote:
  CCing intel-gfx as otherwise it will probably not get seen by developers.
 
  On Sun, 11 May 2014 Carbonated Beverage ram...@psychosnugglebunnies.net 
  wrote:
   Bisecting from 3.13.6 (good) to 3.14.3 (bad) ended up with...
  
   commit b35684b8fa94e04f55fd38bf672b737741d2f9e2
   Author: Jani Nikula jani.nik...@intel.com
   Date:   Thu Nov 14 12:13:41 2013 +0200
  
   drm/i915: do full backlight setup at enable time
  
   We should now have all the information we need to do a full
   initialization of the backlight registers.
  
   v2: Keep QUIRK_NO_PCH_PWM_ENABLE for now (Imre).
  
   Signed-off-by: Jani Nikula jani.nik...@intel.com
   Reviewed-by: Imre Deak imre.d...@intel.com
   Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
  
   Which is in 3.12.0
  
   I'm not sure how that came to be.  Does that look right?  What other
   information would be required to track this down?

 We've killed this again in 3.14 since we've hoped the backlight rework in
 there fixed it. For 3.15 we finally have the right fix - vbt has a bit
 telling us not to look at the integrated PWM for the panel.

 For 3.14 we will (again) resurrect the quirk because the vbt thing is a
 bit too risky an imo needs a full -rc cycle for testing. But that revert
 is currently stalled because Greg KH is travelling too much ;-)

 Cc'ing him to make sure that patch doesn't miss the next 3.14.x release.

 What specific patch are you wanting to make sure makes it in?  I've been

Subject: [PATCH for stable 3.14 only 0/1] drm/i915: restore
QUIRK_NO_PCH_PWM_ENABLE

 avoiding all of the drm patches so far for 3.14.y as it's an easy thing
 to do, but I'll eventually have to start paying attention to them :)

Jani has bugged you twice about it I think.  You've said it's not lost
both times.  Third time is a charm?

josh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] 3.13 i915 brightness settings broken when going from docked - undocked

[Josh Boyer]

On Tue, Feb 25, 2014 at 3:36 AM, Jani Nikula jani.nik...@intel.com wrote:
 On Sun, 23 Feb 2014, Josh Boyer jwbo...@fedoraproject.org wrote:
 Backport of upstream commit c91c9f328

 ---
  drivers/gpu/drm/i915/i915_drv.h   |  1 +
  drivers/gpu/drm/i915/intel_opregion.c | 31 ++-
  drivers/gpu/drm/i915/intel_panel.c|  4 
  3 files changed, 11 insertions(+), 25 deletions(-)

 diff --git a/drivers/gpu/drm/i915/i915_drv.h 
 b/drivers/gpu/drm/i915/i915_drv.h
 index 221ac62..d6d4349 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -1371,6 +1371,7 @@ typedef struct drm_i915_private {

   /* backlight */
   struct {
 + bool present;
   int level;
   bool enabled;
   spinlock_t lock; /* bl registers and the above bl fields */
 diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
 b/drivers/gpu/drm/i915/intel_opregion.c
 index 6d69a9b..b2a51ae 100644
 --- a/drivers/gpu/drm/i915/intel_opregion.c
 +++ b/drivers/gpu/drm/i915/intel_opregion.c
 @@ -414,38 +414,19 @@ static u32 asle_set_backlight(struct drm_device *dev, 
 u32 bclp)
   return ASLC_BACKLIGHT_FAILED;

   mutex_lock(dev-mode_config.mutex);
 - /*
 -  * Could match the OpRegion connector here instead, but we'd also need
 -  * to verify the connector could handle a backlight call.
 -  */
 - list_for_each_entry(encoder, dev-mode_config.encoder_list, head)
 - if (encoder-crtc == crtc) {
 - found = true;
 - break;
 - }
 -
 - if (!found) {
 - ret = ASLC_BACKLIGHT_FAILED;
 - goto out;
 - }

 - list_for_each_entry(connector, dev-mode_config.connector_list, head)
 - if (connector-encoder == encoder)
 - intel_connector = to_intel_connector(connector);
 -
 - if (!intel_connector) {
 - ret = ASLC_BACKLIGHT_FAILED;
 - goto out;
 + DRM_DEBUG_KMS(updating opregion backlight %d/255\n, bclp);
 + list_for_each_entry(connector, dev-mode_config.connector_list, head) 
 {
 + intel_connector = to_intel_connector(connector);
 + if (dev_priv-backlight.present)
 + intel_panel_set_backlight(intel_connector, bclp, 255);
   }

 This is not correct because in v3.13 dev_priv-backlight is still driver
 global, not per connector. This means that if you have at least one
 connector with backlight control, the backlight is attempted to change
 on all connectors. In your case, I'm not sure if it leads to anything
 more than extra adjusting of the same backlight.

Well, empirically it leads to the backlight actually changing after
undocking my machine whereas without it, it doesn't.  So maybe by
changing it globally, it is hitting the connector that does have
backlight control.

Anyway, I'm not arguing my patch is correct.  Just that it does do
_something_ to make the backlight work :).

 If you move the 'bool present' field to intel_connector or intel_panel,
 I think this is all right.

That sounds like more of an invasive change.  I could poke at it, but
I'm not sure it would be suitable for e.g. 3.13.y stable.  Thoughts on
that?  Admittedly it is a somewhat minor problem, so if it's not
easily stable material, I don't think anyone is going to lose sleep
over it.

josh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] 3.13 i915 brightness settings broken when going from docked - undocked

[Josh Boyer]

On Thu, Feb 20, 2014 at 07:31:41PM -0500, Josh Boyer wrote:
On Wed, Feb 19, 2014 at 9:20 PM, Josh Boyer jwbo...@fedoraproject.org wrote:
 Hi All,

 We've had a rather weird report[1] of the brightness adjustments being
 broken in a specific case with Thinkpad x220 hardware (SandyBridge
 based).  If you boot the machine with it in a dock and then undock,
 the brightness adjustments do not work.  That is with either the FN
 keys or the GNOME brightness slider.

 I can see that the value of
 /sys/class/backlight/acpi_video0/brightness increases/decreases but
 /sys/class/backlight/intel_backlight/brightness doesn't reflect any
 changes.  With 3.12 this works, and oddly with 3.14-rc1 it works
 (specifically, it starts working around v3.13-10231-g53d8ab2 which is
 right after the first DRM merge for 3.14).  With 3.13, if I undock and
 echo a higher value in the intel_backlight_brightness sysfs entry, the
 brightness will actually increase so it can be done manually, but it
 does not work as you'd expect.

 I'm in the middle of trying to do a reverse bisect for which patch
 fixes it in the 3.14-rcX series, but that's taking a while.  I thought
 I'd email and see if anyone already knows about this situation, what
 patch in 3.13 broke this, and which one then fixed it again.  Thus far
 all I've gathered is that backlight handling is confusing.

The reverse bisect between 3.13 and 3.14-rc1 didn't prove fruitful,
either because I messed it up or there's a combination of things that
fix the issue.  So instead I did a regular git bisect between 3.12 and
3.13 to see which commit _broke_ things and caused the above behavior.
 That landed me at:

Author: Jesse Barnes jbar...@virtuousgeek.org
Date:   Thu Oct 31 18:55:49 2013 +0200

drm/i915: make backlight functions take a connector

I have no idea if that makes sense or not, but it's at least something
that seems to be in a relevant area of code.  Does anyone involved in
that know why it would cause the above symptoms on 3.13, and which
commit(s) fix it in 3.14-rc1?

Since nobody is replying I poked around a bit myself.  The one commit
that looks somewhat relevant in 3.14-rc1 seems to be:

commit c91c9f32843a1b433de5a1ead4789a6bc8d3d914
Author: Jani Nikula jani.nik...@intel.com
Date:   Fri Nov 8 16:48:55 2013 +0200

drm/i915: make asle notifications update backlight on all connectors

That doesn't apply cleanly on 3.13 because of the other reworks that
went in first, so I came up with the patch below.  It seems to fix it
for my machine, but I'm waiting for confirmation from the original bug
reporter still.  Maybe this will elicit some comments?

josh

Backport of upstream commit c91c9f328

---
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_opregion.c | 31 ++-
 drivers/gpu/drm/i915/intel_panel.c|  4 
 3 files changed, 11 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 221ac62..d6d4349 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1371,6 +1371,7 @@ typedef struct drm_i915_private {
 
/* backlight */
struct {
+   bool present;
int level;
bool enabled;
spinlock_t lock; /* bl registers and the above bl fields */
diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index 6d69a9b..b2a51ae 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -414,38 +414,19 @@ static u32 asle_set_backlight(struct drm_device *dev, u32 
bclp)
return ASLC_BACKLIGHT_FAILED;
 
mutex_lock(dev-mode_config.mutex);
-   /*
-* Could match the OpRegion connector here instead, but we'd also need
-* to verify the connector could handle a backlight call.
-*/
-   list_for_each_entry(encoder, dev-mode_config.encoder_list, head)
-   if (encoder-crtc == crtc) {
-   found = true;
-   break;
-   }
-
-   if (!found) {
-   ret = ASLC_BACKLIGHT_FAILED;
-   goto out;
-   }
 
-   list_for_each_entry(connector, dev-mode_config.connector_list, head)
-   if (connector-encoder == encoder)
-   intel_connector = to_intel_connector(connector);
-
-   if (!intel_connector) {
-   ret = ASLC_BACKLIGHT_FAILED;
-   goto out;
+   DRM_DEBUG_KMS(updating opregion backlight %d/255\n, bclp);
+   list_for_each_entry(connector, dev-mode_config.connector_list, head) {
+   intel_connector = to_intel_connector(connector);
+   if (dev_priv-backlight.present)
+   intel_panel_set_backlight(intel_connector, bclp, 255);
}
 
-   DRM_DEBUG_KMS(updating opregion backlight %d/255\n, bclp);
-   intel_panel_set_backlight(intel_connector

Re: [Intel-gfx] 3.13 i915 brightness settings broken when going from docked - undocked

[Josh Boyer]

On Wed, Feb 19, 2014 at 9:20 PM, Josh Boyer jwbo...@fedoraproject.org wrote:
 Hi All,

 We've had a rather weird report[1] of the brightness adjustments being
 broken in a specific case with Thinkpad x220 hardware (SandyBridge
 based).  If you boot the machine with it in a dock and then undock,
 the brightness adjustments do not work.  That is with either the FN
 keys or the GNOME brightness slider.

 I can see that the value of
 /sys/class/backlight/acpi_video0/brightness increases/decreases but
 /sys/class/backlight/intel_backlight/brightness doesn't reflect any
 changes.  With 3.12 this works, and oddly with 3.14-rc1 it works
 (specifically, it starts working around v3.13-10231-g53d8ab2 which is
 right after the first DRM merge for 3.14).  With 3.13, if I undock and
 echo a higher value in the intel_backlight_brightness sysfs entry, the
 brightness will actually increase so it can be done manually, but it
 does not work as you'd expect.

 I'm in the middle of trying to do a reverse bisect for which patch
 fixes it in the 3.14-rcX series, but that's taking a while.  I thought
 I'd email and see if anyone already knows about this situation, what
 patch in 3.13 broke this, and which one then fixed it again.  Thus far
 all I've gathered is that backlight handling is confusing.

The reverse bisect between 3.13 and 3.14-rc1 didn't prove fruitful,
either because I messed it up or there's a combination of things that
fix the issue.  So instead I did a regular git bisect between 3.12 and
3.13 to see which commit _broke_ things and caused the above behavior.
 That landed me at:

Author: Jesse Barnes jbar...@virtuousgeek.org
Date:   Thu Oct 31 18:55:49 2013 +0200

drm/i915: make backlight functions take a connector

I have no idea if that makes sense or not, but it's at least something
that seems to be in a relevant area of code.  Does anyone involved in
that know why it would cause the above symptoms on 3.13, and which
commit(s) fix it in 3.14-rc1?

josh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] 3.13 i915 brightness settings broken when going from docked - undocked

[Josh Boyer]

Hi All,

We've had a rather weird report[1] of the brightness adjustments being
broken in a specific case with Thinkpad x220 hardware (SandyBridge
based).  If you boot the machine with it in a dock and then undock,
the brightness adjustments do not work.  That is with either the FN
keys or the GNOME brightness slider.

I can see that the value of
/sys/class/backlight/acpi_video0/brightness increases/decreases but
/sys/class/backlight/intel_backlight/brightness doesn't reflect any
changes.  With 3.12 this works, and oddly with 3.14-rc1 it works
(specifically, it starts working around v3.13-10231-g53d8ab2 which is
right after the first DRM merge for 3.14).  With 3.13, if I undock and
echo a higher value in the intel_backlight_brightness sysfs entry, the
brightness will actually increase so it can be done manually, but it
does not work as you'd expect.

I'm in the middle of trying to do a reverse bisect for which patch
fixes it in the 3.14-rcX series, but that's taking a while.  I thought
I'd email and see if anyone already knows about this situation, what
patch in 3.13 broke this, and which one then fixed it again.  Thus far
all I've gathered is that backlight handling is confusing.

josh

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1067071
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] kernfs oops with i915+i2c_core in 3.14 merge window

[Josh Boyer]

Hi All,

I'm seeing the oops below on my MacBookPro 10,2 machine using i915
graphics.  It's after the DRM merge for 3.14 ( v3.13-10094-g9b0cd30) ,
but we seem to have one report[1] of this happening well before that,
in v3.13-3260-g03d11a0 as well.  Does anyone have a clue what is going
on here?

https://bugzilla.redhat.com/show_bug.cgi?id=1055105

josh

[6.058198] INFO: trying to register non-static key.
[6.058203] the code is fine but needs lockdep annotation.
[6.058206] turning off the locking correctness validator.
[6.058210] CPU: 2 PID: 225 Comm: systemd-udevd Not tainted
3.14.0-0.rc0.git17.1.fc21.x86_64 #1
[6.058214] Hardware name: Apple Inc.
MacBookPro10,2/Mac-AFD8A9D944EA4843, BIOS
MBP102.88Z.0106.B03.1211161133 11/16/2012
[6.058219]   8b5190d0 88025cc67460
817cdb1f
[6.058225]  0002 88025cc67470 817c8aa9
88025cc67550
[6.058230]  810fa886 0002 88025cc66000
88025cc67500
[6.058236] Call Trace:
[6.058242]  [817cdb1f] dump_stack+0x4d/0x66
[6.058247]  [817c8aa9] register_lock_class.part.26+0x38/0x3c
[6.058253]  [810fa886] __lock_acquire+0x1776/0x1c40
[6.058258]  [810f8b09] ? mark_held_locks+0xb9/0x140
[6.058262]  [810feb91] ? __raw_spin_lock_init+0x21/0x60
[6.058267]  [810f626c] ? lockdep_init_map+0xac/0x4a0
[6.058271]  [810fb542] lock_acquire+0xa2/0x1d0
[6.058275]  [812beeb8] ? kernfs_addrm_finish+0x38/0x60
[6.058279]  [812be0de] kernfs_deactivate+0x13e/0x1a0
[6.058283]  [812beeb8] ? kernfs_addrm_finish+0x38/0x60
[6.058287]  [810f8b09] ? mark_held_locks+0xb9/0x140
[6.058291]  [810f8b09] ? mark_held_locks+0xb9/0x140
[6.058295]  [812beeb8] kernfs_addrm_finish+0x38/0x60
[6.058299]  [812bf150] kernfs_remove_by_name_ns+0x60/0xc0
[6.058304]  [812bcc81] remove_files.isra.1+0x41/0x80
[6.058308]  [812bcf77] sysfs_remove_group+0x47/0xa0
[6.058312]  [812bd0a3] sysfs_remove_groups+0x33/0x50
[6.058318]  [814f391e] device_remove_attrs+0x5e/0x80
[6.058322]  [814f455e] device_del+0x12e/0x1d0
[6.058325]  [814f461e] device_unregister+0x1e/0x60
[6.058331]  [a000d407] i2c_del_adapter+0x267/0x3b0 [i2c_core]
[6.058354]  [a00df8de] intel_sdvo_init+0x20e/0x8c0 [i915]
[6.058359]  [810f8c95] ? trace_hardirqs_on_caller+0x105/0x1d0
[6.058363]  [810f8d6d] ? trace_hardirqs_on+0xd/0x10
[6.058381]  [a00fb952] ? gen6_read32+0x52/0x1c0 [i915]
[6.058398]  [a00c7922] intel_modeset_init+0xb62/0xff0 [i915]
[6.058414]  [a00ea6b8] ?
intel_power_domains_init_hw+0xa8/0x110 [i915]
[6.058429]  [a008b38c] i915_driver_load+0xccc/0xec0 [i915]
[6.058440]  [a00264cd] ? drm_get_minor+0x1ad/0x200 [drm]
[6.058447]  [a002659d] drm_dev_register+0x7d/0x180 [drm]
[6.058455]  [a0028d10] drm_get_pci_dev+0xa0/0x220 [drm]
[6.058468]  [a008770b] i915_pci_probe+0x3b/0x60 [i915]
[6.058473]  [8140c605] local_pci_probe+0x45/0xa0
[6.058477]  [8140d8b5] ? pci_match_device+0xc5/0xd0
[6.058481]  [8140d9f9] pci_device_probe+0xf9/0x150
[6.058486]  [814f8b95] driver_probe_device+0x125/0x3a0
[6.058490]  [814f8ee3] __driver_attach+0x93/0xa0
[6.058494]  [814f8e50] ? __device_attach+0x40/0x40
[6.058498]  [814f68d3] bus_for_each_dev+0x73/0xc0
[6.058502]  [814f851e] driver_attach+0x1e/0x20
[6.058505]  [814f80c8] bus_add_driver+0x188/0x260
[6.058509]  [a0154000] ? 0xa0153fff
[6.058513]  [814f9584] driver_register+0x64/0xf0
[6.058516]  [a0154000] ? 0xa0153fff
[6.058520]  [8140bfa0] __pci_register_driver+0x60/0x70
[6.058527]  [a0028faa] drm_pci_init+0x11a/0x130 [drm]
[6.058531]  [a0154000] ? 0xa0153fff
[6.058543]  [a015406a] i915_init+0x6a/0x6c [i915]
[6.058548]  [8100214a] do_one_initcall+0xfa/0x1b0
[6.058552]  [810640a3] ? set_memory_nx+0x43/0x50
[6.058557]  [81131d63] load_module+0x1eb3/0x26e0
[6.058560]  [8112cc70] ? store_uevent+0x70/0x70
[6.058565]  [81238710] ? kernel_read+0x50/0x80
[6.058569]  [81132766] SyS_finit_module+0xa6/0xd0
[6.058574]  [817e19a9] system_call_fastpath+0x16/0x1b
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] kernfs oops with i915+i2c_core in 3.14 merge window

[Josh Boyer]

On Thu, Jan 30, 2014 at 2:05 PM, Tejun Heo t...@kernel.org wrote:
 On Thu, Jan 30, 2014 at 02:03:18PM -0500, Josh Boyer wrote:
 Hi All,

 I'm seeing the oops below on my MacBookPro 10,2 machine using i915
 graphics.  It's after the DRM merge for 3.14 ( v3.13-10094-g9b0cd30) ,
 but we seem to have one report[1] of this happening well before that,
 in v3.13-3260-g03d11a0 as well.  Does anyone have a clue what is going
 on here?

 https://bugzilla.redhat.com/show_bug.cgi?id=1055105

 Should be fixed by the following patch which is already queued.

  http://lkml.kernel.org/g/20140129170403.gj30...@htj.dyndns.org

Oh, excellent!  I'll throw that into a build and test it here.  Thanks
for the quick reply, Tejun.

josh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] kernfs oops with i915+i2c_core in 3.14 merge window

[Josh Boyer]

On Thu, Jan 30, 2014 at 2:20 PM, Josh Boyer jwbo...@fedoraproject.org wrote:
 On Thu, Jan 30, 2014 at 2:05 PM, Tejun Heo t...@kernel.org wrote:
 On Thu, Jan 30, 2014 at 02:03:18PM -0500, Josh Boyer wrote:
 Hi All,

 I'm seeing the oops below on my MacBookPro 10,2 machine using i915
 graphics.  It's after the DRM merge for 3.14 ( v3.13-10094-g9b0cd30) ,
 but we seem to have one report[1] of this happening well before that,
 in v3.13-3260-g03d11a0 as well.  Does anyone have a clue what is going
 on here?

 https://bugzilla.redhat.com/show_bug.cgi?id=1055105

 Should be fixed by the following patch which is already queued.

  http://lkml.kernel.org/g/20140129170403.gj30...@htj.dyndns.org

 Oh, excellent!  I'll throw that into a build and test it here.  Thanks
 for the quick reply, Tejun.

FWIW, my test build with that patch does seem to solve the problem.
Thanks again.

josh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [v3.10][v3.11][v3.12][Regression][PATCH 1/1] Revert Revert drm/i915: revert eDP bpp clamping code changes

[Josh Boyer]

On Thu, Oct 31, 2013 at 1:01 PM, Jani Nikula
jani.nik...@linux.intel.com wrote:
 On Thu, 31 Oct 2013, Josh Boyer jwbo...@fedoraproject.org wrote:
 On Thu, Oct 31, 2013 at 10:58 AM, Jani Nikula
 jani.nik...@linux.intel.com wrote:
 On Fri, 25 Oct 2013, Joseph Salisbury joseph.salisb...@canonical.com 
 wrote:
 On 10/16/2013 05:02 PM, Daniel Vetter wrote:
 It's by far not that simple. Jani is working on both the underlying bug
 and a better w/a. See

 https://bugzilla.kernel.org/show_bug.cgi?id=59841

 for the full story in its entire glory.

 Cheers, Daniel

 Thanks for the feedback, Daniel.  Is there an estimate on what mainline
 release might contain Jani's work?

 commit c6cd2ee2d59111a07cd9199564c9bdcb2d11e5cf
 Author: Jani Nikula jani.nik...@intel.com
 Date:   Mon Oct 21 10:52:07 2013 +0300

 drm/i915/dp: workaround BIOS eDP bpp clamping issue

 and a couple of dependencies are now in Linus' tree, i.e. should be
 released in 3.12. The commits are also CC: stable.

 Are the dependency commits you mentioned these?

 Yes; sorry for not mentioning them explicitly.

No problem.  Thanks for confirming.

josh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 0/4] Fix Win8 backlight issue

[Josh Boyer]

On Fri, Oct 11, 2013 at 9:27 AM, Aaron Lu aaron...@intel.com wrote:
 v5:
 1 Introduce video.use_native_backlight module parameter and set its
   value to false by default as suggested by Rafael. For Win8 systems
   which have broken ACPI video backlight control, the parameter can be
   set to 1 in kernel cmdline to skip registering ACPI video's backlight
   interface. Due to this change, the acpi_video_verify_backlight_support
   is moved from video_detect.c to video.c - patch 3/4;

That's a fairly untenable position for distro kernels to be in.  They
now have to ask every user that reports an issue with the backlight to
try setting that option on the command line.  While I appreciate the
setting breaks things for some people, doesn't the Win8 issue impact
far more people?  Shouldn't it be defaulted to true?

If nothing else, can you add a config option for the default so
distros can use that to decide which way to default it and then work
on fixing the remaining users that have troubles?

josh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 0/4] Fix Win8 backlight issue

[Josh Boyer]

On Fri, Oct 11, 2013 at 11:00 PM, Yves-Alexis Perez cor...@debian.org wrote:
 On sam., 2013-10-12 at 00:10 +0200, Rafael J. Wysocki wrote:
 On Friday, October 11, 2013 12:42:43 PM Josh Boyer wrote:
  On Fri, Oct 11, 2013 at 9:27 AM, Aaron Lu aaron...@intel.com wrote:
   v5:
   1 Introduce video.use_native_backlight module parameter and set its
 value to false by default as suggested by Rafael. For Win8 systems
 which have broken ACPI video backlight control, the parameter can be
 set to 1 in kernel cmdline to skip registering ACPI video's backlight
 interface. Due to this change, the acpi_video_verify_backlight_support
 is moved from video_detect.c to video.c - patch 3/4;
 
  That's a fairly untenable position for distro kernels to be in.  They
  now have to ask every user that reports an issue with the backlight to
  try setting that option on the command line.  While I appreciate the
  setting breaks things for some people, doesn't the Win8 issue impact
  far more people?  Shouldn't it be defaulted to true?

 Well, we have a rule in the kernel not to introduce regressions for users 
 even
 if they are minority.

 Well, for some users, the regression actually happened when support for
 Win8 OSI call was introduced.

Yes, this is true.  It's probably one of the more common bug reports
we get in this area.  Kernels prior to that have working backlight,
kernels after that don't.

josh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 0/4] Fix Win8 backlight issue

[Josh Boyer]

On Fri, Oct 11, 2013 at 4:27 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
 On Friday, October 11, 2013 06:01:43 PM Josh Boyer wrote:
 On Fri, Oct 11, 2013 at 6:10 PM, Rafael J. Wysocki r...@rjwysocki.net 
 wrote:
  On Friday, October 11, 2013 12:42:43 PM Josh Boyer wrote:
  On Fri, Oct 11, 2013 at 9:27 AM, Aaron Lu aaron...@intel.com wrote:
   v5:
   1 Introduce video.use_native_backlight module parameter and set its
 value to false by default as suggested by Rafael. For Win8 systems
 which have broken ACPI video backlight control, the parameter can be
 set to 1 in kernel cmdline to skip registering ACPI video's backlight
 interface. Due to this change, the acpi_video_verify_backlight_support
 is moved from video_detect.c to video.c - patch 3/4;
 
  That's a fairly untenable position for distro kernels to be in.  They
  now have to ask every user that reports an issue with the backlight to
  try setting that option on the command line.  While I appreciate the
  setting breaks things for some people, doesn't the Win8 issue impact
  far more people?  Shouldn't it be defaulted to true?
 
  Well, we have a rule in the kernel not to introduce regressions for users 
  even
  if they are minority.
 
  If nothing else, can you add a config option for the default so
  distros can use that to decide which way to default it and then work
  on fixing the remaining users that have troubles?
 
  The current plan is to create a blacklist of systems where that option 
  should
  be set.  We actually already have one, but it is at the _OSI() level, which
  is overkill in my view and may affect things beyond backlight.  Along with 
  that
  we will debug systems where setting that option (to true) causes problems 
  to
  happen, so that we'll be able to drop it going forward (hopefully).
 
  Of course, distro kernels may always change the default to true if they 
  want.

 They can, but they'd need to either patch the kernel to do so, or code
 it in userspace bootloader configs.  Having a config option they can
 set to change the default makes it reasonable and contained within the
 kernel.

 If we are to use a Kconfig option, why don't we use one instead of rather than
 in addition to a command line option?  Say, we have
 CONFIG_ACPI_VIDEO_WIN8_WORKAROUND and if that is set, the code will work like
 the previous version of the Aaron's patchset (the one without
 video.use_native_backlight)?

 Opinions?

If you only have a config option, users can't override the distro
settings.  If you simply have a config option for the default value,
the distros can set it without having to carry a patch (the primary
benefit), but users can still override that without having to rebuild
a kernel.

josh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [git pull] drm for 3.10-rc1

[Josh Boyer]

On Fri, May 03, 2013 at 06:08:52PM +0200, Daniel Vetter wrote:
On Fri, May 3, 2013 at 4:39 PM, Josh Boyer jwbo...@gmail.com wrote:
 On Fri, May 03, 2013 at 02:25:57AM +0100, Dave Airlie wrote:
The following changes since commit b6a9b7f6b1f21735a7456d534dc0e68e61359d2c:

  mm: prevent mmap_cache race in find_vma() (2013-04-04 11:46:28 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux.git drm-next

for you to fetch changes up to 307b9c022720f9de90d58e51743e01e9a42aec59:

  qxl: update to new idr interfaces. (2013-05-03 10:37:20 +1000)



 So something in this batch of commits breaks a Macbook Pro Retina I have
 sitting here.  If I boot a Fedora kernel based on  Linux
 v3.9-8153-g5a148af, things boot up as they did previously with 3.9.0 and
 are generally working fine.  If I boot with a kernel based on Linux
 v3.9-8933-gce85722, it will boot but as soon as plymouth starts, I get
 nothing but static on the screen (like 1950s TV static).

 This machine is using i915 graphics, so I booted with nomodeset and did
 the 'modprobe drm debug=15; modprobe i915 modeset=1' trick and it
 repeated the failure with that.  I've gathered a bunch of data like
 dmesg, an intel_reg_snapshot, etc.  It's all attached below.

 I'll start bisecting to see if I can narrow down the commit that broke
 things, but I thought I would give a heads up now in case anyone has any
 ideas.

Looked through the log files and didn't see a clue. And usually DP
tends to fail pretty noisily. So I think the bisect result would be
interestin. Meanwhile:

Yeah, working on that.

- do you have drm.debug=0xe dmesg for a working kernel, too?

No, but I can try and get one.

- is the panel completely dead or is just the backlight on (or panel
on but backlight off)?

Backlight is on.  Literally static flickering on the screen.
Occasionally it will flicker from static to black back and forth.  But
the backlight is clearly on and what is trying to render (the GDM screen
normally) is just coming up as static.

josh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [git pull] drm for 3.10-rc1

[Josh Boyer]

On Fri, May 03, 2013 at 12:57:20PM -0400, Josh Boyer wrote:
On Fri, May 03, 2013 at 06:08:52PM +0200, Daniel Vetter wrote:
On Fri, May 3, 2013 at 4:39 PM, Josh Boyer jwbo...@gmail.com wrote:
 On Fri, May 03, 2013 at 02:25:57AM +0100, Dave Airlie wrote:
The following changes since commit b6a9b7f6b1f21735a7456d534dc0e68e61359d2c:

  mm: prevent mmap_cache race in find_vma() (2013-04-04 11:46:28 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux.git drm-next

for you to fetch changes up to 307b9c022720f9de90d58e51743e01e9a42aec59:

  qxl: update to new idr interfaces. (2013-05-03 10:37:20 +1000)



 So something in this batch of commits breaks a Macbook Pro Retina I have
 sitting here.  If I boot a Fedora kernel based on  Linux
 v3.9-8153-g5a148af, things boot up as they did previously with 3.9.0 and
 are generally working fine.  If I boot with a kernel based on Linux
 v3.9-8933-gce85722, it will boot but as soon as plymouth starts, I get
 nothing but static on the screen (like 1950s TV static).

 This machine is using i915 graphics, so I booted with nomodeset and did
 the 'modprobe drm debug=15; modprobe i915 modeset=1' trick and it
 repeated the failure with that.  I've gathered a bunch of data like
 dmesg, an intel_reg_snapshot, etc.  It's all attached below.

 I'll start bisecting to see if I can narrow down the commit that broke
 things, but I thought I would give a heads up now in case anyone has any
 ideas.

Looked through the log files and didn't see a clue. And usually DP
tends to fail pretty noisily. So I think the bisect result would be
interestin. Meanwhile:

Yeah, working on that.

OK.  Git bisect tells me this:

57c219633275c7e7413f8bc7be250dc092887458 is the first bad commit
commit 57c219633275c7e7413f8bc7be250dc092887458
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date:   Thu Apr 4 17:19:37 2013 +0200

drm/i915: revert eDP bpp clamping code changes

The behaviour around handling the eDP bpp value from vbt has been
slightly changed in

commit 3600836585e3fdef0a1410d63fe5ce4015007aac
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date:   Wed Mar 27 00:44:59 2013 +0100

drm/i915: convert DP autodither code to new infrastructure

The old behaviour was that we used the plane's bpp (usually 24bpp) for
computing the dp link bw, but set up the pipe with the bpp value from
vbt if available. This takes the vbt bpp override into account even
for the dp link bw configuration.

On Paulo's hsw machine this resulted in a slower link clock and a
black screen - but the mode actually /should/ fit even with the lower
clock. Until we've cleared up simply stay bug-for-bug compatible with
the old code.

While at it, also restore a debug message lost in:

commit 4e53c2e010e531b4a014692199e978482d471c7e
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date:   Wed Mar 27 00:44:58 2013 +0100

drm/i915: precompute pipe bpp before touching the hw

Cc: Paulo Zanoni przan...@gmail.com
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
Tested-by: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

:04 04 a7529c568073885302e5ca03cce5bd224e244b57 
d5d860a0d4b04ad98d77abb1df774c1448bd1697 M  drivers

The bisect log is below.  I can try to revert it directly on top of
Linus' latest tree later.

- do you have drm.debug=0xe dmesg for a working kernel, too?

No, but I can try and get one.

I haven't gotten to this quite yet.  I'll try to get to it over the
weekend.

josh

[jwboyer@obiwan linux]$ git bisect log
git bisect start
# good: [5a148af66932c31814e263366094b5812210b501] Merge branch 'next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc
git bisect good 5a148af66932c31814e263366094b5812210b501
# bad: [ce857229e0c3adc211944a13a5579ef84fd7b4af] ipc: fix GETALL/IPC_RM race 
for sysv semaphores
git bisect bad ce857229e0c3adc211944a13a5579ef84fd7b4af
# bad: [4ed108352d9b60a723a5071ed05e722826c2b72f] drm/radeon: put UVD PLLs in 
bypass mode
git bisect bad 4ed108352d9b60a723a5071ed05e722826c2b72f
# bad: [dc652f90e088798bfa31f496ba994ddadd5d5680] drm/i915: ensure single 
initialization and cleanup of backlight device
git bisect bad dc652f90e088798bfa31f496ba994ddadd5d5680
# good: [bb60b9695ced58768ba05b2d88fb4ee815df18f4] drm/i915: emit a hotplug 
event on resume
git bisect good bb60b9695ced58768ba05b2d88fb4ee815df18f4
# good: [8b47047bd103c9fdb50440790a2ef17fa69a35c4] drm/i915: rip out superflous 
is_dpis_cpu_edp tracking
git bisect good 8b47047bd103c9fdb50440790a2ef17fa69a35c4
# bad: [4615d4c9e27eda42c3e965f208a4b4065841498c] drm/i915: Use MLC (l3$) for 
context objects
git bisect bad 4615d4c9e27eda42c3e965f208a4b4065841498c
# bad: [40c7ead980945ac96eadbd6d99b050458d797e2b] drm/i915: PCH_NOP
git bisect bad

Re: [Intel-gfx] [git pull] drm for 3.10-rc1

[Josh Boyer]

On Fri, May 03, 2013 at 10:40:17PM +0200, Daniel Vetter wrote:
On Fri, May 3, 2013 at 10:31 PM, Josh Boyer jwbo...@gmail.com wrote:
 OK.  Git bisect tells me this:

 57c219633275c7e7413f8bc7be250dc092887458 is the first bad commit
 commit 57c219633275c7e7413f8bc7be250dc092887458
 Author: Daniel Vetter daniel.vet...@ffwll.ch
 Date:   Thu Apr 4 17:19:37 2013 +0200

 drm/i915: revert eDP bpp clamping code changes

Yeah, that commit is a bit dubios and for 3.11 we've already planned
to kick it out. It tries to work around an issue on a funky
pre-release hw. Does reverting this commit fix your issue?

Yes, seems so.  I reverted it on top of Linus tree as of commit
ce857229e0c3adc2 and things boot normally on the machine after that.

josh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx