On Thu 25-06-20 12:00:47, Chris Wilson wrote:
> Quoting Michal Hocko (2020-06-25 08:57:25)
> > On Wed 24-06-20 20:14:17, Chris Wilson wrote:
> > > A general rule of thumb is that shrinkers should be fast and effective.
> > > They are called from direct reclaim at the most incovenient of times when
Am 25.06.20 um 17:10 schrieb Chris Wilson:
We have the DAG of fences, we can use that information to avoid adding
an implicit coupling between execution contexts.
No, we can't. And it sounds like you still have not understood the
underlying problem.
See this has nothing to do with the
On Thu, Jun 25, 2020 at 03:40:44PM +0200, Jan Kara wrote:
> On Thu 25-06-20 12:42:09, Matthew Wilcox wrote:
> > Why are DMA pinned pages still on the LRU list at all? I never got an
> > answer to this that made sense to me. By definition, a page which is
> > pinned for DMA is being accessed, and
Quoting Michal Hocko (2020-06-25 16:12:27)
> On Thu 25-06-20 12:00:47, Chris Wilson wrote:
> > Quoting Michal Hocko (2020-06-25 08:57:25)
> > > On Wed 24-06-20 20:14:17, Chris Wilson wrote:
> > > > A general rule of thumb is that shrinkers should be fast and effective.
> > > > They are called from
WTUF?
How did this ever land in my tree, there is no ACK on this from anyone
in core dma-buf,
Intel team, clean your house up here, I'm going to have to ask you to
stop Chris merging stuff without oversight, if this sort of thing
happens, this is totally unacceptable.
Dave.
Signed-off-by:
On Fri, 8 May 2020 at 15:58, Joonas Lahtinen
wrote:
>
> Quoting Dave Airlie (2020-05-07 21:27:27)
> > On Fri, 8 May 2020 at 01:44, Chris Wilson wrote:
> > >
> > > Quoting Jason Ekstrand (2020-05-07 16:36:00)
> > > > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > > >
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base
implementation").
The bot has tested the following trees: v5.7.5, v5.4.48, v4.19.129.
v5.7.5: Build OK!
v5.4.48: Failed to apply!
On Mon, Jun 01, 2020 at 06:49:10PM -0700, Aditya Swarup wrote:
> Set GMBUS0 Pin Pair Select to 1 at boot and each FLR exit.
> Return GMBUS0 Pin Pair Select to 1 after GMBUS transactions are done.
>
> Cc: Michal Wajdeczko
> Cc: Piotr Piórkowski
> Cc: Matt Roper
> Cc: Jose Souza
>
O Wed, Jun 17, 2020 at 11:00:06AM -0700, Matt Roper wrote:
> This workaround now also applies to TGL and RKL, so extend the PCH test
> to just capture everthing ICP and beyond.
>
> Signed-off-by: Matt Roper
Reviewed-by: Matt Atwood
> ---
> drivers/gpu/drm/i915/i915_irq.c | 6 ++
> 1 file
Quoting Christian König (2020-06-25 16:47:09)
> Am 25.06.20 um 17:10 schrieb Chris Wilson:
> > We have the DAG of fences, we can use that information to avoid adding
> > an implicit coupling between execution contexts.
>
> No, we can't. And it sounds like you still have not understood the
>
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base
implementation").
The bot has tested the following trees: v5.7.5, v5.4.48, v4.19.129.
v5.7.5: Build OK!
v5.4.48: Failed to apply!
Hi, Maarten,
On 6/23/20 4:28 PM, Maarten Lankhorst wrote:
As a preparation step for full object locking and wait/wound handling
during pin and object mapping, ensure that we always pass the ww context
in i915_gem_execbuffer.c to i915_vma_pin, use lockdep to ensure this
happens.
This also
Quoting Janusz Krzysztofik (2020-06-22 18:44:08)
> The purpose of debug messages displayed by the test is to make
> identification of a subtest phase that fails more easy. Since issues
> exhibited by the test are mostly reported to dmesg, print those debug
> messages to /dev/kmsg as well.
I'm
Quoting Christian König (2020-06-25 15:02:41)
> Am 25.06.20 um 15:23 schrieb Chris Wilson:
> > Quoting Christian König (2020-06-25 13:59:16)
> >> Am 25.06.20 um 14:48 schrieb Chris Wilson:
> >>> Quoting Christian König (2020-06-25 09:11:35)
> Am 24.06.20 um 22:18 schrieb Chris Wilson:
> >
On Wed, Jun 24, 2020 at 02:57:23PM -0700, Matt Atwood wrote:
Set the title to drm/i915/gen12: Impl... and let go the semicolon.
> Update code to reflect recent bspec changes
>
> Bspec: 52890
> Bspec: 53508
>
> Signed-off-by: Matt Atwood
With the title fixed,
Reviewed-by: Radhakrishna Sripada
This registers will be used to implement PSR2 manual tracking/selective
fetch.
v2:
- Fixed typo in _PLANE_SEL_FETCH_BASE
- Renamed PSR2_MAN_TRK_CTL bits to better match spec names
- Renamed _PLANE_SEL_FETCH_* to better match spec names
BSpec: 55229
BSpec: 50424
BSpec: 50420
Cc: Gwan-gyeong Mun
On Thu Jun 25 20, Joerg Roedel wrote:
From: Joerg Roedel
Hi,
here is a patch-set to remove the usage of dev->archdata.iommu from
the IOMMU code in the kernel and replace its uses by the iommu per-device
private data field. The changes also remove the field entirely from
the architectures
On Fri, 26 Jun 2020 at 01:24, Daniel Vetter wrote:
>
> Ignoring everything else ...
>
> On Thu, Jun 25, 2020 at 9:28 PM Jani Nikula
> wrote:
> > As a side note, there seem to be extra checks in place for acks when
> > applying non-i915 patches to drm-intel; there are no such checks for
> >
From the 3 WAs for PSR2 man track/selective fetch this is only one
needed when doing single full frames at every flip.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_psr.c | 19 +--
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 18
Future patches will bring PSR2 selective fetch configuration
validation but most of the configuration checks will be used for HW
tracking and selective fetch so the reoder was necessary.
Reviewed-by: Gwan-gyeong Mun
Signed-off-by: José Roberto de Souza
---
All GEN12 platforms supports PSR2 selective fetch but not all GEN12
platforms supports PSR2 hardware tracking(aka RKL).
This feature consists in software programming registers with the
damaged area of each plane this way hardware will only fetch from
memory those areas and sent the PSR2 selective
This property will be used by PSR2 software tracking, adding it to
GEN12+.
Reviewed-by: Gwan-gyeong Mun
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display.c | 4
drivers/gpu/drm/i915/display/intel_sprite.c | 4
2 files changed, 8 insertions(+)
diff
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
between commit:
eaad0c3aa978 ("drm/amdgpu: rename direct to immediate for VM updates")
from the Linus' and commit:
b1a8ef952a25 ("drm/amdgpu: move ttm bo->offset to
I can't figure this out easily so I'd thought I'd just ask, but does
DG1 have VRAM > PCIE aperture, I'm not sure I've see any mention of
mappable VRAM vs non-mappable in patches, is it planned to just thrash
the aperture if userspace ever ties to map too much of it.
Are pagetables stored in the
Quoting Janusz Krzysztofik (2020-06-22 18:44:10)
> Check if this 3-step procedure exhibits any issues with device recover
> after unplug. Such issues may indicate insufficient device hardware
> re-initialization performed by the device driver, or other kernel bugs
> outside the driver code.
>
>
On Fri, Jun 26, 2020 at 12:28:53AM +0300, Ville Syrjälä wrote:
> On Wed, Jun 24, 2020 at 03:11:08PM -0700, Manasi Navare wrote:
> > Based on the platform, Bspec expects us to wait or poll with
> > timeout for DDI BUF IDLE bit to be set to 0 (non idle) or get active
> > after enabling DDI_BUF_CTL.
Continuing our grouping of GT-related code under intel_gt, this series
moves some of the runtime-detected device capabilities. In particular,
the engine_mask and the sseu_info are placed under the gt structure,
inside a newly added struct intel_gt_info.
Error capture and info print at the
Keep all the SSEU code in the relevant file. The code has also been
updated to use intel_gt instead of dev_priv.
Based on an original patch by Sandeep.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
Cc: Venkata Sandeep Dhanalakota
---
We already call 2 gt-related init_mmio functions in driver_mmio_probe
and a 3rd one will be added by a follow-up patch, so pre-emptively
introduce a gt_init_mmio function to group them.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
---
Since the engines belong to the GT, move the runtime-updated list of
available engines to the intel_gt struct. The original mask has been
renamed to indicate it contains the maximum engine list that can be
found on a matching device.
In preparation for other info being moved to the gt in follow
A follow up patch will move the engine mask under the gt structure,
so get ready for that.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 2 +-
All the info we read in intel_device_info_init_mmio are engine-related
and since we already have an engine_init_mmio function we can just
perform the operations from there.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c |
From: Venkata Sandeep Dhanalakota
SSEUs are a GT capability, so track them under gt_info.
Signed-off-by: Venkata Sandeep Dhanalakota
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 7 ---
Use intel__read instead of I915_READ to read the
informational registers.
Extended from an original sseu-only patch by Sandeep.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
Cc: Venkata Sandeep Dhanalakota
---
drivers/gpu/drm/i915/intel_device_info.c | 77
On Fri, 26 Jun 2020 at 05:27, Jani Nikula wrote:
>
> On Fri, 26 Jun 2020, Dave Airlie wrote:
> > WTUF?
> >
> > How did this ever land in my tree, there is no ACK on this from anyone
> > in core dma-buf,
> >
> > Intel team, clean your house up here, I'm going to have to ask you to
> > stop Chris
On Fri, 26 Jun 2020, Dave Airlie wrote:
> WTUF?
>
> How did this ever land in my tree, there is no ACK on this from anyone
> in core dma-buf,
>
> Intel team, clean your house up here, I'm going to have to ask you to
> stop Chris merging stuff without oversight, if this sort of thing
> happens,
Quoting Janusz Krzysztofik (2020-06-22 18:44:11)
> If a GPU gets wedged during driver rebind or device re-plug for some
> reason, current hotunbind/hotunplug test variants may time out before
> lateclose phase, resulting in incomplete CI reports. Let's rename
> those variants to more adequate
Quoting Janusz Krzysztofik (2020-06-22 18:44:13)
> GEM objects belonging to user file descriptors still open on device
> hotunplug may exhibit still more driver issues. Add a subtest that
> implements this scenario.
>
> v2: rebase on upstream
>
> Signed-off-by: Janusz Krzysztofik
> ---
>
This is new step that was recently added to the combo phy
initialization.
v2:
- using intel_de_rmw()
v3:
- going back to read() modify and write() as group register can't be
read
BSpec: 49291
Cc: Clinton A Taylor
Cc: Lucas De Marchi
Signed-off-by: José Roberto de Souza
---
From: Ville Syrjälä
The linetime watermark is a 9 bit value, which gives us
a maximum linetime of just below 64 usec. If the linetime
exceeds that value we currently just discard the high bits
and program the rest into the register, which angers the
state checker.
To avoid that let's just clamp
On Wed, Jun 24, 2020 at 03:11:08PM -0700, Manasi Navare wrote:
> Based on the platform, Bspec expects us to wait or poll with
> timeout for DDI BUF IDLE bit to be set to 0 (non idle) or get active
> after enabling DDI_BUF_CTL.
>
> v3:
> * Add a new function _active for DDI BUF CTL to be non idle
Ignoring everything else ...
On Thu, Jun 25, 2020 at 9:28 PM Jani Nikula wrote:
> As a side note, there seem to be extra checks in place for acks when
> applying non-i915 patches to drm-intel; there are no such checks for
> drm-misc.
One option to generalize that that I pondered is to consult
On Fri, Jun 26, 2020 at 12:28:53AM +0300, Ville Syrjälä wrote:
> On Wed, Jun 24, 2020 at 03:11:08PM -0700, Manasi Navare wrote:
> > Based on the platform, Bspec expects us to wait or poll with
> > timeout for DDI BUF IDLE bit to be set to 0 (non idle) or get active
> > after enabling DDI_BUF_CTL.
Thanks Bhanu for the patch, merged to drm-misc
Manasi
On Mon, Jun 22, 2020 at 07:55:18PM +0530, Bhanuprakash Modem wrote:
> [Why]
> It's useful to know the min and max vrr range for IGT testing.
>
> [How]
> Expose the min and max vfreq for the connector via a debugfs file
> on the connector,
Quoting Janusz Krzysztofik (2020-06-22 18:44:15)
> Verify if a device with a GEM batch job still running on a GPU can be
> hot-unplugged cleanly and released, then recovered.
>
> v2: rebase on upstream
>
> Signed-off-by: Janusz Krzysztofik
> ---
> tests/core_hotunplug.c | 34
On Wed, Jun 24, 2020 at 03:11:07PM -0700, Manasi Navare wrote:
> Modify the helper to add a fixed delay or poll with timeout
> based on platform specification to check for either Idle bit
> set (DDI_BUF_CTL is idle for disable case)
>
> v2:
> * Use 2 separate functions or idle and active (Ville)
On Fri, Jun 26, 2020 at 12:26:22AM +0300, Ville Syrjälä wrote:
> On Wed, Jun 24, 2020 at 03:11:07PM -0700, Manasi Navare wrote:
> > Modify the helper to add a fixed delay or poll with timeout
> > based on platform specification to check for either Idle bit
> > set (DDI_BUF_CTL is idle for disable
On Thu, Jun 25, 2020 at 03:04:33PM -0700, Manasi Navare wrote:
> On Fri, Jun 26, 2020 at 12:28:53AM +0300, Ville Syrjälä wrote:
> > On Wed, Jun 24, 2020 at 03:11:08PM -0700, Manasi Navare wrote:
> > > Based on the platform, Bspec expects us to wait or poll with
> > > timeout for DDI BUF IDLE bit
Quoting Janusz Krzysztofik (2020-06-22 18:44:12)
> Verify if an additional address space associated with an open device
> file descriptor is cleaned up correctly on device hotunplug.
>
> v2: rebase on upstream, update includes order
>
> Signed-off-by: Janusz Krzysztofik
> ---
>
On Mon, 2020-06-15 at 19:23 +, Souza, Jose wrote:
> On Mon, 2020-06-15 at 19:37 +0100, Mun, Gwan-gyeong wrote:
> > On Fri, 2020-06-12 at 21:49 +, Mun, Gwan-gyeong wrote:
> > > On Fri, 2020-06-12 at 14:18 -0700, Souza, Jose wrote:
> > > > On Fri, 2020-06-12 at 21:57 +0100, Mun, Gwan-gyeong
Quoting Janusz Krzysztofik (2020-06-22 18:44:09)
> Future subtests may want to access PCI attributes of the device after
> driver unbind. Refactor prepare() helper.
>
> v2: rebase on upstream
>
> Signed-off-by: Janusz Krzysztofik
> ---
> tests/core_hotunplug.c | 68
Quoting Janusz Krzysztofik (2020-06-22 18:44:14)
> Even if all device file descriptors are closed on device hotunplug,
> PRIME exported objects may still exists, referenced by still open
> dma-buf file handles. Add a subtest that keeps such handle open on
> device hotunplug.
>
> v2: rebase on
On Tue, May 12, 2020 at 08:41:44PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The DP spec says:
> "The transmitter shall support at least three levels of voltage
> swing (Levels 0, 1, and 2).
>
> If only three levels of voltage swing are supported (VOLTAGE
> SWING SET field (bits
On Fri, Jun 26, 2020 at 01:16:42AM +0300, Ville Syrjälä wrote:
> On Thu, Jun 25, 2020 at 03:04:33PM -0700, Manasi Navare wrote:
> > On Fri, Jun 26, 2020 at 12:28:53AM +0300, Ville Syrjälä wrote:
> > > On Wed, Jun 24, 2020 at 03:11:08PM -0700, Manasi Navare wrote:
> > > > Based on the platform,
On Thu, Jun 25, 2020 at 10:34:25AM -0700, Matt Atwood wrote:
> O Wed, Jun 17, 2020 at 11:00:06AM -0700, Matt Roper wrote:
> > This workaround now also applies to TGL and RKL, so extend the PCH test
> > to just capture everthing ICP and beyond.
> >
> > Signed-off-by: Matt Roper
> Reviewed-by:
On Wed 24-06-20 20:14:17, Chris Wilson wrote:
> A general rule of thumb is that shrinkers should be fast and effective.
> They are called from direct reclaim at the most incovenient of times when
> the caller is waiting for a page. If we attempt to reclaim a page being
> pinned for active dma
Op 23-06-2020 om 20:57 schreef Kunal Joshi:
> From: Stanislav Lisovskiy
>
> Added epoch counter checking to intel_encoder_hotplug
> in order to be able process all the connector changes,
> besides connection status. Also now any change in connector
> would result in epoch counter change, so no
The function igt_put_caito_ctx has three parameters, but it looks like only
one of them is actually used. If I'm not wrong about the unnecessary
parameters, removing them makes the function more readable and simpler to
understand. Since the function is used in many tests, this change is a little
On Thu, Jun 25, 2020 at 10:36:28AM +0200, Maarten Lankhorst wrote:
> Op 23-06-2020 om 20:57 schreef Kunal Joshi:
> > From: Stanislav Lisovskiy
> >
> > Added epoch counter checking to intel_encoder_hotplug
> > in order to be able process all the connector changes,
> > besides connection status.
Quoting Christian König (2020-06-25 09:11:35)
> Am 24.06.20 um 22:18 schrieb Chris Wilson:
> > Quoting Dave Airlie (2020-06-24 20:04:02)
> >> On Wed, 24 Jun 2020 at 07:19, Chris Wilson
> >> wrote:
> >>> Quoting Dave Airlie (2020-06-23 22:01:24)
> On Tue, 23 Jun 2020 at 20:03, Chris Wilson
Am 25.06.20 um 14:48 schrieb Chris Wilson:
Quoting Christian König (2020-06-25 09:11:35)
Am 24.06.20 um 22:18 schrieb Chris Wilson:
Quoting Dave Airlie (2020-06-24 20:04:02)
On Wed, 24 Jun 2020 at 07:19, Chris Wilson wrote:
Quoting Dave Airlie (2020-06-23 22:01:24)
On Tue, 23 Jun 2020 at
From: Joerg Roedel
Remove the use of dev->archdata.iommu_domain and use the private
per-device pointer provided by IOMMU core code instead.
Signed-off-by: Joerg Roedel
---
drivers/iommu/fsl_pamu_domain.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
From: Joerg Roedel
Remove the use of dev->archdata.iommu and use the private per-device
pointer provided by IOMMU core code instead.
Signed-off-by: Joerg Roedel
---
drivers/iommu/exynos-iommu.c | 20 +--
.../media/platform/s5p-mfc/s5p_mfc_iommu.h| 4 +++-
From: Joerg Roedel
Remove the use of dev->archdata.iommu and use the private per-device
pointer provided by IOMMU core code instead.
Signed-off-by: Joerg Roedel
---
drivers/iommu/omap-iommu.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git
From: Joerg Roedel
There are no users left, all drivers have been converted to use the
per-device private pointer offered by IOMMU core.
Signed-off-by: Joerg Roedel
---
arch/arm64/include/asm/device.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm64/include/asm/device.h
From: Joerg Roedel
Hi,
here is a patch-set to remove the usage of dev->archdata.iommu from
the IOMMU code in the kernel and replace its uses by the iommu per-device
private data field. The changes also remove the field entirely from
the architectures which no longer need it.
On PowerPC the
From: Joerg Roedel
There are no users left, all drivers have been converted to use the
per-device private pointer offered by IOMMU core.
Signed-off-by: Joerg Roedel
---
arch/arm/include/asm/device.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/include/asm/device.h
From: Joerg Roedel
Remove the use of dev->archdata.iommu and use the private per-device
pointer provided by IOMMU core code instead.
Signed-off-by: Joerg Roedel
---
drivers/iommu/tegra-gart.c | 8
drivers/iommu/tegra-smmu.c | 8
2 files changed, 8 insertions(+), 8
From: Joerg Roedel
Remove the use of dev->archdata.iommu and use the private per-device
pointer provided by IOMMU core code instead.
Signed-off-by: Joerg Roedel
---
drivers/iommu/msm_iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/msm_iommu.c
From: Joerg Roedel
There are no users left, all drivers have been converted to use the
per-device private pointer offered by IOMMU core.
Signed-off-by: Joerg Roedel
---
arch/ia64/include/asm/device.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/ia64/include/asm/device.h
From: Joerg Roedel
There are no users left, so remove the pointer and save some memory.
Signed-off-by: Joerg Roedel
---
arch/powerpc/include/asm/device.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/powerpc/include/asm/device.h
b/arch/powerpc/include/asm/device.h
index
From: Joerg Roedel
Remove the use of dev->archdata.iommu and use the private per-device
pointer provided by IOMMU core code instead.
Signed-off-by: Joerg Roedel
---
drivers/iommu/rockchip-iommu.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
From: Joerg Roedel
The iommu private pointer is already used in the Mediatek IOMMU v1
driver, so move the dma_iommu_mapping pointer into 'struct
mtk_iommu_data' and do not use dev->archdata.iommu anymore.
Signed-off-by: Joerg Roedel
---
drivers/iommu/mtk_iommu.h| 2 ++
From: Joerg Roedel
There are no users left, all drivers have been converted to use the
per-device private pointer offered by IOMMU core.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/device.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/x86/include/asm/device.h
From: Joerg Roedel
Remove the use of dev->archdata.iommu and use the private per-device
pointer provided by IOMMU core code instead.
Signed-off-by: Joerg Roedel
---
.../gpu/drm/i915/selftests/mock_gem_device.c | 10 --
drivers/iommu/intel/iommu.c| 18
Quoting Lionel Landwerlin (2020-06-25 13:34:43)
> There was probably a misunderstand on how the dma-fence-chain is
> supposed to work or what dma_fence_chain_find_seqno() is supposed to
> return.
>
> dma_fence_chain_find_seqno() is here to give us the fence to wait upon
> for a particular point
There was probably a misunderstand on how the dma-fence-chain is
supposed to work or what dma_fence_chain_find_seqno() is supposed to
return.
dma_fence_chain_find_seqno() is here to give us the fence to wait upon
for a particular point in the timeline. The timeline progresses only
when all the
This reverts commit 5de376bb434f80a13138f0ebedc8351ab73d8b0d.
This change breaks synchronization of a timeline.
dma_fence_chain_find_seqno() might be a bit of a confusing name but
this function is not trying to find a particular seqno, is supposed to
give a fence to wait on for a particular point
Am 25.06.20 um 14:34 schrieb Lionel Landwerlin:
This reverts commit 5de376bb434f80a13138f0ebedc8351ab73d8b0d.
This change breaks synchronization of a timeline.
dma_fence_chain_find_seqno() might be a bit of a confusing name but
this function is not trying to find a particular seqno, is supposed
Am 25.06.20 um 14:34 schrieb Lionel Landwerlin:
There was probably a misunderstand on how the dma-fence-chain is
supposed to work or what dma_fence_chain_find_seqno() is supposed to
return.
dma_fence_chain_find_seqno() is here to give us the fence to wait upon
for a particular point in the
Hi Dave and Daniel,
there's the PR for the current patches in drm-misc-fixes. Besides the fixes
there's also a merge of v.5.8-rc1.
Best regards
Thomas
drm-misc-fixes-2020-06-25:
Short summary of fixes pull (less than what git shortlog provides):
* In mcde, set up fbdev after device
Quoting Michal Hocko (2020-06-25 08:57:25)
> On Wed 24-06-20 20:14:17, Chris Wilson wrote:
> > A general rule of thumb is that shrinkers should be fast and effective.
> > They are called from direct reclaim at the most incovenient of times when
> > the caller is waiting for a page. If we attempt
On Wed 24-06-20 17:11:30, John Hubbard wrote:
> On 2020-06-24 16:20, Jason Gunthorpe wrote:
> > > I do like this code change, though. And I *think* it's actually safe to
> > > do this, as it stays away from writeback or other filesystem activity.
> > > But let me double check that, in case I'm
On Wed, Jun 24, 2020 at 08:14:17PM +0100, Chris Wilson wrote:
> A side effect of the LRU shrinker not being dma aware is that we will
> often attempt to perform direct reclaim on the persistent group of dma
> pages while continuing to use the dma HW (an issue as the HW may already
> be actively
Quoting Christian König (2020-06-25 13:59:16)
> Am 25.06.20 um 14:48 schrieb Chris Wilson:
> > Quoting Christian König (2020-06-25 09:11:35)
> >> Am 24.06.20 um 22:18 schrieb Chris Wilson:
> >>> Quoting Dave Airlie (2020-06-24 20:04:02)
> On Wed, 24 Jun 2020 at 07:19, Chris Wilson
>
On 25/06/2020 16:18, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-06-25 13:34:43)
There was probably a misunderstand on how the dma-fence-chain is
supposed to work or what dma_fence_chain_find_seqno() is supposed to
return.
dma_fence_chain_find_seqno() is here to give us the fence to
Hi Joerg,
On 2020/6/25 21:08, Joerg Roedel wrote:
From: Joerg Roedel
Remove the use of dev->archdata.iommu and use the private per-device
pointer provided by IOMMU core code instead.
Signed-off-by: Joerg Roedel
---
.../gpu/drm/i915/selftests/mock_gem_device.c | 10 --
On Thu 25-06-20 12:42:09, Matthew Wilcox wrote:
> On Wed, Jun 24, 2020 at 08:14:17PM +0100, Chris Wilson wrote:
> > A side effect of the LRU shrinker not being dma aware is that we will
> > often attempt to perform direct reclaim on the persistent group of dma
> > pages while continuing to use the
Quoting Lionel Landwerlin (2020-06-25 14:23:25)
> On 25/06/2020 16:18, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2020-06-25 13:34:43)
> >> There was probably a misunderstand on how the dma-fence-chain is
> >> supposed to work or what dma_fence_chain_find_seqno() is supposed to
> >>
On 25/06/2020 16:47, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-06-25 14:23:25)
On 25/06/2020 16:18, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-06-25 13:34:43)
There was probably a misunderstand on how the dma-fence-chain is
supposed to work or what
On Thu, Jun 25, 2020 at 3:23 PM Lionel Landwerlin
wrote:
>
> On 25/06/2020 16:18, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2020-06-25 13:34:43)
> >> There was probably a misunderstand on how the dma-fence-chain is
> >> supposed to work or what dma_fence_chain_find_seqno() is supposed to
91 matches
Mail list logo
