[PATCH 1/2] drm/ttm: Don't evict SG BOs

SG BOs do not occupy space that is managed by TTM. So do not evict them. This fixes unexpected evictions of KFD's userptr BOs. KFD only expects userptr "evictions" in the form of MMU notifiers. Signed-off-by: Felix Kuehling --- drivers/gpu/drm/ttm/ttm_bo.c | 4 1 file changed, 4

[PATCH 2/2] drm/ttm: Fix swapout in ttm_tt_populate

ttm_bo_swapout returns a non-0 value on success. Don't treat that as an error in ttm_tt_populate. Signed-off-by: Felix Kuehling --- drivers/gpu/drm/ttm/ttm_tt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c index

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Wed., Apr. 28, 2021, 00:01 Jason Ekstrand, wrote: > On Tue, Apr 27, 2021 at 4:59 PM Marek Olšák wrote: > > > > Jason, both memory-based signalling as well as interrupt-based > signalling to the CPU would be supported by amdgpu. External devices don't > need to support memory-based sync

[PATCH v4 3/3] arm64: dts: mt8183: Add panel rotation

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

[PATCH v4 2/3] drm/mediatek: init panel orientation property

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 | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c

[PATCH v4 1/3] gpu: drm: separate panel orientation property creating and value setting

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

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tue, Apr 27, 2021 at 4:59 PM Marek Olšák wrote: > > Jason, both memory-based signalling as well as interrupt-based signalling to > the CPU would be supported by amdgpu. External devices don't need to support > memory-based sync objects. The only limitation is that they can't convert >

Re: [PATCH 01/21] drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE

On Tue, Apr 27, 2021 at 4:32 AM Daniel Vetter wrote: > > On Fri, Apr 23, 2021 at 05:31:11PM -0500, Jason Ekstrand wrote: > > This reverts commit 88be76cdafc7 ("drm/i915: Allow userspace to specify > > ringsize on construction"). This API was originally added for OpenCL > > but the

Re: [PATCH v2 3/4] drm/msm: get rid of msm_iomap_size

On Mon 26 Apr 19:18 CDT 2021, Dmitry Baryshkov wrote: [..] > diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c > index 92fe844b517b..be578fc4e54f 100644 > --- a/drivers/gpu/drm/msm/msm_drv.c > +++ b/drivers/gpu/drm/msm/msm_drv.c > @@ -124,7 +124,7 @@ struct clk

[PATCH v1] soc: mediatek: MTK_MMSYS tristrate support

From: Chun-Hung Wu MTK_MMSYS driver tristrate support. Signed-off-by: Chun-Hung Wu Signed-off-by: Yongqiang Niu --- drivers/soc/mediatek/Kconfig | 2 +- drivers/soc/mediatek/mtk-mmsys.c | 7 ++- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git

[PATCH v1] MTK_MMSYS tristrate support

MTK_MMSYS tristrate support Chun-Hung Wu (1): [ALPS05103552] soc: mediatek: MTK_MMSYS tristrate support drivers/soc/mediatek/Kconfig | 2 +- drivers/soc/mediatek/mtk-mmsys.c | 7 ++- 2 files changed, 7 insertions(+), 2 deletions(-) -- 1.8.1.1.dirty

Re: New warnings with gcc-11

On Tue, Apr 27, 2021 at 4:43 PM Linus Torvalds wrote: > > I think I will make the argument type to intel_print_wm_latency() be > just "const u16 wm[]" for now, just to avoid seeing a ton of silly > warnings. After fixing the trivial ones, this one remains:

Re: [PATCH 1/2] drm/msm/dp: service only one irq_hpd if there are multiple irq_hpd pending

Quoting aravi...@codeaurora.org (2021-04-21 11:55:21) > On 2021-04-21 10:26, khs...@codeaurora.org wrote: > >> > >>> + > >>> mutex_unlock(>event_mutex); > >>> > >>> return 0; > >>> @@ -1496,6 +1502,9 @@ int msm_dp_display_disable(struct msm_dp *dp, > >>> struct drm_encoder

New warnings with gcc-11

I've updated to Fedora 34 on one of my machines, and it causes a lot of i915 warnings like drivers/gpu/drm/i915/intel_pm.c: In function ‘ilk_setup_wm_latency’: drivers/gpu/drm/i915/intel_pm.c:3059:9: note: referencing argument 3 of type ‘const u16 *’ {aka ‘const short unsigned int *’}

Re: [PATCH 00/12] Remove vfio_mdev.c, mdev_parent_ops and more

On Tue, Apr 27, 2021 at 09:33:56AM +0200, Christian Borntraeger wrote: > On 26.04.21 19:42, Jason Gunthorpe wrote: > > 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

Re: [PATCH v2 00/13] Remove vfio_mdev.c, mdev_parent_ops and more

On Tue, 27 Apr 2021 19:20:26 -0300 Jason Gunthorpe wrote: > On Tue, Apr 27, 2021 at 03:30:42PM -0600, Alex Williamson wrote: > > > It'd be really helpful if you could consistently copy at least one > > list, preferably one monitored by patchwork, for an entire series. The > > kvm list is

Re: [PATCH 1/2] drm/tegra: Get ref for DP AUX channel, not its ddc adapter

On Mon, 2021-04-26 at 09:42 +0200, Thierry Reding wrote: > On Fri, Apr 23, 2021 at 02:21:45PM -0400, Lyude Paul wrote: > > While we're taking a reference of the DDC adapter for a DP AUX channel in > > tegra_sor_probe() because we're going to be using that adapter with the > > SOR, now that we've

Re: [PATCH v2 00/13] Remove vfio_mdev.c, mdev_parent_ops and more

On Tue, Apr 27, 2021 at 03:30:42PM -0600, Alex Williamson wrote: > It'd be really helpful if you could consistently copy at least one > list, preferably one monitored by patchwork, for an entire series. The > kvm list is missing patches 06 and 08. I can find the latter hopping > over to the

Re: [PATCH v2 4/4] drm/msm/dsi: add DSI PHY registers to snapshot data

On 2021-04-26 17:18, Dmitry Baryshkov wrote: Add DSI PHY registers to the msm state snapshots to be able to check their contents. Signed-off-by: Dmitry Baryshkov Reviewed-by: Abhinav Kumar --- drivers/gpu/drm/msm/dsi/dsi.c | 1 + drivers/gpu/drm/msm/dsi/dsi.h | 1 +

Re: [Freedreno] [PATCH v2 3/4] drm/msm: get rid of msm_iomap_size

On 2021-04-27 13:32, Dmitry Baryshkov wrote: On Tue, 27 Apr 2021 at 22:30, wrote: Hi Dmitry On 2021-04-26 17:18, Dmitry Baryshkov wrote: > 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 We

Re: [Freedreno] [PATCH v2 2/4] drm/msm: make msm_disp_state transient data struct

On 2021-04-27 13:29, Dmitry Baryshkov wrote: On Tue, 27 Apr 2021 at 22:19, wrote: Hi Dmitry On 2021-04-26 17:18, 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

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Jason, both memory-based signalling as well as interrupt-based signalling to the CPU would be supported by amdgpu. External devices don't need to support memory-based sync objects. The only limitation is that they can't convert amdgpu sync objects to dma_fence. The sad thing is that "external ->

Re: [PATCH v2 00/13] Remove vfio_mdev.c, mdev_parent_ops and more

On Mon, 26 Apr 2021 17:00:02 -0300 Jason Gunthorpe wrote: > 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

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tue, Apr 27, 2021 at 1:38 PM Dave Airlie wrote: > > On Tue, 27 Apr 2021 at 22:06, Christian König > wrote: > > > > Correct, we wouldn't have synchronization between device with and without > > user queues any more. > > > > That could only be a problem for A+I Laptops. > > Since I think you

Display notch support

With many more non-desktop form factor devices landing in the kernel, we're starting to run up against some limitations. Notably devices with display notches, cutouts and rounded corners. Given that the DRI subsystem already deals with physical display properties like panel orientation which

Re: [Freedreno] [PATCH v2 3/4] drm/msm: get rid of msm_iomap_size

On Tue, 27 Apr 2021 at 22:30, wrote: > > Hi Dmitry > > On 2021-04-26 17:18, Dmitry Baryshkov wrote: > > 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 > We will have to call into the

Re: [Freedreno] [PATCH v2 2/4] drm/msm: make msm_disp_state transient data struct

On Tue, 27 Apr 2021 at 22:19, wrote: > > Hi Dmitry > > On 2021-04-26 17:18, 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

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Trying to figure out which e-mail in this mess is the right one to reply to On Tue, Apr 27, 2021 at 12:31 PM Lucas Stach wrote: > > Hi, > > Am Dienstag, dem 27.04.2021 um 09:26 -0400 schrieb Marek Olšák: > > Ok. So that would only make the following use cases broken for now: > > - amd render

Re: [Freedreno] [PATCH v2 3/4] drm/msm: get rid of msm_iomap_size

Hi Dmitry On 2021-04-26 17:18, Dmitry Baryshkov wrote: 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 We will have to call into the individual modules anyway everytime we take a snapshot as only

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Supporting interop with any device is always possible. It depends on which drivers we need to interoperate with and update them. We've already found the path forward for amdgpu. We just need to find out how many other drivers need to be updated and evaluate the cost/benefit aspect. Marek On Tue,

Re: [Freedreno] [PATCH v2 2/4] drm/msm: make msm_disp_state transient data struct

Hi Dmitry On 2021-04-26 17:18, 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

Re: [PATCH v2 0/4] drm/msm: improve register snapshotting

On 2021-04-26 17:18, Dmitry Baryshkov wrote: 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 Need to mention the dependency here , got missed from the

Re: [PATCH v2 01/10] drm/fourcc: Add macros to determine the modifier vendor

On Fri, 26 Mar 2021 at 16:29, Thierry Reding wrote: > On Fri, Mar 26, 2021 at 02:54:22PM +, Simon Ser wrote: > > LGTM, thanks! > > > > Reviewed-by: Simon Ser > > > > Let me know if you need me to push this to drm-misc-next. > > I do have commit access for drm-misc-next, but I was thinking

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tue, 27 Apr 2021 at 22:06, Christian König wrote: > > Correct, we wouldn't have synchronization between device with and without > user queues any more. > > That could only be a problem for A+I Laptops. Since I think you mentioned you'd only be enabling this on newer chipsets, won't it be a

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tuesday, April 27th, 2021 at 8:01 PM, Alex Deucher wrote: > It's an upcoming requirement for windows[1], so you are likely to > start seeing this across all GPU vendors that support windows. I > think the timing depends on how quickly the legacy hardware support > sticks around for each

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tue, Apr 27, 2021 at 1:35 PM Simon Ser wrote: > > On Tuesday, April 27th, 2021 at 7:31 PM, Lucas Stach > wrote: > > > > Ok. So that would only make the following use cases broken for now: > > > > > > - amd render -> external gpu > > > - amd video encode -> network device > > > > FWIW, "only"

RE: [PATCH v2] drm/i915/gem: Remove reference to struct drm_device.pdev

>-Original Message- >From: Thomas Zimmermann >Sent: Tuesday, April 27, 2021 1:49 PM >To: jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi, Rodrigo >; airl...@linux.ie; dan...@ffwll.ch; Auld, Matthew >; Ruhl, Michael J >Cc: intel-...@lists.freedesktop.org;

[PATCH v2] drm/i915/gem: Remove reference to struct drm_device.pdev

References to struct drm_device.pdev should not be used any longer as the field will be moved into the struct's legacy section. Add a fix for the rsp commit. v2: * fix an error in the commit description (Michael) Signed-off-by: Thomas Zimmermann Reviewed-by: Jani Nikula Fixes:

Re: [PATCH] drm/i915/gem: Remove reference to struct drm_device.pdev

Am 27.04.21 um 16:39 schrieb Ruhl, Michael J: -Original Message- From: dri-devel On Behalf Of Thomas Zimmermann Sent: Tuesday, April 27, 2021 7:08 AM To: jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi, Rodrigo ; airl...@linux.ie; dan...@ffwll.ch; Auld, Matthew

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tuesday, April 27th, 2021 at 7:31 PM, Lucas Stach wrote: > > Ok. So that would only make the following use cases broken for now: > > > > - amd render -> external gpu > > - amd video encode -> network device > > FWIW, "only" breaking amd render -> external gpu will make us pretty > unhappy I

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Hi, Am Dienstag, dem 27.04.2021 um 09:26 -0400 schrieb Marek Olšák: > Ok. So that would only make the following use cases broken for now: > - amd render -> external gpu > - amd video encode -> network device FWIW, "only" breaking amd render -> external gpu will make us pretty unhappy, as we have

Re: [PATCH v2 0/9] drm: Add privacy-screen class and connector properties

Hi, >>> There now is GNOME userspace code using the new properties: >>> https://hackmd.io/@3v1n0/rkyIy3BOw >> >> Thanks for working on this. >> >> Can these patches be submitted as merge requests against the upstream >> projects? It would be nice to get some feedback from the maintainers, >>

Re: [PATCH 000/190] Revertion of all of the umn.edu commits

On Wed, Apr 21, 2021 at 07:35:44PM +0200, Daniel Vetter wrote: > On Wed, Apr 21, 2021 at 3:01 PM Greg Kroah-Hartman > wrote: > > > > I have been meaning to do this for a while, but recent events have > > finally forced me to do so. > > > > Commits from @umn.edu addresses have been found to be

Re: [PATCH V2 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver

 Hi Marek, SN65DSI84 also supports single-link LVDS. We have quite a few customers using SN65DSI84 on Variscite SOMs with low resolution single-channel LVDS panels. I think having a DTS binding to indicate the number of links used by SN65DSI84 is more flexible than forcing dual-link mode on

Re: [PATCH 2/8] drm/arm/malidp: Always list modifiers

On Tue, Apr 27, 2021 at 11:20:12AM +0200, Daniel Vetter wrote: > Even when all we support is linear, make that explicit. Otherwise the > uapi is rather confusing. :) > > Cc: sta...@vger.kernel.org > Cc: Pekka Paalanen > Cc: Liviu Dudau > Cc: Brian Starkey > Signed-off-by: Daniel Vetter

Re: [PATCH v3 2/3] drm/mediatek: init panel orientation property

Hi, Hsin-Yi: Hsin-Yi Wang 於 2021年4月27日 週二 下午12:49寫道： > > 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

Re: [PATCH] drm: i915: fix build when ACPI is disabled and BACKLIGHT=m

On 4/27/21 1:03 AM, Jani Nikula wrote: > On Mon, 26 Apr 2021, Randy Dunlap wrote: >> When CONFIG_DRM_I915=y, CONFIG_ACPI is not set, and >> CONFIG_BACKLIGHT_CLASS_DEVICE=m, not due to I915 config, >> there are build errors trying to reference backlight_device_{un}register(). >> >> Changing the

Re: [PATCH 1/8] drm/arm: Don't set allow_fb_modifiers explicitly

On Tue, Apr 27, 2021 at 11:20:11AM +0200, Daniel Vetter wrote: > Since > > commit 890880ddfdbe256083170866e49c87618b706ac7 > Author: Paul Kocialkowski > Date: Fri Jan 4 09:56:10 2019 +0100 > > drm: Auto-set allow_fb_modifiers when given modifiers at plane init > > this is done

Re: [PATCH v2 00/10] Implement multi-GPU DMA mappings for KFD

This series is Acked-by: Oak Zeng Regards, Oak On 2021-04-21, 9:31 PM, "dri-devel on behalf of Felix Kuehling" wrote: This patch series fixes DMA-mappings of system memory (GTT and userptr) for KFD running on multi-GPU systems with IOMMU enabled. One SG-BO per GPU is

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Uff good question. DMA-buf certainly supports that use case, but I have no idea if that is actually used somewhere. Daniel do you know any case? Christian. Am 27.04.21 um 15:26 schrieb Marek Olšák: Ok. So that would only make the following use cases broken for now: - amd render -> external

Re: [PATCH v2 08/10] drm/amdgpu: Add DMA mapping of GTT BOs

Am 2021-04-27 um 10:29 a.m. schrieb Zeng, Oak: > Regards, > Oak > > > > On 2021-04-26, 11:56 PM, "Kuehling, Felix" wrote: > > 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

Re: [RFC PATCH 0/3] A drm_plane API to support HDR planes

On Mon, 26 Apr 2021 13:38:49 -0400 Harry Wentland wrote: > ## 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

Re: [PATCH v2 4/7] drm/i915/gtt/dgfx: place the PD in LMEM

On 27/04/2021 09:54, 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() v3: improve the shared dma-resv object comment Signed-off-by: Matthew Auld Cc: Tvrtko Ursulin ---

Re: [Intel-gfx] [PATCH v2 4/7] drm/i915/gtt/dgfx: place the PD in LMEM

On 27/04/2021 14:34, Tang, CQ wrote: -Original Message- From: Intel-gfx On Behalf Of Matthew Auld Sent: Tuesday, April 27, 2021 1:54 AM To: intel-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Subject: [Intel-gfx] [PATCH v2 4/7] drm/i915/gtt/dgfx: place the PD in LMEM

Re: [PATCH v2 3/7] drm/i915/gtt: map the PD up front

On 27/04/2021 09:54, Matthew Auld wrote: We need to generalise our accessor for the page directories and tables from 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. Here we

RE: [PATCH] drm/i915/gem: Remove reference to struct drm_device.pdev

>-Original Message- >From: dri-devel On Behalf Of >Thomas Zimmermann >Sent: Tuesday, April 27, 2021 7:08 AM >To: jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi, Rodrigo >; airl...@linux.ie; dan...@ffwll.ch; Auld, Matthew > >Cc: Tvrtko Ursulin ; Ursulin, Tvrtko >; Mika

Re: [PATCH v2 08/10] drm/amdgpu: Add DMA mapping of GTT BOs

Regards, Oak On 2021-04-26, 11:56 PM, "Kuehling, Felix" wrote: 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

Re: [PATCH] drm/bridge: anx7625: Fix power on delay

On 27/04/2021 07:53, Hsin-Yi Wang wrote: > 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 > --- >

Re: [PATCH] drm: bridge: add missing word in Analogix help text

On 26/04/2021 10:59, Neil Armstrong wrote: > On 26/04/2021 09:42, Robert Foss wrote: >> >> >> On Mon, Apr 26, 2021, 09:15 Neil Armstrong > > wrote: >> >> >> >> Le 24/04/2021 à 08:18, Randy Dunlap a écrit : >> > Insert a missing word "power" in Kconfig help

Re: [Intel-gfx] [PATCH 08/20] drm/i915/gem: Disallow bonding of virtual engines (v2)

On Mon, Apr 26, 2021 at 06:43:30PM -0500, Jason Ekstrand wrote: > 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

Re: [PATCH 08/21] drm/i915/gem: Disallow bonding of virtual engines

On Fri, Apr 23, 2021 at 5:31 PM Jason Ekstrand wrote: > > 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

RE: [Intel-gfx] [PATCH v2 4/7] drm/i915/gtt/dgfx: place the PD in LMEM

> -Original Message- > From: Intel-gfx On Behalf Of > Matthew Auld > Sent: Tuesday, April 27, 2021 1:54 AM > To: intel-...@lists.freedesktop.org > Cc: dri-devel@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH v2 4/7] drm/i915/gtt/dgfx: place the PD in LMEM > > It's a requirement

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Ok. So that would only make the following use cases broken for now: - amd render -> external gpu - amd video encode -> network device What about the case when we get a buffer from an external device and we're supposed to make it "busy" when we are using it, and the external device wants to wait

Re: [PATCH v7 0/4] drm: Move struct drm_device.pdev to legacy

On Tue, 27 Apr 2021, Thomas Zimmermann wrote: > Hi Jani > > Am 27.04.21 um 14:04 schrieb Jani Nikula: >> On Tue, 27 Apr 2021, Thomas Zimmermann wrote: >>> V7 of the patchset fixes some bitrot in the intel driver. >>> >>> The pdev field in struct drm_device points to a PCI device structure and

Re: [PATCH] drm/i915/gem: Remove reference to struct drm_device.pdev

On Tue, 27 Apr 2021, Thomas Zimmermann wrote: > References to struct drm_device.pdev should be used any longer as > the field will be moved into the struct's legacy section. Add a fix > for the rsp commit. > > Signed-off-by: Thomas Zimmermann > Fixes: d57d4a1daf5e ("drm/i915: Create stolen

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Only amd -> external. We can easily install something in an user queue which waits for a dma_fence in the kernel. But we can't easily wait for an user queue as dependency of a dma_fence. The good thing is we have this wait before signal case on Vulkan timeline semaphores which have the same

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

I'll defer to Christian and Alex to decide whether dropping sync with non-amd devices (GPUs, cameras etc.) is acceptable. Rewriting those drivers to this new sync model could be done on a case by case basis. For now, would we only lose the "amd -> external" dependency? Or the "external -> amd"

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Am 27.04.21 um 14:15 schrieb Daniel Vetter: On Tue, Apr 27, 2021 at 2:11 PM Marek Olšák wrote: Ok. I'll interpret this as "yes, it will work, let's do it". It works if all you care about is drm/amdgpu. I'm not sure that's a reasonable approach for upstream, but it definitely is an approach

Re: [PATCH v3] drm/drm_file.c: Define drm_send_event_helper() as 'static'

On Tue, Apr 27, 2021 at 12:55:03PM +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 Applied to drm-misc-next for 5.14, thanks for

Re: [PATCH 8/8] drm/modifiers: Enforce consistency between the cap an IN_FORMATS

On Tue, Apr 27, 2021 at 12:32:19PM +0100, Emil Velikov wrote: > Hi Daniel, > > On Tue, 27 Apr 2021 at 10:20, Daniel Vetter wrote: > > > @@ -360,6 +373,9 @@ static int __drm_universal_plane_init(struct drm_device > > *dev, > > * drm_universal_plane_init() to let the DRM managed resource > >

Re: [PATCH v2] drm/bochs: Add screen blanking support

Am 27.04.21 um 11:56 schrieb Gerd Hoffmann: I'm fine to change in any better way, of course, so feel free to modify the patch. If no one objects, I'll merge it as-is. It's somewhat wrong wrt to VGA, but apparently what qemu wants. No objections. Acked-by: Gerd Hoffmann Great. Merged

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tue, Apr 27, 2021 at 2:11 PM Marek Olšák wrote: > Ok. I'll interpret this as "yes, it will work, let's do it". It works if all you care about is drm/amdgpu. I'm not sure that's a reasonable approach for upstream, but it definitely is an approach :-) We've already gone somewhat through the

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tue, Apr 27, 2021 at 1:49 PM Marek Olšák wrote: > > If we don't use future fences for DMA fences at all, e.g. we don't use them > for memory management, it can work, right? Memory management can suspend user > queues anytime. It doesn't need to use DMA fences. There might be something >

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Ok. I'll interpret this as "yes, it will work, let's do it". Marek On Tue., Apr. 27, 2021, 08:06 Christian König, < ckoenig.leichtzumer...@gmail.com> wrote: > Correct, we wouldn't have synchronization between device with and without > user queues any more. > > That could only be a problem for

Re: [PATCH v7 0/4] drm: Move struct drm_device.pdev to legacy

Hi Jani Am 27.04.21 um 14:04 schrieb Jani Nikula: On Tue, 27 Apr 2021, Thomas Zimmermann wrote: V7 of the patchset fixes some bitrot in the intel driver. The pdev field in struct drm_device points to a PCI device structure and goes back to UMS-only days when all DRM drivers were for PCI

Re: [PATCH v2 1/4] fbtft: Replace custom ->reset() with generic one

On Tue, Apr 27, 2021 at 2:09 PM Greg Kroah-Hartman wrote: > On Fri, Apr 16, 2021 at 05:20:41PM +0300, Andy Shevchenko wrote: > > The custom ->reset() repeats the generic one, replace it. > > > > Note, in newer kernels the context of the function is a sleeping one, > > it's fine to switch over to

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Correct, we wouldn't have synchronization between device with and without user queues any more. That could only be a problem for A+I Laptops. Memory management will just work with preemption fences which pause the user queues of a process before evicting something. That will be a dma_fence,

Re: [PATCH v7 0/4] drm: Move struct drm_device.pdev to legacy

On Tue, 27 Apr 2021, Thomas Zimmermann wrote: > V7 of the patchset fixes some bitrot in the intel driver. > > The pdev field in struct drm_device points to a PCI device structure and > goes back to UMS-only days when all DRM drivers were for PCI devices. > Meanwhile we also support USB, SPI and

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

If we don't use future fences for DMA fences at all, e.g. we don't use them for memory management, it can work, right? Memory management can suspend user queues anytime. It doesn't need to use DMA fences. There might be something that I'm missing here. What would we lose without DMA fences? Just

Re: [PATCH 8/8] drm/modifiers: Enforce consistency between the cap an IN_FORMATS

Hi Daniel, On Tue, 27 Apr 2021 at 10:20, Daniel Vetter wrote: > @@ -360,6 +373,9 @@ static int __drm_universal_plane_init(struct drm_device > *dev, > * drm_universal_plane_init() to let the DRM managed resource infrastructure > * take care of cleanup and deallocation. > * > + * Drivers

[PATCH v2] drm/amd/amdgpu: Fix errors in documentation of function parameters

In the documentation of functions, removed excess parameters, described undocumented ones, and fixed syntax errors. Signed-off-by: Fabio M. De Francesco --- Changes from v1: Cc'ed all the maintainers. drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 12 ++--

Re: [PATCH v1 1/7] drm/st7735r: Avoid spamming logs if probe is deferred

Den 21.04.2021 18.31, skrev Andy Shevchenko: > The GPIO request can fail and probe may be deferred. Thus, > the error message may be printed again and again. Avoid > this by replacing DRM_DEV_ERROR() by dev_err_probe(). > > Signed-off-by: Andy Shevchenko > --- Series is applied to

Re: [PATCH] drm/gud: cleanup coding style a bit

Den 02.04.2021 10.55, skrev Bernard Zhao: > Fix coccicheck warning: > drivers/gpu/drm/gud/gud_internal.h:89:2-3: Unneeded semicolon > drivers/gpu/drm/gud/gud_internal.h:107:2-3: Unneeded semicolon > > Signed-off-by: Bernard Zhao > --- Applied to drm-misc-next. Thanks, Noralf.

[PATCH v7 4/4] drm: Move struct drm_device.pdev to legacy section

Struct drm_device.pdev is being moved to legacy status as only legacy DRM drivers use it. A possible follow-up patchset could remove pdev entirely. v4: * rebased Signed-off-by: Thomas Zimmermann Reviewed-by: Chris Wilson Acked-by: Sam Ravnborg --- include/drm/drm_device.h | 6 +++---

[PATCH v7 2/4] drm/i915: Remove reference to struct drm_device.pdev

References to struct drm_device.pdev should be used any longer as the field will be moved into the struct's legacy section. Fix a rsp comment. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/i915/intel_runtime_pm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v7 1/4] drm/i915/gt: Remove reference to struct drm_device.pdev

References to struct drm_device.pdev should be used any longer as the field will be moved into the struct's legacy section. Add a fix for the rsp commit. Signed-off-by: Thomas Zimmermann Fixes: a50ca39fbd01 ("drm/i915: setup the LMEM region") Cc: Lucas De Marchi Cc: Joonas Lahtinen Cc: Rodrigo

[PATCH v7 3/4] drm/i915: Don't assign to struct drm_device.pdev

Using struct drm_device.pdev is deprecated. Don't assign it. Users should upcast from struct drm_device.dev. v6: * also fix the assignment in selftests in this patch (Chris) Signed-off-by: Thomas Zimmermann Reviewed-by: Chris Wilson Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo

[PATCH v7 0/4] drm: Move struct drm_device.pdev to legacy

V7 of the patchset fixes some bitrot in the intel driver. The pdev field in struct drm_device points to a PCI device structure and goes back to UMS-only days when all DRM drivers were for PCI devices. Meanwhile we also support USB, SPI and platform devices. Each of those uses the generic device

[PATCH] drm/i915/gem: Remove reference to struct drm_device.pdev

References to struct drm_device.pdev should be used any longer as the field will be moved into the struct's legacy section. Add a fix for the rsp commit. Signed-off-by: Thomas Zimmermann Fixes: d57d4a1daf5e ("drm/i915: Create stolen memory region from local memory") Cc: CQ Tang Cc: Matthew Auld

Re: [PATCH v2 1/4] fbtft: Replace custom ->reset() with generic one

On Fri, Apr 16, 2021 at 05:20:41PM +0300, Andy Shevchenko wrote: > The custom ->reset() repeats the generic one, replace it. > > Note, in newer kernels the context of the function is a sleeping one, > it's fine to switch over to the sleeping functions. Keeping the reset > line asserted longer

Re: [PATCH v2 01/13] vfio/mdev: Remove CONFIG_VFIO_MDEV_DEVICE

On Mon, 26 Apr 2021 17:00:03 -0300 Jason Gunthorpe wrote: > 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

Re: [PATCH v5] drm/ast: Fixed CVE for DP501

Hi Am 21.04.21 um 10:58 schrieb KuoHsiang Chou: [Bug][DP501] If ASPEED P2A (PCI to AHB) bridge is disabled and disallowed for CVE_2019_6260 item3, and then the monitor's EDID is unable read through Parade DP501. The reason is the DP501's FW is mapped to BMC addressing space rather than Host

[PATCH v3] drm/drm_file.c: Define drm_send_event_helper() as 'static'

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 v2: Removed all the other lines in function comment. Changes from v1: As suggested by Daniel Vetter, removed

Re: [PATCH] drm/omap: Fix issue with clocks left on after resume

* Tony Lindgren [210427 10:12]: > * Tomi Valkeinen [210427 08:47]: > > If I understand right, this is only an issue when the dss was not enabled > > before the system suspend? And as the dispc is not enabled at suspend, > > pm_runtime_force_suspend and pm_runtime_force_resume don't really do > >

[PATCH] drm/i915: Simplify userptr locking

Use an rwlock instead of spinlock for the global notifier lock to reduce risk of contention in execbuf. Protect object state with the object lock whenever possible rather than with the global notifier lock Don't take an explicit page_ref in userptr_submit_init() but rather call get_pages() after

Re: [PATCH] drm/omap: Fix issue with clocks left on after resume

Hi, * Tomi Valkeinen [210427 08:47]: > Hi Tony, > > On 26/04/2021 17:12, Tony Lindgren wrote: > > 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

Re: [PATCH 07/21] drm/i915: Drop getparam support for I915_CONTEXT_PARAM_ENGINES

On Fri, Apr 23, 2021 at 05:31:17PM -0500, Jason Ekstrand wrote: > This has never been used by any userspace except IGT and provides no > real functionality beyond parroting back parameters userspace passed in > as part of context creation or via setparam. If the context is in > legacy mode (where

Re: [PATCH v2] drm/bochs: Add screen blanking support

> > I'm fine to change in any better way, of course, so feel free to > > modify the patch. > > If no one objects, I'll merge it as-is. It's somewhat wrong wrt to VGA, but > apparently what qemu wants. No objections. Acked-by: Gerd Hoffmann FYI: cirrus is in the same situation, the modesetting

Re: [Intel-gfx] [PATCH 06/21] drm/i915: Implement SINGLE_TIMELINE with a syncobj (v3)

On Fri, Apr 23, 2021 at 05:31:16PM -0500, Jason Ekstrand wrote: > This API is entirely unnecessary and I'd love to get rid of it. If > userspace wants a single timeline across multiple contexts, they can > either use implicit synchronization or a syncobj, both of which existed > at the time this

Re: [Intel-gfx] [PATCH 05/21] drm/i915: Drop the CONTEXT_CLONE API

On Fri, Apr 23, 2021 at 05:31:15PM -0500, Jason Ekstrand wrote: > This API allows one context to grab bits out of another context upon > creation. It can be used as a short-cut for setparam(getparam()) for > things like I915_CONTEXT_PARAM_VM. However, it's never been used by any > real

  1   2   >