Re: PR for new i915 and Xe binaries
On Fri, Aug 2, 2024 at 1:59 PM Daniele Ceraolo Spurio wrote: > > A bulk update of several binaries in the i915 and Xe folders. > > - GuC: > - All TGL+ binaries updated to v70.29.2 > - New binary added for BMG, also v70.29.2 > > - HuC: > - DG2 binary updated to latest rev (v7.10.16) > - New binaries added for LNL (v9.4.13) and BMG (v8.2.10) > > - GSC: > - MTL binary updated to v102.0.10.1878 > - New binary added for LNL, v104.0.0.1161 > > - DMC: > - MTL binary updated to v2.22 > > The following changes since commit 65c5d9b1a4808462f5e885447dae1a133c96abec: > > Merge branch 'amdgpu-20240726' into 'main' (2024-07-28 14:28:08 +) > > are available in the Git repository at: > > https://gitlab.freedesktop.org/drm/firmware.git tags/intel-2024-08-02 Merged and pushed out. https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/266 josh > > for you to fetch changes up to 95c414d44c8e60880be787822d5020a010044a49: > > xe: First GuC release v70.29.2 for BMG (2024-08-01 11:11:04 -0700) > > > Daniele Ceraolo Spurio (5): > i915: update DG2 HuC to v7.10.16 > xe: Add LNL HuC 9.4.13 > xe: Add GSC 104.0.0.1161 for LNL > xe: Add BMG HuC 8.2.10 > i915: update MTL GSC to v102.0.10.1878 > > Dnyaneshwar Bhadane (1): > i915: Update MTL DMC v2.22 > > Julia Filipchuk (3): > i915: Add GuC v70.29.2 for ADL-P, DG1, DG2, MTL, and TGL > xe: Add GuC v70.29.2 for LNL > xe: First GuC release v70.29.2 for BMG > > WHENCE | 30 +- > i915/adlp_guc_70.bin | Bin 347584 -> 328768 bytes > i915/dg1_guc_70.bin | Bin 321472 -> 302656 bytes > i915/dg2_guc_70.bin | Bin 410368 -> 369408 bytes > i915/dg2_huc_gsc.bin | Bin 630784 -> 630784 bytes > i915/mtl_dmc.bin | Bin 52476 -> 52700 bytes > i915/mtl_gsc_1.bin | Bin 1142784 -> 1134592 bytes > i915/mtl_guc_70.bin | Bin 332544 -> 303872 bytes > i915/tgl_guc_70.bin | Bin 335168 -> 316352 bytes > xe/bmg_guc_70.bin| Bin 0 -> 406272 bytes > xe/bmg_huc.bin | Bin 0 -> 585728 bytes > xe/lnl_gsc_1.bin | Bin 0 -> 1155072 bytes > xe/lnl_guc_70.bin| Bin 336640 -> 316160 bytes > xe/lnl_huc.bin | Bin 0 -> 643072 bytes > 14 files changed, 21 insertions(+), 9 deletions(-) > create mode 100644 xe/bmg_guc_70.bin > create mode 100644 xe/bmg_huc.bin > create mode 100644 xe/lnl_gsc_1.bin > create mode 100644 xe/lnl_huc.bin
Re: PR for Xe2LPD DMC v2.21
On Tue, Jul 16, 2024 at 9:25 AM 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-07-16 I don't know what repo you generated this against, but it was very far behind upstream. I rebased and it effectively only pulled in the single commit to update Xe2LPD DMC. https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/252/commits If there's something missing, please submit it separately. josh > > for you to fetch changes up to 72e5970de400e6d55a31e38bcba439ec17cedfe1: > > i915: Update Xe2LPD DMC to v2.21 (2024-07-16 16:11:43 +0530) > > > Intel DRM firmware intel-2024-07-16 > > > Daniele Ceraolo Spurio (1): > i915: Add DG2 HuC 7.10.15 > > Dnyaneshwar Bhadane (2): > i915: Update Xe2LPD DMC to v2.20 > i915: Update Xe2LPD DMC to v2.21 > > 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 -> 59872 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 BMG DMC v2.06
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
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
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(&i915->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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
On Tue, Oct 18, 2022 at 11:22 AM Daniele Ceraolo Spurio wrote: > > The following changes since commit 48407ffd7adb9511701547068b1e6f0956bd1c94: > > cnm: update chips&media 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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)
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)
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)
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
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
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)
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)
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)
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)
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)
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
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
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] [] dump_stack+0x4c/0x65 [8.132880] [] warn_slowpath_common+0x86/0xc0 [8.132884] [] warn_slowpath_fmt+0x55/0x70 [8.132935] [] ? gen5_read32+0x1d5/0x200 [i915] [8.132985] [] intel_disable_pipe+0x28d/0x2a0 [i915] [8.133036] [] ironlake_crtc_disable+0x93/0x7f0 [i915] [8.133087] [] ? intel_frontbuffer_flush+0x65/0x70 [i915] [8.133138] [] __intel_set_mode+0x9de/0xbc0 [i915] [8.133189] [] ? intel_modeset_compute_config+0x3af/0xb60 [i915] [8.133241] [] intel_crtc_set_config+0x2cc/0x610 [i915] [8.133263] [] drm_mode_set_config_internal+0x69/0x110 [drm] [8.133274] [] restore_fbdev_mode+0xc2/0xf0 [drm_kms_helper] [8.133284] [] drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x70 [drm_kms_helper] [8.133294] [] drm_fb_helper_set_par+0x22/0x40 [drm_kms_helper] [8.133345] [] intel_fbdev_set_par+0x1a/0x60 [i915] [8.133350] [] fbcon_init+0x545/0x5d0 [8.133355] [] visual_init+0xbc/0x120 [8.133359] [] do_bind_con_driver+0x1c5/0x3b0 [8.133362] [] do_take_over_console+0x149/0x1a0 [8.133366] [] ? printk+0x55/0x6b [8.133370] [] do_fbcon_takeover+0x57/0xb0 [8.133373] [] fbcon_event_notify+0x674/0x770 [8.133378] [] notifier_call_chain+0x3e/0xb0 [8.133382] [] __blocking_notifier_call_chain+0x51/0x70 [8.133386] [] blocking_notifier_call_chain+0x16/0x20 [8.133389] [] fb_notifier_call_chain+0x1b/0x20 [8.133392] [] register_framebuffer+0x217/0x350 [8.133403] [] drm_fb_helper_initial_config+0x261/0x430 [drm_kms_helper] [8.133455] [] intel_fbdev_initial_config+0x1b/0x20 [i915] [8.133459] [] async_run_entry_fn+0x4a/0x140 [8.133463] [] process_one_work+0x232/0x840 [8.133467] [] ? process_one_work+0x19b/0x840 [8.133472] [] ? debug_lockdep_rcu_enabled+0x1d/0x20 [8.133475] [] ? worker_thread+0xd5/0x450 [8.133480] [] worker_thread+0x4e/0x450 [8.133484] [] ? process_one_work+0x840/0x840 [8.133487] [] kthread+0x104/0x120 [8.133493] [] ? kthread_create_on_node+0x250/0x250 [8.133497] [] ret_from_fork+0x3f/0x70 [8.133500] [] ? 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
On Mon, Jun 22, 2015 at 9:27 AM, Jani Nikula
wrote:
> On Mon, 22 Jun 2015, Josh Boyer wrote:
>> On Mon, Jun 22, 2015 at 8:02 AM, Daniel Vetter
>> 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
>>> Cc: Gaurav K Singh
>>> Cc: Michel Dänzer
>>> Cc: Ville Syrjälä
>>> Signed-off-by: Daniel Vetter
>>> ---
>>> 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/vblank: WARN_ON nested use of drm_vblank_on/off
On Mon, Jun 22, 2015 at 8:02 AM, Daniel Vetter 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
> Cc: Gaurav K Singh
> Cc: Michel Dänzer
> Cc: Ville Syrjälä
> Signed-off-by: Daniel Vetter
> ---
> 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/i915: Fix ilk watermarks calculation when primary plane is disabled
On Thu, May 21, 2015 at 3:21 AM, Ander Conselvan De Oliveira
wrote:
> On Wed, 2015-05-20 at 16:53 +0300, Jani Nikula wrote:
>> On Wed, 20 May 2015, Ander Conselvan de Oliveira
>> 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
>> > Date: Thu Jul 17 23:30:04 2014 -0400
>> >
>> > drm/i915: use helpers
>> >
>> > commit ca5a1b9ba0fb5291b555a23b76dbe5f6c30bfd7a
>> > Merge: c7dbc6c 3488229
>> > Author: Dave Airlie
>> > 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
>> > 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
>> > Date: Fri Feb 27 10:12:00 2015 -0800
>> >
>> > drm/i915: Kill intel_crtc->cursor_{width, height} (v2)
>> >
>> > commit 54da691deb123c045259ebf4f5c67381244f58f1
>> > Author: Thomas Gummerer
>> > 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
>> > 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
On Wed, May 20, 2015 at 9:53 AM, Jani Nikula wrote:
> On Wed, 20 May 2015, Ander Conselvan de Oliveira
> 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
>> Date: Thu Jul 17 23:30:04 2014 -0400
>>
>> drm/i915: use helpers
>>
>> commit ca5a1b9ba0fb5291b555a23b76dbe5f6c30bfd7a
>> Merge: c7dbc6c 3488229
>> Author: Dave Airlie
>> 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
>> 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
>> Date: Fri Feb 27 10:12:00 2015 -0800
>>
>> drm/i915: Kill intel_crtc->cursor_{width, height} (v2)
>>
>> commit 54da691deb123c045259ebf4f5c67381244f58f1
>> Author: Thomas Gummerer
>> 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
>> 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
Thanks for the Ack. Hopefully Greg doesn't immediately
this one :).
josh
>> Cc: Dave Airlie
>> Cc: Jani Nikula
>> Signed-off-by: Ander Conselvan de Oliveira
>>
>> ---
>> 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
On Wed, Apr 22, 2015 at 12:45 PM, Mika Kuoppala
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
> Cc: Chris Wilson
> Cc: Michel Thierry
> Signed-off-by: Mika Kuoppala
> ---
> 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
On Mon, Mar 2, 2015 at 4:30 AM, Jani Nikula wrote: > > Stable team, please backport > > commit f9b61ff6bce9a44555324b29e593fdffc9a115bc > Author: Daniel Vetter > 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
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
On Wed, Mar 25, 2015 at 1:17 PM, Daniel Vetter 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
>> wrote:
>> > On Wed, Mar 25, 2015 at 11:50 AM, Daniel Vetter 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 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
>> >>> >> wrote:
>> >>> >> >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>> >>> >> >> >> Author: Damien Lespiau
>> >>> >> >> >> 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
>> >>> >> > 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
>> >>> >> 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,
>> >>
Re: [Intel-gfx] [git pull] drm fixes
On Wed, Mar 25, 2015 at 11:53 AM, Josh Boyer wrote:
> On Wed, Mar 25, 2015 at 11:50 AM, Daniel Vetter 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 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 wrote:
>>> >> >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>>> >> >> >> Author: Damien Lespiau
>>> >> >> >> 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
>>> >> > 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
>>> >> 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:
>>>
>&
Re: [Intel-gfx] [git pull] drm fixes
On Wed, Mar 25, 2015 at 11:50 AM, Daniel Vetter 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 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 wrote:
>> >> >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>> >> >> >> Author: Damien Lespiau
>> >> >> >> 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
>> >> > 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
>> >> 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
On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter 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 wrote:
>> >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>> >> >> Author: Damien Lespiau
>> >> >> 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
>> > 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
>> 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
On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter wrote: >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52 >> >> Author: Damien Lespiau >> >> 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 > 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 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
On Tue, Mar 24, 2015 at 12:49 PM, Daniel Vetter 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 >> > wrote: >> > > On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter 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 >> > >>> wrote: >> > >>> > On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter >> > >>> > 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 >> > >>> >>> 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 >> > >>> >>> >> wrote: >> > >>> >>> >> >> > >>> >>> >> >> > >>> >>> >> >> > >>> >>> >> >> 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 >> > >>> >>> > 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-fixes&id=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, >&
Re: [Intel-gfx] [git pull] drm fixes
On Tue, Mar 24, 2015 at 10:46 AM, Josh Boyer wrote: > On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter 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 >>> wrote: >>> > On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter 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 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 >>> >>> >> wrote: >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >> 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 >>> >>> > 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-fixes&id=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
Re: [Intel-gfx] [git pull] drm fixes
On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter 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 >> wrote: >> > On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter 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 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 >> >>> >> wrote: >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> 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 >> >>> > 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-fixes&id=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 > 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
On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer wrote: > On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter 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 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 >>> >> wrote: >>> >> >>> >> >>> >> >>> >> >> 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 >>> > 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-fixes&id=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
On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter 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 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 >> >> wrote: >> >> >> >> >> >> >> >> >> 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 >> > 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-fixes&id=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
On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter 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 >> wrote: >> >> >> >> >> 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 > 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-fixes&id=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] [] dump_stack+0x45/0x57 [ +0.05] [] warn_slowpath_common+0x8a/0xc0 [ +0.04] [] warn_slowpath_null+0x1a/0x20 [ +0.12] [] drm_framebuffer_reference+0x7a/0x90 [drm] [ +0.16] [] drm_atomic_set_fb_for_plane+0x2d/0x90 [drm] [ +0.48] [] i9xx_get_initial_plane_config+0x295/0x3e0 [i915] [ +0.15] [] ? drm_modeset_unlock_all+0x36/0x70 [drm] [ +0.31] [] intel_modeset_init+0x9f1/0x1a40 [i915] [ +0.27] [] ? valleyview_irq_postinstall+0x3b/0x50 [i915] [ +0.34] [] i915_driver_load+0xe5f/0x10f0 [i915] [ +0.05] [] ? netlink_broadcast_filtered+0x12b/0x380 [ +0.06] [] ? kobj_ns_drop+0x50/0x50 [ +0.04] [] ? kobject_uevent_env+0x178/0x540 [ +0.06] [] ? devtmpfs_create_node+0x109/0x140 [ +0.04] [] ? get_device+0x17/0x30 [ +0.05] [] ? klist_class_dev_get+0x15/0x20 [ +0.05] [] ? klist_add_tail+0x32/0x40 [ +0.04] [] ? device_add+0x19f/0x6a0 [ +0.12] [] drm_dev_register+0xb5/0x110 [drm] [ +0.11] [] drm_get_pci_dev+0x8d/0x200 [drm] [ +0.22] [] i915_
Re: [Intel-gfx] [git pull] drm fixes
On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer wrote: >> 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] 8800b7e
Re: [Intel-gfx] [git pull] drm fixes
On Fri, Mar 20, 2015 at 5:49 PM, Dave Airlie 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. > > 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] [] dump_stack+0x45/0x57 [ +0.06] [] warn_slowp
Re: [Intel-gfx] 3.14.3 i915 dead display under X11
On Wed, May 14, 2014 at 3:33 PM, Greg KH 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 >> > wrote: >> > > Bisecting from 3.13.6 (good) to 3.14.3 (bad) ended up with... >> > > >> > > commit b35684b8fa94e04f55fd38bf672b737741d2f9e2 >> > > Author: Jani Nikula >> > > 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 >> > > Reviewed-by: Imre Deak >> > > Signed-off-by: Daniel Vetter >> > > >> > > 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
On Tue, Feb 25, 2014 at 3:36 AM, Jani Nikula wrote:
> On Sun, 23 Feb 2014, Josh Boyer 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
On Thu, Feb 20, 2014 at 07:31:41PM -0500, Josh Boyer wrote:
>On Wed, Feb 19, 2014 at 9:20 PM, Josh Boyer 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
>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
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) {
+
Re: [Intel-gfx] 3.13 i915 brightness settings broken when going from docked -> undocked
On Wed, Feb 19, 2014 at 9:20 PM, Josh Boyer 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 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
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
Re: [Intel-gfx] kernfs oops with i915+i2c_core in 3.14 merge window
On Thu, Jan 30, 2014 at 2:20 PM, Josh Boyer wrote: > On Thu, Jan 30, 2014 at 2:05 PM, Tejun Heo 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] kernfs oops with i915+i2c_core in 3.14 merge window
On Thu, Jan 30, 2014 at 2:05 PM, Tejun Heo 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
[Intel-gfx] kernfs oops with i915+i2c_core in 3.14 merge window
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] [] dump_stack+0x4d/0x66 [6.058247] [] register_lock_class.part.26+0x38/0x3c [6.058253] [] __lock_acquire+0x1776/0x1c40 [6.058258] [] ? mark_held_locks+0xb9/0x140 [6.058262] [] ? __raw_spin_lock_init+0x21/0x60 [6.058267] [] ? lockdep_init_map+0xac/0x4a0 [6.058271] [] lock_acquire+0xa2/0x1d0 [6.058275] [] ? kernfs_addrm_finish+0x38/0x60 [6.058279] [] kernfs_deactivate+0x13e/0x1a0 [6.058283] [] ? kernfs_addrm_finish+0x38/0x60 [6.058287] [] ? mark_held_locks+0xb9/0x140 [6.058291] [] ? mark_held_locks+0xb9/0x140 [6.058295] [] kernfs_addrm_finish+0x38/0x60 [6.058299] [] kernfs_remove_by_name_ns+0x60/0xc0 [6.058304] [] remove_files.isra.1+0x41/0x80 [6.058308] [] sysfs_remove_group+0x47/0xa0 [6.058312] [] sysfs_remove_groups+0x33/0x50 [6.058318] [] device_remove_attrs+0x5e/0x80 [6.058322] [] device_del+0x12e/0x1d0 [6.058325] [] device_unregister+0x1e/0x60 [6.058331] [] i2c_del_adapter+0x267/0x3b0 [i2c_core] [6.058354] [] intel_sdvo_init+0x20e/0x8c0 [i915] [6.058359] [] ? trace_hardirqs_on_caller+0x105/0x1d0 [6.058363] [] ? trace_hardirqs_on+0xd/0x10 [6.058381] [] ? gen6_read32+0x52/0x1c0 [i915] [6.058398] [] intel_modeset_init+0xb62/0xff0 [i915] [6.058414] [] ? intel_power_domains_init_hw+0xa8/0x110 [i915] [6.058429] [] i915_driver_load+0xccc/0xec0 [i915] [6.058440] [] ? drm_get_minor+0x1ad/0x200 [drm] [6.058447] [] drm_dev_register+0x7d/0x180 [drm] [6.058455] [] drm_get_pci_dev+0xa0/0x220 [drm] [6.058468] [] i915_pci_probe+0x3b/0x60 [i915] [6.058473] [] local_pci_probe+0x45/0xa0 [6.058477] [] ? pci_match_device+0xc5/0xd0 [6.058481] [] pci_device_probe+0xf9/0x150 [6.058486] [] driver_probe_device+0x125/0x3a0 [6.058490] [] __driver_attach+0x93/0xa0 [6.058494] [] ? __device_attach+0x40/0x40 [6.058498] [] bus_for_each_dev+0x73/0xc0 [6.058502] [] driver_attach+0x1e/0x20 [6.058505] [] bus_add_driver+0x188/0x260 [6.058509] [] ? 0xa0153fff [6.058513] [] driver_register+0x64/0xf0 [6.058516] [] ? 0xa0153fff [6.058520] [] __pci_register_driver+0x60/0x70 [6.058527] [] drm_pci_init+0x11a/0x130 [drm] [6.058531] [] ? 0xa0153fff [6.058543] [] i915_init+0x6a/0x6c [i915] [6.058548] [] do_one_initcall+0xfa/0x1b0 [6.058552] [] ? set_memory_nx+0x43/0x50 [6.058557] [] load_module+0x1eb3/0x26e0 [6.058560] [] ? store_uevent+0x70/0x70 [6.058565] [] ? kernel_read+0x50/0x80 [6.058569] [] SyS_finit_module+0xa6/0xd0 [6.058574] [] 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] [v3.10][v3.11][v3.12][Regression][PATCH 1/1] Revert "Revert "drm/i915: revert eDP bpp clamping code changes""
On Thu, Oct 31, 2013 at 1:01 PM, Jani Nikula wrote: > On Thu, 31 Oct 2013, Josh Boyer wrote: >> On Thu, Oct 31, 2013 at 10:58 AM, Jani Nikula >> wrote: >>> On Fri, 25 Oct 2013, Joseph Salisbury >>> 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 >>> 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] [v3.10][v3.11][v3.12][Regression][PATCH 1/1] Revert "Revert "drm/i915: revert eDP bpp clamping code changes""
On Thu, Oct 31, 2013 at 10:58 AM, Jani Nikula wrote: > On Fri, 25 Oct 2013, Joseph Salisbury 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 > 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? commit 7195a50b5c7e00cc3312934fd022c3006b533d12 Author: Ville Syrjälä Date: Tue Sep 24 14:24:05 2013 +0300 drm/i915: Add HSW CRT output readout support commit 4f56d12ebb28fceac4c6e60c8993fbfc122e1399 Author: Ville Syrjälä Date: Mon Oct 21 10:52:06 2013 +0300 drm/i915: Add support for pipe_bpp readout 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
On Fri, Oct 11, 2013 at 4:27 PM, Rafael J. Wysocki 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 >> wrote: >> > On Friday, October 11, 2013 12:42:43 PM Josh Boyer wrote: >> >> On Fri, Oct 11, 2013 at 9:27 AM, Aaron Lu 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] [PATCH v5 0/4] Fix Win8 backlight issue
On Fri, Oct 11, 2013 at 11:00 PM, Yves-Alexis Perez 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 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
On Fri, Oct 11, 2013 at 6:10 PM, 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 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. 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
On Fri, Oct 11, 2013 at 9:27 AM, Aaron Lu 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] [git pull] drm for 3.10-rc1
On Fri, May 03, 2013 at 10:40:17PM +0200, Daniel Vetter wrote: >On Fri, May 3, 2013 at 10:31 PM, Josh Boyer wrote: >> OK. Git bisect tells me this: >> >> 57c219633275c7e7413f8bc7be250dc092887458 is the first bad commit >> commit 57c219633275c7e7413f8bc7be250dc092887458 >> Author: Daniel Vetter >> 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
Re: [Intel-gfx] [git pull] drm for 3.10-rc1
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 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 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 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 Date: Wed Mar 27 00:44:58 2013 +0100 drm/i915: precompute pipe bpp before touching the hw Cc: Paulo Zanoni Reviewed-by: Paulo Zanoni Tested-by: Paulo Zanoni Signed-off-by: Daniel Vetter :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: [8b4704
Re: [Intel-gfx] [git pull] drm for 3.10-rc1
On Fri, May 03, 2013 at 06:08:52PM +0200, Daniel Vetter wrote: >On Fri, May 3, 2013 at 4:39 PM, Josh Boyer 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
