Re: [Intel-gfx] [Regression] "drm/i915: Implement display w/a #1143" breaks HDMI on ASUS GL552VW

2020-10-12 Thread Kai-Heng Feng
> On Sep 3, 2020, at 14:26, Kai-Heng Feng wrote: > > > >> On Aug 26, 2020, at 21:05, Ville Syrjälä >> wrote: >> >> On Wed, Aug 26, 2020 at 12:40:15PM +0800, Kai-Heng Feng wrote: >>> Hi, >>> On Aug 25, 2020, at 02:46, Runyan, Arthur J wrote: I remember some

[Intel-gfx] ✓ Fi.CI.IGT: success for Introduce DG1

2020-10-12 Thread Patchwork
== Series Details == Series: Introduce DG1 URL : https://patchwork.freedesktop.org/series/82594/ State : success == Summary == CI Bug Log - changes from CI_DRM_9131_full -> Patchwork_18682_full Summary --- **SUCCESS** No

[Intel-gfx] ✗ Fi.CI.IGT: failure for Introduce drm scaling filter property (rev8)

2020-10-12 Thread Patchwork
== Series Details == Series: Introduce drm scaling filter property (rev8) URL : https://patchwork.freedesktop.org/series/73883/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9131_full -> Patchwork_18681_full Summary

Re: [Intel-gfx] [PATCH v4 0/7] Convert the intel iommu driver to the dma-iommu api

2020-10-12 Thread Lu Baolu
Hi Tvrtko, On 10/12/20 4:44 PM, Tvrtko Ursulin wrote: On 29/09/2020 01:11, Lu Baolu wrote: Hi Tvrtko, On 9/28/20 5:44 PM, Tvrtko Ursulin wrote: On 27/09/2020 07:34, Lu Baolu wrote: Hi, The previous post of this series could be found here.

Re: [Intel-gfx] [PATCH v7 07/15] drm/i915/dg1: add hpd interrupt handling

2020-10-12 Thread Lucas De Marchi
On Mon, Oct 12, 2020 at 03:51:29PM -0700, Aditya Swarup wrote: On 10/12/20 2:29 PM, Lucas De Marchi wrote: DG1 has one more combo phy port, no TC and all irq handling goes through SDE, like for MCC. v2: Also change intel_hpd_pin_default() to include DG1 mapping v3: Rebase on hpd refactor Cc:

Re: [Intel-gfx] [PATCH 1/2] drm/i915/dpcd_bl: uncheck PWM_PIN_CAP when detect eDP backlight capabilities

2020-10-12 Thread Lyude Paul
Completely zoned out on Ccing these patches to stable before submitting them, but once they hit the mainline kernel you should be able to ask Greg to backport them if you need. Anyway, pushed to drm-intel-next-queued. Thanks for the patches! On Fri, 2020-10-09 at 16:57 +0800, Aaron Ma wrote: >

Re: [Intel-gfx] [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()

2020-10-12 Thread Ira Weiny
On Mon, Oct 12, 2020 at 09:02:54PM +0100, Matthew Wilcox wrote: > On Mon, Oct 12, 2020 at 12:53:54PM -0700, Ira Weiny wrote: > > On Mon, Oct 12, 2020 at 05:44:38PM +0100, Matthew Wilcox wrote: > > > On Mon, Oct 12, 2020 at 09:28:29AM -0700, Dave Hansen wrote: > > > > kmap_atomic() is always

Re: [Intel-gfx] [PATCH] drm/i915/jsl: Split EHL/JSL platform info and PCI ids

2020-10-12 Thread Matt Roper
On Wed, Oct 07, 2020 at 03:06:38PM +0530, Tejas Upadhyay wrote: > Recently we came across requirement to identify EHL and JSL > platform to program them differently. Thus Split the basic > platform definition, macros, and PCI IDs to differentiate > between EHL and JSL platforms. Also,

Re: [Intel-gfx] [PATCH v7 07/15] drm/i915/dg1: add hpd interrupt handling

2020-10-12 Thread Aditya Swarup
On 10/12/20 2:29 PM, Lucas De Marchi wrote: > DG1 has one more combo phy port, no TC and all irq handling goes through > SDE, like for MCC. > > v2: Also change intel_hpd_pin_default() to include DG1 mapping > v3: Rebase on hpd refactor > > Cc: Ville Syrjälä > Cc: Anshuman Gupta > Cc: José

Re: [Intel-gfx] [PATCH v7 06/15] drm/i915/dg1: Enable DPLL for DG1

2020-10-12 Thread Aditya Swarup
On 10/12/20 2:29 PM, Lucas De Marchi wrote: > Add DG1 DPLL Enable register macro and use the macro to enable the > correct DPLL based on PLL id. Although we use > _MG_PLL1_ENABLE/_MG_PLL2_ENABLE these are rather combo phys. > > While at it, fix coding style: wrong newlines and use if/else chain >

[Intel-gfx] ✓ Fi.CI.BAT: success for Introduce DG1

2020-10-12 Thread Patchwork
== Series Details == Series: Introduce DG1 URL : https://patchwork.freedesktop.org/series/82594/ State : success == Summary == CI Bug Log - changes from CI_DRM_9131 -> Patchwork_18682 Summary --- **SUCCESS** No regressions found.

Re: [Intel-gfx] [PATCH v7 03/15] drm/i915/dg1: Add DG1 power wells

2020-10-12 Thread Matt Roper
On Mon, Oct 12, 2020 at 02:29:47PM -0700, Lucas De Marchi wrote: > TGL power wells can be re-used for DG1 with the exception of the fake > power well for TC_COLD. > > v2: use logic to skip power wells while copying instead of duplicating > the definition of TGL power wells (Matt Roper) > >

Re: [Intel-gfx] [PATCH] drm/i915/dp: Tweak initial dpcd backlight.enabled value

2020-10-12 Thread Lyude Paul
On Mon, 2020-10-12 at 22:02 +, Vivi, Rodrigo wrote: > > On Oct 12, 2020, at 2:47 PM, Lyude Paul wrote: > > > > Just pushed this, but it's not in drm-tip because it would seem that > > rebuilding > > drm-tip has failed, and the conflict doesn't appear to be from any of the > > patches I

Re: [Intel-gfx] [PATCH v7 02/15] drm/i915/cnl: skip PW_DDI_F on certain skus

2020-10-12 Thread Matt Roper
On Mon, Oct 12, 2020 at 02:29:46PM -0700, Lucas De Marchi wrote: > The skus guarded by IS_CNL_WITH_PORT_F() have port F and thus they need > those power wells. The others don't have those. Up to now we were > just overriding the number of power wells on !IS_CNL_WITH_PORT_F(), > relying on those

Re: [Intel-gfx] [PATCH] drm/i915/dp: Tweak initial dpcd backlight.enabled value

2020-10-12 Thread Vivi, Rodrigo
> On Oct 12, 2020, at 2:47 PM, Lyude Paul wrote: > > Just pushed this, but it's not in drm-tip because it would seem that > rebuilding > drm-tip has failed, and the conflict doesn't appear to be from any of the > patches I pushed so I'm getting the feeling from the DRM maintainer docs I >

Re: [Intel-gfx] [PATCH v7 01/15] drm/i915/display: allow to skip certain power wells

2020-10-12 Thread Matt Roper
On Mon, Oct 12, 2020 at 02:29:45PM -0700, Lucas De Marchi wrote: > From: Aditya Swarup > > This allows us to skip power wells on a platform allowing it to re-use > the table from another one instead of having to create a new table from > scratch that is basically a copy with a few removals. > >

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Introduce DG1

2020-10-12 Thread Patchwork
== Series Details == Series: Introduce DG1 URL : https://patchwork.freedesktop.org/series/82594/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/gt/intel_reset.c:1312:5:

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Introduce DG1

2020-10-12 Thread Patchwork
== Series Details == Series: Introduce DG1 URL : https://patchwork.freedesktop.org/series/82594/ State : warning == Summary == $ dim checkpatch origin/drm-tip 8623a162621b drm/i915/display: allow to skip certain power wells -:64: CHECK:MACRO_ARG_REUSE: Macro argument reuse

Re: [Intel-gfx] [PATCH] drm/i915/dp: Tweak initial dpcd backlight.enabled value

2020-10-12 Thread Lyude Paul
Just pushed this, but it's not in drm-tip because it would seem that rebuilding drm-tip has failed, and the conflict doesn't appear to be from any of the patches I pushed so I'm getting the feeling from the DRM maintainer docs I should probably let one of the drm-misc-folks handle the conflict.

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/ingenic: Fix bad revert

2020-10-12 Thread Patchwork
== Series Details == Series: drm/ingenic: Fix bad revert URL : https://patchwork.freedesktop.org/series/82588/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9130_full -> Patchwork_18679_full Summary --- **FAILURE**

[Intel-gfx] [PATCH v7 12/15] drm/i915/dg1: Add initial DG1 workarounds

2020-10-12 Thread Lucas De Marchi
From: Stuart Summers DG1 shares some workarounds with TGL and RKL and also has some additional workarounds of its own. v2: Correct location of Wa_1408615072 (JohnH). v3: Apply WAs 1606700617, 18011464164 and 22010931296 to DG1 (José) v4 (Anusha) - Add Wa_22010271021 -

[Intel-gfx] [PATCH v7 11/15] drm/i915/dg1: Load DMC

2020-10-12 Thread Lucas De Marchi
From: Matt Atwood Add support to load DMC v2.0.2 on DG1 While we're at it, make TGL use the same GEN12 firmware size definition and remove obsolete comment. Bpec: 49230 v2: do not replace GEN12_CSR_MAX_FW_SIZE (from José) and replace stale comment Cc: Matt Roper Signed-off-by: Matt

[Intel-gfx] [PATCH v7 10/15] drm/i915/dg1: Enable ports

2020-10-12 Thread Lucas De Marchi
From: Aditya Swarup For DG1 we have a little of mix up wrt to DDI/port names and indexes. Bspec refers to the ports as DDIA, DDIB, DDI USBC1 and DDI USBC2 (besides the DDIA, DDIB, DDIC, DDID), but the previous naming is the most unambiguous one. This means that for any register on Display Engine

[Intel-gfx] [PATCH v7 09/15] drm/i915/dg1: map/unmap pll clocks

2020-10-12 Thread Lucas De Marchi
DG1 uses 2 registers for the ddi clock mapping, with PHY A and B using DPCLKA_CFGCR0 and PHY C and D using DPCLKA1_CFGCR0. Hide this behind a single macro that chooses the correct register according to the phy being accessed, use the correct bitfields for each pll/phy and implement separate

[Intel-gfx] [PATCH v7 07/15] drm/i915/dg1: add hpd interrupt handling

2020-10-12 Thread Lucas De Marchi
DG1 has one more combo phy port, no TC and all irq handling goes through SDE, like for MCC. v2: Also change intel_hpd_pin_default() to include DG1 mapping v3: Rebase on hpd refactor Cc: Ville Syrjälä Cc: Anshuman Gupta Cc: José Roberto de Souza Cc: Imre Deak Signed-off-by: Lucas De Marchi

[Intel-gfx] [PATCH v7 02/15] drm/i915/cnl: skip PW_DDI_F on certain skus

2020-10-12 Thread Lucas De Marchi
The skus guarded by IS_CNL_WITH_PORT_F() have port F and thus they need those power wells. The others don't have those. Up to now we were just overriding the number of power wells on !IS_CNL_WITH_PORT_F(), relying on those power wells to be the last ones. Now that we have logic in place to skip

[Intel-gfx] [PATCH v7 00/15] Introduce DG1

2020-10-12 Thread Lucas De Marchi
v7: - Remove already applied patches and rebase the rest - Refactor DG1 power well handling to re-use table from TGL - Squash patch to add all the ports in a single patch - Use IS_DGFX() for DMC_DEBUG register move Aditya Swarup (4): drm/i915/display: allow to skip certain power wells

[Intel-gfx] [PATCH v7 04/15] drm/i915/dg1: Add DPLL macros for DG1

2020-10-12 Thread Lucas De Marchi
From: Aditya Swarup DG1 has 4 DPLLs where DPLL0 and DPLL1 drive DDIA/B and DPLL2 and DPLL3 drive DDI-TC1/DDI-TC2. Introduce DG1_DPLL_CFCRx() helper macros to configure DPLL registers. Bspec: 50288, 50299 Cc: Matt Roper Signed-off-by: Aditya Swarup Signed-off-by: Lucas De Marchi

[Intel-gfx] [PATCH v7 05/15] drm/i915/dg1: Add and setup DPLLs for DG1

2020-10-12 Thread Lucas De Marchi
From: Aditya Swarup Add entries for dg1 plls and setup dg1_pll_mgr to reuse ICL callbacks. Initial setup for shared dplls DPLL0/1 for DDIA/DDIB and DPLL2/3 for DDI-TC1/DDI-TC2. Configure dpll cfgcrx registers to drive the plls on DG1. v2 (Lucas): Reword commit message and add missing

[Intel-gfx] [PATCH v7 06/15] drm/i915/dg1: Enable DPLL for DG1

2020-10-12 Thread Lucas De Marchi
Add DG1 DPLL Enable register macro and use the macro to enable the correct DPLL based on PLL id. Although we use _MG_PLL1_ENABLE/_MG_PLL2_ENABLE these are rather combo phys. While at it, fix coding style: wrong newlines and use if/else chain v2: Rewrite original patch from Aditya Swarup based on

[Intel-gfx] [PATCH v7 08/15] drm/i915/dg1: invert HPD pins

2020-10-12 Thread Lucas De Marchi
From: Clinton A Taylor HPD pins are inverted for DG1 platform. Bspec: 49956 Cc: José Roberto de Souza Cc: Matt Roper Signed-off-by: Clinton A Taylor Reviewed-by: Lucas De Marchi Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/i915_irq.c | 9 +

[Intel-gfx] [PATCH v7 14/15] drm/i915/dg1: Update DMC_DEBUG register

2020-10-12 Thread Lucas De Marchi
From: Anshuman Gupta Update the DMC_DEBUG_DC5 register to its new location and do not try reading the DC6 counter since DG1 doesn't support DC6. v2: Use IS_DGFX() instead of IS_DG1(). Even if not having DC6 is not directly related to DGFX, the register move to a new location is. So in future,

[Intel-gfx] [PATCH v7 13/15] drm/i915/dg1: DG1 does not support DC6

2020-10-12 Thread Lucas De Marchi
From: Anshuman Gupta DC6 is not supported on DG1, so change the allowed DC mask for DG1. This is not yet on bspec, but it has been confirmed by HW engineers. Cc: Uma Shankar Signed-off-by: Anshuman Gupta Reviewed-by: Matt Roper --- drivers/gpu/drm/i915/display/intel_display_power.c | 5

[Intel-gfx] [PATCH v7 03/15] drm/i915/dg1: Add DG1 power wells

2020-10-12 Thread Lucas De Marchi
TGL power wells can be re-used for DG1 with the exception of the fake power well for TC_COLD. v2: use logic to skip power wells while copying instead of duplicating the definition of TGL power wells (Matt Roper) Bspec: 49182 Cc: Matt Roper Cc: Anshuman Gupta Signed-off-by: Lucas De Marchi

[Intel-gfx] [PATCH v7 15/15] drm/i915/dgfx: define llc and snooping behaviour

2020-10-12 Thread Lucas De Marchi
From: Michel Thierry While we do lack the faster shared LLC, we should still have support for snooping over PCIe. Signed-off-by: Michel Thierry Signed-off-by: Matthew Auld Reviewed-by: Lucas De Marchi Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/i915_pci.c | 2 ++ 1 file

[Intel-gfx] [PATCH v7 01/15] drm/i915/display: allow to skip certain power wells

2020-10-12 Thread Lucas De Marchi
From: Aditya Swarup This allows us to skip power wells on a platform allowing it to re-use the table from another one instead of having to create a new table from scratch that is basically a copy with a few removals. Cc: Imre Deak Suggested-by: Matt Roper Signed-off-by: Aditya Swarup [ Adapt

[Intel-gfx] ✓ Fi.CI.BAT: success for Introduce drm scaling filter property (rev8)

2020-10-12 Thread Patchwork
== Series Details == Series: Introduce drm scaling filter property (rev8) URL : https://patchwork.freedesktop.org/series/73883/ State : success == Summary == CI Bug Log - changes from CI_DRM_9131 -> Patchwork_18681 Summary ---

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Introduce drm scaling filter property (rev8)

2020-10-12 Thread Patchwork
== Series Details == Series: Introduce drm scaling filter property (rev8) URL : https://patchwork.freedesktop.org/series/73883/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Introduce drm scaling filter property (rev8)

2020-10-12 Thread Patchwork
== Series Details == Series: Introduce drm scaling filter property (rev8) URL : https://patchwork.freedesktop.org/series/73883/ State : warning == Summary == $ dim checkpatch origin/drm-tip db97d091f394 drm: Introduce plane and CRTC scaling filter properties ac9e547c61eb drm/drm-kms.rst: Add

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: reduce context clear batch size to avoid gpu hang (rev2)

2020-10-12 Thread Patchwork
== Series Details == Series: drm/i915/gt: reduce context clear batch size to avoid gpu hang (rev2) URL : https://patchwork.freedesktop.org/series/82587/ State : success == Summary == CI Bug Log - changes from CI_DRM_9130_full -> Patchwork_18678_full

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Refactor .hpd_irq_setup() calls a bit

2020-10-12 Thread Imre Deak
On Tue, Oct 06, 2020 at 09:58:09PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Add a small wrapper for .hpd_irq_setup() which does the > "do we even have the hook?" and "are display interrupts enabled?" > checks. > > Signed-off-by: Ville Syrjälä Reviewed-by: Imre Deak > --- >

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Do drm_mode_config_reset() after HPD init

2020-10-12 Thread Imre Deak
On Tue, Oct 06, 2020 at 09:58:08PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > LSPCON requires HPD detection logic to be enabled when we call > its .reset() hook during resume, to check the live state of the > pin. To that end let's reorder the resume sequence such that > we do HPD

Re: [Intel-gfx] [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()

2020-10-12 Thread Matthew Wilcox
On Mon, Oct 12, 2020 at 12:53:54PM -0700, Ira Weiny wrote: > On Mon, Oct 12, 2020 at 05:44:38PM +0100, Matthew Wilcox wrote: > > On Mon, Oct 12, 2020 at 09:28:29AM -0700, Dave Hansen wrote: > > > kmap_atomic() is always preferred over kmap()/kmap_thread(). > > > kmap_atomic() is _much_ more

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Remove obj->mm.lock! (rev2)

2020-10-12 Thread Patchwork
== Series Details == Series: drm/i915: Remove obj->mm.lock! (rev2) URL : https://patchwork.freedesktop.org/series/82337/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9130_full -> Patchwork_18677_full Summary ---

Re: [Intel-gfx] [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()

2020-10-12 Thread Ira Weiny
On Mon, Oct 12, 2020 at 05:44:38PM +0100, Matthew Wilcox wrote: > On Mon, Oct 12, 2020 at 09:28:29AM -0700, Dave Hansen wrote: > > kmap_atomic() is always preferred over kmap()/kmap_thread(). > > kmap_atomic() is _much_ more lightweight since its TLB invalidation is > > always CPU-local and never

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: DMA map DSM [stolen memory] (rev2)

2020-10-12 Thread Patchwork
== Series Details == Series: drm/i915: DMA map DSM [stolen memory] (rev2) URL : https://patchwork.freedesktop.org/series/82575/ State : success == Summary == CI Bug Log - changes from CI_DRM_9130_full -> Patchwork_18676_full Summary

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Reorder hpd init vs. display resume

2020-10-12 Thread Imre Deak
On Wed, Oct 07, 2020 at 10:22:41PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Currently we call .hpd_irq_setup() directly just before display > resume, and follow it with another call via intel_hpd_init() > just afterwards. Assuming the hpd pins are marked as enabled > during the

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: Add max plane width for NV12 AUX plane for Gen10+ platforms (rev3)

2020-10-12 Thread Patchwork
== Series Details == Series: drm/i915/display: Add max plane width for NV12 AUX plane for Gen10+ platforms (rev3) URL : https://patchwork.freedesktop.org/series/81609/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9130_full -> Patchwork_18675_full

Re: [Intel-gfx] [PATCH] drm/i915/tgl/psr: Fix glitches when doing frontbuffer modifications

2020-10-12 Thread Mun, Gwan-gyeong
On Mon, 2020-10-12 at 11:15 -0700, Souza, Jose wrote: > On Mon, 2020-10-12 at 19:12 +0100, Mun, Gwan-gyeong wrote: > > After applying this patch, the psr screen glitch issue is still > > seen. > > Same IOMMU errors too? In my end it is fixed. > Can you also give a try without the DMC firmware and

[Intel-gfx] [PATCH v6 4/5] drm/i915/display: Add Nearest-neighbor based integer scaling support

2020-10-12 Thread Pankaj Bharadiya
Integer scaling (IS) is a nearest-neighbor upscaling technique that simply scales up the existing pixels by an integer (i.e., whole number) multiplier.Nearest-neighbor (NN) interpolation works by filling in the missing color values in the upscaled image with that of the coordinate-mapped nearest

[Intel-gfx] [PATCH v6 5/5] drm/i915: Enable scaling filter for plane and CRTC

2020-10-12 Thread Pankaj Bharadiya
GEN >= 10 hardware supports the programmable scaler filter. Attach scaling filter property for CRTC and plane for GEN >= 10 hardwares and program scaler filter based on the selected filter type. changes since v3: * None changes since v2: * Use updated functions * Add ps_ctrl var to contain the

[Intel-gfx] [PATCH v6 2/5] drm/drm-kms.rst: Add plane and CRTC scaling filter property documentation

2020-10-12 Thread Pankaj Bharadiya
Add documentation for newly introduced KMS plane and CRTC scaling filter properties. changes since v3: * None changes since v1: * None changes since RFC: * Add separate documentation for plane and CRTC. Reviewed-by: Uma Shankar Signed-off-by: Pankaj Bharadiya --- Documentation/gpu/drm-kms.rst

[Intel-gfx] [PATCH v6 3/5] drm/i915: Introduce scaling filter related registers and bit fields

2020-10-12 Thread Pankaj Bharadiya
Introduce scaler registers and bit fields needed to configure the scaling filter in prgrammed mode and configure scaling filter coefficients. changes since v3: * None changes since v2: * Change macro names to CNL_* and use +(set)*8 instead of adding another trip through _PICK_EVEN (Ville).

[Intel-gfx] [PATCH v6 0/5] Introduce drm scaling filter property

2020-10-12 Thread Pankaj Bharadiya
Earlier, I kept this series on hold since we wanted to have a reference userspace implementation in place. Now, Sameer has implemented Integer scaling in Kodi Retro gaming framework which demonstrate how Integer scaling gives distinctive look to pixel art games when played on higher resolution

[Intel-gfx] [PATCH v6 1/5] drm: Introduce plane and CRTC scaling filter properties

2020-10-12 Thread Pankaj Bharadiya
Introduce per-plane and per-CRTC scaling filter properties to allow userspace to select the driver's default scaling filter or Nearest-neighbor(NN) filter for upscaling operations on CRTC and plane. Drivers can set up this property for a plane by calling drm_plane_create_scaling_filter() and for

Re: [Intel-gfx] [PATCH] drm/i915/dp: Tweak initial dpcd backlight.enabled value

2020-10-12 Thread Lyude Paul
On Mon, 2020-10-12 at 13:50 -0400, Sean Paul wrote: > On Tue, Sep 22, 2020 at 11:36 AM Lyude Paul wrote: > > On Tue, 2020-09-22 at 09:39 -0400, Sean Paul wrote: > > > On Mon, Sep 21, 2020 at 6:35 PM Lyude Paul wrote: > > > > So if I understand this correctly, it sounds like that some Pixelbooks

Re: [Intel-gfx] [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()

2020-10-12 Thread Eric Biggers
On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote: > > > > And I still don't really understand. After this patchset, there is still > > code > > nearly identical to the above (doing a temporary mapping just for a memcpy) > > that > > would still be using kmap_atomic(). > > I don't

Re: [Intel-gfx] [PATCH] drm/i915/tgl/psr: Fix glitches when doing frontbuffer modifications

2020-10-12 Thread Souza, Jose
On Mon, 2020-10-12 at 19:12 +0100, Mun, Gwan-gyeong wrote: > After applying this patch, the psr screen glitch issue is still seen. Same IOMMU errors too? In my end it is fixed. Can you also give a try without the DMC firmware and without this changes? > On Fri, 2020-10-02 at 16:16 -0700, José

Re: [Intel-gfx] [PATCH] drm/i915/tgl/psr: Fix glitches when doing frontbuffer modifications

2020-10-12 Thread Mun, Gwan-gyeong
After applying this patch, the psr screen glitch issue is still seen. On Fri, 2020-10-02 at 16:16 -0700, José Roberto de Souza wrote: > Writes to CURSURFLIVE in TGL are causing IOMMU errors and visual > glitches that are often reproduced when executing CPU intensive > workloads while a eDP 4K

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/ingenic: Fix bad revert

2020-10-12 Thread Patchwork
== Series Details == Series: drm/ingenic: Fix bad revert URL : https://patchwork.freedesktop.org/series/82588/ State : success == Summary == CI Bug Log - changes from CI_DRM_9130 -> Patchwork_18679 Summary --- **SUCCESS** No

Re: [Intel-gfx] [PATCH] drm/i915/dp: Tweak initial dpcd backlight.enabled value

2020-10-12 Thread Sean Paul
On Tue, Sep 22, 2020 at 11:36 AM Lyude Paul wrote: > > On Tue, 2020-09-22 at 09:39 -0400, Sean Paul wrote: > > On Mon, Sep 21, 2020 at 6:35 PM Lyude Paul wrote: > > > So if I understand this correctly, it sounds like that some Pixelbooks > > > boot up > > > with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: reduce context clear batch size to avoid gpu hang (rev2)

2020-10-12 Thread Patchwork
== Series Details == Series: drm/i915/gt: reduce context clear batch size to avoid gpu hang (rev2) URL : https://patchwork.freedesktop.org/series/82587/ State : success == Summary == CI Bug Log - changes from CI_DRM_9130 -> Patchwork_18678

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: reduce context clear batch size to avoid gpu hang (rev2)

2020-10-12 Thread Patchwork
== Series Details == Series: drm/i915/gt: reduce context clear batch size to avoid gpu hang (rev2) URL : https://patchwork.freedesktop.org/series/82587/ State : warning == Summary == $ dim checkpatch origin/drm-tip e87275d426b9 drm/i915/gt: reduce context clear batch size to avoid gpu hang

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove obj->mm.lock! (rev2)

2020-10-12 Thread Patchwork
== Series Details == Series: drm/i915: Remove obj->mm.lock! (rev2) URL : https://patchwork.freedesktop.org/series/82337/ State : success == Summary == CI Bug Log - changes from CI_DRM_9130 -> Patchwork_18677 Summary --- **SUCCESS**

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm: Ask whether drm_gem_get_pages() should clear the CPU cache

2020-10-12 Thread Patchwork
== Series Details == Series: series starting with [1/2] drm: Ask whether drm_gem_get_pages() should clear the CPU cache URL : https://patchwork.freedesktop.org/series/82569/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9128_full -> Patchwork_18672_full

Re: [Intel-gfx] [PATCH v2 14/61] drm/i915: Fix userptr so we do not have to worry about obj->mm.lock, v2.

2020-10-12 Thread Intel
On 10/12/20 4:46 PM, Maarten Lankhorst wrote: Instead of doing what we do currently, which will never work with PROVE_LOCKING, do the same as AMD does, and something similar to relocation slowpath. When all locks are dropped, we acquire the pages for pinning. When the locks are taken, we

Re: [Intel-gfx] [PATCH v4 1/1] drm/i915/gt: Initialize reserved and unspecified MOCS indices

2020-10-12 Thread Lucas De Marchi
On Fri, Jul 31, 2020 at 12:23:57AM -0700, Siddiqui, Ayaz A wrote: -Original Message- From: Siddiqui, Ayaz A Sent: Wednesday, July 29, 2020 3:56 PM To: intel-gfx@lists.freedesktop.org Cc: Siddiqui, Ayaz A ; Chris Wilson ; De Marchi, Lucas ; Lis, Tomasz ; Roper, Matthew D ; Joonas

[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915: Remove obj->mm.lock! (rev2)

2020-10-12 Thread Patchwork
== Series Details == Series: drm/i915: Remove obj->mm.lock! (rev2) URL : https://patchwork.freedesktop.org/series/82337/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function parameter or member 'ww'

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Remove obj->mm.lock! (rev2)

2020-10-12 Thread Patchwork
== Series Details == Series: drm/i915: Remove obj->mm.lock! (rev2) URL : https://patchwork.freedesktop.org/series/82337/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. -

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Remove obj->mm.lock! (rev2)

2020-10-12 Thread Patchwork
== Series Details == Series: drm/i915: Remove obj->mm.lock! (rev2) URL : https://patchwork.freedesktop.org/series/82337/ State : warning == Summary == $ dim checkpatch origin/drm-tip ad5a5f0624eb drm/i915: Move cmd parser pinning to execbuffer f524499cf8c7 drm/i915: Add missing -EDEADLK

Re: [Intel-gfx] [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()

2020-10-12 Thread Matthew Wilcox
On Mon, Oct 12, 2020 at 09:28:29AM -0700, Dave Hansen wrote: > kmap_atomic() is always preferred over kmap()/kmap_thread(). > kmap_atomic() is _much_ more lightweight since its TLB invalidation is > always CPU-local and never broadcast. > > So, basically, unless you *must* sleep while the mapping

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: DMA map DSM [stolen memory] (rev2)

2020-10-12 Thread Patchwork
== Series Details == Series: drm/i915: DMA map DSM [stolen memory] (rev2) URL : https://patchwork.freedesktop.org/series/82575/ State : success == Summary == CI Bug Log - changes from CI_DRM_9130 -> Patchwork_18676 Summary ---

Re: [Intel-gfx] [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()

2020-10-12 Thread Dave Hansen
On 10/12/20 9:19 AM, Eric Biggers wrote: > On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote: >>> And I still don't really understand. After this patchset, there is still >>> code >>> nearly identical to the above (doing a temporary mapping just for a memcpy) >>> that >>> would still be

Re: [Intel-gfx] [PATCH RFC PKS/PMEM 10/58] drivers/rdma: Utilize new kmap_thread()

2020-10-12 Thread Bernard Metzler
-ira.we...@intel.com wrote: - >To: "Andrew Morton" , "Thomas Gleixner" >, "Ingo Molnar" , "Borislav >Petkov" , "Andy Lutomirski" , "Peter >Zijlstra" >From: ira.we...@intel.com >Date: 10/09/2020 09:52PM >Cc: "Ira Weiny" , "Mike Marciniszyn" >, "Dennis Dalessandro" >, "Doug Ledford" ,

Re: [Intel-gfx] [PATCH RFC PKS/PMEM 26/58] fs/zonefs: Utilize new kmap_thread()

2020-10-12 Thread Damien Le Moal
On 2020/10/10 4:52, ira.we...@intel.com wrote: > From: Ira Weiny > > The kmap() calls in this FS are localized to a single thread. To avoid > the over head of global PKRS updates use the new kmap_thread() call. > > Cc: Damien Le Moal > Cc: Naohiro Aota > Signed-off-by: Ira Weiny > --- >

Re: [Intel-gfx] [PATCH RFC PKS/PMEM 57/58] nvdimm/pmem: Stray access protection for pmem->virt_addr

2020-10-12 Thread John Hubbard
On 10/9/20 12:50 PM, ira.we...@intel.com wrote: From: Ira Weiny The pmem driver uses a cached virtual address to access its memory directly. Because the nvdimm driver is well aware of the special protections it has mapped memory with, we call dev_access_[en|dis]able() around the direct

Re: [Intel-gfx] [PATCH RFC PKS/PMEM 51/58] kernel: Utilize new kmap_thread()

2020-10-12 Thread Eric W. Biederman
ira.we...@intel.com writes: > From: Ira Weiny > > This kmap() call is localized to a single thread. To avoid the over > head of global PKRS updates use the new kmap_thread() call. Acked-by: "Eric W. Biederman" > > Cc: Eric Biederman > Signed-off-by: Ira Weiny > --- > kernel/kexec_core.c |

Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree

2020-10-12 Thread Paul Cercueil
Hi Stephen, Le lun. 12 oct. 2020 à 15:24, Stephen Rothwell a écrit : Hi all, On Thu, 8 Oct 2020 15:42:02 +1100 Stephen Rothwell wrote: On Thu, 8 Oct 2020 14:09:03 +1100 Stephen Rothwell wrote: > > After merging the drm-misc tree, today's linux-next build (x86_64 > allmodconfig)

[Intel-gfx] [RFC] drm/i915/gt: reduce context clear batch size to avoid gpu hang (rev2)

2020-10-12 Thread rwright
The first version of this RFC patch caused a build error when - to my suprise - it was automatically built. I had presumed an RFC message would be for comment only, and so I had pasted part of the patch, thereby breaking whitespace. In this version, I have directly included the patch without

[Intel-gfx] [PATCH] drm/ingenic: Fix bad revert

2020-10-12 Thread Paul Cercueil
Fix a badly reverted commit. The revert commit was cherry-picked from drm-misc-next to drm-misc-next-fixes, and in the process some unrelated code was added. Fixes: a3fb64c00d44 "Revert "gpu/drm: ingenic: Add option to mmap GEM buffers cached"" Signed-off-by: Paul Cercueil ---

Re: [Intel-gfx] [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()

2020-10-12 Thread Eric Biggers
On Sat, Oct 10, 2020 at 01:39:54AM +0100, Matthew Wilcox wrote: > On Fri, Oct 09, 2020 at 02:34:34PM -0700, Eric Biggers wrote: > > On Fri, Oct 09, 2020 at 12:49:57PM -0700, ira.we...@intel.com wrote: > > > The kmap() calls in this FS are localized to a single thread. To avoid > > > the over head

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Add max plane width for NV12 AUX plane for Gen10+ platforms (rev3)

2020-10-12 Thread Patchwork
== Series Details == Series: drm/i915/display: Add max plane width for NV12 AUX plane for Gen10+ platforms (rev3) URL : https://patchwork.freedesktop.org/series/81609/ State : success == Summary == CI Bug Log - changes from CI_DRM_9130 -> Patchwork_18675

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/psr: Configure and Program IO buffer Wake and Fast Wake

2020-10-12 Thread Patchwork
== Series Details == Series: drm/i915/psr: Configure and Program IO buffer Wake and Fast Wake URL : https://patchwork.freedesktop.org/series/82581/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9130 -> Patchwork_18674

Re: [Intel-gfx] [PATCH v4 1/1] drm/i915/gt: Initialize reserved and unspecified MOCS indices

2020-10-12 Thread Joonas Lahtinen
Quoting Ayaz A Siddiqui (2020-07-29 13:25:39) > In order to avoid functional breakage of mis-programmed applications that > have grown to depend on unused MOCS entries, we are programming > those entries to be equal to fully cached ("L3 + LLC") entry. > > These reserved and unspecified entries

[Intel-gfx] [PATCH v2 54/61] drm/i915/selftests: Prepare ring submission for obj->mm.lock removal

2020-10-12 Thread Maarten Lankhorst
Use unlocked versions when the ww lock is not held. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gt/selftest_ring_submission.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/selftest_ring_submission.c

[Intel-gfx] [PATCH v2 53/61] drm/i915/selftests: Prepare mocs tests for obj->mm.lock removal

2020-10-12 Thread Maarten Lankhorst
Use pin_map_unlocked when we're not holding locks. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gt/selftest_mocs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/selftest_mocs.c b/drivers/gpu/drm/i915/gt/selftest_mocs.c index

[Intel-gfx] [PATCH v2 38/61] drm/i915: Fix ww locking in shmem_create_from_object

2020-10-12 Thread Maarten Lankhorst
Quick fix, just use the unlocked version. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gt/shmem_utils.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/shmem_utils.c b/drivers/gpu/drm/i915/gt/shmem_utils.c index

[Intel-gfx] [PATCH v2 52/61] drm/i915/selftests: Prepare execlists for obj->mm.lock removal

2020-10-12 Thread Maarten Lankhorst
Convert normal functions to unlocked versions where needed. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gt/selftest_lrc.c | 34 +- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c

[Intel-gfx] [PATCH v2 14/61] drm/i915: Fix userptr so we do not have to worry about obj->mm.lock, v2.

2020-10-12 Thread Maarten Lankhorst
Instead of doing what we do currently, which will never work with PROVE_LOCKING, do the same as AMD does, and something similar to relocation slowpath. When all locks are dropped, we acquire the pages for pinning. When the locks are taken, we transfer those pages in .get_pages() to the bo. As a

[Intel-gfx] [PATCH v2 30/61] drm/i915: Fix workarounds selftest, part 1

2020-10-12 Thread Maarten Lankhorst
pin_map needs the ww lock, so ensure we pin both before submission. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gem/i915_gem_object.h| 3 + drivers/gpu/drm/i915/gem/i915_gem_pages.c | 12 +++ .../gpu/drm/i915/gt/selftest_workarounds.c| 76 --- 3 files

[Intel-gfx] [PATCH v2 56/61] drm/i915/selftests: Prepare i915_request tests for obj->mm.lock removal

2020-10-12 Thread Maarten Lankhorst
Straightforward conversion by using unlocked versions. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/selftests/i915_request.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c

[Intel-gfx] [PATCH v2 20/61] drm/i915: Rework clflush to work correctly without obj->mm.lock.

2020-10-12 Thread Maarten Lankhorst
Pin in the caller, not in the work itself. This should also work better for dma-fence annotations. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git

[Intel-gfx] [PATCH v2 51/61] drm/i915/selftests: Prepare hangcheck for obj->mm.lock removal

2020-10-12 Thread Maarten Lankhorst
Convert a few calls to use the unlocked versions. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c

[Intel-gfx] [PATCH v2 45/61] drm/i915/selftests: Prepare execbuf tests for obj->mm.lock removal.

2020-10-12 Thread Maarten Lankhorst
Also quite simple, a single call needs to use the unlocked version. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gem/selftests/i915_gem_execbuffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_execbuffer.c

[Intel-gfx] [PATCH v2 47/61] drm/i915/selftests: Prepare object tests for obj->mm.lock removal.

2020-10-12 Thread Maarten Lankhorst
Convert a single pin_pages call to use the unlocked version. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c

[Intel-gfx] [PATCH v2 31/61] drm/i915: Prepare for obj->mm.lock removal

2020-10-12 Thread Maarten Lankhorst
From: Thomas Hellström Stolen objects need to lock, and we may call put_pages when refcount drops to 0, ensure all calls are handled correctly. Idea-from: Thomas Hellström Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gem/i915_gem_object.h | 14 ++

[Intel-gfx] [PATCH v2 33/61] drm/i915: Add ww locking around vm_access()

2020-10-12 Thread Maarten Lankhorst
i915_gem_object_pin_map potentially needs a ww context, so ensure we have one we can revoke. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 24 ++-- 1 file changed, 22 insertions(+), 2 deletions(-) diff --git

[Intel-gfx] [PATCH v2 44/61] drm/i915/selftests: Prepare dma-buf tests for obj->mm.lock removal.

2020-10-12 Thread Maarten Lankhorst
Use pin_pages_unlocked() where we don't have a lock. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c

[Intel-gfx] [PATCH v2 19/61] drm/i915: Handle ww locking in init_status_page

2020-10-12 Thread Maarten Lankhorst
Try to pin to ggtt first, and use a full ww loop to handle eviction correctly. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 37 +++ 1 file changed, 24 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c

[Intel-gfx] [PATCH v2 58/61] drm/i915/selftests: Prepare cs engine tests for obj->mm.lock removal

2020-10-12 Thread Maarten Lankhorst
Same as other tests, use pin_map_unlocked. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_cs.c b/drivers/gpu/drm/i915/gt/selftest_engine_cs.c index

  1   2   >