Am 18.04.24 um 03:33 schrieb zhiguojiang:
在 2024/4/15 19:57, Christian König 写道:
[Some people who received this message don't often get email from
christian.koe...@amd.com. Learn why this is important at
https://aka.ms/LearnAboutSenderIdentification ]
Am 15.04.24 um 12:35 schrieb zhiguojiang:
On 18/04/24 11:55 am, Dmitry Baryshkov wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On Thu, Apr 18, 2024 at 03:54:53AM +, dharm...@microchip.com wrote:
>> Hi Dmitry,
>>
>> On 17/04/24 12:05 pm, Dmitry Baryshkov wrote:
>>> EXTERNAL E
Hi all,
After merging the drm-intel tree, today's linux-next build (htmldocs)
produced this warning:
drivers/gpu/drm/i915/display/intel_dmc_wl.c:1: warning: no structured comments
found
Introduced by commit
765425f598c2 ("drm/i915/display: add support for DMC wakelocks")
--
Cheers,
Stephen
On Thu, Apr 18, 2024 at 03:54:53AM +, dharm...@microchip.com wrote:
> Hi Dmitry,
>
> On 17/04/24 12:05 pm, Dmitry Baryshkov wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > On Wed, Apr 17, 2024 at 08:11:35AM +0530, Dharma Balas
On Thu, Apr 18, 2024 at 01:51:33AM +, wangzhu wrote:
> Hi Greg, thanks for your reply. Since there is no patch to fix CVE-2023-52624
> in linux-5.10, there is a patch in the linux-6.7 branch, its commit is
> 2ef98c6d753a744e333b7e34b9cf687040fba57d ("drm/amd/display: Wake DMCUB before
> exec
Hi Dmitry,
On 17/04/24 12:05 pm, Dmitry Baryshkov wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On Wed, Apr 17, 2024 at 08:11:35AM +0530, Dharma Balasubiramani wrote:
>> Add a new LVDS controller driver for sam9x7 which does the followi
Hi Greg, thanks for your reply. Since there is no patch to fix CVE-2023-52624
in linux-5.10, there is a patch in the linux-6.7 branch to fix it, its commit
is 2ef98c6d753a744e333b7e34b9cf687040fba57d ("drm/amd/display: Wake DMCUB
before executing GPINT commands"). When we apply this patch to lin
The CVE-2023-52624 is fixed in linux-6.7 stable, while it is not fixed in 6.6,
this commit is presented to fix it in linux-6.6 stable.
-邮件原件-
发件人: Alex Deucher [mailto:alexdeuc...@gmail.com]
发送时间: 2024年4月18日 9:58
收件人: wangzhu
抄送: Greg KH ; harry.wentl...@amd.com;
sunpeng...@amd.com; ro
On Wed, Apr 17, 2024 at 9:51 PM wangzhu wrote:
>
> Hi Greg, thanks for your reply. Since there is no patch to fix CVE-2023-52624
> in linux-5.10, there is a patch in the linux-6.7 branch, its commit is
> 2ef98c6d753a744e333b7e34b9cf687040fba57d ("drm/amd/display: Wake DMCUB before
> executing G
Hi Greg, thanks for your reply. Since there is no patch to fix CVE-2023-52624
in linux-5.10, there is a patch in the linux-6.7 branch, its commit is
2ef98c6d753a744e333b7e34b9cf687040fba57d ("drm/amd/display: Wake DMCUB before
executing GPINT commands"). When we apply this patch to linux-5.10, t
在 2024/4/15 19:57, Christian König 写道:
[Some people who received this message don't often get email from
christian.koe...@amd.com. Learn why this is important at
https://aka.ms/LearnAboutSenderIdentification ]
Am 15.04.24 um 12:35 schrieb zhiguojiang:
在 2024/4/12 14:39, Christian König 写道:
On Wed, Apr 17, 2024 at 02:20:31PM -0700, Jessica Zhang wrote:
>
>
> On 4/4/2024 3:08 AM, Dmitry Baryshkov wrote:
> > Use .init_load_uA part of the bulk regulator API instead of calling
> > register_set_load() manually.
>
> Hi Dmitry,
>
> Reviewed-by: Jessica Zhang
I wonder why patch 4 was re
On Wed, Apr 17, 2024 at 10:02:59PM +0200, Konrad Dybcio wrote:
> Add the speedbin masks to ensure only the desired OPPs are available on
> chips of a given bin.
>
> Using this, add the binned 719 MHz OPP and the non-binned 124.8 MHz.
>
> Signed-off-by: Konrad Dybcio
> ---
> arch/arm64/boot/dts/
On Wed, Apr 17, 2024 at 10:02:58PM +0200, Konrad Dybcio wrote:
> There is no need to reinvent the wheel for simple read-match-set logic.
>
> Make speedbin discovery and assignment generation independent.
>
> This implicitly removes the bogus 0x80 / BIT(7) speed bin on A5xx,
> which has no represe
On Wed, Apr 17, 2024 at 10:02:57PM +0200, Konrad Dybcio wrote:
> In preparation for commonizing the speedbin handling code.
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 6 ++
> 1 file changed, 6 insertions(+)
Reviewed-by: Dmitry Baryshkov
--
With
On Wed, Apr 17, 2024 at 10:02:56PM +0200, Konrad Dybcio wrote:
> Add speebin data for A740, as found on SM8550 and derivative SoCs.
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 5 +
> 1 file changed, 5 insertions(+)
>
Reviewed-by: Dmitry Baryshkov
On Wed, Apr 17, 2024 at 10:02:55PM +0200, Konrad Dybcio wrote:
> On recent (SM8550+) Snapdragon platforms, the GPU speed bin data is
> abstracted through SMEM, instead of being directly available in a fuse.
>
> Add support for SMEM-based speed binning, which includes getting
> "feature code" and "
On Wed, Apr 17, 2024 at 10:02:54PM +0200, Konrad Dybcio wrote:
> Recent (SM8550+ ish) Qualcomm SoCs have a new mechanism for precisely
> identifying the specific SKU and the precise speed bin (in the general
> meaning of this word, anyway): a pair of values called Product Code
> and Feature Code.
>
On Wed, Apr 17, 2024 at 01:39:16PM +0200, Linus Walleij wrote:
> Hi Herman,
>
> thanks for your patch!
>
> Do you actually have this working on real hardware? I never
> submitted this patch because I could not get the hardware
> working.
>
> I was hoping for smarter people (Dmitry Baryshkov...)
On Wed, Apr 17, 2024 at 01:57:47AM +0200, Marijn Suijten wrote:
> All other functions in dpu_hw_intf name the "self" parameter `intf`,
> except dpu_hw_intf_setup_timing_engine() and the recently added
> dpu_hw_intf_program_intf_cmd_cfg(). Clean that up for consistency.
I really have mixed feeling
On Wed, Apr 17, 2024 at 01:57:45AM +0200, Marijn Suijten wrote:
> This comment one line down references a single, "same CTL" that controls
> two interfaces, so the comment should clearly describe two interfaces
> used with a single active CTL and not "two CTLs".
>
> Fixes: 25fdd5933e4c ("drm/msm:
On 4/4/2024 3:08 AM, Dmitry Baryshkov wrote:
Use .init_load_uA part of the bulk regulator API instead of calling
register_set_load() manually.
Hi Dmitry,
Reviewed-by: Jessica Zhang
Thanks,
Jessica Zhang
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-novatek-nt36672
On 4/17/2024 9:29 AM, David Wronek wrote:
Add support for the 2560x1600@90Hz OLED panel by EDO bundled with a
Raydium RM69380 controller, as found on the Lenovo Xiaoxin Pad Pro 2021.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: David Wronek
Hi David,
Acked-by: Jessica Zhang
Thanks,
Je
There is no need to reinvent the wheel for simple read-match-set logic.
Make speedbin discovery and assignment generation independent.
This implicitly removes the bogus 0x80 / BIT(7) speed bin on A5xx,
which has no representation in hardware whatshowever.
Signed-off-by: Konrad Dybcio
---
drive
Add the speedbin masks to ensure only the desired OPPs are available on
chips of a given bin.
Using this, add the binned 719 MHz OPP and the non-binned 124.8 MHz.
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sm8550.dtsi | 21 -
1 file changed, 20 insertions(+),
On recent (SM8550+) Snapdragon platforms, the GPU speed bin data is
abstracted through SMEM, instead of being directly available in a fuse.
Add support for SMEM-based speed binning, which includes getting
"feature code" and "product code" from said source and parsing them
to form something that le
In preparation for commonizing the speedbin handling code.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 3b631445
Add speebin data for A740, as found on SM8550 and derivative SoCs.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 9
In preparation for parsing the chip "feature code" (FC) and "product
code" (PC) (essentially the parameters that let us conclusively
characterize the sillicon we're running on, including various speed
bins), move the socinfo version defines to the public header.
Signed-off-by: Konrad Dybcio
---
Recent (SM8550+ ish) Qualcomm SoCs have a new mechanism for precisely
identifying the specific SKU and the precise speed bin (in the general
meaning of this word, anyway): a pair of values called Product Code
and Feature Code.
Based on this information, we can deduce the available frequencies for
Newer (SM8550+) SoCs don't seem to have a nice speedbin fuse anymore,
but instead rely on a set of combinations of "feature code" (FC) and
"product code" (PC) identifiers to match the bins. This series adds
support for that.
I suppose a qcom/for-soc immutable branch would be in order if we want
to
On 2024-01-15 11:05, Andri Yngvason wrote:
> From: Werner Sembach
>
> Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check that was performed in the
> drm_mode_is_420_only() case, but not in the drm_mode_is_420_also() &&
> force_yuv420_output case.
>
> Without further knowledge if YCbCr 4:2:0 is
I'm a bit late to the game but I don't think this is merged
yet.
On 2024-01-15 11:05, Andri Yngvason wrote:
> From: Werner Sembach
>
> Add a new general drm property "force color format" which can be used
> by userspace to tell the graphics driver which color format to use.
>
> Possible options
Hi Dave, Sima,
Fixes for 6.9.
The following changes since commit 0bbac3facb5d6cc0171c45c9873a2dc96bea9680:
Linux 6.9-rc4 (2024-04-14 13:38:39 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-6.9-2024-04-17
for you to fetch c
On Wed, 2024-04-17 at 09:07 +0200, Greg Kroah-Hartman wrote:
> On Tue, Apr 16, 2024 at 01:14:52PM -0700, A wrote:
> > > From 6dbcb120581fc7cb45812193227b0a197abd8ba4 Mon Sep 17 00:00:00
> > > 2001
> > From: Ashok Kumar
> > Date: Tue, 16 Apr 2024 09:19:32 -0700
> > Subject: [PATCH] [PATCH] staging:
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 4eab358930711bbeb85bf5ee267d0d42d3394c2c Add linux-next specific
files for 20240417
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202404171743.hfpscodv-...@intel.com
https
On 2024-04-16 10:10, Harry Wentland wrote:
On 2024-04-16 04:01, Pekka Paalanen wrote:
On Mon, 15 Apr 2024 18:33:39 -0400
Leo Li wrote:
On 2024-04-15 04:19, Pekka Paalanen wrote:
On Fri, 12 Apr 2024 16:14:28 -0400
Leo Li wrote:
On 2024-04-12 11:31, Alex Deucher wrote:
On Fri, Apr
On Tue, 16 Apr 2024 17:53:13 +0200, Alexandre Mergnat wrote:
> Add a compatible string for MediaTek Genio 350 MT8365's display PWM
> block: this is the same as MT8183.
>
> Reviewed-by: AngeloGioacchino Del Regno
>
> Acked-by: Uwe Kleine-König
> Signed-off-by: Alexandre Mergnat
> ---
> Docum
On Tue, 16 Apr 2024 17:53:11 +0200, Alexandre Mergnat wrote:
> Document the display Data Path Read DMA on MT8365, which is compatible
> with that of the MT8183.
>
> Signed-off-by: Alexandre Mergnat
> ---
> Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml | 1 +
> 1 file ch
On Tue, 16 Apr 2024 17:53:10 +0200, Alexandre Mergnat wrote:
> Document the display Overlay on MT8365, which is compatible
> with that of the MT8192.
>
> Signed-off-by: Alexandre Mergnat
> ---
> Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml | 1 +
> 1 file changed, 1 ins
On Tue, 16 Apr 2024 17:53:09 +0200, Alexandre Mergnat wrote:
> Document the display Gamma on MT8365, which is compatible
> with that of the MT8183.
>
> Signed-off-by: Alexandre Mergnat
> ---
> Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml | 1 +
> 1 file changed, 1 ins
On Tue, 16 Apr 2024 17:53:07 +0200, amerg...@baylibre.com wrote:
> From: Fabien Parent
>
> DPI is part of the display / multimedia block in MediaTek SoCs, and
> always have a power-domain (at least in the upstream device-trees).
> Add the power-domains property to the binding documentation.
>
On Tue, 16 Apr 2024 17:53:06 +0200, Alexandre Mergnat wrote:
> Document the Display Serial Interface on MT8365, which is compatible
> with that of the MT8183.
>
> Signed-off-by: Alexandre Mergnat
> ---
> Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml | 1 +
> 1 file chang
On Tue, 16 Apr 2024 17:53:05 +0200, Alexandre Mergnat wrote:
> Document the display Dither on MT8365, which is compatible
> with that of the MT8183.
>
> Signed-off-by: Alexandre Mergnat
> ---
> Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml | 1 +
> 1 file changed, 1 i
On Tue, 16 Apr 2024 17:53:04 +0200, Alexandre Mergnat wrote:
> Document the display Color on MT8365, which is compatible
> with that of the MT8173.
>
> Signed-off-by: Alexandre Mergnat
> ---
> Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml | 1 +
> 1 file changed, 1 ins
On Tue, 16 Apr 2024 17:53:02 +0200, Alexandre Mergnat wrote:
> Document the display Adaptive Ambient Light on MT8365, which is compatible
> with that of the MT8183.
>
> Signed-off-by: Alexandre Mergnat
> ---
> Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml | 1 +
> 1 file
On Tue, 16 Apr 2024 17:53:03 +0200, Alexandre Mergnat wrote:
> Document the display Color Correction on MT8365, which is compatible
> with that of the MT8183.
>
> Signed-off-by: Alexandre Mergnat
> ---
> Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml | 3
> +++
> 1 fil
imx-drm doesn't mandate a modeset when the framebuffer modifier changes,
but currently the tile prefetch and resolve (TPR) configuration of the
PRE is only set up on the initial modeset.
As the TPR configuration is double buffered, same as all the other PRE
states, we can support dynamic reconfigu
Move the variables tracking the current dynamic state into a struct
to separate it a bit better from the static device properties.
Signed-off-by: Lucas Stach
Reviewed-by: Philipp Zabel
---
drivers/gpu/ipu-v3/ipu-pre.c | 27 +++
1 file changed, 15 insertions(+), 12 deleti
80.example.dtb:
panel@0: Unevaluated properties are not allowed ('ports' was unexpected)
from schema $id:
http://devicetree.org/schemas/display/panel/raydium,rm69380.yaml#
doc reference errors (make refcheckdocs):
See
https://patchwork.ozlabs.org/project/devicetree-bindings/
Add support for the 2560x1600@90Hz OLED panel by EDO bundled with a
Raydium RM69380 controller, as found on the Lenovo Xiaoxin Pad Pro 2021.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: David Wronek
---
drivers/gpu/drm/panel/Kconfig | 12 +
drivers/gpu/drm/panel/Makefile
This patch adds support the 2560x1600@90Hz dual DSI command mode panel by
EDO in combination with a Raydium RM69380 driver IC.
This driver IC can be found in the following devices:
* Lenovo Xiaoxin Pad Pro 2021 (TB-J716F) with EDO panel
* Lenovo Tab P11 Pro (TB-J706F) with EDO panel
* Robo & Ka
Raydium RM69380 is a display driver IC used to drive OLED DSI panels.
Add a dt-binding for it.
Signed-off-by: David Wronek
---
Note:
Depends on commit 48a516363e29 ("dt-bindings: display: panel: add common
dual-link schema")
---
.../bindings/display/panel/raydium,rm69380.yaml| 89 ++
The mp3309 has two configuration registers, named according to their
address (0x00 and 0x01).
In the second register (0x01), the bit DIMS (Dimming Mode Select) must
be always 0 (zero), in both analog (via i2c commands) and pwm dimming
mode.
In the initial driver version, the DIMS bit was set in pw
The mp3309 has two configuration registers, named according to their
address (0x00 and 0x01).
In the second register (0x01), the bit DIMS (Dimming Mode Select) must
be always 0 (zero), in both analog (via i2c commands) and pwm dimming
mode.
In the initial driver version, the DIMS bit was set in pw
W dniu 2024-04-16 22:52, Marijn Suijten napisał(a):
On 2024-04-16 20:30:49, David Wronek wrote:
Add support for the 2560x1600@90Hz OLED panel by EDO bundled with a
Raydium RM69380 controller, as found on the Lenovo Xiaoxin Pad Pro
2021.
Signed-off-by: David Wronek
---
drivers/gpu/drm/panel/
On 4/16/24 15:22, Jani Nikula wrote:
> Prefer struct drm_edid based functions over struct edid.
>
> Signed-off-by: Jani Nikula
>
> ---
>
Thanks,
Reviewed-by: Noralf Trønnes
On Wed, 17 Apr 2024, Thomas Zimmermann wrote:
>> Many thanks! Just to double check, do you want me to move patch 5
>> earlier and squash patches 6&7?
>
> Your choice. Either is fine by me.
I jumped at the easy option and merged this as-is. :)
Thanks again,
Jani.
--
Jani Nikula, Intel
On Tue, Apr 16, 2024 at 01:31:35PM -0700, Anatoliy Klymenko wrote:
> Implement live video input format setting for ZynqMP DPSUB.
> To: Conor Dooley
If there's nothing dt related here anymore, you can drop me :)
signature.asc
Description: PGP signature
On Wed, 17 Apr 2024 01:28:48 -0700, Andi Shyti wrote:
>
Hi Andi,
> > @@ -839,16 +837,38 @@ void i915_hwmon_register(struct drm_i915_private
> > *i915)
> > if (!hwm_gt_is_visible(ddat_gt, hwmon_energy,
> > hwmon_energy_input, 0))
> > continue;
> >
> > -
When both hwmon and hwmon drvdata (on which hwmon depends) are device
managed resources, the expectation, on device unbind, is that hwmon will be
released before drvdata. However, in i915 there are two separate code
paths, which both release either drvdata or hwmon and either can be
released before
On Tue, Apr 16, 2024 at 08:30:48PM +0200, David Wronek wrote:
> Raydium RM69380 is a display driver IC used to drive OLED DSI panels.
> Add a dt-binding for it.
>
> Signed-off-by: David Wronek
> ---
> Note:
> Depends on commit 48a516363e29 ("dt-bindings: display: panel: add common
> dual-link sc
Enabling the 5k@60Hz uncompressed mode on the MediaTek/Dell U3224KBA
monitor results in a blank screen, at least on MTL platforms on UHBR
link rates with some (<30) uncompressed bpp values. Enabling compression
fixes the problem, so do that for now. Windows enables DSC always if the
sink supports i
Factor out a function to check for 128b/132b channel coding support used
by a follow-up patch in the patchset.
v2: s/drm_dp_uhbr_channel_coding_supported()/drm_dp128b132b_supported()
(Jani)
Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula
Reviewed-by: Ankit Nautiyal
Reviewed-by: Manasi N
Hi Mario,
On Thu, Feb 15, 2024 at 8:04 PM Mario Limonciello
wrote:
> On 2/15/2024 12:47, Ville Syrjälä wrote:
> > On Thu, Feb 15, 2024 at 12:20:56PM -0600, Mario Limonciello wrote:
> >> On 2/14/2024 17:13, Ville Syrjälä wrote:
> >>> On Wed, Feb 14, 2024 at 03:57:54PM -0600, Mario Limonciello wrot
On 4/17/2024 3:03 PM, Karolina Stolarek wrote:
DRM KUnit helpers are selected automatically when TTM tests are enabled,
so there's no need to do it directly in the .kunitconfig file.
Signed-off-by: Karolina Stolarek
Reviewed-by: Nirmoy Das
---
drivers/gpu/drm/ttm/tests/.kunitconfig | 1 -
On 17.04.2024 10:41, Aravind Iddamsetty wrote:
> PCI subsystem provides callbacks to inform the driver about a request to
> do function level reset by user, initiated by writing to sysfs entry
> /sys/bus/pci/devices/.../reset. This will allow the driver to handle FLR
> without the need to do unb
On Wed, Apr 17, 2024 at 02:11:42PM +0530, Aravind Iddamsetty wrote:
> In scenarios where drm_dev_put is directly called by driver we want to
> release devm_drm_dev_init_release action associated with struct
> drm_device.
>
> v2: Directly expose the original function, instead of introducing a
> hel
On 4/17/2024 3:03 PM, Karolina Stolarek wrote:
In commit d393acce7b3f ("drm/tests: Switch to kunit devices"),
DRM test helpers migrated away from using a dummy platform driver
in favour of KUnit device. This means that DMA masks for the device
are not set but are required by ttm_pool_alloc test
Il 17/04/24 12:38, Wojciech Macek ha scritto:
In case there is no DP device attached to the port the
transfer function should return IO error, similar to what
other drivers do.
In case EAGAIN is returned then any read from /dev/drm_dp_aux
device ends up in an infinite loop as the upper layers
con
On 17.04.2024 10:41, Aravind Iddamsetty wrote:
> This would be used in other places outside of gt_reset path.
>
> Cc: Lucas De Marchi
>
> Reviewed-by: Rodrigo Vivi
> Signed-off-by: Aravind Iddamsetty
> ---
> drivers/gpu/drm/xe/xe_gt.c | 31 +--
> drivers/gpu/drm
Il 17/04/24 15:25, Uwe Kleine-König ha scritto:
Hello,
On Wed, Apr 17, 2024 at 12:19:19PM +0200, AngeloGioacchino Del Regno wrote:
Il 16/04/24 17:53, Alexandre Mergnat ha scritto:
According to the Mediatek MT8365 datasheet, the display PWM block has
a power domain.
Signed-off-by: Alexandre Me
Hi Thomas,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-xe/drm-xe-next]
[also build test WARNING on drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.9-rc4 next-20240417]
[cannot apply to drm-misc/drm-misc-next drm/drm-next drm-exynos
Hi Sima and Dave,
Here goes our biggest pull request of this round.
Likely a small pull request coming end of next week as well.
I had to bypass dim on missed link tag in a patch that was a urgent revert
and ended up without the patchwork link.
(Which btw I'm proposing an option to dim for making
Hello,
On Wed, Apr 17, 2024 at 12:19:19PM +0200, AngeloGioacchino Del Regno wrote:
> Il 16/04/24 17:53, Alexandre Mergnat ha scritto:
> > According to the Mediatek MT8365 datasheet, the display PWM block has
> > a power domain.
> >
> > Signed-off-by: Alexandre Mergnat
>
> It's the same for at l
Add test cases that check how the state of dma fences in BO's
reservation object influence the ttm_bo_validation() flow. Do similar
tests for resource manager's move fence.
Signed-off-by: Karolina Stolarek
Reviewed-by: Somalapuram, Amaranath
Tested-by: Somalapuram, Amaranath
---
.../gpu/drm/tt
List improvements for the test suite with some notes.
Signed-off-by: Karolina Stolarek
---
drivers/gpu/drm/ttm/tests/TODO | 25 +
1 file changed, 25 insertions(+)
create mode 100644 drivers/gpu/drm/ttm/tests/TODO
diff --git a/drivers/gpu/drm/ttm/tests/TODO b/drivers/gpu
Add tests for functions that add and release pages to TTs. Test the
swapin operation. Export ttm_tt_unpopulate, ttm_tt_swapin and
ttm_tt_swapout symbols for testing purposes.
Signed-off-by: Karolina Stolarek
Reviewed-by: Somalapuram, Amaranath
Tested-by: Somalapuram, Amaranath
---
drivers/gpu/
Add mock resource manager to test ttm_bo_validate() with non-system
placements. Update KConfig entry to enable DRM Buddy allocator, used
by the mock manager. Update move function to do more than just assign
a resource.
Signed-off-by: Karolina Stolarek
Tested-by: Somalapuram, Amaranath
---
drive
Add tests for ttm_bo_validate that focus on BO eviction and swapout.
Update device funcs definition with eviction-related callbacks. Add
alternative funcs where evict_flags() routes eviction to a domain
that can't allocate resources (dubbed "busy manager" in the tests).
Extract the common path of t
Add tests for ttm_bo_init_reserved() and ttm_bo_validate() that use
sys manager. Define a simple move function in ttm_device_funcs. Expose
destroy callback of the buffer object to make testing of
ttm_bo_init_reserved() behaviour easier.
Signed-off-by: Karolina Stolarek
Reviewed-by: Matthew Auld
DRM KUnit helpers are selected automatically when TTM tests are enabled,
so there's no need to do it directly in the .kunitconfig file.
Signed-off-by: Karolina Stolarek
---
drivers/gpu/drm/ttm/tests/.kunitconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/tests/.kunitc
Add a new helper function that also initializes the device. Use it in
ttm_tt test suite and delete the local definition.
Signed-off-by: Karolina Stolarek
Reviewed-by: Matthew Auld
Reviewed-by: Somalapuram, Amaranath
---
drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c | 14 ++
drivers
Introduce tests for ttm_bo_validate()/ttm_bo_init_validate() that exercise
simple BO placement as well as eviction (including the case where the evict
domain also requires eviction to fit the incoming buffer). Prepare KUnit
helpers to handle such scenarios and add a mock VRAM manager. This series a
In commit d393acce7b3f ("drm/tests: Switch to kunit devices"),
DRM test helpers migrated away from using a dummy platform driver
in favour of KUnit device. This means that DMA masks for the device
are not set but are required by ttm_pool_alloc tests.
Set the DMA mask for coherent mappings to unblo
BOs in a bulk move have to share the same reservation object. That is
not the case in the ttm_bo_unreserve_bulk subtest. Share bo2's resv
object with bo1 to fix the issue.
Fixes: 995279d280d1 ("drm/ttm/tests: Add tests for ttm_bo functions")
Signed-off-by: Karolina Stolarek
---
drivers/gpu/drm/t
On 2024-04-17 11:18:58, Dmitry Baryshkov wrote:
> On Wed, 17 Apr 2024 at 02:57, Marijn Suijten
> wrote:
> >
> > Ordering issues here cause an uninitalized (default STANDALONE)
> > usecase to be programmed (which appears to be a MUX) in some cases
> > when msm_dsi_host_register() is called, leading
On Wed, 17 Apr 2024 at 02:57, Marijn Suijten
wrote:
>
> Just like the active interface and writeback block in ctl_intf_cfg_v1(),
> and later the rest of the blocks in followup active-CTL fixes or
> reworks, multiple calls to this function should enable additional DSC
> blocks instead of overwritin
On Wed, 17 Apr 2024 at 02:57, Marijn Suijten
wrote:
>
> As we can clearly see in a downstream kernel [1], flushing the slave INTF
> is skipped /only if/ the PPSPLIT topology is active.
>
> However, when DPU was originally submitted to mainline PPSPLIT was no
> longer part of it (seems to have been
On Wed, 17 Apr 2024 at 02:57, Marijn Suijten
wrote:
>
> When configuring the timing of DSI hosts (interfaces) in
> dsi_timing_setup() all values written to registers are taking bonded
> DSI into account by dividing the original mode width by 2 (half the
> data is sent over each of the two DSI host
On Wed, 17 Apr 2024 at 02:57, Marijn Suijten
wrote:
>
> When dual-DSI (bonded DSI) was added in commit ed9976a09b48
> ("drm/msm/dsi: adjust dsi timing for dual dsi mode") some DBG() prints
> were not updated, leading to print the original mode->clock rather
> than the adjusted (typically the mode
On Wed, Apr 17, 2024 at 12:21:58PM +0300, Jani Nikula wrote:
> On Wed, 17 Apr 2024, Imre Deak wrote:
> > Factor out a function to check for UHBR channel coding support used by a
> > follow-up patch in the patchset.
> >
> > Cc: dri-devel@lists.freedesktop.org
> > Reviewed-by: Ankit Nautiyal
> > Re
On Wed, Apr 17, 2024 at 12:39:40PM +0300, Jani Nikula wrote:
> On Wed, 17 Apr 2024, Imre Deak wrote:
> > Enabling the 5k@60Hz uncompressed mode on the MediaTek/Dell U3224KBA
> > monitor results in a blank screen, at least on MTL platforms on UHBR
> > link rates with some (<30) uncompressed bpp val
On Wed, 17 Apr 2024 00:30:58 +0200
Louis Chauvet wrote:
> Le 15/04/24 - 15:00, Pekka Paalanen a écrit :
> > On Tue, 09 Apr 2024 12:04:07 +0200
> > Louis Chauvet wrote:
> >
> > > Let's provide more details about the drm_format_info structure because
> > > its content may not be straightforward
Hi Herman,
thanks for your patch!
Do you actually have this working on real hardware? I never
submitted this patch because I could not get the hardware
working.
I was hoping for smarter people (Dmitry Baryshkov...) to step
in and help out to actually make it work before submitting
patches.
Your
On Wed, Apr 17, 2024 at 11:47 AM Enrico Bartky wrote:
>
> Hi,
>
> sorry for the delay. This patch fixes the crash during boot! (tested against
> linux 6.9-rc3)
>
> Greetings
Thanks for testing. Then I'll push this to drm-next-fixes.
-Patrik
>
> Am Mo., 15. Apr. 2024 um 13:57 Uhr schrieb Patrik
On Wed, 17 Apr 2024 00:30:58 +0200
Louis Chauvet wrote:
> Le 15/04/24 - 14:36, Pekka Paalanen a écrit :
> > On Tue, 09 Apr 2024 12:04:06 +0200
> > Louis Chauvet wrote:
> >
> > > The expected behavior of the rotation property was not very clear. Add
> > > more examples to explain what is the e
Hi
Am 17.04.24 um 10:21 schrieb Jani Nikula:
On Tue, 16 Apr 2024, Thomas Zimmermann wrote:
Hi
Am 16.04.24 um 14:27 schrieb Jani Nikula:
On Tue, 16 Apr 2024, Thomas Zimmermann wrote:
Hi
Am 16.04.24 um 11:20 schrieb Jani Nikula:
Repurpose drm_edid_are_equal() to be more helpful for its sin
In case there is no DP device attached to the port the
transfer function should return IO error, similar to what
other drivers do.
In case EAGAIN is returned then any read from /dev/drm_dp_aux
device ends up in an infinite loop as the upper layers
constantly repeats the transfer request.
Fixes: f7
1 - 100 of 145 matches
Mail list logo
