From: Thomas Hellstrom
With SEV encryption, all DMA memory must be marked decrypted
(AKA "shared") for devices to be able to read it. In the future we might
want to be able to switch normal (encrypted) memory to decrypted in exactly
the same way as we handle caching states, and that would require
From: Thomas Hellstrom
The TTM dma pool allocates coherent pages for use with TTM. When SEV is
active, such allocations become very expensive since the linear kernel
map has to be changed to mark the pages decrypted. So to avoid too many
such allocations and frees, cache the decrypted pages even
The sti_hdmi.c file include despite not even
using any GPIOs.
What it does use is devm_ioremap_nocache() which comes from
implicitly by including that header.
Fix this up by including the right header instead.
Cc: Benjamin Gaignard
Cc: Vincent Abriou
Signed-off-by: Linus Walleij
---
driver
On 19/08/2019 17:12, Rob Herring wrote:
> Calling dma_unmap_sg() in drm_gem_shmem_free_object() is too late if the
> backing pages have already been released by the shrinker. The result is
> the following abort:
>
> Unable to handle kernel paging request at virtual address 898ed000
> Mem a
On 19/08/2019 17:12, Rob Herring wrote:
> This fixes 2 issues found by lockdep. First, drm_gem_shmem_purge()
> now uses mutex_trylock for the pages_lock to avoid a circular
> dependency.
NIT: This is in the previous patch.
> Second, it drops the call to panfrost_mmu_unmap() which takes several
>
On 19/08/2019 17:12, Rob Herring wrote:
> We can't hold the mm_lock spinlock as panfrost_mmu_map() can sleep:
>
> BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:909
> in_atomic(): 1, irqs_disabled(): 0, pid: 974, name: glmark2-es2-drm
> 1 lock held by glmark2-es2-d
On 19/08/2019 17:12, Rob Herring wrote:
> Lockdep reports a circular locking dependency with pages_lock taken in
> the shrinker callback. The deadlock can't actually happen with current
> users at least as a BO will never be purgeable when pages_lock is held.
> To be safe, let's use mutex_trylock()
The DPU has some kind of idea that it wants to be able to
bring up power using GPIO lines. The struct dss_gpio is however
completely unused and should this be done, it should be done
using the GPIO descriptor framework rather than this API
which relies on the global GPIO numberspace. Delete this
co
This switches the MSM HDMI code to use GPIO descriptors.
Normally we would fetch the GPIOs from the device with the
flags GPIOD_IN or GPIOD_OUT_[LOW|HIGH] to set up the lines
immediately, but since the code seems eager to actively
drive the lines high/low when turning HDMI on and off, we
just fetch
There is elaborate code in the HDMI connector handling to
leave the connector in the state it was at power-on and
only touch the GPIOs when the connector .enable() and
.disable() callbacks are called.
I don't think this is what we normally want, initialize
the connector as OFF (possibly saving pow
This DSI driver uses the new descriptor API so these old
GPIO API includes are surplus.
Cc: Rob Clark
Cc: Sean Paul
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Reviewed-by: Brian Masney
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Rebased on v5.3-rc1
- Collect
This file is not using any symbols from so just
drop this include.
Cc: Rob Clark
Cc: Sean Paul
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Reviewed-by: Brian Masney
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Rebased on v5.3-rc1
- Collected review tag
---
d
After untangling the MSM HDMI GPIO code we see that the code
is deliberately setting the output value of the HPD (hot plug
detect) line to high, even though it is being used as input
which is of course the only viable use of a HPD pin.
This seems dubious: GPIO lines set up as input will have high
https://bugs.freedesktop.org/show_bug.cgi?id=110795
--- Comment #32 from Tomas ---
Hi,
I have applied the patch to drivers amdgpu-pro-19.30-855429-ubuntu-18.04, and
something is wrong. The process doesn't find as seems some components?
See output i got on the cli. Have I overlooked something?
$
https://bugs.freedesktop.org/show_bug.cgi?id=110795
--- Comment #33 from Tomas ---
System is Ubuntu 19.04, 5.0.0-25-generic #26-Ubuntu SMP Thu Aug 1 12:04:58 UTC
2019 x86_64 x86_64 x86_64 GNU/Linux
--
You are receiving this mail because:
You are the assignee for the bug.
On 21/08/2019 23:26, Aaro Koskinen wrote:
Hi,
On Wed, Aug 21, 2019 at 09:32:26PM +0300, Laurent Pinchart wrote:
When refactoring port lookup for DSS outputs, commit d17eb4537a7e
("drm/omap: Factor out common init/cleanup code for output devices")
incorrectly hardcoded usage of DT port 0. This b
Hi Dave and Daniel,
(atempt v2:
for some reason my dim didn't recognized the path apparently
)
Here goes the final pull request targeting 5.4.
It's important to highlight that we got a conflict on a backmerge yesterday
which had already been solved on linux-next with a fix up patch:
From: Steph
On Thu, 22 Aug 2019, Ramalingam C wrote:
> Handled the need for exposing enum port to mei_hdcp driver, by
> converting the port into ddi index as per ME FW.
>
> Hence enum port definition moved into I915 driver itself.
For future reference, please consider using the imperative style in the
commit
Hi Dave and Daniel,
Here goes the final pull request targeting 5.4.
It's important to highlight that we got a conflict on a backmerge yesterday
which had already been solved on linux-next with a fix up patch:
From: Stephen Rothwell
Date: Wed, 14 Aug 2019 12:48:39 +1000
Subject: [PATCH] drm: fix
From: Thomas Hellstrom
The new header is intended to be used by drivers using the backdoor.
Follow the kvm example using alternatives self-patching to
choose between vmcall, vmmcall and io instructions.
Also define two new CPU feature flags to indicate hypervisor support
for vmcall- and vmmcall
From: Thomas Hellstrom
Use the definition provided by include/asm/vmware.h
CC: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc:
Cc:
Signed-off-by: Thomas Hellstrom
Reviewed-by: Doug Covelli
Acked-by: Dmitry Torokhov
---
drivers/input/mouse/vmmouse.c | 6 +++-
From: Thomas Hellstrom
Use the definition provided by include/asm/vmware.h
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc:
Cc:
Signed-off-by: Thomas Hellstrom
Reviewed-by: Doug Covelli
---
drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 21 +
drive
On Thu, Aug 22, 2019 at 03:13:14PM +0200, Daniel Vetter wrote:
> On Thu, Aug 22, 2019 at 11:06:45AM +0200, Gerd Hoffmann wrote:
> > No need for a home-grown version, the generic helper should work just
> > fine. It also handles vgacon removal these days, see commit
> > 1c74ca7a1a9a ("drm/fb-helper
https://bugs.freedesktop.org/show_bug.cgi?id=110795
--- Comment #34 from Andrew Shark ---
@Tomas, it is strange that it did not asked a password after "Creating local
repository..." which is before "Installing OpenGL PRO...". Probably you already
had a previous version of repository (it happens i
On Fri, Aug 23, 2019 at 10:14 AM Gerd Hoffmann wrote:
> On Thu, Aug 22, 2019 at 03:13:14PM +0200, Daniel Vetter wrote:
> > On Thu, Aug 22, 2019 at 11:06:45AM +0200, Gerd Hoffmann wrote:
> > > No need for a home-grown version, the generic helper should work just
> > > fine. It also handles vgacon
On Fri, Aug 23, 2019 at 1:14 AM Andrew Morton wrote:
>
> On Tue, 20 Aug 2019 22:24:40 +0200 Daniel Vetter wrote:
>
> > Hi Peter,
> >
> > Iirc you've been involved at least somewhat in discussing this. -mm folks
> > are a bit undecided whether these new non_block semantics are a good idea.
> > Mic
Hi Daniel, Dave,
Here is what should be the final drm-misc-next PR for 5.4.
Thanks!
Maxime
drm-misc-next-2019-08-23:
drm-misc-next for 5.4:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- dma-buf: dma-fence selftests
Driver Changes:
- kirin: Various cleanups and reworks
- komeda
On Tue, Aug 20, 2019 at 10:24:40PM +0200, Daniel Vetter wrote:
> On Tue, Aug 20, 2019 at 10:19:01AM +0200, Daniel Vetter wrote:
> > In some special cases we must not block, but there's not a
> > spinlock, preempt-off, irqs-off or similar critical section already
> > that arms the might_sleep() debu
On Fri, Aug 23, 2019 at 10:30:35AM +0200, Daniel Vetter wrote:
> On Fri, Aug 23, 2019 at 10:14 AM Gerd Hoffmann wrote:
> >
> > Whole series or just the i915 patch?
>
> Ok I just checked and this all landed in 5.1 already, I thought it was
> more recent. I think that's good enough, push it all wit
https://bugs.freedesktop.org/show_bug.cgi?id=110795
--- Comment #35 from Etienne Lorrain ---
(In reply to Andrew Shark from comment #31)
> (In reply to Etienne Lorrain from comment #30)
> I do not understand what problem you are talking about. Package just refuses
> to install because of explicit
On 23/08/2019 03:33, Rob Herring wrote:
> Add Steven Price and Alyssa Rosenzweig as reviewers as they have been the
> primary reviewers already.
>
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Cc: Tomeu Vizoso
> Signed-off-by: Rob Herring
> ---
> MAINTAINERS | 2 ++
> 1 file changed, 2 inserti
On 23/08/2019 02:52, Rob Herring wrote:
> On Thu, Aug 22, 2019 at 4:32 AM Steven Price wrote:
>>
>> When modifying panfrost_devfreq_target() to support a device without a
>> regulator defined I missed the check on the error path. Let's add it.
>>
>> Reported-by: Dan Carpenter
>> Fixes: e21dd29088
On 23/08/2019 02:33, Rob Herring wrote:
> Add Steven Price and Alyssa Rosenzweig as reviewers as they have been the
> primary reviewers already.
>
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Cc: Tomeu Vizoso
> Signed-off-by: Rob Herring
Acked-by: Steven Price
Steve
> ---
> MAINTAINERS |
Hi all,
Commit
88b703527ba7 ("drm/nouveau/kms/gf119-: add ctm property support")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
pgpFK0PXpb9VH.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-de
Support for HDR10 video was introduced in DisplayPort 1.4.
On GLK+ platform, in order to use DisplayPort HDR10, we need to support
BT.2020 colorimetry and HDR Static metadata.
It implements the CTA-861-G standard for transport of static HDR metadata.
It enables writing of HDR metadata infoframe SDP
Function intel_dp_setup_hdr_metadata_infoframe_sdp handles Infoframe SDP
header and data block setup for HDR Static Metadata. It enables writing of
HDR metadata infoframe SDP to panel. Support for HDR video was introduced
in DisplayPort 1.4. It implements the CTA-861-G standard for transport of
sta
It refactors and renames a function which handled vsc sdp header and data
block setup for supporting colorimetry format.
Function intel_dp_setup_vsc_sdp handles vsc sdp header and data block
setup for pixel encoding / colorimetry format.
In order to use colorspace information of a connector, it add
It attaches HDR metadata property to DP connector on GLK+.
It enables HDR metadata infoframe sdp on GLK+ to be used to send
HDR metadata to DP sink.
v2: Minor style fix
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/display/intel_dp.c | 5 +
1 file changed, 5 insertions(+)
diff --
When BT.2020 Colorimetry output is used for DP, we should program BT.2020
Colorimetry to MSA and VSC SDP. It adds output_colorspace to
intel_crtc_state struct as a place holder of pipe's output colorspace.
In order to distinguish needed colorimetry for VSC SDP, it adds
intel_dp_needs_vsc_colorimetr
In order to use colorspace property to Display Port connectors, it extends
DRM_MODE_CONNECTOR_DisplayPort connector_type on
drm_mode_create_colorspace_property function.
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/drm_connector.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
d
It attaches the colorspace connector property to a DisplayPort connector.
Based on colorspace change, modeset will be triggered to switch to a new
colorspace.
Based on colorspace property value create a VSC SDP packet with appropriate
colorspace. This would help to enable wider color gamut like BT
No need to do the reservation dance,
we can just wait on the fence directly.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane
Hi
Am 22.08.19 um 22:02 schrieb Dave Airlie:
> On Fri, 23 Aug 2019 at 03:25, Thomas Zimmermann wrote:
>>
>> Hi
>>
>> I was traveling and could reply earlier. Sorry for taking so long.
>>
>> Am 13.08.19 um 11:36 schrieb Feng Tang:
>>> Hi Thomas,
>>>
>>> On Mon, Aug 12, 2019 at 03:25:45PM +0800, Fe
Switch to the virtio_gpu_array_* helper workflow.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 3 +-
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 40 ++
drivers/gpu/drm/virtio/virtgpu_vq.c| 8 --
3 files changed, 23 insertions(+), 28 del
With this gem and ttm will use the same reservation object,
so mixing and matching ttm / gem reservation helpers should
work fine.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_object.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --
No users left.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_drv.h| 1 -
drivers/gpu/drm/virtio/virtgpu_object.c | 13 -
2 files changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/vi
ttm increasingly gets into the way while hacking on virtio-gpu memory
management. It also overkill for what virtio-gpu needs. Lets get rid
of it.
v8:
- rebase to latest drm-misc-next, adapt to changes.
v7:
- rebase to latest drm-misc-next
- reorder patches: switch all virtio commands to objec
Make sure we don't leak half-initialized fences outside the driver.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_fence.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c
b/drivers/gpu/drm/virtio/virtgpu_fence.c
index a0514f5bd006.
Use drm_gem_reservation_object_wait() in virtio_gpu_wait_ioctl().
This also makes the ioctl run lockless.
v5: handle lookup failure.
v2: use reservation_object_test_signaled_rcu for VIRTGPU_WAIT_NOWAIT.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_
No users left.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 21 -
1 file changed, 21 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 85f974a9837b..fb35831ed351 100644
--- a/drivers/gpu/dr
Rework fencing workflow. Stop using ttm helpers, use the
virtio_gpu_array_* helpers instead.
Due to using the gem reservation object it is initialized and ready for
use before calling ttm_bo_init. So we can simply use the standard
fencing workflow and drop the tricky logic which checks whenever
All callers pass no_wait = false.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 5 ++---
drivers/gpu/drm/virtio/virtgpu_gem.c | 4 ++--
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 4 ++--
3 files changed, 6 insertions(+), 7 deletions(-)
dif
Switch to the virtio_gpu_array_* helper workflow.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++--
drivers/gpu/drm/virtio/virtgpu_gem.c | 24 +++-
drivers/gpu/drm/virtio/virtgpu_vq.c | 12
3 files changed, 21 insertions(+), 19 del
Call reservation_object_* directly instead
of using ttm_bo_{reserve,unreserve}.
v4: check for EINTR only.
v3: check for EINTR too.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff
Thin wrapper around virtio_gpu_object_create(),
but calling that directly works equally well.
Signed-off-by: Gerd Hoffmann
Acked-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 4
drivers/gpu/drm/virtio/virtgpu_gem.c | 23 ---
drivers/gpu/drm/virtio/vi
No users left.
Signed-off-by: Gerd Hoffmann
Acked-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 3 --
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 39 --
2 files changed, 42 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/
Rework fencing workflow, starting with virtio_gpu_execbuffer_ioctl.
Stop using ttm helpers, use the virtio_gpu_array_* helpers (which work
on the reservation objects directly) instead.
Also store the object array in struct virtio_gpu_vbuffer, so we
explicitly keep a reference of all buffers used i
No users left.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 15 ---
1 file changed, 15 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 3e5b2d1db42d..85f974a9837b 100644
--- a/drivers/gpu/drm/virt
virtio-gpu basically needs a sg_table for the bo, to tell the host where
the backing pages for the object are. So the gem shmem helpers are a
perfect fit. Some drm_gem_object_funcs need thin wrappers to update the
host state, but otherwise the helpers handle everything just fine.
Once the fencin
Some helper functions to manage an array of gem objects.
v6:
- add ticket to struct virtio_gpu_object_array.
- add virtio_gpu_array_{lock,unlock}_resv helpers.
- add virtio_gpu_array_add_fence helper.
v5: some small optimizations (Chia-I Wu).
v4: make them virtio-private instead of generic help
Switch to the virtio_gpu_array_* helper workflow.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 4 +--
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 50 +++---
drivers/gpu/drm/virtio/virtgpu_plane.c | 21 ---
drivers/gpu/drm/virtio/virtgpu_vq.c
On Fri, Aug 23, 2019 at 3:40 AM Laurent Pinchart
wrote:
> The drm panel bridge creates a connector using a connector type explicit
> passed by the display controller or bridge driver that instantiates the
> panel bridge. Now that drm_panel reports its connector type, use it and
> remove the conne
On Tuesday, 20 August 2019 18:46:19 BST Ayan Halder wrote:
> The de-init routine should be doing the following in order:-
> 1. Unregister the drm device
> 2. Shut down the crtcs - failing to do this might cause a connector leakage
> See the 'commit 109c4d18e574 ("drm/arm/malidp: Ensure that the crt
On 23/08/2019 03:12, Rob Herring wrote:
There's a few issues with the runtime PM initialization.
The documentation states pm_runtime_set_active() should be called before
pm_runtime_enable(). The pm_runtime_put_autosuspend() could suspend the GPU
before panfrost_perfcnt_init() is called which tou
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #114 from Yuxuan Shui ---
(In reply to magist3r from comment #111)
> (In reply to tempel.julian from comment #110)
> > (In reply to magist3r from comment #109)
> > > My patch fixes a bug that breaks this behavior when OverDrive mask
Hi Nicolas,
On Fri, Aug 23, 2019 at 07:30:07AM +, nicolas.fe...@microchip.com wrote:
> On 23/08/2019 at 03:40, Laurent Pinchart wrote:
> > Add a type field to the drm_panel structure to report the panel type,
> > using DRM_MODE_CONNECTOR_* macros (the values that make sense are LVDS,
> > eDP,
On 23/08/2019 03:12, Rob Herring wrote:
There is no point in resuming the h/w just to do flush operations and
doing so takes several locks which cause lockdep issues with the shrinker.
Rework the flush operations to only happen when the h/w is already awake.
This avoids taking any locks associate
On Fri, 23 Aug 2019 07:30:07 +
wrote:
> Hi Laurent,
>
> On 23/08/2019 at 03:40, Laurent Pinchart wrote:
> > Add a type field to the drm_panel structure to report the panel type,
> > using DRM_MODE_CONNECTOR_* macros (the values that make sense are LVDS,
> > eDP, DSI and DPI). This will be us
Hi Sam,
On Fri, Aug 23, 2019 at 06:49:49AM +0200, Sam Ravnborg wrote:
> Hi Laurent.
>
> Thanks for looking into this, but you will not be happy in a minute...
Could be worse :-)
> On Fri, Aug 23, 2019 at 04:40:32AM +0300, Laurent Pinchart wrote:
> > Add a type field to the drm_panel structure t
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #115 from tempel.jul...@gmail.com ---
There is a new patch series that should allow memclock switching with same
refreshrate multi monitor setup:
https://lists.freedesktop.org/archives/amd-gfx/2019-August/038995.html
--
You are rece
On Fri, Aug 23, 2019 at 5:54 AM Robin Murphy wrote:
>
> On 23/08/2019 03:12, Rob Herring wrote:
> > There's a few issues with the runtime PM initialization.
> >
> > The documentation states pm_runtime_set_active() should be called before
> > pm_runtime_enable(). The pm_runtime_put_autosuspend() co
On Fri, Aug 23, 2019 at 09:12:34AM -0300, Jason Gunthorpe wrote:
> I still haven't heard a satisfactory answer why a whole new scheme is
> needed and a simple:
>
>if (IS_ENABLED(CONFIG_DEBUG_ATOMIC_SLEEP))
> preempt_disable()
>
> isn't sufficient to catch the problematic cases during
On 8/23/19 3:33 AM, Rob Herring wrote:
Add Steven Price and Alyssa Rosenzweig as reviewers as they have been the
primary reviewers already.
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: Tomeu Vizoso
Signed-off-by: Rob Herring
Acked-by: Tomeu Vizoso
---
MAINTAINERS | 2 ++
1 file change
On 23/08/2019 03:12, Rob Herring wrote:
tlb_inv_context() hook is only called when freeing the page tables. There's
no point in flushing only to free the page tables immediately following.
FWIW, in general the point of flushing is *because* we're about to free
the pagetables - if there's any p
On Fri, Aug 23, 2019 at 7:56 AM Robin Murphy wrote:
>
> On 23/08/2019 03:12, Rob Herring wrote:
> > tlb_inv_context() hook is only called when freeing the page tables. There's
> > no point in flushing only to free the page tables immediately following.
>
> FWIW, in general the point of flushing is
On Fri, Aug 23, 2019 at 2:12 PM Jason Gunthorpe wrote:
>
> On Fri, Aug 23, 2019 at 10:34:01AM +0200, Daniel Vetter wrote:
> > On Fri, Aug 23, 2019 at 1:14 AM Andrew Morton
> > wrote:
> > >
> > > On Tue, 20 Aug 2019 22:24:40 +0200 Daniel Vetter wrote:
> > >
> > > > Hi Peter,
> > > >
> > > > Iirc
On Tue, Aug 20, 2019 at 03:16:58PM +, Mihail Atanassov wrote:
> komeda_pipeline_destroy has the matching of_node_put().
>
> Fixes: 29e56aec911dd ("drm/komeda: Add DT parsing")
> Signed-off-by: Mihail Atanassov
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 2 +-
> 1 file changed,
On 23/08/2019 14:18, Rob Herring wrote:
On Fri, Aug 23, 2019 at 7:56 AM Robin Murphy wrote:
On 23/08/2019 03:12, Rob Herring wrote:
tlb_inv_context() hook is only called when freeing the page tables. There's
no point in flushing only to free the page tables immediately following.
FWIW, in g
On Fri, Aug 23, 2019 at 03:42:47PM +0200, Daniel Vetter wrote:
> I'm assuming the lockdep one will land, so not going to resend that.
I was assuming you'd wake the might_lock_nested() along with the i915
user through the i915/drm tree. If want me to take some or all of that,
lemme know.
__
On Fri, Aug 23, 2019 at 9:05 AM Robin Murphy wrote:
>
> On 23/08/2019 14:18, Rob Herring wrote:
> > On Fri, Aug 23, 2019 at 7:56 AM Robin Murphy wrote:
> >>
> >> On 23/08/2019 03:12, Rob Herring wrote:
> >>> tlb_inv_context() hook is only called when freeing the page tables.
> >>> There's
> >>>
On Fri, Aug 23, 2019 at 01:43:49PM +, Ayan Halder wrote:
> On Tue, Aug 20, 2019 at 03:16:58PM +, Mihail Atanassov wrote:
> > komeda_pipeline_destroy has the matching of_node_put().
> >
> > Fixes: 29e56aec911dd ("drm/komeda: Add DT parsing")
> > Signed-off-by: Mihail Atanassov
> > ---
> >
On 23/08/2019 03:12, Rob Herring wrote:
Doing a pm_runtime_put as soon as a job is submitted is wrong as it should
not happen until the job completes. It works because we are relying on the
autosuspend timeout to keep the h/w enabled.
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc
On 23/08/2019 03:12, Rob Herring wrote:
Calls to panfrost_device_fini() access the h/w, but we already done a
pm_runtime_put_sync_autosuspend() beforehand. This only works if the
autosuspend delay is long enough. A 0ms delay will hang the system when
removing the device. Fix this by moving the pm
On 23/08/2019 03:12, Rob Herring wrote:
Lockdep reports a circular locking dependency with pages_lock taken in
the shrinker callback. The deadlock can't actually happen with current
users at least as a BO will never be purgeable when pages_lock is held.
To be safe, let's use mutex_trylock() inste
On 23/08/2019 03:12, Rob Herring wrote:
Lockdep reports a circular locking dependency with pages_lock taken in
the shrinker callback. The deadlock can't actually happen with current
users at least as a BO will never be purgeable when pages_lock is held.
To be safe, let's use mutex_trylock() inste
On 23/08/2019 15:26, Rob Herring wrote:
On Fri, Aug 23, 2019 at 9:05 AM Robin Murphy wrote:
On 23/08/2019 14:18, Rob Herring wrote:
On Fri, Aug 23, 2019 at 7:56 AM Robin Murphy wrote:
On 23/08/2019 03:12, Rob Herring wrote:
tlb_inv_context() hook is only called when freeing the page table
On 23/08/2019 12:11, Robin Murphy wrote:
On 23/08/2019 03:12, Rob Herring wrote:
There is no point in resuming the h/w just to do flush operations and
doing so takes several locks which cause lockdep issues with the
shrinker.
Rework the flush operations to only happen when the h/w is already a
On 23/08/2019 03:12, Rob Herring wrote:
There is no point in resuming the h/w just to do flush operations and
doing so takes several locks which cause lockdep issues with the shrinker.
Rework the flush operations to only happen when the h/w is already awake.
This avoids taking any locks associate
On 23/08/2019 03:12, Rob Herring wrote:
tlb_inv_context() hook is only called when freeing the page tables. There's
no point in flushing only to free the page tables immediately following.
There is also a problem that we could be accessing the h/w when suspended.
Cc: Tomeu Vizoso
Cc: Steven Pri
On Fri, Aug 23, 2019 at 9:50 AM Steven Price wrote:
>
> On 23/08/2019 03:12, Rob Herring wrote:
> > Doing a pm_runtime_put as soon as a job is submitted is wrong as it should
> > not happen until the job completes. It works because we are relying on the
> > autosuspend timeout to keep the h/w enab
On Fri, Aug 23, 2019 at 4:06 PM Peter Zijlstra wrote:
> On Fri, Aug 23, 2019 at 03:42:47PM +0200, Daniel Vetter wrote:
> > I'm assuming the lockdep one will land, so not going to resend that.
>
> I was assuming you'd wake the might_lock_nested() along with the i915
> user through the i915/drm tree
Hi Dave, Daniel,
please consider merging these image converter fixes for v5.4, which
avoid image degradation due to intermediate downscaling in some tiled
conversions and fix 1:1 conversions that are multiples of the hardware
tile size. This also adds RGBX and BGRX format support now that these
ar
Hi Brendan,
On 8/20/19 5:20 PM, Brendan Higgins wrote:
Add core facilities for defining unit tests; this provides a common way
to define test cases, functions that execute code which is under test
and determine whether the code under test behaves as expected; this also
provides a way to group to
Hi Brendan,
On 8/20/19 5:20 PM, Brendan Higgins wrote:
Add support for aborting/bailing out of test cases, which is needed for
implementing assertions.
An assertion is like an expectation, but bails out of the test case
early if the assertion is not met. The idea with assertions is that you
use
On 23/08/2019 16:05, Steven Price wrote:
On 23/08/2019 12:11, Robin Murphy wrote:
On 23/08/2019 03:12, Rob Herring wrote:
There is no point in resuming the h/w just to do flush operations and
doing so takes several locks which cause lockdep issues with the
shrinker.
Rework the flush operations
On Fri, Aug 23, 2019 at 10:09 AM Steven Price wrote:
>
> On 23/08/2019 03:12, Rob Herring wrote:
> > There is no point in resuming the h/w just to do flush operations and
> > doing so takes several locks which cause lockdep issues with the shrinker.
> > Rework the flush operations to only happen w
https://bugs.freedesktop.org/show_bug.cgi?id=111236
--- Comment #6 from Julien Isorce ---
Looks similar to
https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/merge_requests/142
It is working fine with mesa 18.3.6 and st/va has not changed in 19.1:
https://cgit.freedesktop.org/mesa/mesa/log
On Fri, Aug 23, 2019 at 10:44 AM Robin Murphy wrote:
>
> On 23/08/2019 16:05, Steven Price wrote:
> > On 23/08/2019 12:11, Robin Murphy wrote:
> >> On 23/08/2019 03:12, Rob Herring wrote:
> >>> There is no point in resuming the h/w just to do flush operations and
> >>> doing so takes several locks
On 2019-08-22 6:46 p.m., Siqueira, Rodrigo wrote:
> DP 1.4 specification defines Link Training Tunable PHY Repeater (LTTPR)
> which is required to add support for systems with Thunderbolt or other
> repeater devices.
>
> Cc: Abdoulaye Berthe
> Cc: Harry Wentland
> Cc: Leo Li
> Signed-off-by: Ro
On 23/08/2019 16:57, Rob Herring wrote:
On Fri, Aug 23, 2019 at 10:44 AM Robin Murphy wrote:
On 23/08/2019 16:05, Steven Price wrote:
On 23/08/2019 12:11, Robin Murphy wrote:
On 23/08/2019 03:12, Rob Herring wrote:
There is no point in resuming the h/w just to do flush operations and
doing
1 - 100 of 176 matches
Mail list logo
