'6cba3fe43341 ("drm/dp: Add backpointer to drm_device in drm_dp_aux")'
introduced a mandator drm_device backpointer in struct drm_dp_aux, but
missed the msm DP driver. Fix this.
Fixes: 6cba3fe43341 ("drm/dp: Add backpointer to drm_device in drm_dp_aux")
Signed-off-by: Bjorn Andersson
---
Hi Dmitry,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on next-20210624]
[also build test WARNING on v5.13-rc7]
[cannot apply to linus/master v5.13-rc7 v5.13-rc6 v5.13-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
On Thu 10 Jun 16:44 CDT 2021, Rob Clark wrote:
[..]
> diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
> index 50d881794758..6975b95c3c29 100644
> --- a/drivers/gpu/drm/msm/msm_iommu.c
> +++ b/drivers/gpu/drm/msm/msm_iommu.c
> @@ -211,8 +211,17 @@ static int
kmalloc_array + __GFP_ZERO is the same with kvcalloc.
Signed-off-by: huqiqiao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index
malloc_array + __GFP_ZERO is the same with kvcalloc.
Signed-off-by: huqiqiao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index
On 2021/06/23 20:41, Pekka Paalanen wrote:
> On Wed, 23 Jun 2021 18:22:47 +0900
> Esaki Tomohito wrote:
>
>> On 2021/06/23 17:39, Pekka Paalanen wrote:
>>> On Wed, 23 Jun 2021 15:56:05 +0900
>>> Esaki Tomohito wrote:
>>>
Hi,
Thank you all for your comments.
On
OK, I'll revise it and submit it againGeorge.
From: "Christian König "To: "huqiqiao ","airlied ","daniel "CC: "dri-devel ","amd-gfx ","linux-kernel "Sent: 2021-06-24 21:14Subject: Re: [PATCH] drm/amdgpu:use kvcalloc instead of kvmalloc_array
Am 23.06.21 um 11:12 schrieb huqiqiao: >
On Thu, Jun 24, 2021 at 12:05:13AM -0700, Matthew Brost wrote:
> From: John Harrison
>
> Changing the reset module parameter has no effect on a running GuC.
> The corresponding entry in the ADS must be updated and then the GuC
> informed via a Host2GuC message.
>
> The new debugfs interface to
On Thu, Jun 24, 2021 at 12:05:12AM -0700, Matthew Brost wrote:
> From: John Harrison
>
> Use the official driver default scheduling policies for configuring
> the GuC scheduler rather than a bunch of hardcoded values.
>
> Signed-off-by: John Harrison
> Signed-off-by: Matthew Brost
> Cc: Jose
On Fri, Jun 25, 2021 at 3:20 AM Konrad Rzeszutek Wilk
wrote:
>
> On Thu, Jun 24, 2021 at 11:55:14PM +0800, Claire Chang wrote:
> > This series implements mitigations for lack of DMA access control on
> > systems without an IOMMU, which could result in the DMA accessing the
> > system memory at
Excerpts from Paolo Bonzini's message of June 25, 2021 1:35 am:
> On 24/06/21 14:57, Nicholas Piggin wrote:
>> KVM: Fix page ref underflow for regions with valid but non-refcounted pages
>
> It doesn't really fix the underflow, it disallows mapping them in the
> first place. Since in principle
On Thu, Jun 24, 2021 at 07:37:01PM +0200, Michal Wajdeczko wrote:
>
>
> On 24.06.2021 09:04, Matthew Brost wrote:
> > Implement a stall timer which fails H2G CTBs once a period of time
> > with no forward progress is reached to prevent deadlock.
> >
> > Also update to ct_write to return -EIO
On Thu, Jun 24, 2021 at 07:02:18PM +0200, Michal Wajdeczko wrote:
>
>
> On 24.06.2021 17:49, Matthew Brost wrote:
> > On Thu, Jun 24, 2021 at 04:48:32PM +0200, Michal Wajdeczko wrote:
> >>
> >>
> >> On 24.06.2021 09:04, Matthew Brost wrote:
> >>> Add non blocking CTB send function,
https://bugzilla.kernel.org/show_bug.cgi?id=213561
Linux_Chemist (untaintablean...@hotmail.co.uk) changed:
What|Removed |Added
Status|NEW |RESOLVED
On Thu, Jun 24, 2021 at 07:02:18PM +0200, Michal Wajdeczko wrote:
>
>
> On 24.06.2021 17:49, Matthew Brost wrote:
> > On Thu, Jun 24, 2021 at 04:48:32PM +0200, Michal Wajdeczko wrote:
> >>
> >>
> >> On 24.06.2021 09:04, Matthew Brost wrote:
> >>> Add non blocking CTB send function,
This adds a driver for panels based on the WideChips WS2401 display
controller. This display controller is used in the Samsung LMS380KF01
display found in the Samsung GT-I8160 (Codina) mobile phone and
possibly others.
As is common with Samsung displays manufacturer commands are necessary
to
This adds device tree bindings for the Samsung Mobile Displays
LMS380KF01 RGB DPI display panel.
Cc: devicet...@vger.kernel.org
Cc: phone-de...@vger.kernel.org
Cc: Douglas Anderson
Cc: Noralf Trønnes
Signed-off-by: Linus Walleij
---
.../display/panel/samsung,lms380kf01.yaml | 96
https://bugzilla.kernel.org/show_bug.cgi?id=213561
Alan Swanson (rei...@improbability.net) changed:
What|Removed |Added
CC|
On Thu, Jun 17, 2021 at 10:43:34AM -0400, Jonathan Marek wrote:
> Document a new phy-type property which will be used to determine whether
> the phy should operate in D-PHY or C-PHY mode.
>
> Signed-off-by: Jonathan Marek
> Reviewed-by: Laurent Pinchart
> ---
>
On Thu, Jun 24, 2021 at 11:00 PM Emma Anholt wrote:
>
> On Thu, Jun 24, 2021 at 1:45 PM Daniel Vetter wrote:
> >
> > This is a very confusingly named function, because not just does it
> > init an object, it arms it and provides a point of no return for
> > pushing a job into the scheduler. It
https://bugzilla.kernel.org/show_bug.cgi?id=212107
miloog (mileikas...@mailbox.org) changed:
What|Removed |Added
CC|
On Thu, Jun 24, 2021 at 1:45 PM Daniel Vetter wrote:
>
> This is a very confusingly named function, because not just does it
> init an object, it arms it and provides a point of no return for
> pushing a job into the scheduler. It would be nice if that's a bit
> clearer in the interface.
>
> But
https://bugzilla.kernel.org/show_bug.cgi?id=213569
miloog (mileikas...@mailbox.org) changed:
What|Removed |Added
CC|
On Tue, Jun 15, 2021 at 08:33:12PM +1000, Alistair Francis wrote:
> Add support for the 10.3" E Ink panel described at:
> https://www.eink.com/product.html?type=productdetail=7
>
> Signed-off-by: Alistair Francis
> ---
> v2:
> - Fix build warning
> - Document new string
>
>
On Thu, Jun 24, 2021 at 1:45 PM Daniel Vetter wrote:
>
> Prep work for using the scheduler dependency handling. We need to call
> drm_sched_job_init earlier so we can use the new drm_sched_job_await*
> functions for dependency handling here.
>
> v2: Slightly better commit message and rebase to
This is a very confusingly named function, because not just does it
init an object, it arms it and provides a point of no return for
pushing a job into the scheduler. It would be nice if that's a bit
clearer in the interface.
But the real reason is that I want to push the dependency tracking
Prep work for using the scheduler dependency handling. We need to call
drm_sched_job_init earlier so we can use the new drm_sched_job_await*
functions for dependency handling here.
v2: Slightly better commit message and rebase to include the
drm_sched_job_arm() call (Emma).
Signed-off-by: Daniel
The pull request you sent on Fri, 25 Jun 2021 06:17:22 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-06-25
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/44db63d1ad8d71c6932cbe007eb41f31c434d140
Thank you!
--
Deet-doot-dot, I am a bot.
Hi Linus,
This is a bit bigger than I'd like at this stage, and I guess last
week was extra quiet, but it's mostly one fix across 3 drivers to wait
for buffer move pinning to complete. There was one locking change that
got reverted so it's just noise. Otherwise the amdgpu/nouveau changes
are for
Hi Lee,
On Tue, Jun 22, 2021 at 02:12:57PM +0100, Lee Jones wrote:
> On Mon, 21 Jun 2021, Uwe Kleine-König wrote:
>
> > The practical upside here is that this only needs a single API call to
> > program the hardware which (depending on the underlaying hardware) can
> > be more effective and
I don't have drm-misc access. Mind pushing?
On Thu, Jun 24, 2021 at 12:59 PM Christian König
wrote:
>
> Am 24.06.21 um 19:47 schrieb Jason Ekstrand:
> > Each add_fence() call does a dma_fence_get() on the relevant fence. In
> > the error path, we weren't calling dma_fence_put() so all those
The buffer object argument to ttm_move_memcpy was only used to
determine whether the destination memory should be cleared only
or whether we should copy data. Replace it with a "clear" bool, and
update the callers.
The intention here is to be able to use ttm_move_memcpy() async under
a dma-fence
In order to make the code a bit more readable and to facilitate
async memcpy moves, reorganize the move code a little. Determine
at an early stage whether to copy or to clear.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 70 ++---
1 file
The ttm_move_memcpy() function was intended to be able to be used async
under a fence.
We are going to utilize that as a fallback if the gpu clearing blit fails
before we set up CPU- or GPU ptes to the memory region.
But to accomplish that the bo argument to ttm_move_memcpy() needs to be
replaced.
Hi Laurent,
On Wed, Jun 23, 2021 at 04:56:37PM +0300, Laurent Pinchart wrote:
> Hello,
>
> This patch series adds a driver for the DSI encoder found in the R-Car
> V3U SoC, which is the first SoC in the family that supports DSI.
>
> The driver is based on an implementation from the BSP written
On Thu, Jun 24, 2021 at 11:58:57PM +0800, Claire Chang wrote:
> On Thu, Jun 24, 2021 at 11:56 PM Konrad Rzeszutek Wilk
> wrote:
> >
> > On Thu, Jun 24, 2021 at 10:10:51AM -0400, Qian Cai wrote:
> > >
> > >
> > > On 6/24/2021 7:48 AM, Will Deacon wrote:
> > > > Ok, diff below which attempts to
On Thu, Jun 24, 2021 at 11:55:14PM +0800, Claire Chang wrote:
> This series implements mitigations for lack of DMA access control on
> systems without an IOMMU, which could result in the DMA accessing the
> system memory at unexpected times and/or unexpected addresses, possibly
> leading to data
Hi Dave, Daniel,
Here's this week drm-misc-fixes PR
Thanks!
Maxime
drm-misc-fixes-2021-06-24:
A DMA address check for nouveau, an error code return fix for kmb, fixes
to wait for a moving fence after pinning the BO for amdgpu, nouveau and
radeon, a crtc and async page flip fix for atmel-hlcdc
Excerpts from Paolo Bonzini's message of June 24, 2021 7:42 pm:
> On 24/06/21 10:52, Nicholas Piggin wrote:
>>> For now, wrap all calls to gfn_to_pfn functions in the new helper
>>> function. Callers which don't need the page struct will be updated in
>>> follow-up patches.
>> Hmm. You mean
Excerpts from Paolo Bonzini's message of June 24, 2021 8:21 pm:
> On 24/06/21 12:17, Nicholas Piggin wrote:
>>> If all callers were updated that is one thing, but from the changelog
>>> it sounds like that would not happen and there would be some gfn_to_pfn
>>> users left over.
>>>
>>> But yes in
On Thu, Jun 24, 2021 at 7:00 AM Daniel Vetter wrote:
>
> Prep work for using the scheduler dependency handling.
>
> Signed-off-by: Daniel Vetter
> Cc: Emma Anholt
Back when I wrote this, I think there were rules that there had to be
no failure paths between a job_init and a push. Has that
From: Jonas Karlman
Rockchip VDPU2 core is present on RK3328, RK3326/PX30, RK3399
and others. It's similar to Hantro G1, but it's not compatible with it.
Signed-off-by: Jonas Karlman
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/hantro/Makefile | 1 +
The hantro_variant.init() function is there for platforms
to perform hardware-specific initialization, such as
clock rate bumping.
Not all platforms require it, so make it optional.
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/hantro/hantro.h | 4 ++--
Excerpts from Paolo Bonzini's message of June 24, 2021 10:41 pm:
> On 24/06/21 13:42, Nicholas Piggin wrote:
>> Excerpts from Nicholas Piggin's message of June 24, 2021 8:34 pm:
>>> Excerpts from David Stevens's message of June 24, 2021 1:57 pm:
KVM supports mapping VM_IO and VM_PFNMAP memory
Given H.264 support for VDPU2 was just added, let's enable it.
For now, this is only enabled on platform that don't have
an RKVDEC core, such as RK3328.
Signed-off-by: Ezequiel Garcia
---
.../staging/media/hantro/rockchip_vpu_hw.c| 26 ++-
1 file changed, 25 insertions(+), 1
Excerpts from David Stevens's message of June 24, 2021 1:57 pm:
> From: David Stevens
> out_unlock:
> if (is_tdp_mmu_root(vcpu->kvm, vcpu->arch.mmu->root_hpa))
> read_unlock(>kvm->mmu_lock);
> else
> write_unlock(>kvm->mmu_lock);
> -
Add a hantro_h264_get_ref_nbr() helper function to get the reference
picture numbers. This will be used by the Rockchip VDPU2 H.264 driver.
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/hantro/hantro_g1_h264_dec.c | 14 ++
drivers/staging/media/hantro/hantro_h264.c
From: Paul Kocialkowski
The Rockchip PX30 SoC has a Hantro VPU that features a decoder (VDPU2)
and an encoder (VEPU2).
Signed-off-by: Paul Kocialkowski
Signed-off-by: Ezequiel Garcia
---
Documentation/devicetree/bindings/media/rockchip-vpu.yaml | 3 +++
1 file changed, 3 insertions(+)
diff
Excerpts from Nicholas Piggin's message of June 24, 2021 7:57 pm:
> Excerpts from Paolo Bonzini's message of June 24, 2021 7:42 pm:
>> On 24/06/21 10:52, Nicholas Piggin wrote:
For now, wrap all calls to gfn_to_pfn functions in the new helper
function. Callers which don't need the page
From: Paul Kocialkowski
The PX30 has a VPU (both decoder and encoder) with a dedicated IOMMU.
Describe these two entities in device-tree.
Signed-off-by: Paul Kocialkowski
Signed-off-by: Ezequiel Garcia
---
arch/arm64/boot/dts/rockchip/px30.dtsi | 23 +++
1 file changed,
The Odroid Go Advance panel is rotated, so let's reflect this
in the device tree.
Signed-off-by: Ezequiel Garcia
---
arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts
Excerpts from David Stevens's message of June 24, 2021 1:57 pm:
> From: David Stevens
Changelog? This looks like a bug, should it have a Fixes: tag?
Thanks,
Nick
>
> Signed-off-by: David Stevens
> ---
> arch/x86/kvm/mmu/mmu_audit.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git
On Thu, 2021-06-24 at 20:37 +0200, Heiko Stübner wrote:
> Am Donnerstag, 24. Juni 2021, 20:26:02 CEST schrieb Ezequiel Garcia:
> > The Odroid Go Advance panel is rotated, so let's reflect this
> > in the device tree.
> >
> > Signed-off-by: Ezequiel Garcia
>
> similar patch already applied for
Getting the next src/dst buffer is relatively expensive
so avoid doing it multiple times.
Signed-off-by: Ezequiel Garcia
---
.../staging/media/hantro/hantro_g1_h264_dec.c | 17 -
.../staging/media/hantro/hantro_g1_vp8_dec.c | 18 +-
From: Paul Kocialkowski
The PX30 SoC includes both the VDPU2 and VEPU2 blocks which are similar
to the RK3399 (Hantro G1/H1 with shuffled registers).
Signed-off-by: Paul Kocialkowski
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/hantro/hantro_drv.c | 1 +
Excerpts from David Stevens's message of June 24, 2021 1:57 pm:
> From: David Stevens
>
> Return a struct kvm_pfn_page containing both a pfn and an optional
> struct page from the gfn_to_pfn family of functions. This differentiates
> the gup and follow_fault_pfn cases, which allows callers that
In order to reuse these bitmaps, move this process to
struct hantro_h264_dec_hw_ctx. This will be used by
the Rockchip VDPU2 H.264 driver.
Signed-off-by: Ezequiel Garcia
---
.../staging/media/hantro/hantro_g1_h264_dec.c | 17 ++---
drivers/staging/media/hantro/hantro_h264.c |
Excerpts from David Stevens's message of June 24, 2021 1:57 pm:
> KVM supports mapping VM_IO and VM_PFNMAP memory into the guest by using
> follow_pte in gfn_to_pfn. However, the resolved pfns may not have
> assoicated struct pages, so they should not be passed to pfn_to_page.
> This series
Excerpts from Nicholas Piggin's message of June 24, 2021 8:34 pm:
> Excerpts from David Stevens's message of June 24, 2021 1:57 pm:
>> KVM supports mapping VM_IO and VM_PFNMAP memory into the guest by using
>> follow_pte in gfn_to_pfn. However, the resolved pfns may not have
>> assoicated struct
When the VP8 decoders can't find a reference frame,
the driver falls back to the current output frame.
This will probably produce some undesirable results,
leading to frame corruption, but shouldn't cause
noisy warnings.
Signed-off-by: Ezequiel Garcia
Acked-by: Nicolas Dufresne
---
Parse the device tree rotation specifier, and set a DRM
connector orientation property. The property can then be read
by compositors to apply hardware plane rotation or a GPU transform.
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/panel/panel-elida-kd35t133.c | 8
1 file changed,
This series adds support for H.264 decoding on the PX30, RK3328
and RK3326 platforms, enabling the VDPU2 core.
Given it's tested on the Odroid Advance Go, patches 1 and 2
add the basic support to report the panel orientation to
userspace (Heiko, if you like them, feel free to pick them).
Weston
Excerpts from Marc Zyngier's message of June 24, 2021 8:06 pm:
> On Thu, 24 Jun 2021 09:58:00 +0100,
> Nicholas Piggin wrote:
>>
>> Excerpts from David Stevens's message of June 24, 2021 1:57 pm:
>> > From: David Stevens
>> > out_unlock:
>> >if (is_tdp_mmu_root(vcpu->kvm,
Am Donnerstag, 24. Juni 2021, 20:26:02 CEST schrieb Ezequiel Garcia:
> The Odroid Go Advance panel is rotated, so let's reflect this
> in the device tree.
>
> Signed-off-by: Ezequiel Garcia
similar patch already applied for 5.14:
Am Donnerstag, 24. Juni 2021, 20:26:01 CEST schrieb Ezequiel Garcia:
> Parse the device tree rotation specifier, and set a DRM
> connector orientation property. The property can then be read
> by compositors to apply hardware plane rotation or a GPU transform.
>
> Signed-off-by: Ezequiel Garcia
Until we support p2p dma or as a complement to that, migrate data
to system memory at dma-buf map time if possible.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git
Objects intended to be used as display framebuffers must reside in
LMEM for discrete. If they happen to not do that, migrate them to
LMEM before pinning.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/display/intel_display.c | 5 -
drivers/gpu/drm/i915/gem/i915_gem_domain.c |
From: Matthew Auld
A selftest for the gem object migrate functionality. Slightly adapted
from the original by Matthew to the new interface and new fill blit
code.
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
Signed-off-by: Matthew Auld
---
Introduce an interface to migrate objects between regions.
This is primarily intended to migrate objects to LMEM for display and
to SYSTEM for dma-buf, but might be reused in one form or another for
performande-based migration.
Signed-off-by: Thomas Hellström
---
We want to be able to explicitly migrate objects between gem memory
regions, initially for display and dma-buf, but there might be more
use-cases coming up.
Introduce a gem migrate interface, add a selftest and use it for
display fb pinning and dma-buf mapping.
This series should make the
On Thu, Jun 24, 2021 at 7:39 PM Christian König
wrote:
>
>
>
> Am 24.06.21 um 19:37 schrieb Daniel Vetter:
> > On Thu, Jun 24, 2021 at 7:30 PM Christian König
> > wrote:
> >> Am 24.06.21 um 16:00 schrieb Daniel Vetter:
> >>> This is a very confusingly named function, because not just does it
>
On Thu, Jun 24, 2021 at 7:56 PM Christian König
wrote:
>
> Am 24.06.21 um 19:43 schrieb Daniel Vetter:
> > On Thu, Jun 24, 2021 at 7:38 PM Christian König
> > wrote:
> >> Am 24.06.21 um 19:29 schrieb Daniel Vetter:
> >>> On Thu, Jun 24, 2021 at 07:03:10PM +0200, Christian König wrote:
> Am
https://bugzilla.kernel.org/show_bug.cgi?id=213561
--- Comment #8 from hagar-du...@wanadoo.fr ---
Thanks for pointing to a different commit. I don't really have the time
currently to revert a specific commit to try it out, pointing out the problem
happening between two consecutive kernel versions
Am 24.06.21 um 19:47 schrieb Jason Ekstrand:
Each add_fence() call does a dma_fence_get() on the relevant fence. In
the error path, we weren't calling dma_fence_put() so all those fences
got leaked. Also, in the krealloc_array failure case, we weren't
freeing the fences array. Instead, ensure
Am 24.06.21 um 19:43 schrieb Daniel Vetter:
On Thu, Jun 24, 2021 at 7:38 PM Christian König
wrote:
Am 24.06.21 um 19:29 schrieb Daniel Vetter:
On Thu, Jun 24, 2021 at 07:03:10PM +0200, Christian König wrote:
Am 24.06.21 um 16:00 schrieb Daniel Vetter:
This is essentially part of
Each add_fence() call does a dma_fence_get() on the relevant fence. In
the error path, we weren't calling dma_fence_put() so all those fences
got leaked. Also, in the krealloc_array failure case, we weren't
freeing the fences array. Instead, ensure that i and fences are always
zero-initialized
On Thu, Jun 24, 2021 at 7:38 PM Christian König
wrote:
>
> Am 24.06.21 um 19:29 schrieb Daniel Vetter:
> > On Thu, Jun 24, 2021 at 07:03:10PM +0200, Christian König wrote:
> >> Am 24.06.21 um 16:00 schrieb Daniel Vetter:
> >>> This is essentially part of drm_sched_dependency_optimized(), which
>
Am 24.06.21 um 19:37 schrieb Daniel Vetter:
On Thu, Jun 24, 2021 at 7:30 PM Christian König
wrote:
Am 24.06.21 um 16:00 schrieb Daniel Vetter:
This is a very confusingly named function, because not just does it
init an object, it arms it and provides a point of no return for
pushing a job
Am 24.06.21 um 19:29 schrieb Daniel Vetter:
On Thu, Jun 24, 2021 at 07:03:10PM +0200, Christian König wrote:
Am 24.06.21 um 16:00 schrieb Daniel Vetter:
This is essentially part of drm_sched_dependency_optimized(), which
only amdgpu seems to make use of. Use it a bit more.
Signed-off-by:
On Thu, Jun 24, 2021 at 7:30 PM Christian König
wrote:
>
> Am 24.06.21 um 16:00 schrieb Daniel Vetter:
> > This is a very confusingly named function, because not just does it
> > init an object, it arms it and provides a point of no return for
> > pushing a job into the scheduler. It would be
On 24.06.2021 09:04, Matthew Brost wrote:
> Implement a stall timer which fails H2G CTBs once a period of time
> with no forward progress is reached to prevent deadlock.
>
> Also update to ct_write to return -EIO rather than -EPIPE on a
> corrupted descriptor.
by doing so you will have the
Am 24.06.21 um 16:00 schrieb Daniel Vetter:
This is a very confusingly named function, because not just does it
init an object, it arms it and provides a point of no return for
pushing a job into the scheduler. It would be nice if that's a bit
clearer in the interface.
We originally had that
On Thu, Jun 24, 2021 at 07:03:10PM +0200, Christian König wrote:
> Am 24.06.21 um 16:00 schrieb Daniel Vetter:
> > This is essentially part of drm_sched_dependency_optimized(), which
> > only amdgpu seems to make use of. Use it a bit more.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: "Christian
On Thu, Jun 24, 2021 at 09:38:33AM -0700, Matthew Brost wrote:
> On Thu, Jun 10, 2021 at 05:27:48PM +0200, Daniel Vetter wrote:
> > On Wed, Jun 09, 2021 at 04:10:23PM -0700, Matthew Brost wrote:
> > > On Tue, Jun 08, 2021 at 10:46:15AM +0200, Daniel Vetter wrote:
> > > > On Tue, Jun 8, 2021 at
On Thu, Jun 24, 2021 at 09:59:08AM -0700, Emma Anholt wrote:
> On Thu, Jun 24, 2021 at 7:00 AM Daniel Vetter wrote:
> >
> > Prep work for using the scheduler dependency handling.
I'll add "We need to call drm_sched_job_init earlier so we can use the new
drm_sched_job_await* functions for
On 24.06.2021 09:04, Matthew Brost wrote:
> In upcoming patch we will allow more CTB requests to be sent in
> parallel to the GuC for processing, so we shouldn't assume any more
> that GuC will always reply without 10ms.
>
> Use bigger value hardcoded value of 1s instead.
>
> v2: Add
Am 24.06.21 um 16:00 schrieb Daniel Vetter:
This is essentially part of drm_sched_dependency_optimized(), which
only amdgpu seems to make use of. Use it a bit more.
Signed-off-by: Daniel Vetter
Cc: "Christian König"
Cc: Daniel Vetter
Cc: Luben Tuikov
Cc: Andrey Grodzovsky
Cc: Alex Deucher
On 24.06.2021 17:49, Matthew Brost wrote:
> On Thu, Jun 24, 2021 at 04:48:32PM +0200, Michal Wajdeczko wrote:
>>
>>
>> On 24.06.2021 09:04, Matthew Brost wrote:
>>> Add non blocking CTB send function, intel_guc_send_nb. GuC submission
>>> will send CTBs in the critical path and does not need to
Am 24.06.21 um 16:39 schrieb Lucas Stach:
Am Donnerstag, dem 24.06.2021 um 16:00 +0200 schrieb Daniel Vetter:
Instead of just a callback we can just glue in the gem helpers that
panfrost, v3d and lima currently use. There's really not that many
ways to skin this cat.
On the naming bikeshed:
On Thu, Jun 10, 2021 at 05:27:48PM +0200, Daniel Vetter wrote:
> On Wed, Jun 09, 2021 at 04:10:23PM -0700, Matthew Brost wrote:
> > On Tue, Jun 08, 2021 at 10:46:15AM +0200, Daniel Vetter wrote:
> > > On Tue, Jun 8, 2021 at 10:39 AM Tvrtko Ursulin
> > > wrote:
> > > >
> > > >
> > > > On
On Thu, Jun 24, 2021 at 12:05:14AM -0700, Matthew Brost wrote:
> From: John Harrison
>
> Added the scheduling policy parameters to the 'guc_info' debugfs state
> dump.
>
> Signed-off-by: John Harrison
> Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
> ---
>
On Thu, Jun 24, 2021 at 12:05:09AM -0700, Matthew Brost wrote:
> From: John Harrison
>
> Clear the 'disable resets' flag to allow GuC to reset hung contexts
> (detected via pre-emption timeout).
>
> Signed-off-by: John Harrison
> Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
>
On Thu, Jun 24, 2021 at 11:56 PM Konrad Rzeszutek Wilk
wrote:
>
> On Thu, Jun 24, 2021 at 10:10:51AM -0400, Qian Cai wrote:
> >
> >
> > On 6/24/2021 7:48 AM, Will Deacon wrote:
> > > Ok, diff below which attempts to tackle the offset issue I mentioned as
> > > well. Qian Cai -- please can you try
On Thu, Jun 24, 2021 at 12:05:08AM -0700, Matthew Brost wrote:
> From: John Harrison
>
> It is impossible to seal all race conditions of resets occurring
> concurrent to other operations. At least, not without introducing
> excesive mutex locking. Instead, don't complain if it occurs. In
>
On Thu, Jun 24, 2021 at 04:48:32PM +0200, Michal Wajdeczko wrote:
>
>
> On 24.06.2021 09:04, Matthew Brost wrote:
> > Add non blocking CTB send function, intel_guc_send_nb. GuC submission
> > will send CTBs in the critical path and does not need to wait for these
> > CTBs to complete before
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
---
drivers/of/address.c| 33 +
Introduce the new compatible string, restricted-dma-pool, for restricted
DMA. One can specify the address and length of the restricted DMA memory
region by restricted-dma-pool in the reserved-memory node.
Signed-off-by: Claire Chang
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
---
Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes.
Regardless of swiotlb setting, the restricted DMA pool is preferred if
available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at
Add the functions, swiotlb_{alloc,free} and is_swiotlb_for_alloc to
support the memory allocation from restricted DMA pool.
The restricted DMA pool is preferred if available.
Note that since coherent allocation needs remapping, one must set up
another device coherent pool by shared-dma-pool and
Rename find_slots to swiotlb_find_slots and move the maintenance of
alloc_size to it for better code reusability later.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
---
kernel/dma/swiotlb.c | 17 +
1 file
1 - 100 of 355 matches
Mail list logo
