Hello,
Helge Deller, le ven. 15 mars 2024 10:35:40 +0100, a ecrit:
> You should have marked this patch with "v2"...
The actual changes were exactly the same.
> On 3/13/24 17:59, Samuel Thibault wrote:
> > This remains relatively simple by just enlarging integers.
>
> I like the patch, but I sti
By using bitmaps we actually support whatever size we would want, but the
console currently limits fonts to 64x128 (which gives 60x16 text on 4k
screens), so we don't need more for now, and we can easily increase later.
Signed-off-by: Samuel Thibault
---
Difference from v1:
- use a bitmap rather
When testing, it's convenient to be able to ignore DPCD errors if there
is test equipment which can't emulate a DPRX connected to the output.
Add some (currently-unused) options to ignore these errors and just
reconfigure our internal registers as we usually would.
Signed-off-by: Sean Anderson
--
Add some locking, since none is provided by the drm subsystem. This will
prevent the IRQ/workers/bridge API calls from stepping on each other's
toes.
Signed-off-by: Sean Anderson
---
drivers/gpu/drm/xlnx/zynqmp_dp.c | 59 +++-
1 file changed, 42 insertions(+), 17 del
The feedback we get from the DPRX is per-lane. Make changes using this
information, instead of picking the maximum values from all lanes. This
results in more-consistent training on marginal links.
Signed-off-by: Sean Anderson
---
drivers/gpu/drm/xlnx/zynqmp_dp.c | 23 ---
1
Add a debugfs interface for exercising the various test modes supported
by the DisplayPort controller. This allows performing compliance
testing, or performing signal integrity measurements on a failing link.
At the moment, we do not support sink-driven link quality testing,
although such support w
In preparation for supporting compliance testing, split off several
helper functions. No functional change intended.
Signed-off-by: Sean Anderson
---
drivers/gpu/drm/xlnx/zynqmp_dp.c | 49 +---
1 file changed, 33 insertions(+), 16 deletions(-)
diff --git a/drivers/g
Enable this message for verbose debugging only as it is otherwise
printed after every AUX message, quickly filling the log buffer.
Signed-off-by: Sean Anderson
---
drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp
This series adds debugfs support for the zynqmp_dp driver. The intent is
to enable compliance testing or to help debug signal-integrity issues.
The first three patches are general improvements (and could be applied
independently), while the last three add debugfs support.
Sean Anderson (6):
dr
Reviewed-by: Dave Airlie
On Sat, Mar 16, 2024 at 7:21 AM Lyude Paul wrote:
>
> I've recently been seeing some unexplained GSP errors on my RTX 6000 from
> failed aux transactions:
>
> [ 132.915867] nouveau :1f:00.0: gsp: cli:0xc1d2 obj:0x0073
> ctrl cmd:0x00731341 failed: 0x
On Fri, Mar 15, 2024 at 2:37 PM Douglas Anderson wrote:
>
> As documented in the description of the transfer() function of
> "struct drm_dp_aux", the transfer() function can be called at any time
> regardless of the state of the DP port. Specifically if the kernel has
> the DP AUX character device
1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28193
> >
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > Changes in v3:
> > - Split XML and git rm patches in hope to pass ML limitations
> > - Link to v2:
> > https://lore.kernel.org/r/20240315-
This is a no-op change to just fix a typo in the name of a static function.
Signed-off-by: Douglas Anderson
---
Changes in v2:
- ("Fix typo in static function (ststus => status)") new for v2.
drivers/gpu/drm/msm/dp/dp_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --
The DP wait_hpd_asserted() callback is passed a timeout which
indicates how long we should wait for HPD. This timeout was being
ignored in the MSM DP implementation and instead a hardcoded 500 ms
timeout was used. Fix it to use the proper timeout.
As part of this we move the hardcoded 500 ms numbe
Before the introduction of the wait_hpd_asserted() callback in commit
841d742f094e ("drm/dp: Add wait_hpd_asserted() callback to struct
drm_dp_aux") the API between panel drivers and DP AUX bus drivers was
that it was up to the AUX bus driver to wait for HPD in the transfer()
function.
Now wait_hp
As documented in the description of the transfer() function of
"struct drm_dp_aux", the transfer() function can be called at any time
regardless of the state of the DP port. Specifically if the kernel has
the DP AUX character device enabled and userspace accesses
"/dev/drm_dp_auxN" directly then th
The main goal of this patch series is to avoid problems running
"fwupd" on Qualcomm devices. Right now several of the plugins used
with fwupd try talking over all DP AUX busses and this results in a
very long timeout on Qualcomm devices.
As part of fixing this, I noticed a case where the MSM DP
I've recently been seeing some unexplained GSP errors on my RTX 6000 from
failed aux transactions:
[ 132.915867] nouveau :1f:00.0: gsp: cli:0xc1d2 obj:0x0073
ctrl cmd:0x00731341 failed: 0x
While the cause of these is not yet clear, these messages made me notice
that the a
Hi Jeffrey,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.8 next-20240315]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to
send the next iteration.
>
> [1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28193
>
> Signed-off-by: Dmitry Baryshkov
> ---
> Changes in v3:
> - Split XML and git rm patches in hope to pass ML limitations
> - Link to v2:
> https://lore.kernel.org/r/20240315-fd-xml-shippe
On 15/03/2024 02:33, Felix Kuehling wrote:
On 2024-03-12 5:45, Tvrtko Ursulin wrote:
On 11/03/2024 14:48, Tvrtko Ursulin wrote:
Hi Felix,
On 06/12/2023 21:23, Felix Kuehling wrote:
Executive Summary: We need to add CRIU support to DRM render nodes
in order to maintain CRIU support for RO
On Fri, Mar 15, 2024 at 06:36:19PM +0100, Alexandre Mergnat wrote:
> On 15/03/2024 16:15, Mark Brown wrote:
> > On Fri, Mar 15, 2024 at 04:05:21PM +0100, Alexandre Mergnat wrote:
> > > > In the register. You only need to reset the gain to -40dB at the start
> > > > of the ramp.
> > > Sorry but I
On 15/03/2024 16:28, John Ogness wrote:
On 2024-03-15, Jocelyn Falempe wrote:
+static inline int drm_panic_trylock(struct drm_device *dev, unsigned long
*flags)
+{
+ return raw_spin_trylock_irqsave(&dev->mode_config.panic_lock, *flags);
+}
[...]
+static inline unsigned long drm_pa
tree: git://anongit.freedesktop.org/drm/drm-misc topic/rust-drm
head: 42abbd1bc1f3362a9adee3d05e54518de90f2205
commit: 5aad7a29ba6037a224c3f8ff36bfb2c82a5d3f4d [8/18] rust: add revocable
objects
config: x86_64-randconfig-r113-20240315
(https://download.01.org/0day-ci/archive/20240316
On 15/03/2024 16:15, Mark Brown wrote:
On Fri, Mar 15, 2024 at 04:05:21PM +0100, Alexandre Mergnat wrote:
On 15/03/2024 15:30, Mark Brown wrote:
Let me know, when you change de gain to do a ramp down (start from user gain
to gain=-40db), next time for the ramp up, how/where do you find the
On Fri, Mar 15, 2024 at 2:28 AM Jani Nikula wrote:
>
> On Thu, 14 Mar 2024, Rob Clark wrote:
> > When we first merged drm/ci I was unsure if it would need it's own
> > -next branch. But after using it for a couple releases, a few times
> > I've found myself wanting to backmerge drm/ci changes wi
From: Leo Li
[Why]
Compositors have different ways of assigning surfaces to DRM planes for
render offloading. It may decide between various strategies: overlay,
underlay, or a mix of both
One way for compositors to implement the underlay strategy is to assign
a higher zpos to the DRM_PRIMARY pl
From: Leo Li
[Why]
DCN is the display hardware for amdgpu. DRM planes are backed by DCN
hardware pipes, which carry pixel data from one end (memory), to the
other (output encoder).
Each DCN pipe has the ability to blend in a cursor early on in the
pipeline. In other words, there are no dedicate
From: Leo Li
These patches aim to make the amdgpgu KMS driver play nicer with compositors
when building multi-plane scanout configurations. They do so by:
1. Making cursor behavior more sensible.
2. Allowing placement of DRM OVERLAY planes underneath the PRIMARY plane for
'underlay' configura
Hi Nirmoy,
> > In Mesa we've been relying on I915_CONTEXT_PARAM_GTT_SIZE so as long as
> > that is adjusted by the kernel
>
> What do you mean by adjusted by, should it be a aligned size?
>
> I915_CONTEXT_PARAM_GTT_SIZE ioctl is returning vm->total which is
> adjusted(reduced by a page).
>
> Th
On Wed, Feb 28, 2024 at 10:12:28AM +, Simon Ser wrote:
> On Tuesday, February 27th, 2024 at 20:35, Ville Syrjala
> wrote:
>
> > From: Ville Syrjälä
> >
> > Add a new immutable plane property by which a plane can advertise
> > a handful of recommended plane sizes. This would be mostly expos
Use the new added capable_any function in appropriate cases, where a
task is required to have any of two capabilities.
Reorder CAP_SYS_ADMIN last.
Signed-off-by: Christian Göttsche
Acked-by: Alexander Gordeev (s390 portion)
---
v4:
Additional usage in kfd_ioctl()
v3:
rename to capable_any
On Thu, Mar 14, 2024 at 09:30:57AM -0700, Abhinav Kumar wrote:
> On 3/14/2024 8:38 AM, Johan Hovold wrote:
> > On Wed, Mar 13, 2024 at 10:24:08AM -0700, Abhinav Kumar wrote:
> > Perhaps I'm missing something in the race that you are trying to
> > describe (and which I've asked you to describe in m
On 3/14/2024 5:41 AM, Jacek Lawrynowicz wrote:
Hi,
On 11.03.2024 17:58, Jeffrey Hugo wrote:
During the boot process of AIC100, the bootloaders (PBL and SBL) log
messages to device RAM. During SBL, if the host opens the QAIC_LOGGING
channel, SBL will offload the contents of the log buffer to the
On 2024-03-15, Jocelyn Falempe wrote:
> +static inline int drm_panic_trylock(struct drm_device *dev, unsigned long
> *flags)
> +{
> + return raw_spin_trylock_irqsave(&dev->mode_config.panic_lock, *flags);
> +}
[...]
> +static inline unsigned long drm_panic_lock(struct drm_device *dev)
> +{
On 15/03/2024 15:38, Mark Brown wrote:
On Tue, Mar 12, 2024 at 09:58:05AM +0100, Alexandre Mergnat wrote:
I'm a bit lost for mixer-test and pcm-test.
Currently, I cross-compile the alsa lib project to be able to build the
tests and put it on my board.
I can execute it, but I still have 2
On Thu, Mar 14, 2024 at 07:43:30PM +, Klymenko, Anatoliy wrote:
> > > +/*
> > > +-
> > > +
> > > + * DRM CRTC
> > > + */
> > > +
> > > +static enum drm_mode_status xlnx_tpg_crtc_mode_valid(struct drm_crtc
> > *crtc,
> >
On Fri, Mar 15, 2024 at 04:05:21PM +0100, Alexandre Mergnat wrote:
> On 15/03/2024 15:30, Mark Brown wrote:
> > > Let me know, when you change de gain to do a ramp down (start from user
> > > gain
> > > to gain=-40db), next time for the ramp up, how/where do you find the user
> > > gain ?
> > In
Add support for the drm_panic module, which displays a message to
the screen when a kernel panic occurs.
v7
* Use drm_for_each_primary_visible_plane()
v8:
* Replace get_scanout_buffer() logic with drm_panic_set_buffer()
(Thomas Zimmermann)
v9:
* Revert to using get_scanout_buffer() (Sima)
Add a debugfs file, so you can test drm_panic without freezing
your machine. This is unsafe, and should be enabled only for
developer or tester.
To display the drm_panic screen on the device 0:
echo 1 > /sys/kernel/debug/dri/0/drm_panic_plane_0
v9:
* Create a debugfs file for each plane in the d
Add support for the drm_panic module, which displays a user-friendly
message to the screen when a kernel panic occurs.
v7:
* use drm_panic_gem_get_scanout_buffer() helper
v8:
* Replace get_scanout_buffer() logic with drm_panic_set_buffer()
v9:
* Revert to using get_scanout_buffer() (Sima)
*
Add support for the drm_panic module, which displays a user-friendly
message to the screen when a kernel panic occurs.
v8:
* Replace get_scanout_buffer() with drm_panic_set_buffer()
(Thomas Zimmermann)
v9:
* Revert to using get_scanout_buffer() (Sima)
* move get_scanout_buffer() to plane he
Add support for the drm_panic module, which displays a message to
the screen when a kernel panic occurs.
v5:
* Also check that the plane is visible and primary. (Thomas Zimmermann)
v7:
* use drm_for_each_primary_visible_plane()
v8:
* Replace get_scanout_buffer() logic with drm_panic_set_buffe
This was initialy done for imx6, but should work on most drivers
using drm_fb_dma_helper.
v8:
* Replace get_scanout_buffer() logic with drm_panic_set_buffer()
(Thomas Zimmermann)
v9:
* go back to get_scanout_buffer()
* move get_scanout_buffer() to plane helper functions
Signed-off-by: Joce
Add support for the following formats:
DRM_FORMAT_RGB565
DRM_FORMAT_RGBA5551
DRM_FORMAT_XRGB1555
DRM_FORMAT_ARGB1555
DRM_FORMAT_RGB888
DRM_FORMAT_XRGB
DRM_FORMAT_ARGB
DRM_FORMAT_XBGR
DRM_FORMAT_XRGB2101010
DRM_FORMAT_ARGB2101010
v10:
* move and simplify the functions from the drm form
This module displays a user friendly message when a kernel panic
occurs. It currently doesn't contain any debug information,
but that can be added later.
v2
* Use get_scanout_buffer() instead of the drm client API.
(Thomas Zimmermann)
* Add the panic reason to the panic message (Nerdopolis)
*
From: Daniel Vetter
Rough sketch for the locking of drm panic printing code. The upshot of
this approach is that we can pretty much entirely rely on the atomic
commit flow, with the pair of raw_spin_lock/unlock providing any
barriers we need, without having to create really big critical
sections
This introduces a new drm panic handler, which displays a message when a panic
occurs.
So when fbcon is disabled, you can still see a kernel panic.
This is one of the missing feature, when disabling VT/fbcon in the kernel:
https://www.reddit.com/r/linux/comments/10eccv9/config_vtn_in_2023/
Fbcon
On 15/03/2024 15:30, Mark Brown wrote:
On Fri, Mar 15, 2024 at 12:01:12PM +0100, Alexandre Mergnat wrote:
On 13/03/2024 18:23, Mark Brown wrote:
On Tue, Mar 12, 2024 at 07:03:25PM +0100, Alexandre Mergnat wrote:
Actually you must save the values because the gain selected by the user will
On 2024-03-15 7:37, Christian Göttsche wrote:
Use the new added capable_any function in appropriate cases, where a
task is required to have any of two capabilities.
Reorder CAP_SYS_ADMIN last.
Signed-off-by: Christian Göttsche
Acked-by: Alexander Gordeev (s390 portion)
Acked-by: Felix Kuehl
Based on work at
https://lore.kernel.org/dri-devel/20230118032413.6496-1-jiash...@iscas.ac.cn/
The API in the origional work seemed to have two issues:
1. The output parameter was not correctly defined
2. The allocating functions did not return the allocated object like the
other drmm functions
Now that drmm_alloc_workqueue() exists, we can stop open coding our own
implementation.
Signed-off-by: Jeffrey Hugo
Reviewed-by: Carl Vanderlip
Reviewed-by: Pranjal Ramajor Asha Kanojiya
---
drivers/accel/qaic/qaic_drv.c | 30 --
1 file changed, 4 insertions(+), 26
From: Jiasheng Jiang
Add drmm_alloc_workqueue() and drmm_alloc_ordered_workqueue(), the helpers
that provide managed workqueue cleanup. The workqueue will be destroyed
with the final reference of the DRM device.
Signed-off-by: Jiasheng Jiang
Reviewed-by: Daniel Vetter
[jhugo: fix API to return
On Tue, Mar 12, 2024 at 09:58:05AM +0100, Alexandre Mergnat wrote:
> I'm a bit lost for mixer-test and pcm-test.
> Currently, I cross-compile the alsa lib project to be able to build the
> tests and put it on my board.
> I can execute it, but I still have 2 issues:
> 1) I've a lot of missing mod
Am 15.03.24 um 15:12 schrieb Alex Deucher:
On Fri, Mar 15, 2024 at 10:12 AM Christian König
wrote:
Am 15.03.24 um 03:39 schrieb vitaly.pros...@amd.com:
From: Vitaly Prosyak
The bug can be triggered by sending an amdgpu_cs_wait_ioctl
to the AMDGPU DRM driver on any ASICs with valid context.
T
On Fri, Mar 15, 2024 at 12:01:12PM +0100, Alexandre Mergnat wrote:
> On 13/03/2024 18:23, Mark Brown wrote:
> > On Tue, Mar 12, 2024 at 07:03:25PM +0100, Alexandre Mergnat wrote:
> > > Actually you must save the values because the gain selected by the user
> > > will
> > > be override to do a ram
On Fri, Mar 15, 2024 at 10:12 AM Christian König
wrote:
>
> Am 15.03.24 um 03:39 schrieb vitaly.pros...@amd.com:
> > From: Vitaly Prosyak
> >
> > The bug can be triggered by sending an amdgpu_cs_wait_ioctl
> > to the AMDGPU DRM driver on any ASICs with valid context.
> > The bug was reported by J
Am 15.03.24 um 03:39 schrieb vitaly.pros...@amd.com:
From: Vitaly Prosyak
The bug can be triggered by sending an amdgpu_cs_wait_ioctl
to the AMDGPU DRM driver on any ASICs with valid context.
The bug was reported by Joonkyo Jung .
For example the following code:
static void Syzkaller2(int
On 3/15/2024 6:45 PM, Alex Deucher wrote:
On Fri, Mar 15, 2024 at 8:13 AM Sunil Khatri wrote:
Add all the IP's version information on a SOC to the
devcoredump.
Signed-off-by: Sunil Khatri
This looks great.
Reviewed-by: Alex Deucher
Thanks Alex
---
drivers/gpu/drm/amd/amdgpu/amdgp
On Fri, Mar 15, 2024 at 8:13 AM Sunil Khatri wrote:
>
> Add all the IP's version information on a SOC to the
> devcoredump.
>
> Signed-off-by: Sunil Khatri
This looks great.
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c | 62 +++
> 1 file cha
On Sun, 10 Mar 2024 14:21:11 +0100, Frank Oltmanns wrote:
> The Allwinner SoC's typically have an upper and lower limit for their
> clocks' rates. Up until now, support for that has been implemented
> separately for each clock type.
>
> Implement that functionality in the sunxi-ng's common part ma
On 3/12/24, Pierre-Louis Dourneau wrote:
> On 3/8/24, ludovic.desroc...@microchip.com
> wrote:
> > This patch fixes the memory leak but introduces a crash on my side when
> > exiting a graphics app using the Microchip graphics library.
>
> We've tried to reproduce your crash with 6.1.22-linux4m
[AMD Official Use Only - General]
Hello Alex
Added the information directly from the ip_version and also added names for
each ip so the version information makes more sense to the user.
Below is the output in devcoredump now:
IP Information
SOC Family: 143
SOC Revision id: 0
SOC External Revisi
Add all the IP's version information on a SOC to the
devcoredump.
Signed-off-by: Sunil Khatri
---
drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c | 62 +++
1 file changed, 62 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_
On 15/03/2024 08:18, Vignesh Raman wrote:
Hi Helen,
On 07/03/24 19:32, Helen Koike wrote:
On 06/03/2024 00:06, Vignesh Raman wrote:
For rockchip rk3288 and rk3399, the display driver is rockchip.
Currently, in drm-ci for rockchip, only the display driver is
tested. Refactor the existing r
On 15/03/2024 08:12, Vignesh Raman wrote:
Hi Helen,
On 07/03/24 19:05, Helen Koike wrote:
On 06/03/2024 00:06, Vignesh Raman wrote:
Uprev IGT and add amd, v3d, vc4 and vgem specific
tests to testlist. Have testlist.txt per driver
and include a base testlist so that the driver
specific tes
Import the gen_headers.py script from Mesa, commit FIXME. This script
will be used to generate MSM register files on the fly during
compilation.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/registers/gen_header.py | 958
1 file changed, 958 insertions(+)
Generate DRM/MSM headers on the fly during kernel build. This removes a
need to push register changes to Mesa with the following manual
synchronization step. Existing headers will be removed in the following
commits (split away to ease reviews).
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/dr
The mmss_cc.xml.h file describes bits of the MMSS clock controller on
APQ8064 / MSM8960 platforms. They are not used by the driver and do not
belong to the DRM MSM driver. Drop the file.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/mmss_cc.xml.h | 131 -
The qfprom.xml.h contains definitions for the nvmem code. They are not
used in the existing code. Also if we were to use them later, we should
have used nvmem cell API instead of using these defs. Drop the file.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/qfprom.xml.h | 61 -
The msm_gpummu.c implementation is used only on A2xx and it is tied to
the A2xx registers. Rename the source file accordingly.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Makefile | 2 +-
drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 4 +-
drivers/gpu/d
In order to stop patching the mdp5 headers, import definitions for the
writeback blocks. This part is extracted from the old Rob's patch.
Co-developed-by: Rob Clark
Signed-off-by: Rob Clark
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.h | 11 +++
1 file ch
Baryshkov
---
Changes in v3:
- Split XML and git rm patches in hope to pass ML limitations
- Link to v2:
https://lore.kernel.org/r/20240315-fd-xml-shipped-v2-0-7cd68ecc4...@linaro.org
Changes in v2:
- Removed the _shipped files, always generating the headers (Masahiro
Yamada)
- Replaced headergen2
On 3/12/24 18:03, Guenter Roeck wrote:
Add name of functions triggering warning backtraces to the __bug_table
object section to enable support for suppressing WARNING backtraces.
To limit image size impact, the pointer to the function name is only added
to the __bug_table section if both CONFIG_
On Wed, 6 Mar 2024 at 05:08, Vignesh Raman wrote:
>
> Uprev IGT and add amd, v3d, vc4 and vgem specific
> tests to testlist. Have testlist.txt per driver
> and include a base testlist so that the driver
> specific tests will run only on those hardware.
> Also add testlists to the MAINTAINERS file.
On 14/03/2024 15:49, Thierry Reding wrote:
From: Thierry Reding
The host1x devices are virtual compound devices and do not perform DMA
accesses themselves, so they do not need to be set up for DMA.
Ideally we would also not need to set up DMA masks for the virtual
devices, but we currently s
Hi Helen,
On 07/03/24 19:32, Helen Koike wrote:
On 06/03/2024 00:06, Vignesh Raman wrote:
Some ARM SOCs have a separate display controller and GPU, each with
different drivers. For mediatek mt8173, the GPU driver is powervr,
and the display driver is mediatek. In the case of mediatek mt8183,
Hi Helen,
On 07/03/24 19:32, Helen Koike wrote:
On 06/03/2024 00:06, Vignesh Raman wrote:
For rockchip rk3288 and rk3399, the display driver is rockchip.
Currently, in drm-ci for rockchip, only the display driver is
tested. Refactor the existing rockchip jobs so that gpu driver
testing jobs c
Hi Helen,
On 07/03/24 19:32, Helen Koike wrote:
On 06/03/2024 00:06, Vignesh Raman wrote:
For mediatek mt8173 and mt8183, the display driver is mediatek.
Currently, in drm-ci for mediatek, only the display driver is
tested. Refactor the existing mediatek jobs so that gpu driver
testing jobs c
Hi Helen,
On 07/03/24 19:05, Helen Koike wrote:
On 06/03/2024 00:06, Vignesh Raman wrote:
Uprev IGT and add amd, v3d, vc4 and vgem specific
tests to testlist. Have testlist.txt per driver
and include a base testlist so that the driver
specific tests will run only on those hardware.
Also add t
On 13/03/2024 18:23, Mark Brown wrote:
On Tue, Mar 12, 2024 at 07:03:25PM +0100, Alexandre Mergnat wrote:
On 26/02/2024 17:09, Mark Brown wrote:
+ case MT6357_ZCD_CON2:
+ regmap_read(priv->regmap, MT6357_ZCD_CON2, ®);
+ priv->ana_gain[ANALOG_VOLUME_HPOUTL]
On Wed, 13 Mar 2024 15:21:42 +0100, Karolina Stolarek wrote:
> Commit 66671944e176 ("drm/tests: helpers: Add atomic helpers")
> introduced a dependency on CRTC helpers in KUnit test helpers.
> Select the former when building KUnit test helpers to avoid
> linker errors.
>
>
Applied to misc/kernel
You should have marked this patch with "v2"...
On 3/13/24 17:59, Samuel Thibault wrote:
This remains relatively simple by just enlarging integers.
I like the patch, but I still see some u32...
drivers/video/fbdev/vt8623fb.c: info->pixmap.blit_x = (bpp == 4) ? (1
<< (8 - 1)) : (~(u32)0
On Thu, 14 Mar 2024, Rob Clark wrote:
> When we first merged drm/ci I was unsure if it would need it's own
> -next branch. But after using it for a couple releases, a few times
> I've found myself wanting to backmerge drm/ci changes without
> necessarily backmerging all of drm-misc-next.
>
> So,
Il 15/03/24 08:29, Shuijing Li ha scritto:
This patch correct calculation formula of PHY timing.
Make actual phy timing more accurate.
More accurate in which cases? By how much? On which SoC(s)?
I agree about those changes if those are improving the PHY timing, but
can you please document wha
There is a statement with two semicolons. Remove the second one, it
is redundant.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c
b/drivers/gpu/drm
On 2/29/24 12:50, Michael Ellerman wrote:
socrates_gc_mode is defined at the top-level but then only used inside
an #ifdef CONFIG_FB_MB862XX_LIME, leading to an error with some configs:
drivers/video/fbdev/mb862xx/mb862xxfbdrv.c:36:31: error: ‘socrates_gc_mode’
defined but not used
36
On 3/5/24 14:51, Roman Smirnov wrote:
The expression htotal * vtotal can have a zero value on
overflow.
I'm not sure if thos always results in zero in kernel on overflow.
Might be architecture-depended too, but let's assume it
can become zero,
It is necessary to prevent division by zero
On 3/14/24 10:58, Li Zhijian wrote:
Per filesystems/sysfs.rst, show() should only use sysfs_emit()
or sysfs_emit_at() when formatting the value to be returned to user space.
coccinelle complains that there are still a couple of functions that use
snprintf(). Convert them to sysfs_emit().
sprint
By adjusting the order of link training and relocating it to HPD,
link training can identify the usability of each lane in the current link.
It also supports handling signal instability and weakness due to
environmental issues, enabling the acquisition of a stable bandwidth
for the current link. S
On Mon, Mar 11, 2024 at 03:49:48PM +0100, Maxime Ripard wrote:
> Infoframes in KMS is usually handled by a bunch of low-level helpers
> that require quite some boilerplate for drivers. This leads to
> discrepancies with how drivers generate them, and which are actually
> sent.
>
> Now that we have
.01.org/0day-ci/archive/20240315/202403151651.nhmv8q3a-...@intel.com/config)
compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project
6009708b4367171ccdbf4b5905cb6a803753fe18)
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240315/202403151651.nhmv8q3a
On Mon, Mar 11, 2024 at 03:49:42PM +0100, Maxime Ripard wrote:
> Now that we have all the infrastructure needed, we can add some code
> that will, for a given connector state and mode, compute the best output
> format and bpc.
>
> The algorithm is equivalent to the one already found in i915 and vc
This patch correct calculation formula of PHY timing.
Make actual phy timing more accurate.
Signed-off-by: Shuijing Li
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 33 +++---
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b
94 matches
Mail list logo
