Hi Dave,
Here's the remaining patches we have in drm-misc-next-fixes
Maxime
drm-misc-next-fixes-2020-10-13:
One fix for a bad revert in ingenic-drm, and one fix for panfrost to increase a
timeout at power up.
The following changes since commit 8ba0b6d196315f68c271f549e8585129caefce97:
drm/vc
> 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 strangene
== 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 regressio
== 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
---
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.
https://lore.kernel.org/linux-iommu/2020091203220
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: V
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:
> BOE
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 preferr
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, IS_ELKHARTLAK
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é Rober
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
>
== 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.
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)
>
> Bspec:
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 pushed
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 pow
> 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
> shou
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.
>
>
== 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: war
== 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 '__power_well_descs'
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.
On
== 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**
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
- s/Wa_14010096844/Wa_140
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
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 Atwoo
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 functio
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
--
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
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 +
drivers/gpu/drm/i915/i915_reg.
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, if
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 -
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
---
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 changed,
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 pow
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
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
Reviewed-by:
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 update_ref_
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
== 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
---
**SUCC
== 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.
+./drivers/gpu/drm/am
== 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 p
== 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
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
> ---
> driv
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 init
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 lightwe
== 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
---
**F
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 b
== 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
---
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 open-
== 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
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
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 so
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 fu
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
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).
chan
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 mon
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 a
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
>
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 unde
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é Ro
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 panel
== 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 regre
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 se
== 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
== 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
(r
== 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**
== 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
==
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 transf
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 Lahti
== 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' no
== 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.
-
+drivers/gpu/drm/i915/gt/i
== 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 handli
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
== 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
---
**SUCC
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
-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" ,
>"Jas
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
> ---
> fs/
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 pmem->v
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 past
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 |
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) fai
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
---
drivers/gpu/drm/i
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
== 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
==
== 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
Summa
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 sho
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
b/drivers/gpu/drm/i915/gt/selfte
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 b25eba50c88
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 43c7acbdc79d..8c8dfa41e032
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
b/drivers/gpu/drm/i915/
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 fin
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 c
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
b/drivers/gpu/drm/i915/selftests
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 a/drivers/gpu/drm/i915/gem/i915_ge
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
b/drivers/gpu/drm/i915/gt/selftest_hangche
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
b/driver
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
b/drivers/gpu/drm/i915/
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 ++
drivers/gpu/drm/i915
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 a/drivers/gpu/drm/i915/gem/i915_g
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
b/drivers/gpu/drm/i915/gem/self
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
b
1 - 100 of 170 matches
Mail list logo