Hi,
On Tue, Jul 09, 2024 at 08:01:26PM GMT, Johan Jonker wrote:
> Change rk3066_hdmi.c to bridge driver mode.
>
> Signed-off-by: Johan Jonker
Generally speaking, I think you should use the new HDMI bridge
infrastructure that recently landed in drm-misc-next.
Maxime
signature.asc
Description:
On Tue, Jul 9, 2024 at 7:48 PM Rodrigo Siqueira Jordao
wrote:
> Hi,
>
> I also tried it with 6900XT. I got the same results on my side.
This is weird.
> Anyway, I could not reproduce the issue with the below components. I may
> be missing something that will trigger this bug; in this sense, coul
On Wed, Jul 10, 2024 at 12:01 PM Mikhail Gavrilov
wrote:
>
> On Tue, Jul 9, 2024 at 7:48 PM Rodrigo Siqueira Jordao
> wrote:
> > Hi,
> >
> > I also tried it with 6900XT. I got the same results on my side.
>
> This is weird.
>
> > Anyway, I could not reproduce the issue with the below components.
On Tue, Jul 09, 2024 at 06:36:08PM GMT, Dragan Simic wrote:
> > > > > As I already wrote earlier, and as the above-linked discussions
> > > > > conclude, solving these issues doesn't belong to any specific driver.
> > > > > It should be resolved within the kernel's firmware loading mechanism
> > >
Merged into drm-misc-next-fixes
Am 08.07.24 um 16:21 schrieb Thomas Zimmermann:
Add qxl_bo_pin_and_vmap() that pins and vmaps a buffer object in one
step. Update callers of the regular qxl_bo_vmap(). Fixes a bug where
qxl accesses an unpinned buffer object while it is being moved; such
as with t
On Tue, 9 Jul 2024 at 22:39, Abhinav Kumar wrote:
>
>
>
> On 7/9/2024 6:48 AM, Dmitry Baryshkov wrote:
> > DPU debugging macros need to be converted to a proper drm_debug_*
> > macros, however this is a going an intrusive patch, not suitable for a
> > fix. Wire DPU_DEBUG and DPU_DEBUG_DRIVER to al
As the comment explains, the if check ensures that the divisor oa_period
is a u32. Explicitly cast oa_period to u32 to remove the following
Coccinelle/coccicheck warning reported by do_div.cocci:
WARNING: do_div() does a 64-by-32 division, please consider using div64_u64
instead
Signed-off-by:
…
> > Signed-off-by: Ma Ke
>
> Thanks for the patch!
> Pushed to drm-misc-fixes
Do you care for the applicability of the available information
according to this tag?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.10-rc7#n3
From: Hsiao Chien Sung
Support "Pre-multiplied" alpha blending mode on in OVL.
Before this patch, only the "coverage" mode is supported.
Signed-off-by: Hsiao Chien Sung
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 32 +---
1 file changed, 25 ins
From: Hsiao Chien Sung
Support "Pre-multiplied" alpha blending mode in Mixer.
Before this patch, only the coverage mode is supported.
To replace the default setting that is set in mtk_ethdr_config(),
we change mtk_ddp_write_mask() to mtk_ddp_write(), and this change will
also reset the NON_PREMU
From: Hsiao Chien Sung
Support "None" alpha blending mode on MediaTek's chips.
Change-Id: I9455c367bb74b75461935ecf4a3eb8e429f6e95e
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_ethdr.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/me
From: Hsiao Chien Sung
Support "Pre-multiplied" and "None" blend mode on MediaTek's chips by
adding correct blend mode property when the planes init.
Before this patch, only the "Coverage" mode (default) is supported.
For more information, there are three pixel blend modes in DRM driver:
"None",
gpu/drm/mediatek/mtk_ethdr.c| 13 +---
drivers/gpu/drm/mediatek/mtk_plane.c| 11 ++
3 files changed, 49 insertions(+), 11 deletions(-)
---
base-commit: 8ad49a92cff4bab13eb2f2725243f5f31eff3f3b
change-id: 20240710-alpha-blending-067295570863
Best regards,
--
Hsiao Chien Sung
From: Hsiao Chien Sung
Support "None" alpha blending mode on MediaTek's chips.
Reviewed-by: CK Hu
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drive
On Tue, Jul 09, 2024 at 04:27:18PM -0400, Rodrigo Vivi wrote:
> On Fri, Jun 28, 2024 at 05:46:01PM +0300, Jani Nikula wrote:
> >
> > Hi Dave & Sima -
> >
> > Another feature pull towards v6.11, hopefully last. This should also fix
> > the 32-bit build issue [1] seen in drm-next.
>
> Sima, Dave,
On Tue, Jul 09, 2024 at 10:02:08AM -0400, Hamza Mahfooz wrote:
> On 7/9/24 06:09, Daniel Vetter wrote:
> > On Tue, Jul 09, 2024 at 11:32:11AM +0200, Daniel Vetter wrote:
> > > On Mon, Jul 08, 2024 at 04:29:07PM -0400, Hamza Mahfooz wrote:
> > > > Hook up drm_crtc_set_vblank_offdelay() in amdgpu_dm,
The VRSTEN and HRSTEN bits control whether a CRTC synchronizes its
display signal with an external source on the VIDRST pin. The G200WB
and G200EW3 models synchronize with a BMC chip, but different external
video encoders, such as the Matrox Maven, can also be attached to the
pin.
Only set VRSTEN
(was: drm/mgag200: Handle VIDRST from BMC helpers)
The VIDRST pin controls CRTC synchronization with an external clock
chip, such as a BMC or TV encoder. This patchset separates the CRTC
state from the BMC state and streamlines the driver code.
v2:
- run BMC and VIDRST logic from CRTC code (Jocel
The callbacks disable_vidrst and enable_vidrst are obsolete. Remove
the fields from struct mgag200_device_funcs. Instead call their
implementations directly of the field 'has_vidrst' has been set in
struct mgag200_device_info.
Also change the logic slightly. The BMC used to start and stop scanout
The BMC's scanout synchronization is only indirectly related to the
VIDRST functionality. Do some renaming.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_bmc.c| 4 ++--
drivers/gpu/drm/mgag200/mgag200_drv.h| 14 +++---
drivers/gpu/drm/mgag200/mgag200_g200e
This series main purpose is to break some common CMDS into helper
functions (select page and reload CMDS), refer to the discussion
between Linus and Doug [1]. It is expected that there will be no
impact on the functionality, but I don???t have an actual board to
verify it.
[1]
https://lore.ker
hj110iz-01a and tv110c9m-ll3 both nt36523 controller, and they have
some common cmds, so let's break them into helper functions.
Signed-off-by: Cong Yang
---
.../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 190 ++
1 file changed, 63 insertions(+), 127 deletions(-)
diff --git a/d
Break select page cmds into helper functions.
Signed-off-by: Cong Yang
---
.../panel/panel-sony-tulip-truly-nt35521.c| 29 ++-
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-sony-tulip-truly-nt35521.c
b/drivers/gpu/drm/panel/panel-
Break select page cmds and reload cmds into helper functions.
Signed-off-by: Cong Yang
---
.../gpu/drm/panel/panel-novatek-nt36672e.c| 69 ---
1 file changed, 44 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
b/drivers/gpu/drm/pan
Break select page cmds into helper function.
Signed-off-by: Cong Yang
---
drivers/gpu/drm/panel/panel-ilitek-ili9806e.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9806e.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9806e
From: Hsiao Chien Sung
Support "None" alpha blending mode on MediaTek's chips.
Reviewed-by: CK Hu
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drive
the Change-Id
- Link to v2:
https://lore.kernel.org/r/20240710-alpha-blending-v2-0-d4b505e69...@mediatek.com
Changes in v2:
- Remove unnecessary codes
- Add more information to the commit message
- Link to v1:
https://lore.kernel.org/r/20240620-blend-v1-0-72670072c...@mediatek.com
---
Hsiao Chien Su
From: Hsiao Chien Sung
Support "Pre-multiplied" alpha blending mode on in OVL.
Before this patch, only the "coverage" mode is supported.
Signed-off-by: Hsiao Chien Sung
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 32 +---
1 file changed, 25 ins
From: Hsiao Chien Sung
Support "Pre-multiplied" alpha blending mode in Mixer.
Before this patch, only the coverage mode is supported.
To replace the default setting that is set in mtk_ethdr_config(),
we change mtk_ddp_write_mask() to mtk_ddp_write(), and this change will
also reset the NON_PREMU
From: Hsiao Chien Sung
Support "Pre-multiplied" and "None" blend mode on MediaTek's chips by
adding correct blend mode property when the planes init.
Before this patch, only the "Coverage" mode (default) is supported.
For more information, there are three pixel blend modes in DRM driver:
"None",
From: Hsiao Chien Sung
Support "None" alpha blending mode on MediaTek's chips.
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_ethdr.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_ethdr.c
b/drivers/gpu/drm/mediatek/mtk_et
On Tue, Jul 09, 2024 at 06:54:26AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:661e504db04c Merge tag 'for-6.10-rc6-tag' of git://git.ker..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=144e9f9998
> kernel
On Tue, Jul 9, 2024 at 5:10 PM Jocelyn Falempe wrote:
>
> I used to list all QR versions in an enum, but I find it a bit too much
> boilerplate to ensure the version is between 1 and 40.
> By transparent newtypes, you mean adding "#[repr(transparent)]" to a
> struct ?
> I don't plan to add more "v
On Wed Jul 10, 2024 at 10:47 AM CEST, Cong Yang wrote:
> Break select page cmds into helper function.
Why though? I don't find that anything easier to read. In fact, I
deliberately chose not to factor that out into a function. It's just
a sequence of magic commands, taken straight from the datashe
On 7/4/2024 10:18 AM, Nirmoy Das wrote:
Clearing bo with uncompress PTE will trigger a CCS clearing as well
for XE2, so skip emit_copy_ccs() when on xe2 when clearing bo.
v2: When clearing BO, CCS clear happens with all command as long
as PTEs are uncompress.
Cc: Himal Prasad Ghimiray
C
On Tue, Jul 09, 2024 at 10:53:18AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:8e2f4becf4fa Merge remote-tracking branch 'tglx/devmsi-arm..
> git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
> for-kernelci
> console outp
We already teach lockdep that dma_resv nests within drm_modeset_lock,
but there's a lot more: All drm kms ioctl rely on being able to
put/get_user while holding modeset locks, so we really need a
might_fault in there too to complete the picture. Add it.
Motivated by a syzbot report that blew up on
console_lock is the outermost subsystem lock for a lot of subsystems,
which means get/put_user must nest within. Which means it cannot be
acquired somewhere deeply nested in other locks, and most definitely
not while holding fs locks potentially needed to resolve faults.
console_trylock is the bes
Reviewed-by: Jacek Lawrynowicz
On 09.07.2024 13:54, Alexander F. Lent wrote:
> Modules that load firmware from various paths at runtime must declare
> those paths at compile time, via the MODULE_FIRMWARE macro, so that the
> firmware paths are included in the module's metadata.
>
> The accel/ivp
Mina Almasry writes:
> Add documentation outlining the usage and details of devmem TCP.
>
> Signed-off-by: Mina Almasry
> Reviewed-by: Bagas Sanjaya
Reviewed-by: Donald Hunter
Mina Almasry writes:
> API takes the dma-buf fd as input, and binds it to the netdevice. The
> user can specify the rx queues to bind the dma-buf to.
>
> Suggested-by: Stanislav Fomichev
> Signed-off-by: Mina Almasry
Reviewed-by: Donald Hunter
On 09/07/2024 15:02, Tvrtko Ursulin wrote:
On 09/07/2024 13:53, Nitin Gote wrote:
We're seeing a GPU HANG issue on a CHV platform, which was caused by
bac24f59f454 ("drm/i915/execlists: Enable coarse preemption boundaries
for gen8").
Gen8 platform has only timeslice and doesn't support a p
On 2024-07-10, Daniel Vetter wrote:
> console_lock is the outermost subsystem lock for a lot of subsystems,
> which means get/put_user must nest within. Which means it cannot be
> acquired somewhere deeply nested in other locks, and most definitely
> not while holding fs locks potentially needed t
On Wed, Jul 10, 2024 at 09:46:51AM +0200, Thorsten Blum wrote:
> As the comment explains, the if check ensures that the divisor oa_period
> is a u32. Explicitly cast oa_period to u32 to remove the following
> Coccinelle/coccicheck warning reported by do_div.cocci:
>
> WARNING: do_div() does a 64
Am 10.07.24 um 11:31 schrieb Daniel Vetter:
We already teach lockdep that dma_resv nests within drm_modeset_lock,
but there's a lot more: All drm kms ioctl rely on being able to
put/get_user while holding modeset locks, so we really need a
might_fault in there too to complete the picture. Add it.
On 10. Jul 2024, at 13:38, Ville Syrjälä wrote:
> On Wed, Jul 10, 2024 at 09:46:51AM +0200, Thorsten Blum wrote:
>> As the comment explains, the if check ensures that the divisor oa_period
>> is a u32. Explicitly cast oa_period to u32 to remove the following
>> Coccinelle/coccicheck warning report
On Wed, 10 Jul 2024 at 13:39, Christian König wrote:
>
> Am 10.07.24 um 11:31 schrieb Daniel Vetter:
> > We already teach lockdep that dma_resv nests within drm_modeset_lock,
> > but there's a lot more: All drm kms ioctl rely on being able to
> > put/get_user while holding modeset locks, so we rea
Il 10/07/24 10:52, Hsiao Chien Sung via B4 Relay ha scritto:
From: Hsiao Chien Sung
Support "Pre-multiplied" alpha blending mode on in OVL.
Before this patch, only the "coverage" mode is supported.
Signed-off-by: Hsiao Chien Sung
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_disp_ovl
Il 10/07/24 10:52, Hsiao Chien Sung via B4 Relay ha scritto:
From: Hsiao Chien Sung
Support "None" alpha blending mode on MediaTek's chips.
Signed-off-by: Hsiao Chien Sung
Reviewed-by: AngeloGioacchino Del Regno
Il 10/07/24 10:52, Hsiao Chien Sung via B4 Relay ha scritto:
From: Hsiao Chien Sung
Support "Pre-multiplied" alpha blending mode in Mixer.
Before this patch, only the coverage mode is supported.
To replace the default setting that is set in mtk_ethdr_config(),
we change mtk_ddp_write_mask() to
On Fri, Jul 05, 2024 at 04:31:34PM GMT, Thierry Reding wrote:
> On Thu, Jul 04, 2024 at 02:24:49PM GMT, Maxime Ripard wrote:
> > On Fri, Jun 28, 2024 at 04:42:35PM GMT, Thierry Reding wrote:
> > > On Fri, Jun 28, 2024 at 03:08:46PM GMT, Maxime Ripard wrote:
> > > > Hi,
> > > >
> > > > On Fri, Jun
On Wed, Jul 10, 2024 at 01:55:32PM +0200, Thorsten Blum wrote:
> On 10. Jul 2024, at 13:38, Ville Syrjälä
> wrote:
> > On Wed, Jul 10, 2024 at 09:46:51AM +0200, Thorsten Blum wrote:
> >> As the comment explains, the if check ensures that the divisor oa_period
> >> is a u32. Explicitly cast oa_per
Am 10.07.24 um 13:58 schrieb Daniel Vetter:
On Wed, 10 Jul 2024 at 13:39, Christian König wrote:
Am 10.07.24 um 11:31 schrieb Daniel Vetter:
We already teach lockdep that dma_resv nests within drm_modeset_lock,
but there's a lot more: All drm kms ioctl rely on being able to
put/get_user while
From: Thomas Hellström
For the drm_exec_trylock() functionality, there is a need to be able
to trylock a dma-resv object as part of a drm_exec transaction.
Therefore expose a variant of dma_resv_trylock that also takes
a struct ww_acquire_ctx parameter.
Cc: Christian König
Cc: Somalapuram Amara
Hi guys,
while this works in an initial test I just realized that we need to
merge the GEM and TTM reference count first for it to be 100% reliable.
Otherwise it can be that we try to evict BOs which are in the process of
being torn down. And this in turn will result in a whole bunch of
problems.
Some contended objects might never be locked again in the case of eviction
handling for example.
Make sure that those doesn't show up in the list of locked objects until
they are explicitely mentioned.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_exec.c | 18 +-
1 file
That is something drivers really shouldn't mess with.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 1 +
drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +
drivers/gpu/drm/ttm/ttm_bo_util.h | 67 +++
include/drm/ttm/ttm_bo.h | 35
Not a walk parameter but important to have that status around.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 26 --
drivers/gpu/drm/ttm/ttm_bo_util.h | 2 ++
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm
The TTM eviction path has some additional requirements which make it
necessary to trylock an object and then eventually keep or drop the lock
again.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_exec.c | 77 ++
include/drm/drm_exec.h | 5 +++
2 f
Allow specifying a drm_exec object in TTMs operation context which is
used to lock objects during eviction.
This allows to handle deadlocks much more gracefully and with that
avoid returning -ENOMEM on heavily contended domains.
v2: rebased on top of Thomas work
TODO: This still doesn't handle B
This allows to detect deadlocks happening because of resource
constraints.
Especially submissions which want to use all of GDS doesn't result in
sporadic -ENOMEM any more.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 86 ++
1 file changed,
On 10/07/2024 07:03, Paneer Selvam, Arunpravin wrote:
Thanks Alex.
Hi Matthew,
Any comments?
Do we not pass the required address alignment when allocating the pages
in the first place?
Thanks,
Arun.
On 7/9/2024 1:42 AM, Alex Deucher wrote:
On Thu, Jul 4, 2024 at 4:40 AM Arunpravin Panee
console_lock is the outermost subsystem lock for a lot of subsystems,
which means get/put_user must nest within. Which means it cannot be
acquired somewhere deeply nested in other locks, and most definitely
not while holding fs locks potentially needed to resolve faults.
console_trylock is the bes
Hi,
On Tue, 09 Jul 2024 21:47:49 +0800, Zhaoxiong Lv wrote:
> The Starry is a 10.1" WXGA TFT LCD panel. Because Starry-er88577
> and boe-th101mb31ig002 have very similar inti_code, after
> discussing with Dmitry Baryshkov, We will modify it based on the
> panel-boe-th101mb31ig002-28a.c driver inst
Am 05.07.24 um 23:14 schrieb Lukas Wunner:
On Fri, Jul 05, 2024 at 12:16:14PM -0500, Jeremy Linton wrote:
Am 05.07.24 um 17:03 schrieb Lukas Wunner:
Careful there, the patch vaguely says...
With that added and identified as "BCM2848",
an id in use by other OSs for this device, the dw
From: Tvrtko Ursulin
Check that the number of perfmons userspace is passing in the copy and
reset extensions is not greater than the internal kernel storage where
the ids will be copied into.
Signed-off-by: Tvrtko Ursulin
Fixes: bae7cb5d6800 ("drm/v3d: Create a CPU job extension for the reset
From: Tvrtko Ursulin
If fetching of userspace memory fails during the main loop, all drm sync
objs looked up until that point will be leaked because of the missing
drm_syncobj_put.
Fix it by exporting and using a common cleanup helper.
Signed-off-by: Tvrtko Ursulin
Fixes: bae7cb5d6800 ("drm/v3
From: Tvrtko Ursulin
If fetching of userspace memory fails during the main loop, all drm sync
objs looked up until that point will be leaked because of the missing
drm_syncobj_put.
Fix it by exporting and using a common cleanup helper.
Signed-off-by: Tvrtko Ursulin
Fixes: 9ba0ff3e083f ("drm/v3
From: Tvrtko Ursulin
When we had to quickly deal with a tree build issue via merging
792d16b5375d ("drm/v3d: Move perfmon init completely into own unit"), we
promised to follow up with a nicer solution.
As in the process of eliminating the hardcoded defines we have discovered a few
issues in han
From: Tvrtko Ursulin
If userspace provides an unknown or invalid handle anywhere in the handle
array the rest of the driver will not handle that well.
Fix it by checking handle was looked up successfuly or otherwise fail the
extension by jumping into the existing unwind.
Signed-off-by: Tvrtko U
From: Tvrtko Ursulin
Add some local variables to make the code a bit less verbose, with the
main benefit being pulling some lines to under 80 columns wide.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/v3d/v3d_submit.c | 79 +---
1 file changed, 42 insertions(+)
From: Tvrtko Ursulin
The loop which looks up the syncobj and copies the kperfmon ids is
identical so lets move it to a helper.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/v3d/v3d_submit.c | 148 +--
1 file changed, 64 insertions(+), 84 deletions(-)
diff --git
From: Tvrtko Ursulin
Instead of statically reserving pessimistic space for the kperfmon_ids
array, make the userspace extension code allocate the exactly required
amount of space.
Apart from saving some memory at runtime, this also removes the need for
the V3D_MAX_PERFMONS macro whose removal wi
From: Tvrtko Ursulin
Removing the intermediate buffer removes the last use of the
V3D_MAX_COUNTERS define, which will enable further driver cleanup.
While at it pull the 32 vs 64 bit copying decision outside the loop in
order to reduce the number of conditional instructions.
Signed-off-by: Tvrt
From: Tvrtko Ursulin
In the timestamp and performance extensions userspace type for counts is
u32 so lets use unsigned in the kernel too.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/v3d/v3d_submit.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/
From: Tvrtko Ursulin
It makes it just a tiny bit more obvious what is going on.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/v3d/v3d_submit.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_submit.c b/drivers/gpu/drm/v3d/v3d_submit.c
From: Tvrtko Ursulin
If userspace provides an unknown or invalid handle anywhere in the handle
array the rest of the driver will not handle that well.
Fix it by checking handle was looked up successfuly or otherwise fail the
extension by jumping into the existing unwind.
Signed-off-by: Tvrtko U
From: Tvrtko Ursulin
Now that the build time dependencies on various array sizes have been
removed, we can move the perfmon init completely into its own compilation
unit and remove the hardcoded defines.
This improves on the temporary fix quickly delivered in
792d16b5375d ("drm/v3d: Move perfmon
Hi Iago,
On 10/07/2024 07:06, Iago Toral wrote:
El mar, 09-07-2024 a las 17:34 +0100, Tvrtko Ursulin escribió:
From: Tvrtko Ursulin
When we had to quickly deal with a tree build issue via merging
792d16b5375d ("drm/v3d: Move perfmon init completely into own unit"),
we
promised to follow up
On 10/07/2024 14:41, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Check that the number of perfmons userspace is passing in the copy and
reset extensions is not greater than the internal kernel storage where
the ids will be copied into.
Signed-off-by: Tvrtko Ursulin
Fixes: bae7cb5d6800 ("drm/
Hi Maíra,
Le 03/07/2024 à 17:41, Maíra Canal a écrit :
Hi Pierre,
On 6/14/24 05:16, Pierre-Eric Pelloux-Prayer wrote:
This commit adds a document section in drm-uapi.rst about tracepoints,
and mark the events gpu_scheduler_trace.h as stable uAPI.
The goal is to explicitly state that tools can
On Tue, Jul 09, 2024 at 03:05:44PM +0200, Neil Armstrong wrote:
> Document the 1200x1920 BOE TV101WUM-LL2 DSI Display Panel found
> in the Lenovo Smart Tab M10 tablet. The controller is unknown.
>
> Signed-off-by: Neil Armstrong
Reviewed-by: Conor Dooley
signature.asc
Description: PGP signatu
On Sat, Jul 06, 2024 at 07:23:34PM +0900, Hironori KIKUCHI wrote:
> The RG28XX panel is a display panel of the Anbernic RG28XX, a handheld
> gaming device from Anbernic. It is 2.8 inches in size (diagonally) with
> a resolution of 480x640.
>
> This panel is driven by a variant of the ST7701 driver
This series adds a new panic screen, with the kmsg data embedded in a QR code.
The main advantage of QR code, is that you can copy/paste the debug data to a
bug report.
The QR code encoder is written in rust, and is very specific to drm panic.
The reason is that it is called in a panic handler,
Add a parameter to the blit function, to upscale the image.
This is necessary to draw a QR code, otherwise, the pixels are
usually too small to be readable by most QR code reader.
It can also be used later for drawing fonts on high DPI display.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/
Check if two rectangles overlap.
It's a bit similar to drm_rect_intersect() but this won't modify
the rectangle.
Simplifies a bit drm_panic.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/drm_panic.c | 3 +--
include/drm/drm_rect.h | 15 +++
2 files changed, 16 insertions(+
This patch adds a new panic screen, with a QR code and the kmsg data
embedded.
If DRM_PANIC_SCREEN_QR_CODE_URL is set, then the kmsg data will be
compressed with zlib and encoded as a numerical segment, and appended
to the URL as a URL parameter. This allows to save space, and put
about ~7500 bytes
On 2024-07-10, Daniel Vetter wrote:
> console_lock is the outermost subsystem lock for a lot of subsystems,
> which means get/put_user must nest within. Which means it cannot be
> acquired somewhere deeply nested in other locks, and most definitely
> not while holding fs locks potentially needed t
Move logo rectangle initialisation, and logo drawing in separate
functions, so they can be re-used by different panic screens.
It prepares the introduction of the QR code panic screen.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/drm_panic.c | 57 +
1 fi
On 2024-07-10, Daniel Vetter wrote:
> console_lock is the outermost subsystem lock for a lot of subsystems,
> which means get/put_user must nest within. Which means it cannot be
> acquired somewhere deeply nested in other locks, and most definitely
> not while holding fs locks potentially needed t
Am 10.07.24 um 15:57 schrieb Lei Liu:
Use vm_insert_page to establish a mapping for the memory allocated
by dmabuf, thus supporting direct I/O read and write; and fix the
issue of incorrect memory statistics after mapping dmabuf memory.
Well big NAK to that! Direct I/O is intentionally disabled
Hello Maxime,
On 2024-07-10 09:13, Maxime Ripard wrote:
On Tue, Jul 09, 2024 at 06:36:08PM GMT, Dragan Simic wrote:
> > > > As I already wrote earlier, and as the above-linked discussions
> > > > conclude, solving these issues doesn't belong to any specific driver.
> > > > It should be resolved
On 10/07/2024 10:42, Thomas Zimmermann wrote:
The callbacks disable_vidrst and enable_vidrst are obsolete. Remove
the fields from struct mgag200_device_funcs. Instead call their
implementations directly of the field 'has_vidrst' has been set in
struct mgag200_device_info.
Also change the logi
On 10/07/2024 10:42, Thomas Zimmermann wrote:
The VRSTEN and HRSTEN bits control whether a CRTC synchronizes its
display signal with an external source on the VIDRST pin. The G200WB
and G200EW3 models synchronize with a BMC chip, but different external
video encoders, such as the Matrox Maven,
On 10/07/2024 10:42, Thomas Zimmermann wrote:
The BMC's scanout synchronization is only indirectly related to the
VIDRST functionality. Do some renaming.
Thanks, it looks good to me.
Reviewed-by: Jocelyn Falempe
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_bmc
On Sun, May 26, 2024 at 10:04 AM Jason-JH Lin (林睿祥)
wrote:
>
> Hi Angelo, Jassi,
>
> Could you help me apply this series?
> Thanks!
>
Please get it reviewed by DT maintainers Rob or Krzysztof.
-Jassi
Hi
Am 10.07.24 um 16:25 schrieb Jocelyn Falempe:
+ if (set_vidrst)
crtcext1 |= MGAREG_CRTCEXT1_VRSTEN |
MGAREG_CRTCEXT1_HRSTEN;
+ else
+ crtcext1 &= ~(MGAREG_CRTCEXT1_VRSTEN | MGAREG_CRTCEXT1_HRSTEN);
The else case is useless, as crtcext1 has already
Am 10.07.24 um 16:35 schrieb Lei Liu:
在 2024/7/10 22:14, Christian König 写道:
Am 10.07.24 um 15:57 schrieb Lei Liu:
Use vm_insert_page to establish a mapping for the memory allocated
by dmabuf, thus supporting direct I/O read and write; and fix the
issue of incorrect memory statistics after map
> -Original Message-
> From: Tvrtko Ursulin
> Sent: Wednesday, July 10, 2024 4:22 PM
> To: Gote, Nitin R ; intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shyti, Andi ;
> chris.p.wil...@linux.intel.com; Das, Nirmoy ;
> janusz.krzyszto...@linux.intel.com; sta...@vge
1 - 100 of 182 matches
Mail list logo
