Hi,
This started since 5.14-rc1. The following error appears in dmesg
(as of 5.14-rc7) when I build the kernel with CONFIG_DRM_SIMPLEDRM=m
[3.252275] [drm] Initialized simpledrm 1.0.0 20200625 for
simple-framebuffer.0 on minor 0
[3.252298] simple-framebuffer simple-framebuffer.0: [drm] *
From: Jing Yangyang
./drivers/gpu/drm/amd/display/dc/dcn31/dcn31_panel_cntl.c:112:9-10:WARNING:
return of 0/1 in function 'dcn31_is_panel_backlight_on'
with return type bool
./drivers/gpu/drm/amd/display/dc/dcn31/dcn31_panel_cntl.c:122:9-10:WARNING:
return of 0/1 in function 'dcn31_is_panel_powe
Hi Sam,
This driver support boe tv1110c9m-ll3 and inx hj110iz-01a panel.The IC chip
is used NT36523, which is a new IC.
1: panel-boe-tv101wum-nl6.c driver cannot meet the timing requirements of the
current two panel.
2: The screen cannot be work in HS mode, panel-boe-tv101wum-nl6.c will swit
Hi Chun-Kuang,
Thanks for the review.
On Fri, 2021-08-20 at 07:25 +0800, Chun-Kuang Hu wrote:
> Hi, Nancy:
>
> Nancy.Lin 於 2021年8月18日 週三 下午5:18寫道：
> >
> > Add vdosys1 MERGE definition.
> >
> > Signed-off-by: Nancy.Lin
> > ---
> > .../devicetree/bindings/display/mediatek/mediatek,merge.yaml
Hi Chun-Kuang,
Thanks for the review.
On Sun, 2021-08-22 at 07:47 +0800, Chun-Kuang Hu wrote:
> Hi, Nancy:
>
> Nancy.Lin 於 2021年8月18日 週三 下午5:19寫道：
> >
> > Add ovl_adaptor driver for MT8195.
> > Ovl_adaptor is an encapsulated module and designed for simplified
> > DRM control flow. This module
Hi Chun-Kuang,
Thanks for the review.
On Sat, 2021-08-21 at 07:37 +0800, Chun-Kuang Hu wrote:
> Hi, Nancy:
>
> Nancy.Lin 於 2021年8月18日 週三 下午5:18寫道：
> >
> > Add driver data of mt8195 vdosys1 to mediatek-drm and modify drm
> > for
> > multi-mmsys support. The two mmsys (vdosys0 and vdosys
Hi Chun-Kuang,
Thanks for the review.
On Sun, 2021-08-22 at 09:14 +0800, Chun-Kuang Hu wrote:
> Hi, Nancy:
>
> Nancy.Lin 於 2021年8月18日 週三 下午5:18寫道：
> >
> > Add driver data of mt8195 vdosys1 to mediatek-drm and modify drm
> > for
> > multi-mmsys support. The two mmsys (vdosys0 and vdosys1
On 23-08-21, 23:24, Dmitry Osipenko wrote:
> It's not clear to me whether it will be okay to add a generic OPP syncing by
> clock rate or should it be a Tegra-specific helper. Viresh, what do you think
> about this generic OPP helper:
>
> /**
> * dev_pm_opp_sync_with_clk_rate() - Sync OPP state
On Mon, Aug 09, 2021 at 01:10:08PM +0800, Shawn Guo wrote:
> It adds a DRM panel driver for Sony Tulip Truly NT35521 5.24" 1280x720
> DSI panel, which can be found on Sony Xperia M4 Aqua phone. The panel
> backlight is managed through DSI link.
>
> The driver is built using linux-mdss-dsi-panel-d
From: Mark Yacoub
[ Upstream commit fa0b1ef5f7a694f48e00804a391245f3471aa155 ]
[Why]
Userspace should get back a copy of drm_wait_vblank that's been modified
even when drm_wait_vblank_ioctl returns a failure.
Rationale:
drm_wait_vblank_ioctl modifies the request and expects the user to read
it
From: Ben Skeggs
[ Upstream commit 148a8653789c01f159764ffcc3f370008966b42f ]
Long ago, there had been plans for making use of a bunch of these APIs
from userspace and there's various checks in place to stop misbehaving.
Countless other projects have occurred in the meantime, and the pieces
did
From: Ben Skeggs
[ Upstream commit 6eaa1f3c59a707332e921e32782ffcad49915c5e ]
When booted with multiple displays attached, the EFI GOP driver on (at
least) Ampere, can leave DP links powered up that aren't being used to
display anything. This confuses our tracking of SOR routing, with the
likel
From: Ben Skeggs
[ Upstream commit 6eaa1f3c59a707332e921e32782ffcad49915c5e ]
When booted with multiple displays attached, the EFI GOP driver on (at
least) Ampere, can leave DP links powered up that aren't being used to
display anything. This confuses our tracking of SOR routing, with the
likel
From: Mark Yacoub
[ Upstream commit fa0b1ef5f7a694f48e00804a391245f3471aa155 ]
[Why]
Userspace should get back a copy of drm_wait_vblank that's been modified
even when drm_wait_vblank_ioctl returns a failure.
Rationale:
drm_wait_vblank_ioctl modifies the request and expects the user to read
it
From: Ben Skeggs
[ Upstream commit 148a8653789c01f159764ffcc3f370008966b42f ]
Long ago, there had been plans for making use of a bunch of these APIs
from userspace and there's various checks in place to stop misbehaving.
Countless other projects have occurred in the meantime, and the pieces
did
From: Ben Skeggs
[ Upstream commit 148a8653789c01f159764ffcc3f370008966b42f ]
Long ago, there had been plans for making use of a bunch of these APIs
from userspace and there's various checks in place to stop misbehaving.
Countless other projects have occurred in the meantime, and the pieces
did
From: Ben Skeggs
[ Upstream commit 6eaa1f3c59a707332e921e32782ffcad49915c5e ]
When booted with multiple displays attached, the EFI GOP driver on (at
least) Ampere, can leave DP links powered up that aren't being used to
display anything. This confuses our tracking of SOR routing, with the
likel
From: Mark Yacoub
[ Upstream commit fa0b1ef5f7a694f48e00804a391245f3471aa155 ]
[Why]
Userspace should get back a copy of drm_wait_vblank that's been modified
even when drm_wait_vblank_ioctl returns a failure.
Rationale:
drm_wait_vblank_ioctl modifies the request and expects the user to read
it
From: Ben Skeggs
[ Upstream commit 6eaa1f3c59a707332e921e32782ffcad49915c5e ]
When booted with multiple displays attached, the EFI GOP driver on (at
least) Ampere, can leave DP links powered up that aren't being used to
display anything. This confuses our tracking of SOR routing, with the
likel
From: Ben Skeggs
[ Upstream commit 148a8653789c01f159764ffcc3f370008966b42f ]
Long ago, there had been plans for making use of a bunch of these APIs
from userspace and there's various checks in place to stop misbehaving.
Countless other projects have occurred in the meantime, and the pieces
did
From: Ben Skeggs
[ Upstream commit e78b1b545c6cfe9f87fc577128e00026fff230ba ]
Should fix some initial modeset failures on (at least) Ampere boards.
Signed-off-by: Ben Skeggs
Reviewed-by: Lyude Paul
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 27 +
From: Kenneth Feng
[ Upstream commit 93c5701b00d50d192ce2247cb10d6c0b3fe25cd8 ]
change the workload type for some cards as it is needed.
Signed-off-by: Kenneth Feng
Reviewed-by: Hawking Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/pm/powerplay/hwmgr/vega
From: Mark Yacoub
[ Upstream commit fa0b1ef5f7a694f48e00804a391245f3471aa155 ]
[Why]
Userspace should get back a copy of drm_wait_vblank that's been modified
even when drm_wait_vblank_ioctl returns a failure.
Rationale:
drm_wait_vblank_ioctl modifies the request and expects the user to read
it
From: Kenneth Feng
[ Upstream commit 2fd31689f9e44af949f60ff4f8aca013e628ab81 ]
This reverts commit 0979d43259e13846d86ba17e451e17fec185d240.
Revert this because it does not apply to all the cards.
Signed-off-by: Kenneth Feng
Reviewed-by: Hawking Zhang
Signed-off-by: Alex Deucher
Signed-off-
From: Ben Skeggs
[ Upstream commit 148a8653789c01f159764ffcc3f370008966b42f ]
Long ago, there had been plans for making use of a bunch of these APIs
from userspace and there's various checks in place to stop misbehaving.
Countless other projects have occurred in the meantime, and the pieces
did
From: Ben Skeggs
[ Upstream commit 6eaa1f3c59a707332e921e32782ffcad49915c5e ]
When booted with multiple displays attached, the EFI GOP driver on (at
least) Ampere, can leave DP links powered up that aren't being used to
display anything. This confuses our tracking of SOR routing, with the
likel
From: Ben Skeggs
[ Upstream commit fa25f28ef2cef19bc9ffeb827b8ecbf48af7f892 ]
Still no GA106 as I don't have HW to verif.
Signed-off-by: Ben Skeggs
Reviewed-by: Lyude Paul
Signed-off-by: Sasha Levin
---
.../gpu/drm/nouveau/nvkm/engine/device/base.c | 21 +++
1 file changed,
From: Ben Skeggs
[ Upstream commit e78b1b545c6cfe9f87fc577128e00026fff230ba ]
Should fix some initial modeset failures on (at least) Ampere boards.
Signed-off-by: Ben Skeggs
Reviewed-by: Lyude Paul
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 27 +
From: Kenneth Feng
[ Upstream commit 93c5701b00d50d192ce2247cb10d6c0b3fe25cd8 ]
change the workload type for some cards as it is needed.
Signed-off-by: Kenneth Feng
Reviewed-by: Hawking Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/pm/powerplay/hwmgr/vega
From: Mark Yacoub
[ Upstream commit fa0b1ef5f7a694f48e00804a391245f3471aa155 ]
[Why]
Userspace should get back a copy of drm_wait_vblank that's been modified
even when drm_wait_vblank_ioctl returns a failure.
Rationale:
drm_wait_vblank_ioctl modifies the request and expects the user to read
it
From: Kenneth Feng
[ Upstream commit 2fd31689f9e44af949f60ff4f8aca013e628ab81 ]
This reverts commit 0979d43259e13846d86ba17e451e17fec185d240.
Revert this because it does not apply to all the cards.
Signed-off-by: Kenneth Feng
Reviewed-by: Hawking Zhang
Signed-off-by: Alex Deucher
Signed-off-
Hi all,
[Thanks Guenter for pointing this out]
On Mon, 23 Aug 2021 12:41:22 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
>
> between commit:
>
> 71ac6f390f6a ("drm/mediatek: Add AAL output si
Hi allr,
On Mon, 23 Aug 2021 08:47:38 -0700 Guenter Roeck wrote:
>
> Seen in next-20210823:
>
> Building x86_64:allyesconfig ... failed
>
> drivers/gpu/drm/i915/i915_module.c:50:11: error:
> positional initialization of field in 'struct' declared with
Acked-by: Anitha Chrisanthus
> -Original Message-
> From: jing yangyang
> Sent: Thursday, August 19, 2021 7:10 PM
> To: Chrisanthus, Anitha
> Cc: Dea, Edmund J ; David Airlie ;
> Daniel Vetter ; dri-devel@lists.freedesktop.org; linux-
> ker...@vger.kernel.org; jing yangyang ; Zeal
> Rob
On 23 August 2021 22:13:45 BST, Alyssa Rosenzweig wrote:
>> > When locking a region, we currently clamp to a PAGE_SIZE as the minimum
>> > lock region. While this is valid for Midgard, it is invalid for Bifrost,
>>
>> While the spec does seem to state it's invalid for Bifrost - kbase
>> didn't bo
On 8/20/2021 6:54 PM, Jason Gunthorpe wrote:
On Thu, Jul 29, 2021 at 12:39:12PM +0300, Leon Romanovsky wrote:
+/**
+ * __sg_free_table - Free a previously mapped sg table
+ * @table: The sg table header to use
+ * @max_ents: The maximum number of entries per single scatterlist
+ * @total
On 8/23/2021 3:45 PM, Jason Gunthorpe wrote:
On Mon, Aug 23, 2021 at 02:09:37PM +0300, Maor Gottlieb wrote:
On 8/20/2021 6:54 PM, Jason Gunthorpe wrote:
On Thu, Jul 29, 2021 at 12:39:12PM +0300, Leon Romanovsky wrote:
+/**
+ * __sg_free_table - Free a previously mapped sg table
+ * @table:
On 23 August 2021 22:11:09 BST, Alyssa Rosenzweig wrote:
>> > Mali virtual addresses are 48-bit. Use a u64 instead of size_t to ensure
>> > we can express the "lock everything" condition as ~0ULL without relying
>> > on platform-specific behaviour.
>>
>> 'platform-specific behaviour' makes it sou
On 23 August 2021 22:09:08 BST, Alyssa Rosenzweig wrote:
>> > In lock_region, simplify the calculation of the region_width parameter.
>> > This field is the size, but encoded as log2(ceil(size)) - 1.
>> > log2(ceil(size)) may be computed directly as fls(size - 1). However, we
>> > want to use the
The wrappers in include/linux/pci-dma-compat.h should go away.
The patch has been generated with the coccinelle script below.
@@
expression e1, e2, e3, e4;
@@
-pci_free_consistent(e1, e2, e3, e4)
+dma_free_coherent(&e1->dev, e2, e3, e4)
Signed-off-by: Christophe JAILLET
---
If needed, s
[snip]
I think I might still be misunderstanding something, some comments below
On Mon, 2021-08-23 at 06:33 +, Lin, Wayne wrote:
> > > Hi Lyude,
> > >
> > > Really thankful for willing to explain in such details. Really
> > > appreciate.
> > >
> > > I'm trying to fix some problems that obse
> > When locking a region, we currently clamp to a PAGE_SIZE as the minimum
> > lock region. While this is valid for Midgard, it is invalid for Bifrost,
>
> While the spec does seem to state it's invalid for Bifrost - kbase
> didn't bother with a lower clamp for a long time. I actually think this
> > Mali virtual addresses are 48-bit. Use a u64 instead of size_t to ensure
> > we can express the "lock everything" condition as ~0ULL without relying
> > on platform-specific behaviour.
>
> 'platform-specific behaviour' makes it sound like this is something to
> do with a particular board. This
> > In lock_region, simplify the calculation of the region_width parameter.
> > This field is the size, but encoded as log2(ceil(size)) - 1.
> > log2(ceil(size)) may be computed directly as fls(size - 1). However, we
> > want to use the 64-bit versions as the amount to lock can exceed
> > 32-bits.
20.08.2021 15:57, Ulf Hansson пишет:
...
>> We already have similar APIs, so that won't be a problem. We also have
>> a mechanism inside the OPP core, frequency based, which is used to
>> guess the current OPP. Maybe we can enhance and use that directly
>> here.
>
> After reading the last reply fr
On Thu, Aug 19, 2021 at 12:10:19PM +0200, Krzysztof Kozlowski wrote:
> Correct indentation warning:
> ilitek,ili9341.yaml:25:9: [warning] wrong indentation: expected 10 but
> found 8 (indentation)
>
> Signed-off-by: Krzysztof Kozlowski
Thanks, applied to drm-misc-next, and the patch will show
[Public]
> -Original Message-
> From: Koenig, Christian
> Sent: Monday, August 23, 2021 3:02 PM
> To: Kees Cook ; Lazar, Lijo
>
> Cc: Pan, Xinhui ; David Airlie ;
> Daniel Vetter ; Zhang, Hawking
> ; Xu, Feifei ; Gao, Likun
> ; Gu, JiaWei (Will) ; Quan,
> Evan ; amd-...@lists.freedesktop
On Mon, Aug 23, 2021 at 09:38:56PM +0200, Sam Ravnborg wrote:
> On Mon, Aug 23, 2021 at 06:37:55PM +0100, Mark Brown wrote:
> > [2/2] dt-bindings: sound: rt1015p: correct indentation
> > commit: 0aeb17d1728257f29131a290f0cc8e281cc7274c
> I am confused here.
> Did you apply both patches or o
Hi Mark,
On Mon, Aug 23, 2021 at 06:37:55PM +0100, Mark Brown wrote:
> On Thu, 19 Aug 2021 12:10:19 +0200, Krzysztof Kozlowski wrote:
> > Correct indentation warning:
> > ilitek,ili9341.yaml:25:9: [warning] wrong indentation: expected 10 but
> > found 8 (indentation)
>
> Applied to
>
>htt
Am 23.08.21 um 16:23 schrieb Kees Cook:
On August 22, 2021 11:28:54 PM PDT, "Christian König"
wrote:
Am 19.08.21 um 22:14 schrieb Kees Cook:
[...]
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 96e895d6be35..4605934a4fb7 100644
--- a/drivers/gp
Ping? This is a pretty clear bug and it is not fixed in -next or
drm-intel at this point.
On Fri, Aug 13, 2021 at 10:11:58AM -0700, Nathan Chancellor wrote:
> Clang warns:
>
> In file included from drivers/gpu/drm/i915/gt/intel_reset.c:1514:
> drivers/gpu/drm/i915/gt/selftest_hangcheck.c:465:62:
23.08.2021 17:33, Thierry Reding пишет:
> On Sat, Aug 21, 2021 at 08:45:54PM +0300, Dmitry Osipenko wrote:
>> 20.08.2021 16:08, Ulf Hansson пишет:
>> ...
I suppose if there's really no good way of doing this other than
providing a struct device, then so be it. I think the cleaned up sysfs
On Sat, 21 Aug 2021 11:13:57 +0800, Zenghui Yu wrote:
> The zte zx platform had been removed in commit 89d4f98ae90d ("ARM: remove
> zte zx platform"), so this driver is no longer needed.
>
> Cc: Arnd Bergmann
> Cc: Jun Nie
> Cc: Shawn Guo
> Signed-off-by: Zenghui Yu
> ---
> .../devicetree/bin
On Sun, Aug 22, 2021 at 5:34 PM Christophe JAILLET
wrote:
>
> The wrappers in include/linux/pci-dma-compat.h should go away.
>
> The patch has been generated with the coccinelle script below.
>
> It has been compile tested.
>
> @@
> @@
> -PCI_DMA_BIDIRECTIONAL
> +DMA_BIDIRECTIONAL
>
> @@
>
On Mon, Aug 23, 2021 at 12:41 AM Andy Shevchenko
wrote:
>
> On Mon, Aug 23, 2021 at 1:21 AM Jim Cromie wrote:
> >
> > DEFINE_DYNAMIC_DEBUG_CATEGORIES(name, var, bitmap_desc, @bit_descs)
> > allows users to define a drm.debug style (bitmap) sysfs interface, and
> > to specify the desired mapping f
Applied. Thanks!
Alex
On Mon, Aug 23, 2021 at 2:17 AM Christian König
wrote:
>
> Am 22.08.21 um 23:23 schrieb Christophe JAILLET:
> > The wrappers in include/linux/pci-dma-compat.h should go away.
> >
> > The patch has been generated with the coccinelle script below.
> >
> > It has been compile
Applied. Thanks!
Alex
On Mon, Aug 23, 2021 at 2:16 AM Christian König
wrote:
>
> Am 22.08.21 um 23:21 schrieb Christophe JAILLET:
> > The wrappers in include/linux/pci-dma-compat.h should go away.
> >
> > The patch has been generated with the coccinelle script below.
> >
> > It has been compile
On Thu, 19 Aug 2021 12:10:19 +0200, Krzysztof Kozlowski wrote:
> Correct indentation warning:
> ilitek,ili9341.yaml:25:9: [warning] wrong indentation: expected 10 but
> found 8 (indentation)
>
>
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
On Mon, Aug 23, 2021 at 05:50:27PM +1000, Stephen Rothwell wrote:
> From: Stephen Rothwell
> Date: Mon, 23 Aug 2021 17:46:27 +1000
> Subject: [PATCH] drm/i915/ttm: fix up for "lib/scatterlist: Provide a
> dedicated function to support tableappend"
>
> Signed-off-by: Stephen Rothwell
> drivers/
Previously, master_lookup_lock was introduced in
commit 0b0860a3cf5e ("drm: serialize drm_file.master with a new
spinlock") to serialize accesses to drm_file.master. This then allowed
us to write drm_file_get_master in commit 56f0729a510f ("drm: protect
drm_master pointers in drm_lease.c").
The ra
drm_device.master_rwsem is an outer lock that's grabbed in the ioctl
handler. However, in a future patch, master_rwsem will replace
drm_file.master_lookup_lock in drm_file_get_master, which is sometimes
called while holding other locks that depend on master_rwsem. This
circular locking should be av
In drm_client_modeset.c and drm_fb_helper.c,
drm_master_internal_{acquire,release} are used to avoid races with DRM
userspace. These functions hold onto drm_device.master_rwsem while
committing, and bail if there's already a master.
However, there are other places where modesetting rights can race
In a future patch, a read lock on drm_device.master_rwsem is
held in the ioctl handler before the check for ioctl
permissions. However, this inverts the lock hierarchy of
drm_global_mutex --> master_rwsem.
To avoid this, we do some prep work to grab the drm_global_mutex
before checking for ioctl p
drm_device.master_mutex currently protects the following:
- drm_device.master
- drm_file.master
- drm_file.was_master
- drm_file.is_master
- drm_master.unique
- drm_master.unique_len
- drm_master.magic_map
There is a clear separation between functions that read or change
these attributes. Hence, c
drm_master_release can be called on a drm_file without a master, which
results in a null ptr dereference of file_priv->master->magic_map. The
three cases are:
1. Error path in drm_open_helper
drm_open():
drm_open_helper():
drm_master_open():
drm_new_set_master(); <--- returns -
Hi,
I updated the series to untangle more lock inversions caught by the
Intel-gfx CI, but again there might be more that I missed.
This series now converts drm_device.master_mutex into master_rwsem, and
also removes drm_file.master_lookup_lock.
Overall, this series makes the following changes:
Hi Maxime,
On 23.08.2021 10:47, Maxime Ripard wrote:
> Interactions between bridges, panels, MIPI-DSI host and the component
> framework are not trivial and can lead to probing issues when
> implementing a display driver. Let's document the various cases we need
> too consider, and the solution t
Hi,
On Wed, Aug 18, 2021 at 08:48:46AM -0500, Rob Herring wrote:
> On Wed, Aug 18, 2021 at 7:43 AM Maxime Ripard wrote:
> >
> > Hi Rob, Sam,
> >
> > On Wed, Jul 21, 2021 at 08:29:47PM -0600, Rob Herring wrote:
> > > On Wed, Jul 21, 2021 at 04:03:40PM +0200, Maxime Ripard wrote:
> > > > The bindin
The DP 2.0 128b/132b channel coding uses TX FFE presets instead of
vswing and pre-emphasis.
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_dp_helper.c | 14 ++
include/drm/drm_dp_helper.h | 2 ++
2 files changed
DP 2.0 brings some new DPCD addresses for PHY repeaters.
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Manasi Navare
Signed-off-by: Jani Nikula
---
include/drm/drm_dp_helper.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
in
Extend the use of extended receiver cap at 0x2200 to cover
MAIN_LINK_CHANNEL_CODING_CAP in 0x2206, in case an implementation hides
the DP 2.0 128b/132b channel encoding cap.
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Manasi Navare
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_dp_help
The bw code equals link_rate / 0.27 Gbps only for 8b/10b link
rates. Handle DP 2.0 UHBR rates as special cases, though this is not
pretty.
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_dp_helper.c | 26 ++
1 file changed, 22 insert
On Mon, 23 Aug 2021, Guenter Roeck wrote:
> On Tue, Jul 27, 2021 at 02:10:37PM +0200, Daniel Vetter wrote:
>> The module init code is somewhat misplaced in i915_pci.c, since it
>> needs to pull in init/exit functions from every part of the driver and
>> pollutes the include list a lot.
>>
>> Extr
Hi Dave, Daniel,
The following changes since commit e73f0f0ee7541171d89f2e2491130c7771ba58d3:
Linux 5.14-rc1 (2021-07-11 15:07:40 -0700)
are available in the Git repository at:
git://git.pengutronix.de/pza/linux tags/imx-drm-fixes-2021-08-18
for you to fetch changes up to 72fc2752f91b40312
23.08.2021 13:46, Ulf Hansson пишет:
>>> ...
>>> dev_pm_opp_set_rate(rate)
>>> pm_runtime_get_noresume()
>>> pm_runtime_set_active()
>>> pm_runtime_enable()
>>> ...
>>> pm_runtime_put()
>>> ...
>>>
>>> We need to call genpd_set_performance_state() independently of whether
>>> the device is runtime
Add driver for BOE tv110c9m-ll3 panel is a 10.95" 1200x2000 panel.
Signed-off-by: yangcong
---
drivers/gpu/drm/panel/Kconfig | 10 +
drivers/gpu/drm/panel/Makefile |1 +
drivers/gpu/drm/panel/panel-boe-tv110c9m.c | 1303
3 files changed, 1314 i
Hi yangcong,
On Mon, Aug 23, 2021 at 07:51:23PM +0800, yangcong wrote:
> Documentation/devicetree/bindings/display/panel/boe,tv110c9m-ll3.yaml:
>
> Compared with v1, add a space in the required list.
>
> yangcong (2):
> drm/panel: support for BOE tv1110c9m-ll3 wuxga dsi video mode panel
Can
On Tue, Jul 27, 2021 at 02:10:37PM +0200, Daniel Vetter wrote:
> The module init code is somewhat misplaced in i915_pci.c, since it
> needs to pull in init/exit functions from every part of the driver and
> pollutes the include list a lot.
>
> Extract an i915_module.c file which pulls all the bits
Hi Geert,
On Mon, Aug 23, 2021 at 02:25:32PM +0200, Geert Uytterhoeven wrote:
> On Sun, Aug 22, 2021 at 2:36 AM Laurent Pinchart wrote:
> > On R-Car D3 and E3, the LVDS encoders provide the pixel clock to the DU,
> > even when LVDS outputs are not used. For this reason, the rcar-lvds
> > driver pr
On Sat, Aug 21, 2021 at 4:46 AM Liviu Cheru wrote:
>
> Fixed warnings regarding SPDX license, using "unsigned" instead
> of "unsigned int", wrong function parameter name for the
> documentation and a space between the function name and "(".
>
In general, please split these up by the type of chang
On Sat, Aug 21, 2021 at 08:45:54PM +0300, Dmitry Osipenko wrote:
> 20.08.2021 16:08, Ulf Hansson пишет:
> ...
> >> I suppose if there's really no good way of doing this other than
> >> providing a struct device, then so be it. I think the cleaned up sysfs
> >> shown in the summary above looks much
On August 22, 2021 11:28:54 PM PDT, "Christian König"
wrote:
>
>
>Am 19.08.21 um 22:14 schrieb Kees Cook:
>> [...]
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> index 96e895d6be35..4605934a4fb7 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu
On Mon, Aug 23, 2021 at 04:45:45PM +0300, Maor Gottlieb wrote:
>
> On 8/23/2021 3:45 PM, Jason Gunthorpe wrote:
> > On Mon, Aug 23, 2021 at 02:09:37PM +0300, Maor Gottlieb wrote:
> > > On 8/20/2021 6:54 PM, Jason Gunthorpe wrote:
> > > > On Thu, Jul 29, 2021 at 12:39:12PM +0300, Leon Romanovsky wr
Am 23.08.21 um 13:28 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Proposal to standardise the fdinfo text format as optionally output by DRM
drivers.
Idea is that a simple but, well defined, spec will enable generic
userspace tools to be written while at the same time avoiding a more heavy
han
On Mon, 23 Aug 2021 19:51:25 +0800, yangcong wrote:
> Add documentation for boe tv110c9m-ll3 panel.
>
> Signed-off-by: yangcong
> ---
> .../display/panel/boe,tv110c9m-ll3.yaml | 83 +++
> 1 file changed, 83 insertions(+)
> create mode 100644
> Documentation/devicetree/bin
On Mon, Aug 23, 2021 at 02:09:37PM +0300, Maor Gottlieb wrote:
>
> On 8/20/2021 6:54 PM, Jason Gunthorpe wrote:
> > On Thu, Jul 29, 2021 at 12:39:12PM +0300, Leon Romanovsky wrote:
> >
> > > +/**
> > > + * __sg_free_table - Free a previously mapped sg table
> > > + * @table: The sg table he
Hi Laurent,
On Sun, Aug 22, 2021 at 2:36 AM Laurent Pinchart
wrote:
> On R-Car D3 and E3, the LVDS encoders provide the pixel clock to the DU,
> even when LVDS outputs are not used. For this reason, the rcar-lvds
> driver probes successfully on those platforms even if no further bridge
> or panel
From: Tvrtko Ursulin
As contexts are abandoned we want to remember how much GPU time they used
(per class) so later we can used it for smarter purposes.
As GEM contexts are closed we want to have the DRM client remember how
much GPU time they used (per class) so later we can used it for smarter
From: Tvrtko Ursulin
Convert fdinfo format to one documented in drm-usage-stats.rst.
Opens:
* Does it work for AMD?
* What are the semantics of AMD engine utilisation reported in percents?
Can it align with what i915 does or needs to document the alternative
in the specification document
From: Tvrtko Ursulin
We soon want to start answering questions like how much GPU time is the
context belonging to a client which exited still using.
To enable this we start tracking all context belonging to a client on a
separate list.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamse
From: Tvrtko Ursulin
Similar to AMD commit
874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
infrastructure added in previous patches, we add basic client info
and GPU engine utilisation for i915.
Example of the output:
pos:0
flags: 012
mnt_id: 21
drm-driver:
From: Tvrtko Ursulin
Track context active (on hardware) status together with the start
timestamp.
This will be used to provide better granularity of context
runtime reporting in conjunction with already tracked pphwsp accumulated
runtime.
The latter is only updated on context save so does not g
From: Tvrtko Ursulin
Proposal to standardise the fdinfo text format as optionally output by DRM
drivers.
Idea is that a simple but, well defined, spec will enable generic
userspace tools to be written while at the same time avoiding a more heavy
handed approach of adding a mid-layer to DRM.
i91
From: Tvrtko Ursulin
Make GEM contexts keep a reference to i915_drm_client for the whole of
of their lifetime which will come handy in following patches.
v2: Don't bother supporting selftests contexts from debugfs. (Chris)
v3 (Lucas): Finish constructing ctx before adding it to the list
v4 (Ram)
From: Tvrtko Ursulin
Tracking DRM clients more explicitly will allow later patches to
accumulate past and current GPU usage in a centralised place and also
consolidate access to owning task pid/name.
Unique client id is also assigned for the purpose of distinguishing/
consolidating between multi
From: Tvrtko Ursulin
Same old work but now rebased and series ending with some DRM docs proposing
the common specification which should enable nice common userspace tools to be
written.
For the moment I only have intel_gpu_top converted to use this and that seems to
work okay.
v2:
* Added prot
On Thu, Aug 19, 2021 at 12:10:20PM +0200, Krzysztof Kozlowski wrote:
> Use common enum instead of oneOf and correct indentation warning:
> realtek,rt1015p.yaml:18:7: [warning] wrong indentation: expected 4 but
> found 6 (indentation)
For stuff like this where there's no relationship between the
On Mon, 2021-08-23 at 13:05 +0200, Christian König wrote:
> Adding Thomas on CC as well.
>
> Just a gentle ping. I think the patch set makes sense now.
>
> Regards,
> Christian.
>
> Am 28.07.21 um 15:05 schrieb Christian König:
> > Doing this in vmw_ttm_destroy() is to late.
> >
> > It turned o
Adding Thomas on CC as well.
Just a gentle ping. I think the patch set makes sense now.
Regards,
Christian.
Am 28.07.21 um 15:05 schrieb Christian König:
Doing this in vmw_ttm_destroy() is to late.
It turned out that this is not a good idea at all because it leaves pointers
to freed up system
[...]
> We have three components comprising PM on Tegra:
>
> 1. Power gate
> 2. Clock state
> 3. Voltage state
>
> GENPD on/off represents the 'power gate'.
>
> Clock and reset are controlled by device drivers using clk and rst APIs.
>
> Volta
1 - 100 of 123 matches
Mail list logo
