On Fri, 18 Jun 2021 11:11:08 +0200
Werner Sembach wrote:
> Add a new general drm property "active color range" which can be used by
> graphic drivers to report the used color range back to userspace.
>
> There was no way to check which color range got actually used on a given
> monitor. To surel
On Fri, 18 Jun 2021 11:11:11 +0200
Werner Sembach wrote:
> Add a new general drm property "preferred color format" which can be used
> by userspace to tell the graphic drivers to which color format to use.
>
> Possible options are:
> - auto (default/current behaviour)
> - rgb
> - ycb
On Fri, 18 Jun 2021 11:11:14 +0200
Werner Sembach wrote:
> Add "Broadcast RGB" to general drm context so that more drivers besides
> i915 and gma500 can implement it without duplicating code.
>
> Userspace can use this property to tell the graphic driver to use full or
> limited color range for
Am Montag, dem 21.06.2021 um 18:30 +0200 schrieb Marek Vasut:
> On 6/21/21 2:14 PM, Lucas Stach wrote:
>
> [...]
>
> > > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > > b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > > index 98d8ba0bae84..22cb749fc9bc 100644
> > > --- a/drivers/gpu/drm/mxsfb/mxsfb_
On Fri, 18 Jun 2021 11:11:16 +0200
Werner Sembach wrote:
> This commit implements the "Broadcast RGB" drm property for the AMD GPU
> driver.
>
> Signed-off-by: Werner Sembach
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 22 ++-
> .../display/amdgpu_dm/amdgpu_dm_mst_t
Am Montag, dem 21.06.2021 um 18:45 +0200 schrieb Marek Vasut:
> On 6/21/21 2:08 PM, Lucas Stach wrote:
> > Am Montag, dem 21.06.2021 um 00:47 +0200 schrieb Marek Vasut:
> > > In case the DRAM is under high load, the MXSFB FIFO might underflow
> > > and that causes visible artifacts. This could be t
This reverts commit 1815d9c86e3090477fbde066ff314a7e9721ee0f.
Unfortunately this inverts the locking hierarchy, so back to the
drawing board. Full lockdep splat below:
==
WARNING: possible circular locking dependency detected
5.13.0-rc7-CI-CI_DR
On Tue, 22 Jun 2021 13:02:59 +0900
Esaki Tomohito wrote:
> Hi, Thomas
> Thank you for reply.
>
> On 2021/06/21 16:10, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 21.06.21 um 08:27 schrieb Tomohito Esaki:
> >> Virtual DRM splits the overlay planes of a display controller into
> >> multiple
> >>
Fix undefined symbols errors arising from 64-bit division on 32-bit
arm targets. Add 64-bit version of mult_frac and use it for calculating
bandwidth.
ERROR: modpost: "__aeabi_ldivmod" [drivers/gpu/drm/msm/msm.ko] undefined!
ERROR: modpost: "__aeabi_uldivmod" [drivers/gpu/drm/msm/msm.ko] undefined
On Monday, June 21st, 2021 at 08:43, Tomohito Esaki wrote:
> Virtual DRM splits the overlay planes of a display controller into multiple
> virtual devices to allow each plane to be accessed by each process.
> This makes it possible to overlay images output from multiple processes on a
> display.
On Tue, 22 Jun 2021 13:03:39 +0900
Esaki Tomohito wrote:
> Hi, Enrico Weigelt
> Thank you for reply.
>
> On 2021/06/22 1:05, Enrico Weigelt, metux IT consult wrote:
> > On 21.06.21 08:27, Tomohito Esaki wrote:
> >
> > Hi,
> >
> >> Virtual DRM splits the overlay planes of a display controller
Hi Rob,
On Tue, Jun 15, 2021 at 9:16 PM Rob Herring wrote:
> If a property has an 'items' list, then a 'minItems' or 'maxItems' with the
> same size as the list is redundant and can be dropped. Note that is DT
> schema specific behavior and not standard json-schema behavior. The tooling
> will fi
On Wed, Jun 16, 2021 at 11:16:14AM +0200, Neil Armstrong wrote:
> On 16/06/2021 09:50, Xin Ji wrote:
> > The basic anx7625 driver only support MIPI DSI rx signal input.
> > This patch add MIPI DPI rx input configuration support, after apply
> > this patch, the driver can support DSI rx or DPI rx by
On Tue, Jun 22, 2021 at 09:54:09AM +0200, Daniel Vetter wrote:
> This reverts commit 1815d9c86e3090477fbde066ff314a7e9721ee0f.
>
> Unfortunately this inverts the locking hierarchy, so back to the
> drawing board. Full lockdep splat below:
>
> ==
Applied to drm-misc-next
On Mon, 21 Jun 2021 at 20:49, Sam Ravnborg wrote:
>
> Hi Laurent,
>
> On Mon, Jun 21, 2021 at 03:55:13PM +0300, Laurent Pinchart wrote:
> > Hello,
> >
> > This patch series is based on top of "[PATCH] drm/bridge: ti-sn65dsi83:
> > Replace connector format patching with a
On Tue, Jun 22, 2021 at 9:37 AM Christian König
wrote:
>
> Am 22.06.21 um 01:29 schrieb Jason Gunthorpe:
> > On Mon, Jun 21, 2021 at 10:24:16PM +0300, Oded Gabbay wrote:
> >
> >> Another thing I want to emphasize is that we are doing p2p only
> >> through the export/import of the FD. We do *not* a
Hi
Am 22.06.21 um 06:02 schrieb Esaki Tomohito:
Hi, Thomas
Thank you for reply.
On 2021/06/21 16:10, Thomas Zimmermann wrote:
Hi
Am 21.06.21 um 08:27 schrieb Tomohito Esaki:
Virtual DRM splits the overlay planes of a display controller into
multiple
virtual devices to allow each plane to be
Am 17.06.21 um 23:09 schrieb Alex Deucher:
On Mon, Jun 14, 2021 at 1:45 PM Christian König
wrote:
Drop the workaround and instead implement a better solution.
Basically we are now chaining all submissions using a dma_fence_chain
container and adding them as exclusive fence to the dma_resv obje
On Mon, Jun 21, 2021 at 5:53 PM Daniel Vetter wrote:
>
> On Mon, Jun 21, 2021 at 5:49 PM Christian König
> wrote:
> >
> > Am 21.06.21 um 16:54 schrieb Daniel Vetter:
> > > On Mon, Jun 21, 2021 at 03:03:26PM +0200, Christian König wrote:
> > >> We actually need to wait for the moving fence after p
Am 22.06.21 um 09:29 schrieb Pekka Paalanen:
> On Fri, 18 Jun 2021 11:11:16 +0200
> Werner Sembach wrote:
>
>> This commit implements the "Broadcast RGB" drm property for the AMD GPU
>> driver.
>>
>> Signed-off-by: Werner Sembach
>> ---
>> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 22 +
Am 22.06.21 um 11:20 schrieb Daniel Vetter:
On Mon, Jun 21, 2021 at 5:53 PM Daniel Vetter wrote:
On Mon, Jun 21, 2021 at 5:49 PM Christian König
wrote:
Am 21.06.21 um 16:54 schrieb Daniel Vetter:
On Mon, Jun 21, 2021 at 03:03:26PM +0200, Christian König wrote:
We actually need to wait for t
Ping? Does anybody wants to give me an rb or acked-by?
AGP is basically broken on nouveu without this.
Christian.
Am 14.06.21 um 13:05 schrieb Christian König:
AGP for example doesn't have a dma_address array.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++--
On 6/22/21 9:28 AM, Lucas Stach wrote:
Am Montag, dem 21.06.2021 um 18:30 +0200 schrieb Marek Vasut:
On 6/21/21 2:14 PM, Lucas Stach wrote:
[...]
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index 98d8ba0bae84..22cb749fc9bc 100644
--- a/drivers/gpu/drm/m
Early implementation of moving system memory for discrete cards over to
TTM. We first add the notion of objects being migratable under the object
lock to i915 gem, and add some asserts to verify that objects are either
locked or pinned when the placement is checked by the gem code.
Patch 2 deals w
The object ops i915_GEM_OBJECT_HAS_IOMEM and the object
I915_BO_ALLOC_STRUCT_PAGE flags are considered immutable by
much of our code. Introduce a new mem_flags member to hold these
and make sure checks for these flags being set are either done
under the object lock or with pages properly pinned. Th
After a TTM move or object init we need to update the i915 gem flags and
caching settings to reflect the new placement. Currently caching settings
are not changed during the lifetime of an object, although that might
change moving forward if we run into performance issues or issues with
WC system p
For discrete, use TTM for both cached and WC system memory. That means
we currently rely on the TTM memory accounting / shrinker. For cached
system memory we should consider remaining shmem-backed, which can be
implemented from our ttm_tt_populate callback. We can then also reuse our
own very elabo
On Tue, 22 Jun 2021 at 10:34, Thomas Hellström
wrote:
>
> After a TTM move or object init we need to update the i915 gem flags and
> caching settings to reflect the new placement. Currently caching settings
> are not changed during the lifetime of an object, although that might
> change moving for
Am 22.06.21 um 09:00 schrieb Pekka Paalanen:
> On Fri, 18 Jun 2021 11:11:08 +0200
> Werner Sembach wrote:
>
>> Add a new general drm property "active color range" which can be used by
>> graphic drivers to report the used color range back to userspace.
>>
>> There was no way to check which color
Am 22.06.21 um 09:25 schrieb Pekka Paalanen:
> On Fri, 18 Jun 2021 11:11:14 +0200
> Werner Sembach wrote:
>
>> Add "Broadcast RGB" to general drm context so that more drivers besides
>> i915 and gma500 can implement it without duplicating code.
>>
>> Userspace can use this property to tell the gra
Just checking the current region is not enough, if we later migrate the
object somewhere else. For example if the placements are {SMEM, LMEM},
then we might get this wrong. Another idea might be to make the
page_alignment part of the ttm_place, instead of the BO.
Signed-off-by: Matthew Auld
Cc: T
On 6/22/21 11:44 AM, Matthew Auld wrote:
On Tue, 22 Jun 2021 at 10:34, Thomas Hellström
wrote:
After a TTM move or object init we need to update the i915 gem flags and
caching settings to reflect the new placement. Currently caching settings
are not changed during the lifetime of an object, a
On 6/22/21 11:58 AM, Matthew Auld wrote:
Just checking the current region is not enough, if we later migrate the
object somewhere else. For example if the placements are {SMEM, LMEM},
then we might get this wrong. Another idea might be to make the
page_alignment part of the ttm_place, instead o
On Tue, 22 Jun 2021 at 10:34, Thomas Hellström
wrote:
>
> For discrete, use TTM for both cached and WC system memory. That means
> we currently rely on the TTM memory accounting / shrinker. For cached
> system memory we should consider remaining shmem-backed, which can be
> implemented from our tt
On 6/22/21 12:55 PM, Matthew Auld wrote:
On Tue, 22 Jun 2021 at 10:34, Thomas Hellström
wrote:
For discrete, use TTM for both cached and WC system memory. That means
we currently rely on the TTM memory accounting / shrinker. For cached
system memory we should consider remaining shmem-backed,
mt8192 has different routing registers than mt8183
Signed-off-by: Yongqiang Niu
---
drivers/soc/mediatek/mt8192-mmsys.h | 68 +
drivers/soc/mediatek/mtk-mmsys.c| 11 ++
2 files changed, 79 insertions(+)
create mode 100644 drivers/soc/mediatek/mt8192-m
This patch add some more ddp component
OVL_2L2 is ovl which include 2 layers overlay
POSTMASK control round corner for display frame
RDMA4 read dma buffer
Signed-off-by: Yongqiang Niu
Reviewed-by: Chun-Kuang Hu
Reviewed-by: Enric Balletbo i Serra
Signed-off-by: Yongqiang Niu
---
include/linux
base 5.13-rc1
Change since v5:
- remove change id
Yongqiang Niu (2):
soc: mediatek: mmsys: add comp OVL_2L2/POSTMASK/RDMA4
soc: mediatek: mmsys: Add mt8192 mmsys routing table
drivers/soc/mediatek/mt8192-mmsys.h| 68 ++
drivers/soc/mediatek/mtk-mmsys.c
We actually need to wait for the moving fence after pinning
the BO to make sure that the pin is completed.
v2: grab the lock while waiting
Signed-off-by: Christian König
References:
https://lore.kernel.org/dri-devel/20210621151758.2347474-1-daniel.vet...@ffwll.ch/
CC: sta...@kernel.org
---
dri
We actually need to wait for the moving fence after pinning
the BO to make sure that the pin is completed.
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
References:
https://lore.kernel.org/dri-devel/20210621151758.2347474-1-daniel.vet...@ffwll.ch/
CC: sta...@kernel.org
---
drivers/
We actually need to wait for the moving fence after pinning
the BO to make sure that the pin is completed.
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
References:
https://lore.kernel.org/dri-devel/20210621151758.2347474-1-daniel.vet...@ffwll.ch/
CC: sta...@kernel.org
---
drivers/
On Tuesday, June 22nd, 2021 at 11:50, Werner Sembach
wrote:
> Unknown is when no monitor is connected or is when the
> connector/monitor is disabled.
I think the other connector props (link-status, non-desktop, etc) don't
have a special "unset" value, and instead the value is set to a random
en
On Tue, Jun 22, 2021 at 11:42:27AM +0300, Oded Gabbay wrote:
> On Tue, Jun 22, 2021 at 9:37 AM Christian König
> wrote:
> >
> > Am 22.06.21 um 01:29 schrieb Jason Gunthorpe:
> > > On Mon, Jun 21, 2021 at 10:24:16PM +0300, Oded Gabbay wrote:
> > >
> > >> Another thing I want to emphasize is that we
Hi,
on drm-tip, I see a null-ptr deref in radeon_ttm_bo_destroy(). Happens
when I try to start weston or X. Full error is below. Let me know if you
need more info.
Best regards
Thomas
[ 1849.999218]
==
[ 1850.006544] BUG: K
On Tue, Jun 22, 2021 at 3:01 PM Jason Gunthorpe wrote:
>
> On Tue, Jun 22, 2021 at 11:42:27AM +0300, Oded Gabbay wrote:
> > On Tue, Jun 22, 2021 at 9:37 AM Christian König
> > wrote:
> > >
> > > Am 22.06.21 um 01:29 schrieb Jason Gunthorpe:
> > > > On Mon, Jun 21, 2021 at 10:24:16PM +0300, Oded G
On Tue, Jun 22, 2021 at 1:45 PM Christian König
wrote:
>
> We actually need to wait for the moving fence after pinning
> the BO to make sure that the pin is completed.
>
> v2: grab the lock while waiting
>
> Signed-off-by: Christian König
> References:
> https://lore.kernel.org/dri-devel/2021062
On Tue, 22 Jun 2021 at 11:11, Thomas Hellström
wrote:
>
>
> On 6/22/21 11:58 AM, Matthew Auld wrote:
> > Just checking the current region is not enough, if we later migrate the
> > object somewhere else. For example if the placements are {SMEM, LMEM},
> > then we might get this wrong. Another idea
On Tue, Jun 22, 2021 at 03:04:30PM +0300, Oded Gabbay wrote:
> On Tue, Jun 22, 2021 at 3:01 PM Jason Gunthorpe wrote:
> >
> > On Tue, Jun 22, 2021 at 11:42:27AM +0300, Oded Gabbay wrote:
> > > On Tue, Jun 22, 2021 at 9:37 AM Christian König
> > > wrote:
> > > >
> > > > Am 22.06.21 um 01:29 schrie
Hi Thomas,
yeah that's a known issue. A patch to fix that is already under review.
Christian.
Am 22.06.21 um 14:03 schrieb Thomas Zimmermann:
Hi,
on drm-tip, I see a null-ptr deref in radeon_ttm_bo_destroy(). Happens
when I try to start weston or X. Full error is below. Let me know if
you n
Am 22.06.21 um 14:01 schrieb Jason Gunthorpe:
On Tue, Jun 22, 2021 at 11:42:27AM +0300, Oded Gabbay wrote:
On Tue, Jun 22, 2021 at 9:37 AM Christian König
wrote:
Am 22.06.21 um 01:29 schrieb Jason Gunthorpe:
On Mon, Jun 21, 2021 at 10:24:16PM +0300, Oded Gabbay wrote:
Another thing I want t
On 6/22/21 2:15 PM, Matthew Auld wrote:
On Tue, 22 Jun 2021 at 11:11, Thomas Hellström
wrote:
On 6/22/21 11:58 AM, Matthew Auld wrote:
Just checking the current region is not enough, if we later migrate the
object somewhere else. For example if the placements are {SMEM, LMEM},
then we might
Hi all, this patch series implement MIPI rx DPI feature. Please help to review.
This is the v9 version, rebase all patches on the latest code.
Any mistakes, please let me know, I'll fix it in the next series.
Change history:
v9: Fix Neil Amstrong comment
- use macro define 'V4L2_FWNODE_BUS_TYPE_
Add 'bus-type' and 'data-lanes' define for port0. Define DP tx lane0,
lane1 swing register array define, and audio enable flag.
Signed-off-by: Xin Ji
---
.../display/bridge/analogix,anx7625.yaml | 57 ++-
1 file changed, 56 insertions(+), 1 deletion(-)
diff --git
a/Documen
At some time, the original code may return non zero value, force return 0
if operation finished.
Reviewed-by: Robert Foss
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/a
The basic anx7625 driver only support MIPI DSI rx signal input.
This patch add MIPI DPI rx input configuration support, after apply
this patch, the driver can support DSI rx or DPI rx by adding
'bus-type' in DT.
Reviewed-by: Robert Foss
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/
Add audio HDMI codec function support, enable it through device true
flag "analogix,audio-enable".
Reviewed-by: Robert Foss
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 226 ++
drivers/gpu/drm/bridge/analogix/anx7625.h | 5 +
2 files changed, 231 i
On 22/06/2021 13:29, Thomas Hellström wrote:
On 6/22/21 2:15 PM, Matthew Auld wrote:
On Tue, 22 Jun 2021 at 11:11, Thomas Hellström
wrote:
On 6/22/21 11:58 AM, Matthew Auld wrote:
Just checking the current region is not enough, if we later migrate the
object somewhere else. For example if t
Changes in this series add support for MSM display DSI CTRL & PHY drivers
for the SC7280 SoC, which has DSI controller v2.5.0 and DSI PHY v4.1.
Changes in v2:
- Dropped patch #1 (dt-bindings: msm/dsi: Add yaml schema for 7nm DSI PHY) and
reused Jonathan's patch [1] (dt-bindings: msm: dsi: add mi
The SC7280 SoC uses the 7nm (V4.1) DSI PHY driver.
Signed-off-by: Rajeev Nandan
---
Changes in v2:
- New
This patch depends on [1] (dt-bindings: msm: dsi: add missing 7nm bindings)
[1]
https://lore.kernel.org/linux-arm-msm/20210617144349.28448-2-jonat...@marek.ca/
Documentation/devicetree/
Add support for v2.5.0 DSI block in the SC7280 SoC.
Signed-off-by: Rajeev Nandan
Reviewed-by: Dmitry Baryshkov
---
(no changes since v1)
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 20
drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 +
2 files changed, 21 insertions(+)
diff --git a/drive
The SC7280 SoC uses the 7nm (V4.1) DSI PHY driver with
different enable|disable regulator loads.
Signed-off-by: Rajeev Nandan
Reviewed-by: Dmitry Baryshkov
---
Changes in v2:
- Fixed clang warning for max_pll_rate as per [1] (Dmitry Baryshkov)
- Fixed num_dsi_phy and io_start (Dmitry Baryshkov)
Daniel pointed me towards this function and there are multiple obvious problems
in the implementation.
First of all the retry loop is not working as intended. In general the retry
makes only sense if you grab the reference first and then check the sequence
values.
It's also good practice to keep
Crap, hit enter to early before adding a cover letter.
This is the same patch as before, but as requested I'm keeping the
exclusive fence handling as it is for now.
Daniel can you double check this and/or make sure that it is tested?
I only smoke tested it and the code is so complicated that
On Mon, 21 Jun 2021, Uwe Kleine-König wrote:
> According to .update_status() is supposed to
> return 0 on success and a negative error code otherwise. Adapt
> lm3630a_bank_a_update_status() and lm3630a_bank_b_update_status() to
> actually do it.
>
> While touching that also add the error code to
On Tue, Jun 22, 2021 at 3:15 PM Jason Gunthorpe wrote:
>
> On Tue, Jun 22, 2021 at 03:04:30PM +0300, Oded Gabbay wrote:
> > On Tue, Jun 22, 2021 at 3:01 PM Jason Gunthorpe wrote:
> > >
> > > On Tue, Jun 22, 2021 at 11:42:27AM +0300, Oded Gabbay wrote:
> > > > On Tue, Jun 22, 2021 at 9:37 AM Chris
On Mon, 21 Jun 2021, Uwe Kleine-König wrote:
> The practical upside here is that this only needs a single API call to
> program the hardware which (depending on the underlaying hardware) can
> be more effective and prevents glitches.
>
> Up to now the return value of the pwm functions was ignored
https://bugzilla.kernel.org/show_bug.cgi?id=212327
Jani Nikula (jani.nik...@intel.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
Re
https://bugzilla.kernel.org/show_bug.cgi?id=210005
Jani Nikula (jani.nik...@intel.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
Re
On Tue, Jun 22, 2021 at 5:32 AM Christian König
wrote:
>
> Ping? Does anybody wants to give me an rb or acked-by?
>
> AGP is basically broken on nouveu without this.
Looks correct to me.
Acked-by: Alex Deucher
>
> Christian.
>
> Am 14.06.21 um 13:05 schrieb Christian König:
> > AGP for example
On Tue, Jun 22, 2021 at 2:17 AM Geert Uytterhoeven wrote:
>
> Hi Rob,
>
> On Tue, Jun 15, 2021 at 9:16 PM Rob Herring wrote:
> > If a property has an 'items' list, then a 'minItems' or 'maxItems' with the
> > same size as the list is redundant and can be dropped. Note that is DT
> > schema specif
On Tue, Jun 22, 2021 at 8:39 AM Adam Ford wrote:
>
> On Mon, Jun 21, 2021 at 2:25 AM Jagan Teki wrote:
> >
> > Add eLCDIF controller node for i.MX8MM.
> >
> > Cc: Rob Herring
> > Signed-off-by: Jagan Teki
> > ---
> > arch/arm64/boot/dts/freescale/imx8mm.dtsi | 19 +++
> > 1 fil
On Mon, Jun 21, 2021 at 4:17 AM Marek Vasut wrote:
>
> There is some sort of corner case behavior of the controller,
> which could rarely be triggered at least on i.MX6SX connected
> to 800x480 DPI panel and i.MX8MM connected to DPI->DSI->LVDS
> bridged 1920x1080 panel (and likely on other setups
On Mon, Jun 21, 2021 at 4:19 AM Marek Vasut wrote:
>
> Make sure the FIFO_CLEAR bit is latched in when configuring the
> controller, so that the FIFO is really cleared. And then clear
> the FIFO_CLEAR bit, since it is not self-clearing.
>
> Fixes: 45d59d704080 ("drm: Add new driver for MXSFB contr
Remove references to struct drm_device.irq_enabled from modern
DRM drivers and core.
KMS drivers enable IRQs for their devices internally. They don't
have to keep track of the IRQ state via irq_enabled. For vblanking,
it's cleaner to test for vblanking support directly than to test
for enabled IRQ
Replace usage of struct drm_device.irq_enabled with the driver's
own state field struct amdgpu_device.irq.installed. The field in
the DRM device structure is considered legacy and should not be
used by KMS drivers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 6
Remove the check around drm_irq_uninstall(). The same test is
done by the function internally. The tested state in irq_enabled
is considered obsolete and should not be used by KMS drivers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 3 +--
1 file change
For KMS drivers, replace the IRQ check in VBLANK ioctls with a check for
vblank support. IRQs might be enabled wthout vblanking being supported.
This change also removes the DRM framework's only dependency on IRQ state
for non-legacy drivers. For legacy drivers with userspace modesetting,
the orig
Replace usage of struct drm_device.irq_enabled with the driver's
own state field struct radeon_device.irq.installed. The field in
the DRM device structure is considered legacy and should not be
used by KMS drivers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/radeon/radeon_fence.c | 2
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in komeda.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komed
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in exynos.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in malidp.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/arm/malidp_drv.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in kirin.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_d
Replace usage of struct drm_device.irq_enabled with the driver's
own state field struct omap_drm_device.irq_enabled. The field in
the DRM device structure is considered legacy and should not be
used by KMS drivers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/omapdrm/omap_drv.h | 2 ++
d
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in mediatek.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/dri
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in imx.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/imx/dcss/dcss-kms.c | 3 ---
drivers/gpu/drm/imx/imx-drm-core.c | 11 ---
2 files changed, 14 deletions(-)
diff --git a
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in nouveau.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/g
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't use it in tidss.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tidss/tidss_irq.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_irq.c
b/drivers/gpu/drm/tid
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in stm.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/stm/ltdc.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 08b
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in vc4.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vc4/vc4_kms.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
ind
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in sun4i.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in sti.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/sti/sti_compositor.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_compositor.c
b/drivers/gpu/drm/
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in rockchip.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_dr
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in tegra.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tegra/drm.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in xlnx.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
b/drivers/gpu/drm/x
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in vmxgfx. All usage of
the field within vmwgfx can safely be removed.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vmwgfx/vmwgfx_irq.c | 8
1 file changed, 8 deletions(-)
d
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in zte.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/zte/zx_drm_drv.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c b/drivers/gpu/drm/zte/z
On Tue, Jun 22, 2021 at 04:12:26PM +0300, Oded Gabbay wrote:
> > 1) Setting sg_page to NULL
> > 2) 'mapping' pages for P2P DMA without going through the iommu
> > 3) Allowing P2P DMA without using the p2p dma API to validate that it
> >can work at all in the first place.
> >
> > All of these r
fix the warning- variable 'dev' set but not used
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 984721b..cb3ff4a 100644
--- a/drivers/gpu
On Tue, Jun 22, 2021 at 02:23:03PM +0200, Christian König wrote:
> Am 22.06.21 um 14:01 schrieb Jason Gunthorpe:
> > On Tue, Jun 22, 2021 at 11:42:27AM +0300, Oded Gabbay wrote:
> > > On Tue, Jun 22, 2021 at 9:37 AM Christian König
> > > wrote:
> > > > Am 22.06.21 um 01:29 schrieb Jason Gunthorpe:
Am 22.06.21 um 17:11 schrieb Jason Gunthorpe:
On Tue, Jun 22, 2021 at 04:12:26PM +0300, Oded Gabbay wrote:
1) Setting sg_page to NULL
2) 'mapping' pages for P2P DMA without going through the iommu
3) Allowing P2P DMA without using the p2p dma API to validate that it
can work at all in th
1 - 100 of 197 matches
Mail list logo
