>From anx7625 spec, the delay between powering on power supplies and gpio
should be larger than 10ms.
Fixes: 6c744983004e ("drm/bridge: anx7625: disable regulators when power off")
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 2 +-
1 file changed, 1 insertion(+),
On Mon, Apr 26, 2021 at 11:33 PM Ville Syrjälä
wrote:
>
> On Mon, Apr 26, 2021 at 01:18:47PM +0800, Hsin-Yi Wang wrote:
> > drm_dev_register() sets connector->registration_state to
> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > drm_connector_set_panel_orientation() is first
krane, kakadu, and kodama boards have a default panel rotation.
Signed-off-by: Hsin-Yi Wang
---
arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
Init panel orientation property after connector is initialized. Let the
panel driver decides the orientation value later.
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
drm_dev_register() sets connector->registration_state to
DRM_CONNECTOR_REGISTERED and dev->registered to true. If
drm_connector_set_panel_orientation() is first called after
drm_dev_register(), it will fail several checks and results in following
warning.
Add a function to create panel
Am 2021-04-26 um 8:35 p.m. schrieb Zeng, Oak:
> Regards,
> Oak
>
>
>
> On 2021-04-21, 9:31 PM, "amd-gfx on behalf of Felix Kuehling"
>
> wrote:
>
> Use DMABufs with dynamic attachment to DMA-map GTT BOs on other GPUs.
>
> Signed-off-by: Felix Kuehling
> ---
>
Am 2021-04-26 um 8:23 p.m. schrieb Zeng, Oak:
> Regards,
> Oak
>
>
>
> On 2021-04-21, 9:31 PM, "dri-devel on behalf of Felix Kuehling"
>
> wrote:
>
> DMA map kfd_mem_attachments in update_gpuvm_pte. This function is called
> with the BO and page tables reserved, so we can safely
Am 2021-04-26 um 8:09 p.m. schrieb Zeng, Oak:
> As I understand it, when one GPU map another GPU's vram, this vram should
> also be mapped in iommu page table. Also normal GTT memory (versus userptr)
> also need to be mapped in iommu. But don't see this code below.
Right, I'm not solving all
Regards,
Oak
On 2021-04-21, 9:31 PM, "amd-gfx on behalf of Felix Kuehling"
wrote:
Use DMABufs with dynamic attachment to DMA-map GTT BOs on other GPUs.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 2 +
On Sat, 24 Apr 2021 at 04:43, Lyude Paul wrote:
>
> Since it's been asked quite a few times on some of the various DP
> related patch series I've submitted to use the new DRM printk helpers,
> and it technically wasn't really trivial to do this before due to the
> lack of a consistent way to find
Regards,
Oak
On 2021-04-21, 9:31 PM, "dri-devel on behalf of Felix Kuehling"
wrote:
DMA map kfd_mem_attachments in update_gpuvm_pte. This function is called
with the BO and page tables reserved, so we can safely update the DMA
mapping.
DMA unmap when a BO is unmapped
Instead of looping throught the resources each time to get the DSI CTRL
area size, get it at the ioremap time.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 5 +++--
drivers/gpu/drm/msm/msm_drv.c | 27 +--
drivers/gpu/drm/msm/msm_drv.h
Add DSI PHY registers to the msm state snapshots to be able to check
their contents.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi.c | 1 +
drivers/gpu/drm/msm/dsi/dsi.h | 1 +
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 31 +++
Instead of always getting the disp_state from drm device, pass it as an
argument.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 5 +
drivers/gpu/drm/msm/disp/msm_disp_snapshot.h| 8
Instead of allocating snapshotting structure at the driver probe time
and later handling concurrent access, actual state, etc, make
msm_disp_state transient struct. Allocate one when snapshotting happens
and free it after coredump data is read by userspace.
Signed-off-by: Dmitry Baryshkov
---
Rework MSM coredump support: add DSI PHY registers, simplify
snapshotting code.
Changes since v1:
- Readd mutex serializing register snapshot calls
- Add DSI PHY register dumping support
Dmitry Baryshkov (4):
drm/msm: pass
As I understand it, when one GPU map another GPU's vram, this vram should also
be mapped in iommu page table. Also normal GTT memory (versus userptr) also
need to be mapped in iommu. But don't see this code below. I only see you map
userptr in iommu. Maybe you map them in iommu not during
From: Rob Clark
Our initial logic for excluding dma-bufs was not quite right. In
particular we want msm_gem_get/put_pages() path used for exported
dma-bufs to increment/decrement the pin-count.
Also, in case the importer is vmap'ing the dma-buf, we need to be
sure to update the object's
Sadly, we can't have this patch as long as we support SUBMIT_FENCE.
Turns out this is used for something real. :-(
--Jason
On Fri, Apr 23, 2021 at 5:31 PM Jason Ekstrand wrote:
>
> This was only ever used for bonded virtual engine execution. Since
> that's no longer allowed, this is dead code.
This adds a bunch of complexity which the media driver has never
actually used. The media driver does technically bond a balanced engine
to another engine but the balanced engine only has one engine in the
sibling set. This doesn't actually result in a virtual engine.
Unless some userspace
On 2021-04-26 15:14, Dmitry Baryshkov wrote:
On Tue, 27 Apr 2021 at 01:03, wrote:
On 2021-04-26 14:23, Dmitry Baryshkov wrote:
> On 26/04/2021 23:50, abhin...@codeaurora.org wrote:
>> On 2021-04-25 09:08, Dmitry Baryshkov wrote:
>>> Instead of allocating snapshotting structure at the driver
On Tue, 27 Apr 2021 at 01:03, wrote:
>
> On 2021-04-26 14:23, Dmitry Baryshkov wrote:
> > On 26/04/2021 23:50, abhin...@codeaurora.org wrote:
> >> On 2021-04-25 09:08, Dmitry Baryshkov wrote:
> >>> Instead of allocating snapshotting structure at the driver probe time
> >>> and later handling
On 2021-04-26 14:23, Dmitry Baryshkov wrote:
On 26/04/2021 23:50, abhin...@codeaurora.org wrote:
On 2021-04-25 09:08, Dmitry Baryshkov wrote:
Instead of allocating snapshotting structure at the driver probe time
and later handling concurrent access, actual state, etc, make
msm_disp_state
On 26/04/2021 23:50, abhin...@codeaurora.org wrote:
On 2021-04-25 09:08, Dmitry Baryshkov wrote:
Instead of allocating snapshotting structure at the driver probe time
and later handling concurrent access, actual state, etc, make
msm_disp_state transient struct. Allocate one when snapshotting
On Mon, 26 Apr 2021 11:29:15 +0530, Rajeev Nandan wrote:
> Add bindings for DisplayPort aux backlight driver.
>
> Changes in v2:
> - New
>
> Signed-off-by: Rajeev Nandan
> ---
> .../bindings/leds/backlight/dp-aux-backlight.yaml | 49
> ++
> 1 file changed, 49
Thanks everybody. The initial proposal is dead. Here are some thoughts on
how to do it differently.
I think we can have direct command submission from userspace via
memory-mapped queues ("user queues") without changing window systems.
The memory management doesn't have to use GPU page faults
On 2021-04-25 09:08, Dmitry Baryshkov wrote:
Instead of allocating snapshotting structure at the driver probe time
and later handling concurrent access, actual state, etc, make
msm_disp_state transient struct. Allocate one when snapshotting happens
and free it after coredump data is read by
On 2021-04-25 09:07, Dmitry Baryshkov wrote:
Instead of always getting the disp_state from drm device, pass it as an
argument.
Signed-off-by: Dmitry Baryshkov
This certainly reduces some amount of code, I am onboard with this,
hence:
Reviewed-by: Abhinav Kumar
---
The last useful member in this struct is the supported_type_groups, move
it to the mdev_driver and delete mdev_parent_ops.
Replace it with mdev_driver as an argument to mdev_register_device()
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
While there is a confusing mess of pointers and structs in this driver,
the struct kvmgt_vdev (which in turn is 1:1 with a struct intel_vgpu) is
what holds the vfio_device. Replace all the drvdata's and weird
derivations of vgpu and vdev with container_of() or vdev->vgpu.
Signed-off-by: Jason
drm_send_event_helper() has not prototype, it has internal linkage and
therefore it should be defined with storage class 'static'.
Signed-off-by: Fabio M. De Francesco
---
Changes from v1: As suggested by Daniel Vetter, removed unnecessary
kernel-doc comments.
drivers/gpu/drm/drm_file.c | 10
For some reason the vfio_mdev shim mdev_driver has its own module and
kconfig. As the next patch requires access to it from mdev.ko merge the
two modules together and remove VFIO_MDEV_DEVICE.
A later patch deletes this driver entirely.
Signed-off-by: Jason Gunthorpe
---
The mdev bus's core part for managing the lifecycle of devices is mostly
as one would expect for a driver core bus subsystem.
However instead of having a normal 'struct device_driver' and binding the
actual mdev drivers through the standard driver core mechanisms it open
codes this with the
Am 26.04.21 um 21:36 schrieb Ruhl, Michael J:
-Original Message-
From: dri-devel On Behalf Of
Christian König
Sent: Monday, April 26, 2021 1:58 PM
To: dri-devel@lists.freedesktop.org
Cc: bske...@redhat.com
Subject: [PATCH] drm/ttm: cleanup ttm_agp_backend
Audit the includes and stop
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Monday, April 26, 2021 1:58 PM
>To: dri-devel@lists.freedesktop.org
>Cc: bske...@redhat.com
>Subject: [PATCH] drm/ttm: cleanup ttm_agp_backend
>
>Audit the includes and stop accessing the internal drm_mm_node.
>
drm_modeset_lock_all() is not needed here, so it is replaced with
drm_modeset_lock(). The crtc list around which we are looping never
changes, therefore the only lock we need is to protect access to
crtc->state.
Suggested-by: Daniel Vetter
Suggested-by: Matthew Wilcox
Signed-off-by: Fabio M. De
On 4/26/21 11:26 AM, Jason Gunthorpe wrote:
> On Fri, Apr 23, 2021 at 05:08:10PM -0700, Randy Dunlap wrote:
>> On 4/23/21 4:02 PM, Jason Gunthorpe wrote:
>>> @@ -171,7 +171,7 @@ config SAMPLE_VFIO_MDEV_MDPY_FB
>>>
>>> config SAMPLE_VFIO_MDEV_MBOCHS
>>> tristate "Build VFIO mdpy example
On Mon, Apr 26, 2021 at 02:56:26PM -0400, Harry Wentland wrote:
> On 2021-04-26 2:07 p.m., Ville Syrjälä wrote:
> > On Mon, Apr 26, 2021 at 01:38:50PM -0400, Harry Wentland wrote:
> >> From: Bhawanpreet Lakha
> >>
> >> Add the following color encodings
> >> - RGB versions for BT601, BT709, BT2020
On Monday, April 26, 2021 6:11:11 PM CEST Daniel Vetter wrote:
> On Thu, Apr 22, 2021 at 05:50:34PM +0100, Matthew Wilcox wrote:
> > On Thu, Apr 22, 2021 at 05:59:51PM +0200, Fabio M. De Francesco wrote:
> > > - drm_modeset_lock_all(drm_dev);
> > > -
> > >
> > >
Hi Thomas,
On Mon, Apr 26, 2021 at 2:22 PM Thomas Zimmermann wrote:
> Am 20.04.21 um 11:27 schrieb Geert Uytterhoeven:
> > On Tue, Apr 20, 2021 at 11:22 AM Gerd Hoffmann wrote:
> > Patches 4 to 8 add the simpledrm driver. It's build on simple DRM
> > helpers
> > and SHMEM. It
On 2021-04-26 2:07 p.m., Ville Syrjälä wrote:
On Mon, Apr 26, 2021 at 01:38:50PM -0400, Harry Wentland wrote:
From: Bhawanpreet Lakha
Add the following color encodings
- RGB versions for BT601, BT709, BT2020
- DCI-P3: Used for digital movies
Signed-off-by: Bhawanpreet Lakha
Signed-off-by:
On 2021-04-26 8:15, Nirmoy wrote:
> Reviewed-by: Nirmoy Das
>
> On 4/26/21 2:13 PM, Colin King wrote:
>> From: Colin Ian King
>>
>> There is a spelling mistake in a pr_debug message. Fix it.
>>
>> Signed-off-by: Colin Ian King
Applied to amd-staging-drm-next.
Thanks,
Felix
>> ---
>>
Hi
Am 21.04.21 um 10:08 schrieb Takashi Iwai:
On bochs DRM driver, the execution of "setterm --blank force" results
in a frozen screen instead of a blank screen. It's due to the lack of
the screen blanking support in its code.
Actually, the QEMU bochs vga side can switch to the blanking mode
isplay/intel_panel.c |2 +-
drivers/gpu/drm/i915/display/intel_panel.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- linux-next-20210426.orig/drivers/gpu/drm/i915/display/intel_panel.c
+++ linux-next-20210426/drivers/gpu/drm/i915/display/intel_panel.c
@@ -12
On Mon, Apr 26, 2021 at 04:19:11PM +0200, Christoph Hellwig wrote:
> > +The mediated bus driver's probe function should create a vfio_device on
> > top of
> > +the mdev_device and connect it to an appropriate implementation of
> > vfio_device_ops.
>
> Overly long line.
>
> > +This will provide
On Fri, Apr 23, 2021 at 05:08:10PM -0700, Randy Dunlap wrote:
> On 4/23/21 4:02 PM, Jason Gunthorpe wrote:
> > @@ -171,7 +171,7 @@ config SAMPLE_VFIO_MDEV_MDPY_FB
> >
> > config SAMPLE_VFIO_MDEV_MBOCHS
> > tristate "Build VFIO mdpy example mediated device sample code --
> > loadable
On Mon, Apr 26, 2021 at 01:38:50PM -0400, Harry Wentland wrote:
> From: Bhawanpreet Lakha
>
> Add the following color encodings
> - RGB versions for BT601, BT709, BT2020
> - DCI-P3: Used for digital movies
>
> Signed-off-by: Bhawanpreet Lakha
> Signed-off-by: Harry Wentland
> ---
>
Am 21.04.21 um 19:04 schrieb Takashi Iwai:
The commit 7cbb93d89838 ("drm/ast: Use managed pci functions")
converted a few PCI accessors to the managed API and dropped the
manual pci_iounmap() calls, but it seems to have forgotten converting
pci_iomap() to the managed one. It resulted in the
Audit the includes and stop accessing the internal drm_mm_node.
The ttm_resource::start should be the same value as the
drm_mm_node::start.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_agp_backend.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
On Mon, Apr 26, 2021 at 06:43:14PM +0200, Christian Borntraeger wrote:
> On 24.04.21 01:02, Jason Gunthorpe wrote:
> > Prologue
> >
> >
> > This is series #3 in part of a larger work that arose from the minor
> > remark that the mdev_parent_ops indirection shim is useless and
> >
From: Bhawanpreet Lakha
Due to the way displays and human vision work it is most effective to
encode luminance information in a non-linear space.
For SDR this non-linear mapping is assumed to roughly use a gamma 2.2 curve.
This was due to the way CRTs worked and was fine for SDR content with a
From: Bhawanpreet Lakha
SDR is typically mastered at 200 nits and HDR is mastered at up to 10,000
nits. Due to this luminance range difference if we blend a SDR and
HDR plane together, we can run into problems where the HDR plane is too
bright or the SDR plane is too dim
A common solution to
From: Bhawanpreet Lakha
Add the following color encodings
- RGB versions for BT601, BT709, BT2020
- DCI-P3: Used for digital movies
Signed-off-by: Bhawanpreet Lakha
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/drm_color_mgmt.c | 4
include/drm/drm_color_mgmt.h | 4
2 files
## Introduction
We are looking to enable HDR support for a couple of single-plane and
multi-plane scenarios. To do this effectively we recommend new interfaces to
drm_plane. Below I'll give a bit of background on HDR and why we propose these
interfaces.
## Defining a pixel's luminance
On 24.04.21 01:02, Jason Gunthorpe wrote:
Prologue
This is series #3 in part of a larger work that arose from the minor
remark that the mdev_parent_ops indirection shim is useless and
complicates things.
It applies on top of Alex's current tree and requires the prior two
series.
On 04/26, Daniel Vetter wrote:
> On Mon, Apr 26, 2021 at 11:03:15AM +0300, Pekka Paalanen wrote:
> > On Sat, 24 Apr 2021 05:25:31 -0300
> > Melissa Wen wrote:
> >
> > > Add support for composing XRGB888 planes in addition to the ARGB
> > > format. In the case of an XRGB plane at the top, the
On 4/26/21 7:58 AM, Simon Ser wrote:
> On Monday, April 26th, 2021 at 9:36 AM, Pekka Paalanen
> wrote:
>
This should probably explain what the bits in the mask correspond to.
As in, which CRTC does bit 0 refer to, and so on.
>>>
>>> What about:
>>>
>>> "possible_crtcs: Bitmask of
On Mon, Apr 26, 2021 at 06:08:59PM +0200, Daniel Vetter wrote:
> On Thu, Apr 22, 2021 at 04:11:22PM +0300, Ville Syrjälä wrote:
> > On Thu, Apr 22, 2021 at 11:49:43AM +0200, Daniel Vetter wrote:
> > > On Wed, Apr 21, 2021 at 06:34:01PM +0300, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > >
On 04/26, Pekka Paalanen wrote:
> On Sat, 24 Apr 2021 05:26:10 -0300
> Melissa Wen wrote:
>
> > Add support to overlay plane, in addition to primary and cursor
> > planes. In this approach, the plane composition still requires an
> > active primary plane and planes are composed associatively in
Our code analyzer reported a double free bug.
In gen8_preallocate_top_level_pdp, pde and pde->pt.base are allocated
via alloc_pd(vm) with one reference. If pin_pt_dma() failed, pde->pt.base
is freed by i915_gem_object_put() with a reference dropped. Then free_pd
calls free_px() defined in
On Fri, Apr 23, 2021 at 9:31 PM Robin Murphy wrote:
>
> On 2021-04-22 09:15, Claire Chang wrote:
> > Update is_swiotlb_active to add a struct device argument. This will be
> > useful later to allow for restricted DMA pool.
> >
> > Signed-off-by: Claire Chang
> > ---
> >
On Fri, Apr 23, 2021 at 9:35 PM Robin Murphy wrote:
>
> On 2021-04-22 09:15, Claire Chang wrote:
> > 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
> > ---
> >
On 26/04/2021 16:22, Tvrtko Ursulin wrote:
On 26/04/2021 11:18, Matthew Auld wrote:
It's a requirement that for dgfx we place all the paging structures in
device local-memory.
v2: use i915_coherent_map_type()
Signed-off-by: Matthew Auld
Cc: Tvrtko Ursulin
---
On Fri, Apr 23, 2021 at 7:34 PM Steven Price wrote:
>
> On 22/04/2021 09:14, Claire Chang wrote:
> > Add the initialization function to create restricted DMA pools from
> > matching reserved-memory nodes.
> >
> > Signed-off-by: Claire Chang
> > ---
> > include/linux/device.h | 4 +++
> >
On Mon, Apr 26, 2021 at 11:25:09AM -0500, Jason Ekstrand wrote:
> On Mon, Apr 26, 2021 at 10:31 AM Matthew Auld wrote:
> >
> > On 26/04/2021 16:11, Jason Ekstrand wrote:
> > > On Mon, Apr 26, 2021 at 4:42 AM Matthew Auld
> > > wrote:
> > >>
> > >> Add an entry for the new uAPI needed for DG1.
On Mon, Apr 26, 2021 at 11:03:15AM +0300, Pekka Paalanen wrote:
> On Sat, 24 Apr 2021 05:25:31 -0300
> Melissa Wen wrote:
>
> > Add support for composing XRGB888 planes in addition to the ARGB
> > format. In the case of an XRGB plane at the top, the composition consists
> > of copying the
On Mon, Apr 26, 2021 at 10:31 AM Matthew Auld wrote:
>
> On 26/04/2021 16:11, Jason Ekstrand wrote:
> > On Mon, Apr 26, 2021 at 4:42 AM Matthew Auld wrote:
> >>
> >> Add an entry for the new uAPI needed for DG1. Also add the overall
> >> upstream plan, including some notes for the TTM
On 26/04/2021 16:20, Tvrtko Ursulin wrote:
On 26/04/2021 11:18, Matthew Auld wrote:
We need to general our accessor for the page directories and tables from
Generalise?
using the simple kmap_atomic to support local memory, and this setup
must be done on acquisition of the backing storage
On Thu, Apr 22, 2021 at 07:51:46PM +0200, Fabio M. De Francesco wrote:
> drm_send_event_helper() has not prototype, it has internal linkage and
> therefore it should be defined with storage class 'static'.
>
> Signed-off-by: Fabio M. De Francesco
> ---
> drivers/gpu/drm/drm_file.c | 2 +-
> 1
On Thu, Apr 22, 2021 at 05:50:34PM +0100, Matthew Wilcox wrote:
> On Thu, Apr 22, 2021 at 05:59:51PM +0200, Fabio M. De Francesco wrote:
> > - drm_modeset_lock_all(drm_dev);
> > -
> > drm_for_each_crtc(crtc, drm_dev) {
> > + drm_modeset_lock(>mutex, NULL);
>
On Thu, Apr 22, 2021 at 04:11:22PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 22, 2021 at 11:49:43AM +0200, Daniel Vetter wrote:
> > On Wed, Apr 21, 2021 at 06:34:01PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Currently we try to detect a symmetric memory configurations
>
On Mon, Apr 26, 2021 at 04:13:55PM +0200, Christoph Hellwig wrote:
> > diff --git a/drivers/vfio/mdev/Makefile b/drivers/vfio/mdev/Makefile
> > index ff9ecd80212503..7c236ba1b90eb1 100644
> > +++ b/drivers/vfio/mdev/Makefile
> > @@ -1,5 +1,5 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> >
>
On Mon, Apr 26, 2021 at 07:10:06PM +0800, Kai-Heng Feng wrote:
> On Fri, Apr 23, 2021 at 8:41 PM Ville Syrjälä
> wrote:
> >
> > On Fri, Apr 23, 2021 at 12:46:54PM +0800, Kai-Heng Feng wrote:
> > > On HP Fury G7 Workstations, graphics output is re-routed from Intel GFX
> > > to discrete GFX after
On Mon, Apr 26, 2021 at 01:18:47PM +0800, Hsin-Yi Wang wrote:
> drm_dev_register() sets connector->registration_state to
> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> drm_connector_set_panel_orientation() is first called after
> drm_dev_register(), it will fail several checks and
On 26/04/2021 16:11, Jason Ekstrand wrote:
On Mon, Apr 26, 2021 at 4:42 AM Matthew Auld wrote:
Add an entry for the new uAPI needed for DG1. Also add the overall
upstream plan, including some notes for the TTM conversion.
v2(Daniel):
- include the overall upstreaming plan
- add a note
On HP Fury G7 Workstations, graphics output is re-routed from Intel GFX
to discrete GFX after S3. This is not desirable, because userspace will
treat connected display as a new one, losing display settings.
The expected behavior is to let discrete GFX drives all external
displays.
The platform
On 26/04/2021 11:18, Matthew Auld wrote:
It's a requirement that for dgfx we place all the paging structures in
device local-memory.
v2: use i915_coherent_map_type()
Signed-off-by: Matthew Auld
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 5 -
On Wed, Apr 21, 2021 at 2:23 PM Daniel Vetter wrote:
>
> On Wed, Apr 21, 2021 at 8:28 PM Tvrtko Ursulin
> wrote:
> > On 21/04/2021 18:17, Jason Ekstrand wrote:
> > > On Wed, Apr 21, 2021 at 9:25 AM Tvrtko Ursulin
> > > wrote:
> > >> On 21/04/2021 14:54, Jason Ekstrand wrote:
> > >>> On Wed, Apr
On 26/04/2021 11:18, Matthew Auld wrote:
We need to general our accessor for the page directories and tables from
Generalise?
using the simple kmap_atomic to support local memory, and this setup
must be done on acquisition of the backing storage prior to entering
fence execution contexts.
On Mon, Apr 26, 2021 at 4:42 AM Matthew Auld wrote:
>
> Add an entry for the new uAPI needed for DG1. Also add the overall
> upstream plan, including some notes for the TTM conversion.
>
> v2(Daniel):
> - include the overall upstreaming plan
> - add a note for mmap, there are differences here
On Mon, Apr 26, 2021 at 02:18:05PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 20.04.21 um 10:46 schrieb Daniel Vetter:
> > On Mon, Apr 19, 2021 at 10:00:56AM +0200, Geert Uytterhoeven wrote:
> > > Hi Thomas,
> > >
> > > On Fri, Apr 16, 2021 at 11:00 AM Thomas Zimmermann
> > > wrote:
> > > >
On 26-04-2021 15:19, Jani Nikula wrote:
On Mon, 26 Apr 2021, Rajeev Nandan wrote:
Add backlight driver for the panels supporting backlight control
using DPCD registers on the DisplayPort aux channel.
No, please don't do this.
I wrote you last week in reply to v1 why I thought merging this
On resume, dispc pm_runtime_force_resume() is not enabling the hardware
as we pass the pm_runtime_need_not_resume() test as the device is suspended
with no child devices.
As the resume continues, omap_atomic_comit_tail() calls dispc_runtime_get()
that calls rpm_resume() enabling the hardware, and
On Wed, 17 Mar 2021, zuoqil...@163.com wrote:
> From: zuoqilin
>
> Change 'befor' to 'before'.
>
> Signed-off-by: zuoqilin
Thanks, pushed, sorry for the delay.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/display/vlv_dsi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Fri, 02 Apr 2021, Dan Carpenter wrote:
> tree: git://anongit.freedesktop.org/drm-intel drm-intel-next
> head: b29854ec3b9ca6512a783e2153465f27a777a654
> commit: 989cf9a93892409cf8e84c30c0faaa522ac83807 [3/4] drm/i915/hdcp: Add DP
> HDCP2.2 timeout to read entire msg
> config:
On Mon, Apr 26, 2021 at 06:50:15PM +0800, ChiYuan Huang wrote:
> Hi,
>
> Daniel Thompson 於 2021年4月26日 週一 下午6:19寫道：
> >
> > On Mon, Apr 26, 2021 at 03:18:11PM +0800, cy_huang wrote:
> > > From: ChiYuan Huang
> > >
> > > Adds support for Richtek RT4831 backlight.
> > >
> > > Signed-off-by:
Hi
Am 20.04.21 um 11:27 schrieb Geert Uytterhoeven:
Hi Gerd,
On Tue, Apr 20, 2021 at 11:22 AM Gerd Hoffmann wrote:
Patches 4 to 8 add the simpledrm driver. It's build on simple DRM helpers
and SHMEM. It supports 16-bit, 24-bit and 32-bit RGB framebuffers. During
if support for 8-bit
Hi
Am 20.04.21 um 10:46 schrieb Daniel Vetter:
On Mon, Apr 19, 2021 at 10:00:56AM +0200, Geert Uytterhoeven wrote:
Hi Thomas,
On Fri, Apr 16, 2021 at 11:00 AM Thomas Zimmermann wrote:
This patchset adds support for simple-framebuffer platform devices and
a handover mechanism for native
Reviewed-by: Nirmoy Das
On 4/26/21 2:13 PM, Colin King wrote:
From: Colin Ian King
There is a spelling mistake in a pr_debug message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Colin Ian King
There is a spelling mistake in a pr_debug message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
On Sat, Apr 24, 2021 at 07:57:19AM +0800, Art Nikpal wrote:
> > I would expect the driver to unregister the controller at the start of
> > the remove function, suspend doesn't really make sense here
> It's strange - But without spi_master_suspend i have randomly stucks when i
> try unload this
On Mon, 26 Apr 2021, Kai-Heng Feng wrote:
> On Fri, Apr 23, 2021 at 3:35 PM Jani Nikula
> wrote:
>>
>> On Fri, 23 Apr 2021, Kai-Heng Feng wrote:
>> > On HP Fury G7 Workstations, graphics output is re-routed from Intel GFX
>> > to discrete GFX after S3. This is not desirable, because userspace
Just a gentle ping?
Are you ok with this explanation Andrew or should I look for a different
approach?
Thanks,
Christian.
Am 16.04.21 um 09:08 schrieb Christian König:
Am 15.04.21 um 22:33 schrieb Andrew Morton:
On Thu, 15 Apr 2021 13:56:24 +0200 "Christian König"
wrote:
@@ -530,6
On Sat, Apr 24, 2021 at 03:25:04AM +0530, Rajeev Nandan wrote:
> Add backlight driver for the panels supporting backlight control
> using DPCD registers on the DisplayPort aux channel.
>
> Changes in v2:
> - New (most of the code reused from drm_dp_aux_backlight.c of v1)
Did you respond to
On Fri, Apr 23, 2021 at 8:41 PM Ville Syrjälä
wrote:
>
> On Fri, Apr 23, 2021 at 12:46:54PM +0800, Kai-Heng Feng wrote:
> > On HP Fury G7 Workstations, graphics output is re-routed from Intel GFX
> > to discrete GFX after S3. This is not desirable, because userspace will
> > treat connected
Hi all,
we are still affected by this issue from 2019 on 5.10.
For example when setting "cma=256M" on phycore imx6q with 2G ram we get:
[ 12.573276] etnaviv etnaviv: command buffer outside valid memory window
[ 12.616460] etnaviv etnaviv: command buffer outside valid memory window
[
On Fri, Apr 23, 2021 at 3:35 PM Jani Nikula wrote:
>
> On Fri, 23 Apr 2021, Kai-Heng Feng wrote:
> > On HP Fury G7 Workstations, graphics output is re-routed from Intel GFX
> > to discrete GFX after S3. This is not desirable, because userspace will
> > treat connected display as a new one,
On Monday, April 26th, 2021 at 9:36 AM, Pekka Paalanen
wrote:
> > > This should probably explain what the bits in the mask correspond to.
> > > As in, which CRTC does bit 0 refer to, and so on.
> >
> > What about:
> >
> > "possible_crtcs: Bitmask of CRTC's compatible with the plane. CRTC's are
Hi,
Daniel Thompson 於 2021年4月26日 週一 下午6:19寫道：
>
> On Mon, Apr 26, 2021 at 03:18:11PM +0800, cy_huang wrote:
> > From: ChiYuan Huang
> >
> > Adds support for Richtek RT4831 backlight.
> >
> > Signed-off-by: ChiYuan Huang
> > Reviewed-by: Daniel Thompson
> > ---
> > Resend this v6 patch series
When an amdgpu device fails to init, it makes another VGA device cause
kernel splat:
kernel: amdgpu :08:00.0: amdgpu: amdgpu_device_ip_init failed
kernel: amdgpu :08:00.0: amdgpu: Fatal error during GPU init
kernel: amdgpu: probe of :08:00.0 failed with error -110
...
kernel: amdgpu
1 - 100 of 140 matches
Mail list logo
