Hi Noralf,
On Tue, Jun 18, 2019 at 03:56:19PM +0200, Noralf Trønnes wrote:
> Den 18.06.2019 15.13, skrev Laurent Pinchart:
> > The recommended way to specify GEM object functions is to provide a
> > drm_gem_object_funcs structure instance and set the GEM object to point
> > to it. The
Notify drm core before sending pending events during crtc disable.
This fixes the first event after disable having an old stale timestamp
by having drm_crtc_vblank_off update the timestamp to now.
This was seen while debugging weston log message:
Warning: computed repaint delay is insane: -8212
On 18/06/2019 16:19, Greg Kroah-Hartman wrote:
> On Fri, Jun 14, 2019 at 10:36:14PM +0200, Daniel Vetter wrote:
>> Greg is busy already, but maybe he won't do everything ...
>>
>> Cc: Greg Kroah-Hartman
>> Signed-off-by: Daniel Vetter
>> ---
>> Documentation/gpu/todo.rst | 3 +++
>> 1 file
On Tue, Jun 18, 2019 at 2:16 AM Boris Brezillon
wrote:
>
> Hello,
>
> This a new version of the panfrost perfcnt series, this time exposing
> this functionality through 2 ioctls instead of the debugfs approach
> used in v2.
>
> I also went for Emil's suggestion to expose those ioctls only when
>
On Tue, Jun 18, 2019 at 2:13 AM Boris Brezillon
wrote:
>
> mmu_ops->unmap() will fail when called on a BO that has not been
> previously mapped, and the error path in panfrost_ioctl_create_bo()
> can call drm_gem_object_put_unlocked() (which in turn calls
> panfrost_mmu_unmap()) on a BO that has
Ah crap. I need to fix copy_one_buf32() as well. I will sent a v2.
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Jun 18, 2019 at 05:19:38PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Jun 14, 2019 at 10:36:14PM +0200, Daniel Vetter wrote:
> > Greg is busy already, but maybe he won't do everything ...
> >
> > Cc: Greg Kroah-Hartman
> > Signed-off-by: Daniel Vetter
> > ---
> >
On Tue, May 21, 2019 at 11:44:11AM -0400, Jerome Glisse wrote:
> On Mon, May 20, 2019 at 11:39:42PM +0200, Daniel Vetter wrote:
> > Just a bit of paranoia, since if we start pushing this deep into
> > callchains it's hard to spot all places where an mmu notifier
> > implementation might fail when
Dear All,
this series adds HDMI support to the HiHope RZ/G2M board.
Thanks,
Fab
Fabrizio Castro (3):
dt-bindings: display: renesas: Add r8a774a1 support
arm64: dts: renesas: r8a774a1: Add HDMI encoder instance
arm64: dts: renesas: hihope-common: Add HDMI support
On Fri, Jun 14, 2019 at 10:36:14PM +0200, Daniel Vetter wrote:
> Greg is busy already, but maybe he won't do everything ...
>
> Cc: Greg Kroah-Hartman
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/todo.rst | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git
Document RZ/G2M (R8A774A1) SoC bindings.
Signed-off-by: Fabrizio Castro
---
Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
On Tue, Jun 18, 2019 at 02:17:11PM +0200, Daniel Vetter wrote:
> On Tue, Jun 18, 2019 at 02:01:35PM +0200, Greg Kroah-Hartman wrote:
> > On Fri, Jun 14, 2019 at 05:37:58PM +0200, Daniel Vetter wrote:
> > > On Fri, Jun 14, 2019 at 5:20 PM Greg Kroah-Hartman
> > > wrote:
> > > >
> > > > On Fri, Jun
https://bugs.freedesktop.org/show_bug.cgi?id=110944
--- Comment #2 from Sebastian Parborg ---
Yes that patch seems to solve the issue!
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=110944
--- Comment #1 from Pierre-Eric Pelloux-Prayer
---
Can you test the commit from
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1071? I think it should
fix this issue.
--
You are receiving this mail because:
You are the assignee for
On Tue, 18 Jun 2019 at 16:18, Rob Herring wrote:
>
> On Tue, Jun 18, 2019 at 3:27 AM Krzysztof Kozlowski wrote:
> >
> > On Sat, 15 Jun 2019 at 01:57, Joseph Kogut wrote:
> > >
> > > Add device tree node for mali gpu on Odroid XU3 SoCs.
> > >
> > > Signed-off-by: Joseph Kogut
> > > ---
> > >
>
On Tue, Jun 18, 2019 at 8:11 PM Jagan Teki wrote:
>
> On Tue, Jun 18, 2019 at 5:13 PM Chen-Yu Tsai wrote:
> >
> > On Tue, Jun 18, 2019 at 6:51 PM Jagan Teki
> > wrote:
> > >
> > > On Fri, Jun 14, 2019 at 8:15 PM Maxime Ripard
> > > wrote:
> > > >
> > > > On Fri, Jun 14, 2019 at 12:03:13PM
https://bugs.freedesktop.org/show_bug.cgi?id=110944
Bug ID: 110944
Summary: [Bisected] Blender 2.8 crashes when closing certain
windows
Product: Mesa
Version: 19.1
Hardware: x86-64 (AMD64)
OS: Linux (All)
Hi Ulrich,
On Tue, Jun 18, 2019 at 04:12:01PM +0200, Ulrich Hecht wrote:
> > On June 17, 2019 at 11:09 PM Laurent Pinchart wrote:
> >
> > Routing configuration for the DU is complex. Depending on the SoC
> > generation various routing options are available:
> >
> > - The VSP to DU routing is
On Tue, Jun 18, 2019 at 04:14:27PM +0200, Thomas Hellstrom wrote:
> On 6/18/19 3:27 PM, Daniel Vetter wrote:
> > On Tue, Jun 18, 2019 at 03:08:01PM +0200, Thomas Hellstrom wrote:
> > > On 6/18/19 2:19 PM, Daniel Vetter wrote:
> > > > On Tue, Jun 18, 2019 at 11:54:08AM +0100, Emil Velikov wrote:
>
On Tue, Jun 18, 2019 at 03:58:16PM +0200, Gerd Hoffmann wrote:
> Use gem reservation helpers and direct reservation_object_* calls
> instead of ttm.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/virtio/virtgpu_object.c | 28 +++--
> 1 file changed, 8
On Tue, Jun 18, 2019 at 04:16:04PM +0200, Daniel Vetter wrote:
> On Tue, Jun 18, 2019 at 03:58:15PM +0200, Gerd Hoffmann wrote:
> > Use gem reservation helpers and direct reservation_object_* calls
> > instead of ttm.
> >
> > Signed-off-by: Gerd Hoffmann
> > ---
> >
On Tue, Jun 18, 2019 at 3:27 AM Krzysztof Kozlowski wrote:
>
> On Sat, 15 Jun 2019 at 01:57, Joseph Kogut wrote:
> >
> > Add device tree node for mali gpu on Odroid XU3 SoCs.
> >
> > Signed-off-by: Joseph Kogut
> > ---
> >
> > Changes v1 -> v2:
> > - Use interrupt name ordering from binding doc
On Tue, Jun 18, 2019 at 03:58:15PM +0200, Gerd Hoffmann wrote:
> Use gem reservation helpers and direct reservation_object_* calls
> instead of ttm.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/virtio/virtgpu_ioctl.c | 36 --
> 1 file changed, 17
Den 18.06.2019 16.02, skrev Daniel Vetter:
> I rushed merging this a bit too much, and Noralf pointed out that
> we're a lot better already and have made great progress.
>
> Let's try again.
>
> Fixes: 42dbbb4b54a3 ("drm/todo: Add new debugfs todo")
> Cc: Greg Kroah-Hartman
> Cc: Daniel
On 6/18/19 3:27 PM, Daniel Vetter wrote:
On Tue, Jun 18, 2019 at 03:08:01PM +0200, Thomas Hellstrom wrote:
On 6/18/19 2:19 PM, Daniel Vetter wrote:
On Tue, Jun 18, 2019 at 11:54:08AM +0100, Emil Velikov wrote:
Hi Thomas,
On 2019/06/18, Thomas Hellström (VMware) wrote:
From: Thomas Hellstrom
Thank you for your patch.
> On June 17, 2019 at 11:09 PM Laurent Pinchart
> wrote:
>
>
> Routing configuration for the DU is complex. Depending on the SoC
> generation various routing options are available:
>
> - The VSP to DU routing is not available on Gen1, is configurable on
> Gen2 and
On Tue, Jun 18, 2019 at 03:58:14PM +0200, Gerd Hoffmann wrote:
> Call reservation_object_* directly instead
> of using ttm_bo_{reserve,unreserve}.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff
On Tue, Jun 18, 2019 at 03:58:10PM +0200, Gerd Hoffmann wrote:
> Use drm_gem_reservation_object_wait() in virtio_gpu_wait_ioctl().
> This also makes the ioctl run lockless.
>
> Signed-off-by: Gerd Hoffmann
> Reviewed-by: Daniel Vetter
Nit: Missing the v2 changelog here.
-Daniel
> ---
>
I rushed merging this a bit too much, and Noralf pointed out that
we're a lot better already and have made great progress.
Let's try again.
Fixes: 42dbbb4b54a3 ("drm/todo: Add new debugfs todo")
Cc: Greg Kroah-Hartman
Cc: Daniel Vetter
Cc: David Airlie
Cc: Daniel Vetter
Cc: Maarten Lankhorst
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
Use gem reservation helpers and direct reservation_object_* calls
instead of ttm.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_object.c | 28 +++--
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
Now with ttm initialization being out of the way we can simplify
virtio_gpu_object_create fencing even more. No need to check whenever
the command is still running after ttm_bo_init() returned. We have a
fully initialized gem bo before we kick off the resource creation
command, so we can simply
No users left.
Signed-off-by: Gerd Hoffmann
---
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/virtio/virtgpu_drv.h
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.
cheers,
Gerd
Gerd Hoffmann (12):
drm/virtio: pass gem reservation object to ttm init
drm/virtio: switch virtio_gpu_wait_ioctl() to gem helper.
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
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
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
All callers pass no_wait = false.
Signed-off-by: Gerd Hoffmann
---
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(-)
diff --git
Use gem reservation helpers and direct reservation_object_* calls
instead of ttm.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 36 --
1 file changed, 17 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
Thin wrapper around virtio_gpu_object_create(),
but calling that directly works equally well.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 4
drivers/gpu/drm/virtio/virtgpu_gem.c | 23 ---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 6
Call reservation_object_* directly instead
of using ttm_bo_{reserve,unreserve}.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
Use drm_gem_reservation_object_wait() in virtio_gpu_wait_ioctl().
This also makes the ioctl run lockless.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
diff
On Tue, Jun 18, 2019 at 10:33:58AM -0300, Mauro Carvalho Chehab wrote:
> There are three left-overs from the recent file renames,
> probably due to some other conflicting patch.
>
> Fix them.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
>
> This patch is against today's next-20190617 branch.
On Tue, Jun 18, 2019 at 04:26:51PM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Tue, Jun 18, 2019 at 03:21:55PM +0200, Daniel Vetter wrote:
> > On Tue, Jun 18, 2019 at 3:13 PM Laurent Pinchart
> > wrote:
> > >
> > > The recommended way to specify GEM object functions is to provide a
> > >
Den 18.06.2019 15.13, skrev Laurent Pinchart:
> The recommended way to specify GEM object functions is to provide a
> drm_gem_object_funcs structure instance and set the GEM object to point
> to it. The drm_cma_gem_create_object_default_funcs() function provided
> by the GEM CMA helper does so
> On June 17, 2019 at 11:09 PM Laurent Pinchart
> wrote:
>
>
> From: Kieran Bingham
>
> Create rcar_du_group_atomic_check() and rcar_du_group_atomic_setup()
> functions to track and apply group state through the DRM atomic state.
> The use_count field is moved from the rcar_du_group
Hi Ulrich,
On Tue, Jun 18, 2019 at 02:32:13PM +0200, Ulrich Hecht wrote:
> > On June 17, 2019 at 11:09 PM Laurent Pinchart
> > wrote:
> >
> > From: Kieran Bingham
> >
> > Break vsp1_du_setup_lif() into components more suited to the DRM Atomic
> > API. The existing vsp1_du_setup_lif() API
On Tue, Jun 18, 2019 at 10:33:58AM -0300, Mauro Carvalho Chehab wrote:
> There are three left-overs from the recent file renames,
> probably due to some other conflicting patch.
>
> Fix them.
>
> Signed-off-by: Mauro Carvalho Chehab
Thanks!
Acked-by: Wolfram Sang
signature.asc
On Fri, 2019-06-14 at 13:05 -0700, Doug Anderson wrote:
> Hi,
>
> On Thu, Jun 13, 2019 at 12:23 PM Ezequiel Garcia
> wrote:
> > @@ -1744,6 +1793,41 @@ int rockchip_drm_wait_vact_end(struct drm_crtc
> > *crtc, unsigned int mstimeout)
> > }
> > EXPORT_SYMBOL(rockchip_drm_wait_vact_end);
> >
>
> On June 17, 2019 at 11:09 PM Laurent Pinchart
> wrote:
>
>
> From: Kieran Bingham
>
> Create a new private state object for the DU groups, and move the
> initialisation of a group object to a new function rcar_du_group_init().
>
> Signed-off-by: Kieran Bingham
> Signed-off-by: Laurent
On Thu, 2019-06-13 at 15:36 -0400, Ilia Mirkin wrote:
> Note that userspace may provide any size of gamma lut. Have a look at
> i915/intel_color.c:intel_color_check which filters out only the
> allowed sizes. Consider having a special allowance for 256-sized LUTs
> since that's what most legacy
There are three left-overs from the recent file renames,
probably due to some other conflicting patch.
Fix them.
Signed-off-by: Mauro Carvalho Chehab
---
This patch is against today's next-20190617 branch. Not sure if it
will apply cleanly at -docs tree. If not, Please let me know for me to
This patch adds Raydium RM67191 TFT LCD panel driver (MIPI-DSI
protocol).
Signed-off-by: Robert Chiras
---
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-raydium-rm67191.c | 709 ++
Add dt-bindings documentation for Raydium RM67191 DSI panel.
Signed-off-by: Robert Chiras
---
.../bindings/display/panel/raydium,rm67191.txt | 43 ++
1 file changed, 43 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt
This patch-set contains the DRM panel driver and dt-bindings documentation
for the DSI driven panel: Raydium RM67191.
Changes since v1:
- Fixed 'reset-gpio' to 'reset-gpios' property naming
- Changed the state of the reset gpio to active low and fixed how it is
handled in driver
- Fixed
On 6/18/19 12:54 PM, Emil Velikov wrote:
Hi Thomas,
On 2019/06/18, Thomas Hellström (VMware) wrote:
From: Thomas Hellstrom
TTM provides a means to assign eviction priorities to buffer object. This
means that all buffer objects with a lower priority will be evicted first
on memory pressure.
Hi Daniel,
On Tue, Jun 18, 2019 at 03:21:55PM +0200, Daniel Vetter wrote:
> On Tue, Jun 18, 2019 at 3:13 PM Laurent Pinchart
> wrote:
> >
> > The recommended way to specify GEM object functions is to provide a
> > drm_gem_object_funcs structure instance and set the GEM object to point
> > to
On Tue, Jun 18, 2019 at 03:08:01PM +0200, Thomas Hellstrom wrote:
> On 6/18/19 2:19 PM, Daniel Vetter wrote:
> > On Tue, Jun 18, 2019 at 11:54:08AM +0100, Emil Velikov wrote:
> > > Hi Thomas,
> > >
> > > On 2019/06/18, Thomas Hellström (VMware) wrote:
> > > > From: Thomas Hellstrom
> > > >
> >
On Tue, Jun 18, 2019 at 3:13 PM Laurent Pinchart
wrote:
>
> The recommended way to specify GEM object functions is to provide a
> drm_gem_object_funcs structure instance and set the GEM object to point
> to it. The drm_cma_gem_create_object_default_funcs() function provided
> by the GEM CMA
The copy_from_user() function returns the number of bytes remaining
to be copied but we want to return a negative error code. Otherwise
the callers treat it as a successful copy.
Signed-off-by: Dan Carpenter
---
v2: The first version was missing a chunk
drivers/gpu/drm/drm_bufs.c | 5 -
On Tue, Jun 18, 2019 at 2:31 PM Chris Wilson wrote:
> Quoting Daniel Vetter (2019-06-14 21:36:04)
> > It looks like this was done purely to get a consistent place to look
> > up the reservation object pointer. With the drm_prime.c helper code
> > now also setting gem_object->resv for imported
On Fri, Jun 14, 2019 at 10:35:55PM +0200, Daniel Vetter wrote:
> They're the default.
>
> Aside: Would be really nice to switch the others over to
> drm_gem_object_funcs.
>
> Signed-off-by: Daniel Vetter
> Cc: Shawn Guo
Acked-by: Shawn Guo
> ---
> drivers/gpu/drm/zte/zx_drm_drv.c | 2 --
>
> On June 17, 2019 at 11:09 PM Laurent Pinchart
> wrote:
>
>
> From: Kieran Bingham
>
> Refactoring of the group control code will soon require more iteration
> over the available groups. Simplify this process by introducing a group
> iteration helper.
>
> Signed-off-by: Kieran Bingham
>
The recommended way to specify GEM object functions is to provide a
drm_gem_object_funcs structure instance and set the GEM object to point
to it. The drm_cma_gem_create_object_default_funcs() function provided
by the GEM CMA helper does so when creating the GEM object, simplifying
the driver
> On June 17, 2019 at 11:09 PM Laurent Pinchart
> wrote:
>
>
> From: Kieran Bingham
>
> The CRTC mode setting and routing configuration are performed at the
> earliest of atomic enable and atomic begin, to ensure that a valid
> configuration is applied to the hardware before the CRTC gets
On 6/18/19 2:19 PM, Daniel Vetter wrote:
On Tue, Jun 18, 2019 at 11:54:08AM +0100, Emil Velikov wrote:
Hi Thomas,
On 2019/06/18, Thomas Hellström (VMware) wrote:
From: Thomas Hellstrom
TTM provides a means to assign eviction priorities to buffer object. This
means that all buffer objects
> On June 17, 2019 at 11:09 PM Laurent Pinchart
> wrote:
>
>
> From: Kieran Bingham
>
> Manage the power state, and initial configuration of the CRTC from the
> commit tail handler. CRTCs which need to be activated are taken out of
> standby, and any deactivated CRTCs are put into standby.
The copy_to_user() function returns the number of bytes remaining to be
copied, but we want to return -EFAULT. This function is called from
__drm_legacy_infobufs() which expects negative error codes.
Fixes: 5c7640ab6258 ("switch compat_drm_infobufs() to drm_ioctl_kernel()")
Signed-off-by: Dan
Hi,
On Fri, 2019-05-17 at 17:05 +0200, Paul Kocialkowski wrote:
> On a trivial gpio-backlight setup with a panel using the backlight but
> no boot software to enable it beforehand, we fall in a case where the
> backlight is disabled (not just blanked) and thus remains disabled when
> the panel
https://bugs.freedesktop.org/show_bug.cgi?id=110831
Sylvain BERTRAND changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
> On June 17, 2019 at 11:09 PM Laurent Pinchart
> wrote:
>
>
> From: Kieran Bingham
>
> The vsp1_du_setup_lif() function is deprecated, and the users have been
> removed. Remove the implementation and the associated configuration
> structure.
>
> Signed-off-by: Kieran Bingham
>
> On June 17, 2019 at 11:09 PM Laurent Pinchart
> wrote:
>
>
> From: Kieran Bingham
>
> The configuration API between the VSP and the DU has been updated to
> provide finer grain control over modesetting, and enablement.
>
> Split rcar_du_vsp_enable() into rcar_du_vsp_modeset() and
>
> On June 17, 2019 at 11:09 PM Laurent Pinchart
> wrote:
>
>
> The vsp1_du_atomic_flush() function calls vsp1_du_pipeline_configure()
> to configure the hardware pipeline. The function is currently guaranteed
> to be called with the pipeline enabled, but this will change by future
> rework
Thank you for your patch.
> On June 17, 2019 at 11:09 PM Laurent Pinchart
> wrote:
>
>
> From: Kieran Bingham
>
> Break vsp1_du_setup_lif() into components more suited to the DRM Atomic
> API. The existing vsp1_du_setup_lif() API call is maintained as it is
> still used from the DU.
>
>
Hi Laurent,
On 17/06/2019 22:09, Laurent Pinchart wrote:
> The vsp1_du_atomic_flush() function calls vsp1_du_pipeline_configure()
> to configure the hardware pipeline. The function is currently guaranteed
> to be called with the pipeline enabled, but this will change by future
> rework of the DU
Quoting Daniel Vetter (2019-06-14 21:36:04)
> It looks like this was done purely to get a consistent place to look
> up the reservation object pointer. With the drm_prime.c helper code
> now also setting gem_object->resv for imported objects we can just use
> that pointer directly, instead of
Thanks!
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Jun 18, 2019 at 11:54:08AM +0100, Emil Velikov wrote:
> Hi Thomas,
>
> On 2019/06/18, Thomas Hellström (VMware) wrote:
> > From: Thomas Hellstrom
> >
> > TTM provides a means to assign eviction priorities to buffer object. This
> > means that all buffer objects with a lower priority
On Tue, Jun 18, 2019 at 02:01:35PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Jun 14, 2019 at 05:37:58PM +0200, Daniel Vetter wrote:
> > On Fri, Jun 14, 2019 at 5:20 PM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Fri, Jun 14, 2019 at 04:59:08PM +0200, Daniel Vetter wrote:
> > > > On Fri, Jun 14,
On Tue, Jun 18, 2019 at 07:48:06PM +0800, Cheng-yi Chiang wrote:
> On Tue, Jun 11, 2019 at 8:35 PM Daniel Vetter wrote:
> >
> > On Tue, Jun 11, 2019 at 08:10:38PM +0800, Cheng-yi Chiang wrote:
> > > On Tue, Jun 4, 2019 at 3:24 PM Daniel Vetter wrote:
> > > >
> > > > On Tue, Jun 04, 2019 at
On Tue, Jun 18, 2019 at 5:13 PM Chen-Yu Tsai wrote:
>
> On Tue, Jun 18, 2019 at 6:51 PM Jagan Teki wrote:
> >
> > On Fri, Jun 14, 2019 at 8:15 PM Maxime Ripard
> > wrote:
> > >
> > > On Fri, Jun 14, 2019 at 12:03:13PM +0530, Jagan Teki wrote:
> > > > On Thu, Jun 13, 2019 at 6:56 PM Maxime
On Fri, Jun 14, 2019 at 05:37:58PM +0200, Daniel Vetter wrote:
> On Fri, Jun 14, 2019 at 5:20 PM Greg Kroah-Hartman
> wrote:
> >
> > On Fri, Jun 14, 2019 at 04:59:08PM +0200, Daniel Vetter wrote:
> > > On Fri, Jun 14, 2019 at 11:51:09AM +0200, Greg Kroah-Hartman wrote:
> > > > The function can
Pipeline removal of the BOs backing store when no placement is given
during validation.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index
This way we can even pipeline imported BO evictions.
v2: Limit this to only cases when the parent object uses a separate
reservation object as well. This fixes another OOM problem.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 20 +++-
1 file
On Tue, Jun 11, 2019 at 9:11 PM Hans Verkuil wrote:
>
> On 6/11/19 2:10 PM, Cheng-yi Chiang wrote:
> > On Tue, Jun 4, 2019 at 3:24 PM Daniel Vetter wrote:
> >>
> >> On Tue, Jun 04, 2019 at 10:32:50AM +0800, Cheng-yi Chiang wrote:
> >>> On Mon, Jun 3, 2019 at 4:09 PM Daniel Vetter wrote:
>
Instead of relying on the DRM functions just implement our own import
functions. This prepares support for taking care of unpinned DMA-buf.
v2: enable for all exporters, not just amdgpu, fix invalidation
handling, lock reservation object while setting callback
v3: change to new dma_buf attach
We need to handle the case when of_drm_find_bridge() returns
NULL.
Reported-by: Dan Carpenter
Cc: Dan Carpenter
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Account for both NULL and error pointers by two clauses.
---
drivers/gpu/drm/mcde/mcde_drv.c | 6 +-
1 file changed, 5
Avoid that we ping/pong the buffers when we stop to pin DMA-buf
exports by using the allowed domains for exported buffers.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
On the exporter side we add optional explicit pinning callbacks. If those
callbacks are implemented the framework no longer caches sg tables and the
map/unmap callbacks are always called with the lock of the reservation object
held.
On the importer side we add an optional invalidate callback.
The caching of SGT's is actually quite harmful and should probably removed
altogether when all drivers are audited.
Start by providing a separate DMA-buf export implementation in amdgpu.
This is also a prerequisite of unpinned DMA-buf handling.
v2: fix unintended recursion, remove debugging
On Tue, Jun 11, 2019 at 8:35 PM Daniel Vetter wrote:
>
> On Tue, Jun 11, 2019 at 08:10:38PM +0800, Cheng-yi Chiang wrote:
> > On Tue, Jun 4, 2019 at 3:24 PM Daniel Vetter wrote:
> > >
> > > On Tue, Jun 04, 2019 at 10:32:50AM +0800, Cheng-yi Chiang wrote:
> > > > On Mon, Jun 3, 2019 at 4:09 PM
Op 18-06-2019 om 13:17 schreef Bartlomiej Zolnierkiewicz:
> Hi,
>
> On 6/18/19 11:20 AM, Maarten Lankhorst wrote:
>> Op 14-06-2019 om 11:25 schreef Maarten Lankhorst:
>>> Hi all,
>>>
>>> As discussed with Daniel V, I'm just doing the paperwork here as drm-misc
>>> maintainer.
>>>
>>> This is the
On Tue, Jun 18, 2019 at 6:51 PM Jagan Teki wrote:
>
> On Fri, Jun 14, 2019 at 8:15 PM Maxime Ripard
> wrote:
> >
> > On Fri, Jun 14, 2019 at 12:03:13PM +0530, Jagan Teki wrote:
> > > On Thu, Jun 13, 2019 at 6:56 PM Maxime Ripard
> > > wrote:
> > > >
> > > > On Wed, Jun 05, 2019 at 01:17:11PM
On Tue, 18 Jun 2019, Daniel Vetter wrote:
> On Tue, Jun 18, 2019 at 11:03:47AM +0100, Lee Jones wrote:
> > On Tue, 18 Jun 2019, Maarten Lankhorst wrote:
> >
> > > Op 14-06-2019 om 11:25 schreef Maarten Lankhorst:
> > > > Hi all,
> > > >
> > > > As discussed with Daniel V, I'm just doing the
Hi,
On 6/18/19 11:20 AM, Maarten Lankhorst wrote:
> Op 14-06-2019 om 11:25 schreef Maarten Lankhorst:
>> Hi all,
>>
>> As discussed with Daniel V, I'm just doing the paperwork here as drm-misc
>> maintainer.
>>
>> This is the topic pull request for the fbdev notifier removal.
>>
>> Bar, please
On Tue, Jun 18, 2019 at 07:56:23AM +, Simon Ser wrote:
> Interestingly, even with the previous code, possible_crtcs=1 was
> exposed to userspace [1]. I think this is because of a safeguard in
> drm_crtc_init_with_planes (drm_crtc.c:284) which sets the primary and
> cursor plane's
https://bugs.freedesktop.org/show_bug.cgi?id=110831
--- Comment #5 from Sylvain BERTRAND ---
Did update the amd-staging-drm-next branch earlier today. The hanging boot is
gone. Did a quick check: your patch was already applied. So it probably did fix
it.
--
You are receiving this mail because:
On Fri, Jun 14, 2019 at 7:58 PM Maxime Ripard wrote:
>
> On Thu, Jun 13, 2019 at 01:34:04PM +0530, Jagan Teki wrote:
> > On Fri, May 31, 2019 at 12:23 AM Maxime Ripard
> > wrote:
> > >
> > > On Fri, May 24, 2019 at 03:55:42PM +0530, Jagan Teki wrote:
> > > > On Fri, May 24, 2019 at 2:07 AM
Hi Thomas,
On 2019/06/18, Thomas Hellström (VMware) wrote:
> From: Thomas Hellstrom
>
> TTM provides a means to assign eviction priorities to buffer object. This
> means that all buffer objects with a lower priority will be evicted first
> on memory pressure.
> Use this to make sure surfaces
On Tue, Jun 18, 2019 at 6:34 PM Jagan Teki wrote:
>
> On Tue, Jun 18, 2019 at 1:23 PM Chen-Yu Tsai wrote:
> >
> > On Tue, Jun 18, 2019 at 3:45 PM Jagan Teki
> > wrote:
> > >
> > > On Tue, Jun 18, 2019 at 12:49 PM Chen-Yu Tsai wrote:
> > > >
> > > > On Mon, Jun 17, 2019 at 6:30 PM Jagan Teki
101 - 200 of 270 matches
Mail list logo
