On Tue, Jul 07, 2020 at 10:12:11PM +0200, Daniel Vetter wrote:
> Like the helpers, nothing special. Well except not, because we the
> critical section extends until after hw_done(), since that's the last
> thing which could hold up a subsequent atomic commit. That means the
> wait_for_flip_done is
== Series Details ==
Series: series starting with [1/2] drm/i915/uc: Extract uc usage details into
separate debugfs
URL : https://patchwork.freedesktop.org/series/79220/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8711_full -> Patchwork_18102_full
== Series Details ==
Series: Move some device capabilities under intel_gt (rev3)
URL : https://patchwork.freedesktop.org/series/78829/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8711 -> Patchwork_18103
Summary
---
== Series Details ==
Series: dma-fence annotations, round 3 (rev2)
URL : https://patchwork.freedesktop.org/series/79212/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8711_full -> Patchwork_18101_full
Summary
---
== Series Details ==
Series: Move some device capabilities under intel_gt (rev3)
URL : https://patchwork.freedesktop.org/series/78829/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
-
== Series Details ==
Series: Move some device capabilities under intel_gt (rev3)
URL : https://patchwork.freedesktop.org/series/78829/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7ed094988586 drm/i915: Convert device_info to uncore/de_read
fdcbfbd417ae drm/i915: Use the gt
== Series Details ==
Series: drm/i915/ehl: Add new PCI ids (rev2)
URL : https://patchwork.freedesktop.org/series/78910/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8711_full -> Patchwork_18100_full
Summary
---
On Tue, 2020-06-16 at 20:31 -0700, Matt Roper wrote:
> After doing normal PHY-B initialization on Rocket Lake, we need to
> manually copy some additional PHY-A register values into PHY-B
> registers.
>
> Note that the bspec's combo phy page doesn't specify that this
> workaround is restricted to
On Tue, 2020-06-16 at 20:31 -0700, Matt Roper wrote:
> After doing normal PHY-B initialization on Rocket Lake, we need to
> manually copy some additional PHY-A register values into PHY-B
> registers.
>
> Note that the bspec's combo phy page doesn't specify that this
> workaround is restricted to
On Tue, 2020-06-16 at 20:30 -0700, Matt Roper wrote:
> RKL and TGL share some general gen12 workarounds, but each platform also
> has its own platform-specific workarounds.
>
> v2:
> - Add Wa_1604555607 for RKL. This makes RKL's ctx WA list identical to
>TGL's, so we'll have both functions
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
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
Reviewed-by: Tvrtko Ursulin
---
On Tue, 2020-06-16 at 20:30 -0700, Matt Roper wrote:
> If HTI (also sometimes called HDPORT) is enabled at startup, it may be
> using some of the PHYs and DPLLs making them unavailable for general
> usage. Let's read out the HDPORT_STATE register and avoid making use of
> resources that HTI is
Ahead of moving the sseu debugfs logic under gt/, update the functions
to use intel_gt where possible to make the move cleaner.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
---
drivers/gpu/drm/i915/i915_debugfs.c | 93 +++--
1 file changed,
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.
v2: clarify comment about forcewake requirements and pruning (Chris)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko
Rebased to the latest tip.
Cc: Tvrtko Ursulin
Cc: Andi Shyti
Cc: Venkata Sandeep Dhanalakota
Daniele Ceraolo Spurio (8):
drm/i915: Convert device_info to uncore/de_read
drm/i915: Use the gt in HAS_ENGINE
drm/i915: Move engine-related mmio init to engines_init_mmio
drm/i915: Move 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
Reviewed-by: Tvrtko Ursulin
---
A follow up patch will move the engine mask under the gt structure,
so get ready for that.
v2: switch the remaining gvt case using dev_priv->gt to gvt->gt (Chris)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
Cc: Chris Wilson
Reviewed-by: Tvrtko Ursulin #v1
---
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
Reviewed-by: Tvrtko Ursulin
---
In line with what happened for other gt-related features, move the sseu
debugfs files under gt/.
The sseu_status debugfs has also been kept at the top level as we do
have tests that use it; it will be removed once we teach the tests to
look into the new path.
Suggested-by: Tvrtko Ursulin
On Tue, 2020-06-16 at 20:30 -0700, Matt Roper wrote:
> RKL uses a slightly different bit layout for the DPCLKA_CFGCR0 register.
>
> v2:
> - Fix inverted mask application when updating ICL_DPCLKA_CFGCR0
> - Checkpatch style fixes
>
Reviewed-by: José Roberto de Souza
> Bspec: 50287
> Cc:
Hi Daniel,
Thank you for the patch.
On Tue, Jul 07, 2020 at 10:12:16PM +0200, Daniel Vetter wrote:
> Ends right after drm_atomic_helper_commit_hw_done(), absolutely
> nothing fancy going on here.
Just looking at this patch and the commit message, I have no idea what
this does, and why. It would
On Tue, May 26, 2020 at 02:23:10PM -0400, Lyude Paul wrote:
> From: Lee Shawn C
>
> So far, max dot clock rate for MST mode rely on physcial
> bandwidth limitation. It would caused compatibility issue
> if source display resolution exceed MST hub output ability.
>
> For example, source DUT had
On 7/7/2020 2:52 PM, Michał Winiarski wrote:
From: Michał Winiarski
Firmware "Selected" state is a transient state - we don't expect to see
it after finishing driver probe, we even have asserts sprinkled over
i915 to confirm whether that's the case.
Unfortunately - we don't handle the
== Series Details ==
Series: series starting with [1/2] drm/i915/uc: Extract uc usage details into
separate debugfs
URL : https://patchwork.freedesktop.org/series/79220/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8711 -> Patchwork_18102
On 7/7/2020 2:52 PM, Michał Winiarski wrote:
From: Michał Winiarski
It has been pointed out that information about HuC usage doesn't belong
in guc_info debugfs. Let's move "supported/used/wanted" matrix to a
separate debugfs file, keeping guc_info strictly about GuC.
Suggested-by: Daniele
== Series Details ==
Series: dma-fence annotations, round 3 (rev2)
URL : https://patchwork.freedesktop.org/series/79212/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8711 -> Patchwork_18101
Summary
---
**SUCCESS**
== Series Details ==
Series: drm/i915/display: Fix initial fb to use resource_size_t (rev2)
URL : https://patchwork.freedesktop.org/series/79205/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8710_full -> Patchwork_18098_full
== Series Details ==
Series: dma-fence annotations, round 3 (rev2)
URL : https://patchwork.freedesktop.org/series/79212/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: dma-fence annotations, round 3 (rev2)
URL : https://patchwork.freedesktop.org/series/79212/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2ef2cbad3c3f dma-fence: basic lockdep annotations
-:23: ERROR:GIT_COMMIT_ID: Please use git commit description
On Tue, Jul 07, 2020 at 01:45:30PM -0700, José Roberto de Souza wrote:
> Two new PCI ids added to ehl.
>
> v2: added two additional PCI ids
>
> BSpec: 29153
> Cc: Matt Roper
> Cc: Anusha Srivatsa
> Signed-off-by: José Roberto de Souza
Reviewed-by: Matt Roper
> ---
>
== Series Details ==
Series: drm/i915/display: Fix initial fb to use resource_size_t
URL : https://patchwork.freedesktop.org/series/79205/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8710_full -> Patchwork_18097_full
== Series Details ==
Series: drm/i915/ehl: Add new PCI ids (rev2)
URL : https://patchwork.freedesktop.org/series/78910/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8711 -> Patchwork_18100
Summary
---
**SUCCESS**
== Series Details ==
Series: drm/i915/gem: Unpin idle contexts from kswapd reclaim
URL : https://patchwork.freedesktop.org/series/79204/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8710_full -> Patchwork_18096_full
From: Michał Winiarski
Firmware "Selected" state is a transient state - we don't expect to see
it after finishing driver probe, we even have asserts sprinkled over
i915 to confirm whether that's the case.
Unfortunately - we don't handle the transition out of "Selected" in case
of GuC fetch
From: Michał Winiarski
It has been pointed out that information about HuC usage doesn't belong
in guc_info debugfs. Let's move "supported/used/wanted" matrix to a
separate debugfs file, keeping guc_info strictly about GuC.
Suggested-by: Daniele Ceraolo Spurio
Signed-off-by: Michał Winiarski
One of these drivers that predates the nonblocking support in helpers,
and hand-rolled its own thing. Entirely not anything specific here, we
can just delete it all and replace it with the helper version.
Could also perhaps use the drm_mode_config_helper_suspend/resume
stuff, for another few
== Series Details ==
Series: series starting with [1/3] drm/i915/gt: Replace opencoded
i915_gem_object_pin_map()
URL : https://patchwork.freedesktop.org/series/79211/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8711 -> Patchwork_18099
Hello Hans,
On Tue, Jul 07, 2020 at 07:31:29PM +0200, Hans de Goede wrote:
> On 7/7/20 9:34 AM, Uwe Kleine-König wrote:
> > On Mon, Jul 06, 2020 at 10:53:08PM +0200, Hans de Goede wrote:
> > > But if we do then I think closest to the truth would be:
> > >
> > > state->period = UINT_MAX;
> >
== Series Details ==
Series: series starting with [1/3] drm/i915/gt: Replace opencoded
i915_gem_object_pin_map()
URL : https://patchwork.freedesktop.org/series/79211/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3286cb8bd6d2 drm/i915/gt: Replace opencoded
Two new PCI ids added to ehl.
v2: added two additional PCI ids
BSpec: 29153
Cc: Matt Roper
Cc: Anusha Srivatsa
Signed-off-by: José Roberto de Souza
---
include/drm/i915_pciids.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
Hi Daniel.
On Tue, Jul 07, 2020 at 10:12:13PM +0200, Daniel Vetter wrote:
> One of these drivers that predates the nonblocking support in helpers,
> and hand-rolled its own thing. Entirely not anything specific here, we
> can just delete it all and replace it with the helper version.
>
> Could
On Tue, 2020-06-30 at 15:19 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/display: Implement new combo phy initialization step (rev3)
> URL : https://patchwork.freedesktop.org/series/78796/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from
This is one from the department of "maybe play lottery if you hit
this, karma compensation might work". Or at least lockdep ftw!
This reverts commit 565d1941557756a584ac357d945bc374d5fcd1d0.
It's not quite as low-risk as the commit message claims, because this
grabs console_lock, which might be
...
I think it's time to stop this little exercise.
The lockdep splat, for the record:
[ 132.583381] ==
[ 132.584091] WARNING: possible circular locking dependency detected
[ 132.584775] 5.7.0-rc3+ #346 Tainted: GW
[ 132.585461]
Again ends just after drm_atomic_helper_commit_hw_done(), but with the
twist that we need to make sure we're only annotate the custom
version. And not the other clause which just calls
drm_atomic_helper_commit_tail_rpm(), which is already annotated.
Signed-off-by: Daniel Vetter
Cc: Thierry
Gives us proper nonblocking support for free, and a pile of other
things. The tilcdc code is simply old enough that it was never
converted over, but was stuck forever with the copypasta from when it
was initially merged.
The riskiest thing with this conversion is maybe that there's an issue
with
In the face of unpriviledged userspace being able to submit bogus gpu
workloads the kernel needs gpu timeout and reset (tdr) to guarantee
that dma_fences actually complete. Annotate this worker to make sure
we don't have any accidental locking inversions or other problems
lurking.
Originally this
This is a bit tricky, since ->notifier_lock is held while calling
dma_fence_wait we must ensure that also the read side (i.e.
dma_fence_begin_signalling) is on the same side. If we mix this up
lockdep complaints, and that's again why we want to have these
annotations.
A nice side effect of this
drm_atomic_helper_commit_hw_done() is the last thing (no plane cleanup
apparrently), so it's the entire function. And a nice comment
explaining why thw wait_for_flip_done is ahead, unlike the usual
sequence.
Aside, I think since the atomic helpers do track plane disabling now
separately this
To improve coverage also annotate the gpu reset code itself, since
that's called from other places than drm/scheduler (which is already
annotated). Annotations nests, so this doesn't break anything, and
allows easier testing.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc:
Ends right after drm_atomic_helper_commit_hw_done(), absolutely
nothing fancy going on here.
Signed-off-by: Daniel Vetter
Cc: Laurent Pinchart
Cc: Kieran Bingham
Cc: linux-renesas-...@vger.kernel.org
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
My dma-fence lockdep annotations caught an inversion because we
allocate memory where we really shouldn't:
kmem_cache_alloc+0x2b/0x6d0
amdgpu_fence_emit+0x30/0x330 [amdgpu]
amdgpu_ib_schedule+0x306/0x550 [amdgpu]
amdgpu_job_run+0x10f/0x260 [amdgpu]
Not going to bother with a complete commit message, just
offending backtrace:
kvmalloc_node+0x47/0x80
dc_create_state+0x1f/0x60 [amdgpu]
dc_commit_state+0xcb/0x9b0 [amdgpu]
amdgpu_dm_atomic_commit_tail+0xd31/0x2010 [amdgpu]
commit_tail+0xa4/0x140
Trying to grab dma_resv_lock while in commit_tail before we've done
all the code that leads to the eventual signalling of the vblank event
(which can be a dma_fence) is deadlock-y. Don't do that.
Here the solution is easy because just grabbing locks to read
something races anyway. We don't need
One of these drivers that predates the nonblocking support in helpers,
and hand-rolled its own thing. Entirely not anything specific here, we
can just delete it all and replace it with the helper version.
Could also perhaps use the drm_mode_config_helper_suspend/resume
stuff, for another few
Again needs to be put right after the call to
drm_atomic_helper_commit_hw_done(), since that's the last thing which
can hold up a subsequent atomic commit.
No surprises here.
Signed-off-by: Daniel Vetter
Cc: "James (Qian) Wang"
Cc: Liviu Dudau
Cc: Mihail Atanassov
---
I need a canary in a ttm-based atomic driver to make sure the
dma_fence_begin/end_signalling annotations actually work.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: Chris
Nothing special, just put the end right after hw_done(). Note that in
one path there's a wait for the flip/update to complete. But as far as
I understand from comments and code that's only relevant for modesets,
and skipped if there wasn't a modeset done on a given crtc.
For a bit more clarity
Like the helpers, nothing special. Well except not, because we the
critical section extends until after hw_done(), since that's the last
thing which could hold up a subsequent atomic commit. That means the
wait_for_flip_done is included, but that's not a problem, we're
allowed to call
This is a bit disappointing since we need to split the annotations
over all the different parts.
I was considering just leaking the critical section into the
->atomic_commit_tail callback of each driver. But that would mean we
need to pass the fence_cookie into each driver (there's a total of 13
If the scheduler rt thread gets stuck on a mutex that we're holding
while waiting for gpu workloads to complete, we have a problem.
Add dma-fence annotations so that lockdep can check this for us.
I've tried to quite carefully review this, and I think it's at the
right spot. But obviosly no
Ends right after hw_done(), totally standard case.
Signed-off-by: Daniel Vetter
Cc: Jyri Sarha
Cc: Tomi Valkeinen
---
drivers/gpu/drm/tidss/tidss_kms.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/tidss/tidss_kms.c
b/drivers/gpu/drm/tidss/tidss_kms.c
index
Two in one go:
- it is allowed to call dma_fence_wait() while holding a
dma_resv_lock(). This is fundamental to how eviction works with ttm,
so required.
- it is allowed to call dma_fence_wait() from memory reclaim contexts,
specifically from shrinker callbacks (which i915 does), and from
Hi all,
Bunch of changes that might matter:
- Clarification that dma_fences are for drivers/gpu, requested by Jason
Gunthorpe.
- New patch to list all the past discussions around
indefinite/future/whatever fences, and why this (sadly) still just plain
doesn't work. Came up again when
This is needed to signal the fences from page flips, annotate it
accordingly. We need to annotate entire timer callback since if we get
stuck anywhere in there, then the timer stops, and hence fences stop.
Just annotating the top part that does the vblank handling isn't
enough.
Cc:
This is rather overkill since currently all drivers call this from
hardirq (or at least timers). But maybe in the future we're going to
have thread irq handlers and what not, doesn't hurt to be prepared.
Plus this is an easy start for sprinkling these fence annotations into
shared code.
Cc:
Comes up every few years, gets somewhat tedious to discuss, let's
write this down once and for all.
What I'm not sure about is whether the text should be more explicit in
flat out mandating the amdkfd eviction fences for long running compute
workloads or workloads where userspace fencing is
Design is similar to the lockdep annotations for workers, but with
some twists:
- We use a read-lock for the execution/worker/completion side, so that
this explicit annotation can be more liberally sprinkled around.
With read locks lockdep isn't going to complain if the read-side
isn't
As we have a pin_map interface, that knows how to flush the data to the
device, use it. The only downside is that we keep the kmap around, as
once acquired we keep the mapping cached until the object's backing
store is released.
Signed-off-by: Chris Wilson
---
Some objects we map once during their construction, and then never
access their mappings again, even if they are kept around for the
duration of the driver. Keeping those pages mapped, often vmapped, is
therefore wasteful and we should release the maps as soon as we no
longer need them.
Last user removed, remove the convenience function.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 4
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 14 --
2 files changed, 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
Hi,
On 7/7/20 9:09 PM, Uwe Kleine-König wrote:
Hello Hans,
On Tue, Jul 07, 2020 at 07:31:29PM +0200, Hans de Goede wrote:
On 7/7/20 9:34 AM, Uwe Kleine-König wrote:
On Mon, Jul 06, 2020 at 10:53:08PM +0200, Hans de Goede wrote:
But if we do then I think closest to the truth would be:
Hi Uwe,
On 7/7/20 9:50 AM, Uwe Kleine-König wrote:
Hello Hans,
On Sat, Jun 20, 2020 at 02:17:58PM +0200, Hans de Goede wrote:
Now that the PWM drivers which we use have been converted to the atomic
PWM API, we can move the i915 panel code over to using the atomic PWM API.
Note that there
== Series Details ==
Series: drm/i915/display: Fix initial fb to use resource_size_t (rev2)
URL : https://patchwork.freedesktop.org/series/79205/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8710 -> Patchwork_18098
Quoting lepton (2020-07-07 19:17:51)
> On Tue, Jul 7, 2020 at 10:20 AM Chris Wilson wrote:
> >
> > Quoting lepton (2020-07-07 18:05:21)
> > > On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson
> > > wrote:
> > > >
> > > > If we assign obj->filp, we believe that the create vgem bo is native and
> > > >
On Tue, Jul 7, 2020 at 10:20 AM Chris Wilson wrote:
>
> Quoting lepton (2020-07-07 18:05:21)
> > On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson
> > wrote:
> > >
> > > If we assign obj->filp, we believe that the create vgem bo is native and
> > > allow direct operations like mmap() assuming it
== Series Details ==
Series: drm/i915/display: Fix initial fb to use resource_size_t (rev2)
URL : https://patchwork.freedesktop.org/series/79205/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
40ee693823d1 drm/i915/display: Fix initial fb to use resource_size_t
-:17:
We lookup up the physical address of the inherited framebuffer, and
presume that is an offset into the stolen memory region. As we are
dealing with physical resources and their addresses, we need to use
resource_size_t and not assume everything fits within a plain u32 [based
on prior assumptions
Quoting Tvrtko Ursulin (2020-07-07 18:48:23)
>
> On 07/07/2020 18:15, Chris Wilson wrote:
> > We lookup up the physical address of the inherited framebuffer, and
> > presume that is an offset into the stolen memory region. As we are
> > dealing with physical resources and their addresses, we need
== Series Details ==
Series: drm/i915/display: Fix initial fb to use resource_size_t
URL : https://patchwork.freedesktop.org/series/79205/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8710 -> Patchwork_18097
Summary
On 07/07/2020 18:15, Chris Wilson wrote:
We lookup up the physical address of the inherited framebuffer, and
presume that is an offset into the stolen memory region. As we are
dealing with physical resources and their addresses, we need to use
resource_size_t and not assume everything fits
== Series Details ==
Series: drm/i915/display: Fix initial fb to use resource_size_t
URL : https://patchwork.freedesktop.org/series/79205/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f694486df0d8 drm/i915/display: Fix initial fb to use resource_size_t
-:17:
On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson wrote:
>
> If we assign obj->filp, we believe that the create vgem bo is native and
> allow direct operations like mmap() assuming it behaves as backed by a
> shmemfs inode. When imported from a dmabuf, the obj->pages are
> not always meaningful and the
Hi,
On 7/7/20 9:34 AM, Uwe Kleine-König wrote:
On Mon, Jul 06, 2020 at 10:53:08PM +0200, Hans de Goede wrote:
Hi,
Thank you for your review and sorry for the slow reply.
No problem for me, I didn't hold my breath :-)
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index
Quoting lepton (2020-07-07 18:05:21)
> On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson wrote:
> >
> > If we assign obj->filp, we believe that the create vgem bo is native and
> > allow direct operations like mmap() assuming it behaves as backed by a
> > shmemfs inode. When imported from a dmabuf, the
We lookup up the physical address of the inherited framebuffer, and
presume that is an offset into the stolen memory region. As we are
dealing with physical resources and their addresses, we need to use
resource_size_t and not assume everything fits within a plain u32 [based
on prior assumptions
== Series Details ==
Series: drm/i915/gem: Unpin idle contexts from kswapd reclaim
URL : https://patchwork.freedesktop.org/series/79204/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8710 -> Patchwork_18096
Summary
---
== Series Details ==
Series: drm/i915/gem: Unpin idle contexts from kswapd reclaim
URL : https://patchwork.freedesktop.org/series/79204/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9357a85637f9 drm/i915/gem: Unpin idle contexts from kswapd reclaim
-:25:
== Series Details ==
Series: series starting with [1/2] drm/vgem: Do not allocate backing shmemfs
file for an import dmabuf object
URL : https://patchwork.freedesktop.org/series/79203/
State : failure
== Summary ==
Applying: drm/vgem: Do not allocate backing shmemfs file for an import dmabuf
We removed retiring requests from the shrinker in order to decouple the
mutexes from reclaim in preparation for unravelling the struct_mutex.
The impact of not retiring is that we are much less agressive in making
global objects available for shrinking, as such objects remain pinned
until they are
drm_gem_dumb_map_offset() now exists and does everything
vgem_gem_dump_map does and *ought* to do.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/vgem/vgem_drv.c | 28 +---
1 file changed, 1 insertion(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c
If we assign obj->filp, we believe that the create vgem bo is native and
allow direct operations like mmap() assuming it behaves as backed by a
shmemfs inode. When imported from a dmabuf, the obj->pages are
not always meaningful and the shmemfs backing store misleading.
Note, that regular mmap
== Series Details ==
Series: series starting with [01/12] drm/i915/gt: Decouple completed requests
on unwind
URL : https://patchwork.freedesktop.org/series/79183/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8709_full -> Patchwork_18093_full
Hi
On 19.06.2020 12:36, Marek Szyprowski wrote:
> The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
> returns the number of the created entries in the DMA address space.
> However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
> dma_unmap_sg must be called
== Series Details ==
Series: drm/i915: Fix spelling mistake in i915_reg.h (rev2)
URL : https://patchwork.freedesktop.org/series/79156/
State : failure
== Summary ==
Applying: drm/i915: Fix spelling mistake in i915_reg.h
Using index info to reconstruct a base tree...
M
Hello Hans,
On Mon, Jul 06, 2020 at 11:05:20PM +0200, Hans de Goede wrote:
> Before I post a new version of this patch-set, you have only responded
> to some of the PWM patches in this set. Do you have any remarks on the
> other PWM patches ?
I stopped looking at them as I hoped someone would
Hello,
On Sat, Jun 20, 2020 at 02:17:52PM +0200, Hans de Goede wrote:
> The pwm-crc code is using 2 different enable bits:
> 1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
> 2. bit 0 of the BACKLIGHT_EN register
>
> So far we've kept the PWM_OUTPUT_ENABLE bit set when disabling the PWM,
> this
Fix typo: "TRIGER" --> "TRIGGER"
The two misplelled macros:
1) OAREPORTTRIG1_EDGE_LEVEL_TRIGER_SELECT_MASK
2) OAREPORTTRIG5_EDGE_LEVEL_TRIGER_SELECT_MASK
are not used in any other sources of the kernel,
so this change can be consider only a local change
for the i915_reg.h file.
Signed-off-by:
1 - 100 of 127 matches
Mail list logo
