Re: 答复: [PATCH v6.6] drm/amd/display: Wake DMCUB before executing GPINT commands
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
> executing GPINT commands"). When we apply this patch to linux-5.10, there are
> lots of conflicts, and we found there are lots of dependent patches, and lots
> of patches are not proposed to fix the cve, they are presented to add new
> functions of the kernel.
>
> My commit comes from nearly 20 patches. For each patch, not all of its
> content is meant to fix the cve, so I just get the part which is helpful to
> fix. It is why I don't present the patches one by one instead of merging them
> into one big patch.
>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
Also, yes, we want to take the original commits, as you see on the
stable mailing list, submit a series of commits that are in Linus's tree
that resolve the issue (and send them to the proper people, as explained
in the link above.)
thanks,
greg k-h
Re: [PATCH v6 2/4] drm/bridge: add lvds controller support for sam9x7
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 following:
>> - Prepares and enables the LVDS Peripheral clock
>> - Defines its connector type as DRM_MODE_CONNECTOR_LVDS and adds itself
>> to the global bridge list.
>> - Identifies its output endpoint as panel and adds it to the encoder
>> display pipeline
>> - Enables the LVDS serializer
>>
>> Signed-off-by: Manikandan Muralidharan
>> Signed-off-by: Dharma Balasubiramani
>> ---
>> Changelog
>> v5 -> v6
>> - No Changes.
>> v4 -> v5
>> - Drop the unused variable 'format'.
>> - Use DRM wrapper for dev_err() to maintain uniformity.
>> - return -ENODEV instead of -EINVAL to maintain consistency with other DRM
>>bridge drivers.
>> v3 -> v4
>> - No changes.
>> v2 ->v3
>> - Correct Typo error "serializer".
>> - Consolidate get() and prepare() functions and use devm_clk_get_prepared().
>> - Remove unused variable 'ret' in probe().
>> - Use devm_pm_runtime_enable() and drop the mchp_lvds_remove().
>> v1 -> v2
>> - Drop 'res' variable and combine two lines into one.
>> - Handle deferred probe properly, use dev_err_probe().
>> - Don't print anything on deferred probe. Dropped print.
>> - Remove the MODULE_ALIAS and add MODULE_DEVICE_TABLE().
>> - symbol 'mchp_lvds_driver' was not declared. It should be static.
>> ---
>> drivers/gpu/drm/bridge/Kconfig | 7 +
>> drivers/gpu/drm/bridge/Makefile | 1 +
>> drivers/gpu/drm/bridge/microchip-lvds.c | 228
>> 3 files changed, 236 insertions(+)
>> create mode 100644 drivers/gpu/drm/bridge/microchip-lvds.c
>>
>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>> index efd996f6c138..889098e2d65f 100644
>> --- a/drivers/gpu/drm/bridge/Kconfig
>> +++ b/drivers/gpu/drm/bridge/Kconfig
>> @@ -190,6 +190,13 @@ config DRM_MEGACHIPS_STDP_GE_B850V3_FW
>> to DP++. This is used with the i.MX6 imx-ldb
>> driver. You are likely to say N here.
>>
>> +config DRM_MICROCHIP_LVDS_SERIALIZER
>> + tristate "Microchip LVDS serializer support"
>> + depends on OF
>> + depends on DRM_ATMEL_HLCDC
>> + help
>> + Support for Microchip's LVDS serializer.
>> +
>> config DRM_NWL_MIPI_DSI
>>tristate "Northwest Logic MIPI DSI Host controller"
>>depends on DRM
>> diff --git a/drivers/gpu/drm/bridge/Makefile
>> b/drivers/gpu/drm/bridge/Makefile
>> index 017b5832733b..7df87b582dca 100644
>> --- a/drivers/gpu/drm/bridge/Makefile
>> +++ b/drivers/gpu/drm/bridge/Makefile
>> @@ -13,6 +13,7 @@ obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
>> obj-$(CONFIG_DRM_LONTIUM_LT9611UXC) += lontium-lt9611uxc.o
>> obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
>> obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
>> megachips-stdp-ge-b850v3-fw.o
>> +obj-$(CONFIG_DRM_MICROCHIP_LVDS_SERIALIZER) += microchip-lvds.o
>> obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
>> obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
>> obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
>> diff --git a/drivers/gpu/drm/bridge/microchip-lvds.c
>> b/drivers/gpu/drm/bridge/microchip-lvds.c
>> new file mode 100644
>> index ..149704f498a6
>> --- /dev/null
>> +++ b/drivers/gpu/drm/bridge/microchip-lvds.c
>> @@ -0,0 +1,228 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (C) 2023 Microchip Technology Inc. and its subsidiaries
>> + *
>> + * Author: Manikandan Muralidharan
>> + * Author: Dharma Balasubiramani
>> + *
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define LVDS_POLL_TIMEOUT_MS 1000
>> +
>> +/* LVDSC register offsets */
>> +#define LVDSC_CR 0x00
>> +#define LVDSC_CFGR 0x04
>> +#define LVDSC_SR 0x0C
>> +#define LVDSC_WPMR 0xE4
>> +
>> +/* Bitfields in LVDSC_CR (Control Register) */
>> +#define LVDSC_CR_SER_EN BIT(0)
>> +
>> +/* Bitfields in LVDSC_CFGR (Configuration Register) */
>> +#define LVDSC_CFGR_PIXSIZE_24BITS0
>> +#define LVDSC_CFGR_DEN_POL_HIGH 0
>> +#define LVDSC_CFGR_DC_UNBALANCED 0
>> +#define LVDSC_CFGR_MAPPING_JEIDA BIT(6)
>> +
>> +/*Bitfields in LVDSC_SR */
>> +#define LVDSC_SR_CS BIT(0)
>> +
>> +/* Bitfields in LVDSC_WPMR (Write Protection Mode Register) */
>> +#define LVDSC_WPMR_WPKEY_MASKGENMASK(31, 8)
>> +#define LVDSC_WPMR_WPKEY_PSSWD 0x4C5644
>> +
>> +struct mchp_lvds {
>> + struct device *dev;
>> + void __iomem *regs;
>> + struct clk *pclk;
>> + struct drm_panel *panel;
>> + struct drm_bridge bridge;
>> +
答复: [PATCH v5.10] drm/amd/display: Wake DMCUB before executing GPINT commands
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 linux-5.10,
there are lots of conflicts, and we found there are lots of dependent patches,
we do not apply all these patches since some are not meant to fix the cve, so
we just get part of them, and for each patch we just get the part which is
helpful to fix.
-邮件原件-
发件人: Greg KH [mailto:gre...@linuxfoundation.org]
发送时间: 2024年4月16日 12:49
收件人: wangzhu
抄送: harry.wentl...@amd.com; sunpeng...@amd.com; alexander.deuc...@amd.com;
christian.koe...@amd.com; airl...@linux.ie; dan...@ffwll.ch;
sanglipe...@jd.com; sas...@kernel.org; wayne@amd.com; jos...@froggi.es;
hon...@uniontech.com; c...@net-c.es; nicholas.kazlaus...@amd.com;
chiahsuan.ch...@amd.com; m...@igalia.com; roman...@amd.com;
aurabindo.pil...@amd.com; hansen.dso...@amd.com; rodrigo.sique...@amd.com;
Konstantin Meskhidze (A) ; aric@amd.com;
zhangjialin (F) ; jaehyun.ch...@amd.com;
mario.limoncie...@amd.com; amd-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org
主题: Re: [PATCH v5.10] drm/amd/display: Wake DMCUB before executing GPINT
commands
On Tue, Apr 16, 2024 at 02:43:47AM +, Zhu Wang wrote:
> From: Nicholas Kazlauskas
>
> stable inclusion
> from stable-v6.7.3
> commit2ef98c6d753a7 ("drm/amd/display: Wake DMCUB before executing
> GPINT commands")
> category: bugfix
> bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9BV4C
> CVE: CVE-2023-52624
>
> Reference:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/com
> mit/?id=2ef98c6d753a744e333b7e34b9cf687040fba57d
>
>
>
> [ Upstream commit e5ffd1263dd5b ("drm/amd/display: Wake DMCUB before
> executing GPINT commands") ]
>
> [Why]
> DMCUB can be in idle when we attempt to interface with the HW through
> the GPINT mailbox resulting in a system hang.
>
> [How]
> Add dc_wake_and_execute_gpint() to wrap the wake, execute, sleep
> sequence.
>
> If the GPINT executes successfully then DMCUB will be put back into
> sleep after the optional response is returned.
>
> It functions similar to the inbox command interface.
>
> Cc: Mario Limonciello
> Cc: Alex Deucher
> Cc: sta...@vger.kernel.org
> Reviewed-by: Hansen Dsouza
> Acked-by: Wayne Lin
> Signed-off-by: Nicholas Kazlauskas
> Tested-by: Daniel Wheeler
> Signed-off-by: Alex Deucher
>
> This patch comes from following commits:
>
> 115c7e7f0501 ("drm/amd/display: Add psr get_state call")
> 1d496907f1c5 ("drm/amd/display: Engage PSR synchronously")
> 34ba432c946d ("drm/amd/display: [FW Promotion] Release 0.0.44")
> 672251b223c1 ("drm/amd/display: [FW Promotion] Release 0.0.40")
> 04f3c88f0955 ("drm/amd/display: Retry getting PSR state if command
> times out") b30eda8d416c ("drm/amd/display: Add ETW log to
> dmub_psr_get_state") f59a66c1915e ("drm/amd/display: use do-while-0
> for DC_TRACE_LEVEL_MESSAGE()") e97cc04fe0fb ("drm/amd/display:
> refactor dmub commands into single function")
> 522b9a5d5852 ("drm/amd/display: drain dmub inbox if queue is full")
> 9dce8c2a5f1b ("drm/amd/display: [FW Promotion] Release 0.0.161.0")
> 276641775848 ("drm/amd/display: [FW Promotion] Release 0.0.162.0")
> 8774029f76b9 ("drm/amd/display: Add DCN35 CLK_MGR") 65138eb72e1f
> ("drm/amd/display: Add DCN35 DMUB") dc01c4b79bfe ("drm/amd/display:
> Update driver and IPS interop")
> 5b7954272ae9 ("drm/amd/display: [FW Promotion] Release 0.0.183.0")
> da2d16fcdda3 ("drm/amd/display: Fix IPS handshake for idle
> optimizations")
> 5e8a0d3598b4 ("drm/amd/display: Negate IPS allow and commit bits")
> 820c3870c491 ("drm/amd/display: Refactor DMCUB enter/exit idle
> interface") 2ef98c6d753a ("drm/amd/display: Wake DMCUB before
> executing GPINT commands")
>
> Signed-off-by: Zhu Wang
I'm confused, what are we supposed to do with this?
greg k-h
答复: [PATCH v6.6] drm/amd/display: Wake DMCUB before executing GPINT commands
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; rodrigo.sique...@amd.com; alexander.deuc...@amd.com;
christian.koe...@amd.com; airl...@linux.ie; dan...@ffwll.ch;
qingqing.z...@amd.com; stylon.w...@amd.com; josip.pa...@amd.com;
t...@redhat.com; cruise.h...@amd.com; eric.ya...@amd.com;
mario.limoncie...@amd.com; alvin.l...@amd.com; jun@amd.com;
austin.zh...@amd.com; sung...@amd.com; paul.hs...@amd.com; hanghong...@amd.com;
jinze...@amd.com; lewis.hu...@amd.com; Zhengzengkai ;
alex.h...@amd.com; syed.has...@amd.com; wayne@amd.com;
nicholas.kazlaus...@amd.com; chiahsuan.ch...@amd.com; aurabindo.pil...@amd.com;
aric@amd.com; amd-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org
主题: Re: [PATCH v6.6] drm/amd/display: Wake DMCUB before executing GPINT commands
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 GPINT commands"). When we apply this patch to linux-5.10, there are
> lots of conflicts, and we found there are lots of dependent patches, and lots
> of patches are not proposed to fix the cve, they are presented to add new
> functions of the kernel.
>
Why is there a CVE? Have you uncovered some specific issue?
Alex
> My commit comes from nearly 20 patches. For each patch, not all of its
> content is meant to fix the cve, so I just get the part which is helpful to
> fix. It is why I don't present the patches one by one instead of merging them
> into one big patch.
>
>
> -邮件原件-
> 发件人: Greg KH [mailto:gre...@linuxfoundation.org]
> 发送时间: 2024年4月16日 12:54
> 收件人: wangzhu
> 抄送: harry.wentl...@amd.com; sunpeng...@amd.com;
> rodrigo.sique...@amd.com; alexander.deuc...@amd.com;
> christian.koe...@amd.com; airl...@linux.ie; dan...@ffwll.ch;
> qingqing.z...@amd.com; stylon.w...@amd.com; josip.pa...@amd.com;
> t...@redhat.com; cruise.h...@amd.com; eric.ya...@amd.com;
> mario.limoncie...@amd.com; alvin.l...@amd.com; jun@amd.com;
> austin.zh...@amd.com; sung...@amd.com; paul.hs...@amd.com;
> hanghong...@amd.com; jinze...@amd.com; lewis.hu...@amd.com;
> Zhengzengkai ; alex.h...@amd.com;
> syed.has...@amd.com; wayne@amd.com; nicholas.kazlaus...@amd.com;
> chiahsuan.ch...@amd.com; aurabindo.pil...@amd.com; aric@amd.com;
> amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> linux-ker...@vger.kernel.org
> 主题: Re: [PATCH v6.6] drm/amd/display: Wake DMCUB before executing
> GPINT commands
>
> On Tue, Apr 16, 2024 at 03:52:40AM +, Zhu Wang wrote:
> > From: Nicholas Kazlauskas
> >
> > stable inclusion
> > from stable-v6.7.3
> > commit 2ef98c6d753a744e333b7e34b9cf687040fba57d
> > category: bugfix
> > bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9BV4C
> > CVE: CVE-2023-52624
> >
> > Reference:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/c
> > om mit/?id=2ef98c6d753a744e333b7e34b9cf687040fba57d
> >
> >
> >
> > [ Upstream commit e5ffd1263dd5b44929c676171802e7b6af483f21 ]
> >
> > [Why]
> > DMCUB can be in idle when we attempt to interface with the HW
> > through the GPINT mailbox resulting in a system hang.
> >
> > [How]
> > Add dc_wake_and_execute_gpint() to wrap the wake, execute, sleep
> > sequence.
> >
> > If the GPINT executes successfully then DMCUB will be put back into
> > sleep after the optional response is returned.
> >
> > It functions similar to the inbox command interface.
> >
> > Cc: Mario Limonciello
> > Cc: Alex Deucher
> > Cc: sta...@vger.kernel.org
> > Reviewed-by: Hansen Dsouza
> > Acked-by: Wayne Lin
> > Signed-off-by: Nicholas Kazlauskas
> > Tested-by: Daniel Wheeler
> > Signed-off-by: Alex Deucher
> >
> > This commit comes from following commits:
> >
> > 8774029f76b9 ("drm/amd/display: Add DCN35 CLK_MGR") 65138eb72e1f
> > ("drm/amd/display: Add DCN35 DMUB") dc01c4b79bfe ("drm/amd/display:
> > Update driver and IPS interop")
> > 820c3870c491 ("drm/amd/display: Refactor DMCUB enter/exit idle
> > interface") 2ef98c6d753a ("drm/amd/display: Wake DMCUB before
> > executing GPINT commands")
>
> Why are you putting multiple commits together and not just submitting the
> individual ones? And what is this for?
>
> confused,
>
> greg k-h
Re: [PATCH v2] drm/mediatek/dp: fix mtk_dp_aux_transfer return value
Re: [PATCH v6.6] drm/amd/display: Wake DMCUB before executing GPINT commands
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 GPINT commands"). When we apply this patch to linux-5.10, there are
> lots of conflicts, and we found there are lots of dependent patches, and lots
> of patches are not proposed to fix the cve, they are presented to add new
> functions of the kernel.
>
Why is there a CVE? Have you uncovered some specific issue?
Alex
> My commit comes from nearly 20 patches. For each patch, not all of its
> content is meant to fix the cve, so I just get the part which is helpful to
> fix. It is why I don't present the patches one by one instead of merging them
> into one big patch.
>
>
> -邮件原件-
> 发件人: Greg KH [mailto:gre...@linuxfoundation.org]
> 发送时间: 2024年4月16日 12:54
> 收件人: wangzhu
> 抄送: harry.wentl...@amd.com; sunpeng...@amd.com; rodrigo.sique...@amd.com;
> alexander.deuc...@amd.com; christian.koe...@amd.com; airl...@linux.ie;
> dan...@ffwll.ch; qingqing.z...@amd.com; stylon.w...@amd.com;
> josip.pa...@amd.com; t...@redhat.com; cruise.h...@amd.com;
> eric.ya...@amd.com; mario.limoncie...@amd.com; alvin.l...@amd.com;
> jun@amd.com; austin.zh...@amd.com; sung...@amd.com; paul.hs...@amd.com;
> hanghong...@amd.com; jinze...@amd.com; lewis.hu...@amd.com; Zhengzengkai
> ; alex.h...@amd.com; syed.has...@amd.com;
> wayne@amd.com; nicholas.kazlaus...@amd.com; chiahsuan.ch...@amd.com;
> aurabindo.pil...@amd.com; aric@amd.com; amd-...@lists.freedesktop.org;
> dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org
> 主题: Re: [PATCH v6.6] drm/amd/display: Wake DMCUB before executing GPINT
> commands
>
> On Tue, Apr 16, 2024 at 03:52:40AM +, Zhu Wang wrote:
> > From: Nicholas Kazlauskas
> >
> > stable inclusion
> > from stable-v6.7.3
> > commit 2ef98c6d753a744e333b7e34b9cf687040fba57d
> > category: bugfix
> > bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9BV4C
> > CVE: CVE-2023-52624
> >
> > Reference:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/com
> > mit/?id=2ef98c6d753a744e333b7e34b9cf687040fba57d
> >
> >
> >
> > [ Upstream commit e5ffd1263dd5b44929c676171802e7b6af483f21 ]
> >
> > [Why]
> > DMCUB can be in idle when we attempt to interface with the HW through
> > the GPINT mailbox resulting in a system hang.
> >
> > [How]
> > Add dc_wake_and_execute_gpint() to wrap the wake, execute, sleep
> > sequence.
> >
> > If the GPINT executes successfully then DMCUB will be put back into
> > sleep after the optional response is returned.
> >
> > It functions similar to the inbox command interface.
> >
> > Cc: Mario Limonciello
> > Cc: Alex Deucher
> > Cc: sta...@vger.kernel.org
> > Reviewed-by: Hansen Dsouza
> > Acked-by: Wayne Lin
> > Signed-off-by: Nicholas Kazlauskas
> > Tested-by: Daniel Wheeler
> > Signed-off-by: Alex Deucher
> >
> > This commit comes from following commits:
> >
> > 8774029f76b9 ("drm/amd/display: Add DCN35 CLK_MGR") 65138eb72e1f
> > ("drm/amd/display: Add DCN35 DMUB") dc01c4b79bfe ("drm/amd/display:
> > Update driver and IPS interop")
> > 820c3870c491 ("drm/amd/display: Refactor DMCUB enter/exit idle
> > interface") 2ef98c6d753a ("drm/amd/display: Wake DMCUB before
> > executing GPINT commands")
>
> Why are you putting multiple commits together and not just submitting the
> individual ones? And what is this for?
>
> confused,
>
> greg k-h
答复: [PATCH v6.6] drm/amd/display: Wake DMCUB before executing GPINT commands
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, there are
lots of conflicts, and we found there are lots of dependent patches, and lots
of patches are not proposed to fix the cve, they are presented to add new
functions of the kernel.
My commit comes from nearly 20 patches. For each patch, not all of its content
is meant to fix the cve, so I just get the part which is helpful to fix. It is
why I don't present the patches one by one instead of merging them into one big
patch.
-邮件原件-
发件人: Greg KH [mailto:gre...@linuxfoundation.org]
发送时间: 2024年4月16日 12:54
收件人: wangzhu
抄送: harry.wentl...@amd.com; sunpeng...@amd.com; rodrigo.sique...@amd.com;
alexander.deuc...@amd.com; christian.koe...@amd.com; airl...@linux.ie;
dan...@ffwll.ch; qingqing.z...@amd.com; stylon.w...@amd.com;
josip.pa...@amd.com; t...@redhat.com; cruise.h...@amd.com; eric.ya...@amd.com;
mario.limoncie...@amd.com; alvin.l...@amd.com; jun@amd.com;
austin.zh...@amd.com; sung...@amd.com; paul.hs...@amd.com; hanghong...@amd.com;
jinze...@amd.com; lewis.hu...@amd.com; Zhengzengkai ;
alex.h...@amd.com; syed.has...@amd.com; wayne@amd.com;
nicholas.kazlaus...@amd.com; chiahsuan.ch...@amd.com; aurabindo.pil...@amd.com;
aric@amd.com; amd-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org
主题: Re: [PATCH v6.6] drm/amd/display: Wake DMCUB before executing GPINT commands
On Tue, Apr 16, 2024 at 03:52:40AM +, Zhu Wang wrote:
> From: Nicholas Kazlauskas
>
> stable inclusion
> from stable-v6.7.3
> commit 2ef98c6d753a744e333b7e34b9cf687040fba57d
> category: bugfix
> bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9BV4C
> CVE: CVE-2023-52624
>
> Reference:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/com
> mit/?id=2ef98c6d753a744e333b7e34b9cf687040fba57d
>
>
>
> [ Upstream commit e5ffd1263dd5b44929c676171802e7b6af483f21 ]
>
> [Why]
> DMCUB can be in idle when we attempt to interface with the HW through
> the GPINT mailbox resulting in a system hang.
>
> [How]
> Add dc_wake_and_execute_gpint() to wrap the wake, execute, sleep
> sequence.
>
> If the GPINT executes successfully then DMCUB will be put back into
> sleep after the optional response is returned.
>
> It functions similar to the inbox command interface.
>
> Cc: Mario Limonciello
> Cc: Alex Deucher
> Cc: sta...@vger.kernel.org
> Reviewed-by: Hansen Dsouza
> Acked-by: Wayne Lin
> Signed-off-by: Nicholas Kazlauskas
> Tested-by: Daniel Wheeler
> Signed-off-by: Alex Deucher
>
> This commit comes from following commits:
>
> 8774029f76b9 ("drm/amd/display: Add DCN35 CLK_MGR") 65138eb72e1f
> ("drm/amd/display: Add DCN35 DMUB") dc01c4b79bfe ("drm/amd/display:
> Update driver and IPS interop")
> 820c3870c491 ("drm/amd/display: Refactor DMCUB enter/exit idle
> interface") 2ef98c6d753a ("drm/amd/display: Wake DMCUB before
> executing GPINT commands")
Why are you putting multiple commits together and not just submitting the
individual ones? And what is this for?
confused,
greg k-h
Re: [PATCH] dmabuf: fix dmabuf file poll uaf issue
在 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 写道: [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 12.04.24 um 08:19 schrieb zhiguojiang: [SNIP] -> Here task 2220 do epoll again where internally it will get/put then start to free twice and lead to final crash. Here is the basic flow: 1. Thread A install the dma_buf_fd via dma_buf_export, the fd refcount is 1 2. Thread A add the fd to epoll list via epoll_ctl(EPOLL_CTL_ADD) 3. After use the dma buf, Thread A close the fd, then here fd refcount is 0, and it will run __fput finally to release the file Stop, that isn't correct. The fs layer which calls dma_buf_poll() should make sure that the file can't go away until the function returns. Then inside dma_buf_poll() we add another reference to the file while installing the callback: /* Paired with fput in dma_buf_poll_cb */ get_file(dmabuf->file); Hi, The problem may just occurred here. Is it possible file reference count already decreased to 0 and fput already being in progressing just before calling get_file(dmabuf->file) in dma_buf_poll()? No, exactly that isn't possible. If a function gets a dma_buf pointer or even more general any reference counted pointer which has already decreased to 0 then that is a major bug in the caller of that function. BTW: It's completely illegal to work around such issues by using file_count() or RCU functions. So when you suggest stuff like that it will immediately face rejection. Regards, Christian. Hi, Thanks for your kind comment. 'If a function gets a dma_buf pointer or even more general any reference counted pointer which has already decreased to 0 then that is a major bug in the caller of that function.' According to the issue log, we can see the dma buf file close and epoll operation running in parallel. Apparently at the moment caller calls epoll, although another task caller already called close on the same fd, but this fd was still in progress to close, so fd is still valid, thus no EBADF returned to caller. Then the two task contexts operate on same dma buf fd(one is close, another is epoll) in kernel space. Please kindly help to comment whether above scenario is possible. If there is some bug in the caller logic, Can u help to point it out? :) Regards, Zhiguo This reference is only dropped after the callback is completed in dma_buf_poll_cb(): /* Paired with get_file in dma_buf_poll */ fput(dmabuf->file); So your explanation for the issue just seems to be incorrect. 4. Here Thread A not do epoll_ctl(EPOLL_CTL_DEL) manunally, so it still resides in one epoll_list. Although __fput will call eventpoll_release to remove the file from binded epoll list, but it has small time window where Thread B jumps in. Well if that is really the case then that would then be a bug in epoll_ctl(). 5. During the small window, Thread B do the poll action for dma_buf_fd, where it will fget/fput for the file, this means the fd refcount will be 0 -> 1 -> 0, and it will call __fput again. This will lead to __fput twice for the same file. 6. So the potenial fix is use get_file_rcu which to check if file refcount already zero which means under free. If so, we just return and no need to do the dma_buf_poll. Well to say it bluntly as far as I can see this suggestion is completely nonsense. When the reference to the file goes away while dma_buf_poll() is executed then that's a massive bug in the caller of that function. Regards, Christian. Here is the race condition: Thread A Thread B dma_buf_export fd_refcount is 1 epoll_ctl(EPOLL_ADD) add dma_buf_fd to epoll list close(dma_buf_fd) fd_refcount is 0 __fput dma_buf_poll fget fput fd_refcount is zero again Thanks
Re: [PATCH 4/6] drm/panel: novatek-nt36672e: stop calling regulator_set_load manually
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 reviewed, but patch 3 was not. -- With best wishes Dmitry
Re: [PATCH v2 7/7] arm64: dts: qcom: sm8550: Wire up GPU speed bin & more OPPs
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/qcom/sm8550.dtsi | 21 - > 1 file changed, 20 insertions(+), 1 deletion(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v2 6/7] drm/msm/adreno: Redo the speedbin assignment
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 representation in hardware whatshowever.
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 34
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 56 --
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 70
> +++--
> drivers/gpu/drm/msm/adreno/adreno_gpu.h | 3 --
> drivers/gpu/drm/msm/msm_gpu.c | 3 --
> 5 files changed, 57 insertions(+), 109 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> index c003f970189b..eed6a2eb1731 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> @@ -1704,38 +1704,6 @@ static const struct adreno_gpu_funcs funcs = {
> .get_timestamp = a5xx_get_timestamp,
> };
>
> -static void check_speed_bin(struct device *dev)
> -{
> - struct nvmem_cell *cell;
> - u32 val;
> -
> - /*
> - * If the OPP table specifies a opp-supported-hw property then we have
> - * to set something with dev_pm_opp_set_supported_hw() or the table
> - * doesn't get populated so pick an arbitrary value that should
> - * ensure the default frequencies are selected but not conflict with any
> - * actual bins
> - */
> - val = 0x80;
> -
> - cell = nvmem_cell_get(dev, "speed_bin");
> -
> - if (!IS_ERR(cell)) {
> - void *buf = nvmem_cell_read(cell, NULL);
> -
> - if (!IS_ERR(buf)) {
> - u8 bin = *((u8 *) buf);
> -
> - val = (1 << bin);
> - kfree(buf);
> - }
> -
> - nvmem_cell_put(cell);
> - }
> -
> - devm_pm_opp_set_supported_hw(dev, , 1);
> -}
> -
> struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
> {
> struct msm_drm_private *priv = dev->dev_private;
> @@ -1763,8 +1731,6 @@ struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
>
> a5xx_gpu->lm_leakage = 0x4E001A;
>
> - check_speed_bin(>dev);
> -
> nr_rings = 4;
>
> if (config->info->revn == 510)
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index 60708c23ae4c..1242697d64a7 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -2878,55 +2878,6 @@ static bool a6xx_progress(struct msm_gpu *gpu, struct
> msm_ringbuffer *ring)
> return progress;
> }
>
> -static u32 fuse_to_supp_hw(const struct adreno_info *info, u32 fuse)
> -{
> - if (!info->speedbins)
> - return UINT_MAX;
> -
> - for (int i = 0; info->speedbins[i].fuse != SHRT_MAX; i++)
> - if (info->speedbins[i].fuse == fuse)
> - return BIT(info->speedbins[i].speedbin);
> -
> - return UINT_MAX;
> -}
> -
> -static int a6xx_set_supported_hw(struct adreno_gpu *adreno_gpu,
> - struct device *dev,
> - const struct adreno_info *info)
> -{
> - u32 supp_hw;
> - u32 speedbin;
> - int ret;
> -
> - ret = adreno_read_speedbin(adreno_gpu, dev, );
> - /*
> - * -ENOENT means that the platform doesn't support speedbin which is
> - * fine
> - */
> - if (ret == -ENOENT) {
> - return 0;
> - } else if (ret) {
> - dev_err_probe(dev, ret,
> - "failed to read speed-bin. Some OPPs may not be
> supported by hardware\n");
> - return ret;
> - }
> -
> - supp_hw = fuse_to_supp_hw(info, speedbin);
> -
> - if (supp_hw == UINT_MAX) {
> - DRM_DEV_ERROR(dev,
> - "missing support for speed-bin: %u. Some OPPs may not
> be supported by hardware\n",
> - speedbin);
> - supp_hw = BIT(0); /* Default */
> - }
> -
> - ret = devm_pm_opp_set_supported_hw(dev, _hw, 1);
> - if (ret)
> - return ret;
> -
> - return 0;
> -}
> -
> static const struct adreno_gpu_funcs funcs = {
> .base = {
> .get_param = adreno_get_param,
> @@ -3058,13 +3009,6 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
>
> a6xx_llc_slices_init(pdev, a6xx_gpu, is_a7xx);
>
> - ret = a6xx_set_supported_hw(adreno_gpu, >dev, config->info);
> - if (ret) {
> - a6xx_llc_slices_destroy(a6xx_gpu);
> - kfree(a6xx_gpu);
> - return ERR_PTR(ret);
> - }
> -
> if (is_a7xx)
> ret = adreno_gpu_init(dev, pdev, adreno_gpu, _a7xx, 1);
> else if (adreno_has_gmu_wrapper(adreno_gpu))
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
>
Re: [PATCH v2 5/7] drm/msm/adreno: Define A530 speed bins explicitly
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 best wishes Dmitry
Re: [PATCH v2 4/7] drm/msm/adreno: Add speedbin data for SM8550 / A740
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 -- With best wishes Dmitry
Re: [PATCH v2 3/7] drm/msm/adreno: Implement SMEM-based speed bin
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 "product code" from said source and parsing them
> to form something that lets us match OPPs against.
>
> Due to the product code being ignored in the context of Adreno on
> production parts (as of SM8650), hardcode it to SOCINFO_PC_UNKNOWN.
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 8 +++---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 2 ++
> drivers/gpu/drm/msm/adreno/adreno_gpu.c| 41
> +++---
> drivers/gpu/drm/msm/adreno/adreno_gpu.h| 12 ++---
> 4 files changed, 53 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index d10323f15d40..60708c23ae4c 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -2890,13 +2890,15 @@ static u32 fuse_to_supp_hw(const struct adreno_info
> *info, u32 fuse)
> return UINT_MAX;
> }
>
> -static int a6xx_set_supported_hw(struct device *dev, const struct
> adreno_info *info)
> +static int a6xx_set_supported_hw(struct adreno_gpu *adreno_gpu,
> + struct device *dev,
> + const struct adreno_info *info)
> {
> u32 supp_hw;
> u32 speedbin;
> int ret;
>
> - ret = adreno_read_speedbin(dev, );
> + ret = adreno_read_speedbin(adreno_gpu, dev, );
> /*
>* -ENOENT means that the platform doesn't support speedbin which is
>* fine
> @@ -3056,7 +3058,7 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
>
> a6xx_llc_slices_init(pdev, a6xx_gpu, is_a7xx);
>
> - ret = a6xx_set_supported_hw(>dev, config->info);
> + ret = a6xx_set_supported_hw(adreno_gpu, >dev, config->info);
> if (ret) {
> a6xx_llc_slices_destroy(a6xx_gpu);
> kfree(a6xx_gpu);
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> b/drivers/gpu/drm/msm/adreno/adreno_device.c
> index c3703a51287b..901ef767e491 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> @@ -6,6 +6,8 @@
> * Copyright (c) 2014,2017 The Linux Foundation. All rights reserved.
> */
>
> +#include
> +
Stray leftover?
> #include "adreno_gpu.h"
>
> bool hang_debug = false;
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 074fb498706f..58fd70140685 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -21,6 +21,9 @@
> #include "msm_gem.h"
> #include "msm_mmu.h"
>
> +#include
> +#include
> +
> static u64 address_space_size = 0;
> MODULE_PARM_DESC(address_space_size, "Override for size of processes private
> GPU address space");
> module_param(address_space_size, ullong, 0600);
> @@ -1057,9 +1060,39 @@ void adreno_gpu_ocmem_cleanup(struct adreno_ocmem
> *adreno_ocmem)
> adreno_ocmem->hdl);
> }
>
> -int adreno_read_speedbin(struct device *dev, u32 *speedbin)
> +int adreno_read_speedbin(struct adreno_gpu *adreno_gpu,
> + struct device *dev, u32 *fuse)
> {
> - return nvmem_cell_read_variable_le_u32(dev, "speed_bin", speedbin);
> + u32 fcode;
> + int ret;
> +
> + /*
> + * Try reading the speedbin via a nvmem cell first
> + * -ENOENT means "no nvmem-cells" and essentially means "old DT" or
> + * "nvmem fuse is irrelevant", simply assume it's fine.
> + */
> + ret = nvmem_cell_read_variable_le_u32(dev, "speed_bin", fuse);
> + if (!ret)
> + return 0;
> + else if (ret != -ENOENT)
> + return dev_err_probe(dev, ret, "Couldn't read the speed bin
> fuse value\n");
> +
> +#ifdef CONFIG_QCOM_SMEM
Please extract to a separate function and put the function under ifdef
(providing a stub otherwise). Having #ifndefs inside funciton body is
frowned upon.
> + /*
> + * Only check the feature code - the product code only matters for
> + * proto SoCs unavailable outside Qualcomm labs, as far as GPU bin
> + * matching is concerned.
> + *
> + * Ignore EOPNOTSUPP, as not all SoCs expose this info through SMEM.
> + */
> + ret = qcom_smem_get_feature_code();
> + if (!ret)
> + *fuse = ADRENO_SKU_ID(fcode);
> + else if (ret != -EOPNOTSUPP)
> + return dev_err_probe(dev, ret, "Couldn't get feature code from
> SMEM\n");
> +#endif
> +
> + return 0;
> }
>
> int adreno_gpu_init(struct drm_device *drm, struct platform_device *pdev,
> @@ -1098,9 +1131,9 @@ int adreno_gpu_init(struct drm_device *drm, struct
>
Re: [PATCH v2 2/7] soc: qcom: smem: Add a feature code getter
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.
>
> Based on this information, we can deduce the available frequencies for
> things such as Adreno. In the case of Adreno specifically, Pcode is
> useless for non-prototype SoCs.
>
> Introduce a getter for the feature code and export it.
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/soc/qcom/smem.c | 33 +
> include/linux/soc/qcom/smem.h| 1 +
> include/linux/soc/qcom/socinfo.h | 26 ++
> 3 files changed, 60 insertions(+)
>
> diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
> index 7191fa0c087f..29e708789eec 100644
> --- a/drivers/soc/qcom/smem.c
> +++ b/drivers/soc/qcom/smem.c
> @@ -795,6 +795,39 @@ int qcom_smem_get_soc_id(u32 *id)
> }
> EXPORT_SYMBOL_GPL(qcom_smem_get_soc_id);
>
> +/**
> + * qcom_smem_get_feature_code() - return the feature code
> + * @code: On success, return the feature code here.
> + *
> + * Look up the feature code identifier from SMEM and return it.
> + *
> + * Return: 0 on success, negative errno on failure.
> + */
> +int qcom_smem_get_feature_code(u32 *code)
> +{
> + struct socinfo *info;
> + u32 raw_code;
> +
> + info = qcom_smem_get(QCOM_SMEM_HOST_ANY, SMEM_HW_SW_BUILD_ID, NULL);
> + if (IS_ERR(info))
> + return PTR_ERR(info);
> +
> + /* This only makes sense for socinfo >= 16 */
> + if (__le32_to_cpu(info->fmt) < SOCINFO_VERSION(0, 16))
> + return -EOPNOTSUPP;
> +
> + raw_code = __le32_to_cpu(info->feature_code);
> +
> + /* Ensure the value makes sense */
> + if (raw_code >= SOCINFO_FC_INT_MAX)
> + raw_code = SOCINFO_FC_UNKNOWN;
> +
> + *code = raw_code;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(qcom_smem_get_feature_code);
> +
> static int qcom_smem_get_sbl_version(struct qcom_smem *smem)
> {
> struct smem_header *header;
> diff --git a/include/linux/soc/qcom/smem.h b/include/linux/soc/qcom/smem.h
> index a36a3b9d4929..0943bf419e11 100644
> --- a/include/linux/soc/qcom/smem.h
> +++ b/include/linux/soc/qcom/smem.h
> @@ -13,5 +13,6 @@ int qcom_smem_get_free_space(unsigned host);
> phys_addr_t qcom_smem_virt_to_phys(void *p);
>
> int qcom_smem_get_soc_id(u32 *id);
> +int qcom_smem_get_feature_code(u32 *code);
>
> #endif
> diff --git a/include/linux/soc/qcom/socinfo.h
> b/include/linux/soc/qcom/socinfo.h
> index 10e0a4c287f4..52439f48428f 100644
> --- a/include/linux/soc/qcom/socinfo.h
> +++ b/include/linux/soc/qcom/socinfo.h
> @@ -3,6 +3,8 @@
> #ifndef __QCOM_SOCINFO_H__
> #define __QCOM_SOCINFO_H__
>
> +#include
> +
> /*
> * SMEM item id, used to acquire handles to respective
> * SMEM region.
> @@ -82,4 +84,28 @@ struct socinfo {
> __le32 boot_core;
> };
>
> +/* Internal feature codes */
> +enum qcom_socinfo_feature_code {
> + /* External feature codes */
> + SOCINFO_FC_UNKNOWN = 0x0,
> + SOCINFO_FC_AA,
> + SOCINFO_FC_AB,
> + SOCINFO_FC_AC,
> + SOCINFO_FC_AD,
> + SOCINFO_FC_AE,
> + SOCINFO_FC_AF,
> + SOCINFO_FC_AG,
> + SOCINFO_FC_AH,
> +};
> +
> +/* Internal feature codes */
> +/* Valid values: 0 <= n <= 0xf */
> +#define SOCINFO_FC_Yn(n) (0xf1 + n)
> +#define SOCINFO_FC_INT_MAX SOCINFO_FC_Yn(0x10)
This is 0x101 rather than 0x100 or 0xff. Is that expected?
> +
> +/* Product codes */
> +#define SOCINFO_PC_UNKNOWN 0
> +#define SOCINFO_PCn(n) (n + 1)
> +#define SOCINFO_PC_RESERVE (BIT(31) - 1)
This patch works on fcodes, why do we have PCode defines here?
> +
> #endif
>
> --
> 2.44.0
>
--
With best wishes
Dmitry
Re: [PATCH] component: Support masters with no subcomponents
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...) to step > in and help out to actually make it work before submitting > patches. I have LVDS working on apq8064, but it requires fixes in the MMCC driver, in the MDP4 driver and in DTS. I need to clean up them first before even attempting to send them out. Also a PWM/LPG driver would help as otherwise the power supply is quick to be overloaded by the backlight. Nevertheless, LVDS/LCDC-only MDP4 is a valid usecase, but it has to be handled in the driver rather than in the core lib. -- With best wishes Dmitry
Re: [PATCH 7/7] drm/msm/dpu: Rename `ctx` parameter to `intf` to match other functions
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 feelings towards such patches. On one hand it
improves readability, on the other hand, it's just a name, it has no
specific value.
Still:
Reviewed-by: Dmitry Baryshkov
>
> Signed-off-by: Marijn Suijten
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> index 965692ef7892..34d0c4e04d27 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> @@ -96,11 +96,11 @@
> #define INTF_CFG2_DCE_DATA_COMPRESS BIT(12)
>
>
> -static void dpu_hw_intf_setup_timing_engine(struct dpu_hw_intf *ctx,
> +static void dpu_hw_intf_setup_timing_engine(struct dpu_hw_intf *intf,
> const struct dpu_hw_intf_timing_params *p,
> const struct dpu_format *fmt)
> {
> - struct dpu_hw_blk_reg_map *c = >hw;
> + struct dpu_hw_blk_reg_map *c = >hw;
> u32 hsync_period, vsync_period;
> u32 display_v_start, display_v_end;
> u32 hsync_start_x, hsync_end_x;
> @@ -118,7 +118,7 @@ static void dpu_hw_intf_setup_timing_engine(struct
> dpu_hw_intf *ctx,
> /* read interface_cfg */
> intf_cfg = DPU_REG_READ(c, INTF_CONFIG);
>
> - if (ctx->cap->type == INTF_DP)
> + if (intf->cap->type == INTF_DP)
> dp_intf = true;
>
> hsync_period = p->hsync_pulse_width + p->h_back_porch + p->width +
> @@ -223,7 +223,7 @@ static void dpu_hw_intf_setup_timing_engine(struct
> dpu_hw_intf *ctx,
> DPU_REG_WRITE(c, INTF_FRAME_LINE_COUNT_EN, 0x3);
> DPU_REG_WRITE(c, INTF_CONFIG, intf_cfg);
> DPU_REG_WRITE(c, INTF_PANEL_FORMAT, panel_format);
> - if (ctx->cap->features & BIT(DPU_DATA_HCTL_EN)) {
> + if (intf->cap->features & BIT(DPU_DATA_HCTL_EN)) {
> /*
>* DATA_HCTL_EN controls data timing which can be different from
>* video timing. It is recommended to enable it for all cases,
> except
> @@ -518,10 +518,10 @@ static void dpu_hw_intf_disable_autorefresh(struct
> dpu_hw_intf *intf,
>
> }
>
> -static void dpu_hw_intf_program_intf_cmd_cfg(struct dpu_hw_intf *ctx,
> +static void dpu_hw_intf_program_intf_cmd_cfg(struct dpu_hw_intf *intf,
>struct dpu_hw_intf_cmd_mode_cfg
> *cmd_mode_cfg)
> {
> - u32 intf_cfg2 = DPU_REG_READ(>hw, INTF_CONFIG2);
> + u32 intf_cfg2 = DPU_REG_READ(>hw, INTF_CONFIG2);
>
> if (cmd_mode_cfg->data_compress)
> intf_cfg2 |= INTF_CFG2_DCE_DATA_COMPRESS;
> @@ -529,7 +529,7 @@ static void dpu_hw_intf_program_intf_cmd_cfg(struct
> dpu_hw_intf *ctx,
> if (cmd_mode_cfg->wide_bus_en)
> intf_cfg2 |= INTF_CFG2_DATABUS_WIDEN;
>
> - DPU_REG_WRITE(>hw, INTF_CONFIG2, intf_cfg2);
> + DPU_REG_WRITE(>hw, INTF_CONFIG2, intf_cfg2);
> }
>
> struct dpu_hw_intf *dpu_hw_intf_init(struct drm_device *dev,
>
> --
> 2.44.0
>
--
With best wishes
Dmitry
Re: [PATCH 5/7] drm/msm/dpu: Correct dual-ctl -> dual-intf typo in comment
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: Add SDM845 DPU support")
> Signed-off-by: Marijn Suijten
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
> index d9e7dbf0499c..7e849fe74801 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
> @@ -428,7 +428,7 @@ static void dpu_encoder_phys_vid_enable(struct
> dpu_encoder_phys *phys_enc)
> dpu_encoder_phys_vid_setup_timing_engine(phys_enc);
>
> /*
> - * For single flush cases (dual-ctl or pp-split), skip setting the
> + * For single flush cases (dual-intf or pp-split), skip setting the
It should be fixed, but in the other way: it's 'single-ctl'. See
sde_encoder_phys_needs_single_flush().
>* flush bit for the slave intf, since both intfs use same ctl
>* and HW will only flush the master.
>*/
>
> --
> 2.44.0
>
--
With best wishes
Dmitry
Re: [PATCH 4/6] drm/panel: novatek-nt36672e: stop calling regulator_set_load manually
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-nt36672e.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
b/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
index 9a870b9b6765..20b7bfe4aa12 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
@@ -343,17 +343,7 @@ static int nt36672e_1080x2408_60hz_init(struct
mipi_dsi_device *dsi)
static int nt36672e_power_on(struct nt36672e_panel *ctx)
{
struct mipi_dsi_device *dsi = ctx->dsi;
- int ret, i;
-
- for (i = 0; i < ARRAY_SIZE(ctx->supplies); i++) {
- ret = regulator_set_load(ctx->supplies[i].consumer,
- regulator_enable_loads[i]);
- if (ret) {
- dev_err(>dev, "regulator set load failed for supply %s:
%d\n",
- ctx->supplies[i].supply, ret);
- return ret;
- }
- }
+ int ret;
ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
if (ret < 0) {
@@ -550,8 +540,10 @@ static int nt36672e_panel_probe(struct mipi_dsi_device
*dsi)
return -ENODEV;
}
- for (i = 0; i < ARRAY_SIZE(ctx->supplies); i++)
+ for (i = 0; i < ARRAY_SIZE(ctx->supplies); i++) {
ctx->supplies[i].supply = regulator_names[i];
+ ctx->supplies[i].init_load_uA = regulator_enable_loads[i];
+ }
ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ctx->supplies),
ctx->supplies);
--
2.39.2
Re: [PATCH v4 2/2] drm/panel: Add driver for EDO RM69380 OLED panel
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,
Jessica Zhang
---
drivers/gpu/drm/panel/Kconfig | 12 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-raydium-rm69380.c | 344 ++
3 files changed, 357 insertions(+)
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 154f5bf82980..e2a66c21349f 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -542,6 +542,18 @@ config DRM_PANEL_RAYDIUM_RM692E5
Say Y here if you want to enable support for Raydium RM692E5-based
display panels, such as the one found in the Fairphone 5 smartphone.
+config DRM_PANEL_RAYDIUM_RM69380
+ tristate "Raydium RM69380-based DSI panel"
+ depends on OF && GPIOLIB
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for Raydium RM69380-based
+ display panels.
+
+ This panel controller can be found in the Lenovo Xiaoxin Pad Pro 2021
+ in combination with an EDO OLED panel.
+
config DRM_PANEL_RONBO_RB070D30
tristate "Ronbo Electronics RB070D30 panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 24a02655d726..e2a2807d4ef0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) +=
panel-raspberrypi-touchscreen
obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM67191) += panel-raydium-rm67191.o
obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) += panel-raydium-rm68200.o
obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM692E5) += panel-raydium-rm692e5.o
+obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM69380) += panel-raydium-rm69380.o
obj-$(CONFIG_DRM_PANEL_RONBO_RB070D30) += panel-ronbo-rb070d30.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_ATNA33XC20) += panel-samsung-atna33xc20.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_DB7430) += panel-samsung-db7430.o
diff --git a/drivers/gpu/drm/panel/panel-raydium-rm69380.c
b/drivers/gpu/drm/panel/panel-raydium-rm69380.c
new file mode 100644
index ..4dca6802faef
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-raydium-rm69380.c
@@ -0,0 +1,344 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Generated with linux-mdss-dsi-panel-driver-generator from vendor device
tree.
+ * Copyright (c) 2024 David Wronek
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+
+struct rm69380_panel {
+ struct drm_panel panel;
+ struct mipi_dsi_device *dsi[2];
+ struct regulator_bulk_data supplies[2];
+ struct gpio_desc *reset_gpio;
+};
+
+static inline
+struct rm69380_panel *to_rm69380_panel(struct drm_panel *panel)
+{
+ return container_of(panel, struct rm69380_panel, panel);
+}
+
+static void rm69380_reset(struct rm69380_panel *ctx)
+{
+ gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+ usleep_range(15000, 16000);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+ usleep_range(1, 11000);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+ msleep(30);
+}
+
+static int rm69380_on(struct rm69380_panel *ctx)
+{
+ struct mipi_dsi_device *dsi = ctx->dsi[0];
+ struct device *dev = >dev;
+ int ret;
+
+ dsi->mode_flags |= MIPI_DSI_MODE_LPM;
+ if (ctx->dsi[1])
+ ctx->dsi[1]->mode_flags |= MIPI_DSI_MODE_LPM;
+
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0xd4);
+ mipi_dsi_dcs_write_seq(dsi, 0x00, 0x80);
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0xd0);
+ mipi_dsi_dcs_write_seq(dsi, 0x48, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0x26);
+ mipi_dsi_dcs_write_seq(dsi, 0x75, 0x3f);
+ mipi_dsi_dcs_write_seq(dsi, 0x1d, 0x1a);
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, MIPI_DCS_WRITE_CONTROL_DISPLAY, 0x28);
+ mipi_dsi_dcs_write_seq(dsi, 0xc2, 0x08);
+
+ ret = mipi_dsi_dcs_set_tear_on(dsi, MIPI_DSI_DCS_TEAR_MODE_VBLANK);
+ if (ret < 0) {
+ dev_err(dev, "Failed to set tear on: %d\n", ret);
+ return ret;
+ }
+
+ ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
+ if (ret < 0) {
+ dev_err(dev, "Failed to exit sleep mode: %d\n", ret);
+ return ret;
+ }
+ msleep(20);
+
+ ret = mipi_dsi_dcs_set_display_on(dsi);
+ if (ret < 0) {
+ dev_err(dev, "Failed to set display on: %d\n", ret);
+ return ret;
+ }
+ msleep(36);
+
+ return 0;
+}
+
+static int rm69380_off(struct rm69380_panel *ctx)
+{
+
[PATCH v2 6/7] drm/msm/adreno: Redo the speedbin assignment
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
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 34
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 56 --
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 70 +++--
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 3 --
drivers/gpu/drm/msm/msm_gpu.c | 3 --
5 files changed, 57 insertions(+), 109 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index c003f970189b..eed6a2eb1731 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1704,38 +1704,6 @@ static const struct adreno_gpu_funcs funcs = {
.get_timestamp = a5xx_get_timestamp,
};
-static void check_speed_bin(struct device *dev)
-{
- struct nvmem_cell *cell;
- u32 val;
-
- /*
-* If the OPP table specifies a opp-supported-hw property then we have
-* to set something with dev_pm_opp_set_supported_hw() or the table
-* doesn't get populated so pick an arbitrary value that should
-* ensure the default frequencies are selected but not conflict with any
-* actual bins
-*/
- val = 0x80;
-
- cell = nvmem_cell_get(dev, "speed_bin");
-
- if (!IS_ERR(cell)) {
- void *buf = nvmem_cell_read(cell, NULL);
-
- if (!IS_ERR(buf)) {
- u8 bin = *((u8 *) buf);
-
- val = (1 << bin);
- kfree(buf);
- }
-
- nvmem_cell_put(cell);
- }
-
- devm_pm_opp_set_supported_hw(dev, , 1);
-}
-
struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
{
struct msm_drm_private *priv = dev->dev_private;
@@ -1763,8 +1731,6 @@ struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
a5xx_gpu->lm_leakage = 0x4E001A;
- check_speed_bin(>dev);
-
nr_rings = 4;
if (config->info->revn == 510)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 60708c23ae4c..1242697d64a7 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -2878,55 +2878,6 @@ static bool a6xx_progress(struct msm_gpu *gpu, struct
msm_ringbuffer *ring)
return progress;
}
-static u32 fuse_to_supp_hw(const struct adreno_info *info, u32 fuse)
-{
- if (!info->speedbins)
- return UINT_MAX;
-
- for (int i = 0; info->speedbins[i].fuse != SHRT_MAX; i++)
- if (info->speedbins[i].fuse == fuse)
- return BIT(info->speedbins[i].speedbin);
-
- return UINT_MAX;
-}
-
-static int a6xx_set_supported_hw(struct adreno_gpu *adreno_gpu,
-struct device *dev,
-const struct adreno_info *info)
-{
- u32 supp_hw;
- u32 speedbin;
- int ret;
-
- ret = adreno_read_speedbin(adreno_gpu, dev, );
- /*
-* -ENOENT means that the platform doesn't support speedbin which is
-* fine
-*/
- if (ret == -ENOENT) {
- return 0;
- } else if (ret) {
- dev_err_probe(dev, ret,
- "failed to read speed-bin. Some OPPs may not be
supported by hardware\n");
- return ret;
- }
-
- supp_hw = fuse_to_supp_hw(info, speedbin);
-
- if (supp_hw == UINT_MAX) {
- DRM_DEV_ERROR(dev,
- "missing support for speed-bin: %u. Some OPPs may not
be supported by hardware\n",
- speedbin);
- supp_hw = BIT(0); /* Default */
- }
-
- ret = devm_pm_opp_set_supported_hw(dev, _hw, 1);
- if (ret)
- return ret;
-
- return 0;
-}
-
static const struct adreno_gpu_funcs funcs = {
.base = {
.get_param = adreno_get_param,
@@ -3058,13 +3009,6 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
a6xx_llc_slices_init(pdev, a6xx_gpu, is_a7xx);
- ret = a6xx_set_supported_hw(adreno_gpu, >dev, config->info);
- if (ret) {
- a6xx_llc_slices_destroy(a6xx_gpu);
- kfree(a6xx_gpu);
- return ERR_PTR(ret);
- }
-
if (is_a7xx)
ret = adreno_gpu_init(dev, pdev, adreno_gpu, _a7xx, 1);
else if (adreno_has_gmu_wrapper(adreno_gpu))
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 58fd70140685..08b2f08e2a14 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -1060,8 +1060,8 @@ void adreno_gpu_ocmem_cleanup(struct
[PATCH v2 7/7] arm64: dts: qcom: sm8550: Wire up GPU speed bin & more OPPs
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(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi
b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index 5cae8d773cec..2f6842f6a5b7 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -2087,48 +2087,67 @@ zap-shader {
memory-region = <_micro_code_mem>;
};
- /* Speedbin needs more work on A740+, keep only lower
freqs */
gpu_opp_table: opp-table {
compatible = "operating-points-v2";
+ opp-71900 {
+ opp-hz = /bits/ 64 <71900>;
+ opp-level =
;
+ opp-supported-hw = <0x1>;
+ };
+
opp-68000 {
opp-hz = /bits/ 64 <68000>;
opp-level =
;
+ opp-supported-hw = <0x3>;
};
opp-61500 {
opp-hz = /bits/ 64 <61500>;
opp-level =
;
+ opp-supported-hw = <0x3>;
};
opp-55000 {
opp-hz = /bits/ 64 <55000>;
opp-level = ;
+ opp-supported-hw = <0x3>;
};
opp-47500 {
opp-hz = /bits/ 64 <47500>;
opp-level =
;
+ opp-supported-hw = <0x3>;
};
opp-40100 {
opp-hz = /bits/ 64 <40100>;
opp-level =
;
+ opp-supported-hw = <0x3>;
};
opp-34800 {
opp-hz = /bits/ 64 <34800>;
opp-level =
;
+ opp-supported-hw = <0x3>;
};
opp-29500 {
opp-hz = /bits/ 64 <29500>;
opp-level =
;
+ opp-supported-hw = <0x3>;
};
opp-22000 {
opp-hz = /bits/ 64 <22000>;
opp-level =
;
+ opp-supported-hw = <0x3>;
+ };
+
+ opp-12480 {
+ opp-hz = /bits/ 64 <12480>;
+ opp-level =
;
+ opp-supported-hw = <0x3>;
};
};
};
--
2.44.0
[PATCH v2 3/7] drm/msm/adreno: Implement SMEM-based speed bin
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 lets us match OPPs against.
Due to the product code being ignored in the context of Adreno on
production parts (as of SM8650), hardcode it to SOCINFO_PC_UNKNOWN.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 8 +++---
drivers/gpu/drm/msm/adreno/adreno_device.c | 2 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.c| 41 +++---
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 12 ++---
4 files changed, 53 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index d10323f15d40..60708c23ae4c 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -2890,13 +2890,15 @@ static u32 fuse_to_supp_hw(const struct adreno_info
*info, u32 fuse)
return UINT_MAX;
}
-static int a6xx_set_supported_hw(struct device *dev, const struct adreno_info
*info)
+static int a6xx_set_supported_hw(struct adreno_gpu *adreno_gpu,
+struct device *dev,
+const struct adreno_info *info)
{
u32 supp_hw;
u32 speedbin;
int ret;
- ret = adreno_read_speedbin(dev, );
+ ret = adreno_read_speedbin(adreno_gpu, dev, );
/*
* -ENOENT means that the platform doesn't support speedbin which is
* fine
@@ -3056,7 +3058,7 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
a6xx_llc_slices_init(pdev, a6xx_gpu, is_a7xx);
- ret = a6xx_set_supported_hw(>dev, config->info);
+ ret = a6xx_set_supported_hw(adreno_gpu, >dev, config->info);
if (ret) {
a6xx_llc_slices_destroy(a6xx_gpu);
kfree(a6xx_gpu);
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index c3703a51287b..901ef767e491 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -6,6 +6,8 @@
* Copyright (c) 2014,2017 The Linux Foundation. All rights reserved.
*/
+#include
+
#include "adreno_gpu.h"
bool hang_debug = false;
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 074fb498706f..58fd70140685 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -21,6 +21,9 @@
#include "msm_gem.h"
#include "msm_mmu.h"
+#include
+#include
+
static u64 address_space_size = 0;
MODULE_PARM_DESC(address_space_size, "Override for size of processes private
GPU address space");
module_param(address_space_size, ullong, 0600);
@@ -1057,9 +1060,39 @@ void adreno_gpu_ocmem_cleanup(struct adreno_ocmem
*adreno_ocmem)
adreno_ocmem->hdl);
}
-int adreno_read_speedbin(struct device *dev, u32 *speedbin)
+int adreno_read_speedbin(struct adreno_gpu *adreno_gpu,
+struct device *dev, u32 *fuse)
{
- return nvmem_cell_read_variable_le_u32(dev, "speed_bin", speedbin);
+ u32 fcode;
+ int ret;
+
+ /*
+* Try reading the speedbin via a nvmem cell first
+* -ENOENT means "no nvmem-cells" and essentially means "old DT" or
+* "nvmem fuse is irrelevant", simply assume it's fine.
+*/
+ ret = nvmem_cell_read_variable_le_u32(dev, "speed_bin", fuse);
+ if (!ret)
+ return 0;
+ else if (ret != -ENOENT)
+ return dev_err_probe(dev, ret, "Couldn't read the speed bin
fuse value\n");
+
+#ifdef CONFIG_QCOM_SMEM
+ /*
+* Only check the feature code - the product code only matters for
+* proto SoCs unavailable outside Qualcomm labs, as far as GPU bin
+* matching is concerned.
+*
+* Ignore EOPNOTSUPP, as not all SoCs expose this info through SMEM.
+*/
+ ret = qcom_smem_get_feature_code();
+ if (!ret)
+ *fuse = ADRENO_SKU_ID(fcode);
+ else if (ret != -EOPNOTSUPP)
+ return dev_err_probe(dev, ret, "Couldn't get feature code from
SMEM\n");
+#endif
+
+ return 0;
}
int adreno_gpu_init(struct drm_device *drm, struct platform_device *pdev,
@@ -1098,9 +1131,9 @@ int adreno_gpu_init(struct drm_device *drm, struct
platform_device *pdev,
devm_pm_opp_set_clkname(dev, "core");
}
- if (adreno_read_speedbin(dev, ) || !speedbin)
+ if (adreno_read_speedbin(adreno_gpu, dev, ) || !speedbin)
speedbin = 0x;
- adreno_gpu->speedbin = (uint16_t) (0x & speedbin);
+ adreno_gpu->speedbin = speedbin;
gpu_name = devm_kasprintf(dev, GFP_KERNEL,
[PATCH v2 5/7] drm/msm/adreno: Define A530 speed bins explicitly
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 3b631445c541..53302995fc81 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -258,6 +258,12 @@ static const struct adreno_info gpulist[] = {
ADRENO_QUIRK_FAULT_DETECT_MASK,
.init = a5xx_gpu_init,
.zapfw = "a530_zap.mdt",
+ .speedbins = ADRENO_SPEEDBINS(
+ { 0, 0 },
+ { 1, 1 },
+ { 2, 2 },
+ { 3, 3 },
+ ),
}, {
.chip_ids = ADRENO_CHIP_IDS(0x05040001),
.family = ADRENO_5XX,
--
2.44.0
[PATCH v2 4/7] drm/msm/adreno: Add speedbin data for SM8550 / A740
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 901ef767e491..3b631445c541 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -570,6 +570,11 @@ static const struct adreno_info gpulist[] = {
.zapfw = "a740_zap.mdt",
.hwcg = a740_hwcg,
.address_space_size = SZ_16G,
+ .speedbins = ADRENO_SPEEDBINS(
+ { ADRENO_SKU_ID(SOCINFO_FC_AB), 1 },
+ { ADRENO_SKU_ID(SOCINFO_FC_AC), 0 },
+ { ADRENO_SKU_ID(SOCINFO_FC_AF), 0 },
+ ),
}, {
.chip_ids = ADRENO_CHIP_IDS(0x43051401), /* "C520v2" */
.family = ADRENO_7XX_GEN3,
--
2.44.0
[PATCH v2 1/7] soc: qcom: Move some socinfo defines to the header
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
---
drivers/soc/qcom/socinfo.c | 8
include/linux/soc/qcom/socinfo.h | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
index 277c07a6603d..cf4616a468f2 100644
--- a/drivers/soc/qcom/socinfo.c
+++ b/drivers/soc/qcom/socinfo.c
@@ -21,14 +21,6 @@
#include
-/*
- * SoC version type with major number in the upper 16 bits and minor
- * number in the lower 16 bits.
- */
-#define SOCINFO_MAJOR(ver) (((ver) >> 16) & 0x)
-#define SOCINFO_MINOR(ver) ((ver) & 0x)
-#define SOCINFO_VERSION(maj, min) maj) & 0x) << 16)|((min) & 0x))
-
/* Helper macros to create soc_id table */
#define qcom_board_id(id) QCOM_ID_ ## id, __stringify(id)
#define qcom_board_id_named(id, name) QCOM_ID_ ## id, (name)
diff --git a/include/linux/soc/qcom/socinfo.h b/include/linux/soc/qcom/socinfo.h
index e78777bb0f4a..10e0a4c287f4 100644
--- a/include/linux/soc/qcom/socinfo.h
+++ b/include/linux/soc/qcom/socinfo.h
@@ -12,6 +12,14 @@
#define SMEM_SOCINFO_BUILD_ID_LENGTH 32
#define SMEM_SOCINFO_CHIP_ID_LENGTH32
+/*
+ * SoC version type with major number in the upper 16 bits and minor
+ * number in the lower 16 bits.
+ */
+#define SOCINFO_MAJOR(ver) (((ver) >> 16) & 0x)
+#define SOCINFO_MINOR(ver) ((ver) & 0x)
+#define SOCINFO_VERSION(maj, min) maj) & 0x) << 16)|((min) & 0x))
+
/* Socinfo SMEM item structure */
struct socinfo {
__le32 fmt;
--
2.44.0
[PATCH v2 2/7] soc: qcom: smem: Add a feature code getter
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
things such as Adreno. In the case of Adreno specifically, Pcode is
useless for non-prototype SoCs.
Introduce a getter for the feature code and export it.
Signed-off-by: Konrad Dybcio
---
drivers/soc/qcom/smem.c | 33 +
include/linux/soc/qcom/smem.h| 1 +
include/linux/soc/qcom/socinfo.h | 26 ++
3 files changed, 60 insertions(+)
diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
index 7191fa0c087f..29e708789eec 100644
--- a/drivers/soc/qcom/smem.c
+++ b/drivers/soc/qcom/smem.c
@@ -795,6 +795,39 @@ int qcom_smem_get_soc_id(u32 *id)
}
EXPORT_SYMBOL_GPL(qcom_smem_get_soc_id);
+/**
+ * qcom_smem_get_feature_code() - return the feature code
+ * @code: On success, return the feature code here.
+ *
+ * Look up the feature code identifier from SMEM and return it.
+ *
+ * Return: 0 on success, negative errno on failure.
+ */
+int qcom_smem_get_feature_code(u32 *code)
+{
+ struct socinfo *info;
+ u32 raw_code;
+
+ info = qcom_smem_get(QCOM_SMEM_HOST_ANY, SMEM_HW_SW_BUILD_ID, NULL);
+ if (IS_ERR(info))
+ return PTR_ERR(info);
+
+ /* This only makes sense for socinfo >= 16 */
+ if (__le32_to_cpu(info->fmt) < SOCINFO_VERSION(0, 16))
+ return -EOPNOTSUPP;
+
+ raw_code = __le32_to_cpu(info->feature_code);
+
+ /* Ensure the value makes sense */
+ if (raw_code >= SOCINFO_FC_INT_MAX)
+ raw_code = SOCINFO_FC_UNKNOWN;
+
+ *code = raw_code;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(qcom_smem_get_feature_code);
+
static int qcom_smem_get_sbl_version(struct qcom_smem *smem)
{
struct smem_header *header;
diff --git a/include/linux/soc/qcom/smem.h b/include/linux/soc/qcom/smem.h
index a36a3b9d4929..0943bf419e11 100644
--- a/include/linux/soc/qcom/smem.h
+++ b/include/linux/soc/qcom/smem.h
@@ -13,5 +13,6 @@ int qcom_smem_get_free_space(unsigned host);
phys_addr_t qcom_smem_virt_to_phys(void *p);
int qcom_smem_get_soc_id(u32 *id);
+int qcom_smem_get_feature_code(u32 *code);
#endif
diff --git a/include/linux/soc/qcom/socinfo.h b/include/linux/soc/qcom/socinfo.h
index 10e0a4c287f4..52439f48428f 100644
--- a/include/linux/soc/qcom/socinfo.h
+++ b/include/linux/soc/qcom/socinfo.h
@@ -3,6 +3,8 @@
#ifndef __QCOM_SOCINFO_H__
#define __QCOM_SOCINFO_H__
+#include
+
/*
* SMEM item id, used to acquire handles to respective
* SMEM region.
@@ -82,4 +84,28 @@ struct socinfo {
__le32 boot_core;
};
+/* Internal feature codes */
+enum qcom_socinfo_feature_code {
+ /* External feature codes */
+ SOCINFO_FC_UNKNOWN = 0x0,
+ SOCINFO_FC_AA,
+ SOCINFO_FC_AB,
+ SOCINFO_FC_AC,
+ SOCINFO_FC_AD,
+ SOCINFO_FC_AE,
+ SOCINFO_FC_AF,
+ SOCINFO_FC_AG,
+ SOCINFO_FC_AH,
+};
+
+/* Internal feature codes */
+/* Valid values: 0 <= n <= 0xf */
+#define SOCINFO_FC_Yn(n) (0xf1 + n)
+#define SOCINFO_FC_INT_MAX SOCINFO_FC_Yn(0x10)
+
+/* Product codes */
+#define SOCINFO_PC_UNKNOWN 0
+#define SOCINFO_PCn(n) (n + 1)
+#define SOCINFO_PC_RESERVE (BIT(31) - 1)
+
#endif
--
2.44.0
[PATCH v2 0/7] Add SMEM-based speedbin matching
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 land this in the upcoming cycle. FWIW I preferred the fuses myself.. Patches 5 and 6 culd be omitted, but I'd reaaally like them to land and soon at that. This would enable even more overdue and necessary cleanups/feature prepwork sooner than later. The dt patch can only be picked if the drm patches are there. Depends on: https://lore.kernel.org/linux-arm-msm/20240412-topic-adreno_nullptr_supphw-v1-1-eb30a1c12...@linaro.org/ Signed-off-by: Konrad Dybcio --- Changes in v2: - Separate moving existing and adding new defines - Fix kerneldoc copypasta - Remove some wrong comments and defines - Remove assumed "max" values for PCs and external FCs - Improve some commit messages - Return -EOPNOTSUPP instead of -EINVAL when calling p/fcode getters on socinfo older than v16 - Drop pcode getters and evaluation (doesn't matter for Adreno on non-proto SoCs, might matter in the future or w/ other peripherals) - Rework the speedbin logic to be hopefully saner (accidental support for A2xx-A4xx, I guess!) - Reorder some existing function calls to avoid crazy nullptrs - ""fix"" the smem dependency inconvenience - Link to v1: https://lore.kernel.org/r/20240405-topic-smem_speedbin-v1-0-ce2b86425...@linaro.org --- Konrad Dybcio (7): soc: qcom: Move some socinfo defines to the header soc: qcom: smem: Add a feature code getter drm/msm/adreno: Implement SMEM-based speed bin drm/msm/adreno: Add speedbin data for SM8550 / A740 drm/msm/adreno: Define A530 speed bins explicitly drm/msm/adreno: Redo the speedbin assignment arm64: dts: qcom: sm8550: Wire up GPU speed bin & more OPPs arch/arm64/boot/dts/qcom/sm8550.dtsi | 21 +- drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 34 -- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 54 --- drivers/gpu/drm/msm/adreno/adreno_device.c | 13 drivers/gpu/drm/msm/adreno/adreno_gpu.c| 103 + drivers/gpu/drm/msm/adreno/adreno_gpu.h| 11 +-- drivers/gpu/drm/msm/msm_gpu.c | 3 - drivers/soc/qcom/smem.c| 33 + drivers/soc/qcom/socinfo.c | 8 --- include/linux/soc/qcom/smem.h | 1 + include/linux/soc/qcom/socinfo.h | 34 ++ 11 files changed, 198 insertions(+), 117 deletions(-) --- base-commit: b13768266bf3a129adf5bbd0bad28e23a74329a2 change-id: 20240404-topic-smem_speedbin-8deecd0bef0e Best regards, -- Konrad Dybcio
Re: [PATCH v2 1/4] drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check
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 supported outside of HDMI, > there is no reason to use RGB when the display > reports drm_mode_is_420_only() even on a non HDMI connection. > > This patch also moves both checks in the same if-case. This eliminates an > extra else-if-case. > > Signed-off-by: Werner Sembach > Signed-off-by: Andri Yngvason > Tested-by: Andri Yngvason > --- > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 +- > 1 file changed, 1 insertion(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > index f6575d7dee971..cc4d1f7f97b98 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > @@ -5575,11 +5575,7 @@ static void > fill_stream_properties_from_drm_display_mode( > timing_out->v_border_bottom = 0; > /* TODO: un-hardcode */ > if (drm_mode_is_420_only(info, mode_in) > - && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A) > - timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420; > - else if (drm_mode_is_420_also(info, mode_in) > - && aconnector > - && aconnector->force_yuv420_output) > + || (drm_mode_is_420_also(info, mode_in) && > aconnector->force_yuv420_output)) We need to keep the && aconnector NULL check here, otherwise writeback connectors will blow up. Harry > timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420; > else if ((connector->display_info.color_formats & > DRM_COLOR_FORMAT_YCBCR444) > && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
Re: [PATCH v2 2/4] drm/uAPI: Add "force color format" drm property as setting for userspace
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 are:
> - auto (default/current behaviour)
> - rgb
> - ycbcr444
> - ycbcr422 (supported by neither amdgpu or i915)
If no driver uses this should we expose this now? I would
prefer to leave ycbcr422 out of this until we have a driver
that actually uses it.
I've seen too many properties with ever possible value defined
but they're not used by any (open) userspace and then become
the object of intense discussion on how they should work. I
doubt that this would happen here, but I still feel a slight
aversion to defining things that no open userspace can use at
this point.
I agree with all of Sebastian and Pekka's comments elsewhere in
this thread, in particular with Sebastian's comments to not
advertise color formats that a driver can't support. See this
patch for how I implemented something similar for Colorspace
c265f340eaa8 ("drm/connector: Allow drivers to pass list of supported
colorspaces")
Harry
> - ycbcr420
>
> In theory the auto option should choose the best available option for the
> current setup, but because of bad internal conversion some monitors look
> better with rgb and some with ycbcr444.
>
> Also, because of bad shielded connectors and/or cables, it might be
> preferable to use the less bandwidth heavy ycbcr422 and ycbcr420 formats
> for a signal that is less susceptible to interference.
>
> In the future, automatic color calibration for screens might also depend on
> this option being available.
>
> Signed-off-by: Werner Sembach
> Signed-off-by: Andri Yngvason
> Tested-by: Andri Yngvason
> ---
>
> Changes in v2:
> - Renamed to "force color format" from "preferred color format"
> - Removed Reported-by pointing to invalid email address
>
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 4 +++
> drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
> drivers/gpu/drm/drm_connector.c | 48 +
> include/drm/drm_connector.h | 16 ++
> 4 files changed, 72 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 39ef0a6addeba..1dabd164c4f09 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -707,6 +707,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> if (old_connector_state->max_requested_bpc !=
> new_connector_state->max_requested_bpc)
> new_crtc_state->connectors_changed = true;
> +
> + if (old_connector_state->force_color_format !=
> + new_connector_state->force_color_format)
> + new_crtc_state->connectors_changed = true;
> }
>
> if (funcs->atomic_check)
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 29d4940188d49..e45949bf4615f 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -776,6 +776,8 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> state->max_requested_bpc = val;
> } else if (property == connector->privacy_screen_sw_state_property) {
> state->privacy_screen_sw_state = val;
> + } else if (property == connector->force_color_format_property) {
> + state->force_color_format = val;
> } else if (connector->funcs->atomic_set_property) {
> return connector->funcs->atomic_set_property(connector,
> state, property, val);
> @@ -859,6 +861,8 @@ drm_atomic_connector_get_property(struct drm_connector
> *connector,
> *val = state->max_requested_bpc;
> } else if (property == connector->privacy_screen_sw_state_property) {
> *val = state->privacy_screen_sw_state;
> + } else if (property == connector->force_color_format_property) {
> + *val = state->force_color_format;
> } else if (connector->funcs->atomic_get_property) {
> return connector->funcs->atomic_get_property(connector,
> state, property, val);
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b0516505f7ae9..e0535e58b4535 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1061,6 +1061,14 @@ static const struct drm_prop_enum_list
> drm_dp_subconnector_enum_list[] = {
> { DRM_MODE_SUBCONNECTOR_Native, "Native"}, /* DP */
> };
>
> +static const struct drm_prop_enum_list drm_force_color_format_enum_list[] = {
> + { 0, "auto" },
> + {
[pull] amdgpu, amdkfd, radeon drm-fixes-6.9
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 changes up to 781d41fed19caf900c8405064676813dc9921d32: drm/radeon: silence UBSAN warning (v3) (2024-04-17 11:50:43 -0400) amd-drm-fixes-6.9-2024-04-17: amdgpu: - Fix invalid resource->start check - USB-C DSC fix - Fix a potential UAF in VA IOCTL - Fix visible VRAM handling during faults amdkfd: - Fix memory leak in create_process failure radeon: - Silence UBSAN warnings from variable sized arrays Alex Deucher (3): Revert "drm/amd/display: fix USB-C flag update after enc10 feature init" drm/radeon: make -fstrict-flex-arrays=3 happy drm/radeon: silence UBSAN warning (v3) Christian König (2): drm/amdgpu: remove invalid resource->start check v2 drm/amdgpu: fix visible VRAM handling during faults Felix Kuehling (1): drm/amdkfd: Fix memory leak in create_process failure xinhui pan (1): drm/amdgpu: validate the parameters of bo mapping operations more clearly drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 22 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 22 --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 65 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h| 3 + drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 72 ++ drivers/gpu/drm/amd/amdkfd/kfd_process.c | 4 +- .../amd/display/dc/dcn32/dcn32_dio_link_encoder.c | 8 +-- .../amd/display/dc/dcn35/dcn35_dio_link_encoder.c | 4 +- drivers/gpu/drm/radeon/pptable.h | 10 +-- drivers/gpu/drm/radeon/radeon_atombios.c | 8 ++- 11 files changed, 117 insertions(+), 103 deletions(-)
Re: [PATCH] staging: fbtft Removed redundant parentheses
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: fbtft Removed redundant
> > parentheses on
> > logical expr
> >
> > Adhere to Linux Kernel coding style removed redundant parentheses,
> > multiple blank lines and indentation alignment.
> >
> > Reported by checkpatch.pl
> >
> > --
> > fb_ili9320.c
> >
> > + if ((devcode != 0x) && (devcode != 0x9320))
> >
> > --
> > fb_ra8875.c
> >
> > CHECK: Unnecessary parentheses around 'par->info->var.xres == 320'
> > + if ((par->info->var.xres == 320) && (par->info->var.yres ==
> > 240)) {
> >
> > --
> > fb_ssd1325.c
> >
> > CHECK: Please don't use multiple blank lines
> > --
> >
> > fb_tinylcd.c - indentation adjustment
> >
> > -
> > fbtft-bus.c
> >
> > CHECK: Unnecessary parentheses around 'par->spi->bits_per_word ==
> > 8'
> >
> > --
> > fbtft-core.c
> >
> > CHECK: Please don't use multiple blank lines
> >
> > CHECK: Unnecessary parentheses around '!txbuflen'
> >
> > CHECK: Please don't use multiple blank lines
> > --
> >
> > Signed-off-by: Ashok Kumar
> > ---
> > drivers/staging/fbtft/fb_ili9320.c | 2 +-
> > drivers/staging/fbtft/fb_ra8875.c | 8
> > drivers/staging/fbtft/fb_ssd1325.c | 2 --
> > drivers/staging/fbtft/fb_tinylcd.c | 2 +-
> > drivers/staging/fbtft/fbtft-bus.c | 6 +++---
> > drivers/staging/fbtft/fbtft-core.c | 7 +--
> > 6 files changed, 10 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/staging/fbtft/fb_ili9320.c
> > b/drivers/staging/fbtft/fb_ili9320.c
> > index 0be7c2d51548..409b54cc562e 100644
> > --- a/drivers/staging/fbtft/fb_ili9320.c
> > +++ b/drivers/staging/fbtft/fb_ili9320.c
> > @@ -37,7 +37,7 @@ static int init_display(struct fbtft_par *par)
> > devcode = read_devicecode(par);
> > fbtft_par_dbg(DEBUG_INIT_DISPLAY, par, "Device code:
> > 0x%04X\n",
> > devcode);
> > - if ((devcode != 0x) && (devcode != 0x9320))
> > + if (devcode != 0x && devcode != 0x9320)
> > dev_warn(par->info->device,
> > "Unrecognized Device code: 0x%04X
> > (expected
> > 0x9320)\n",
> > devcode);
> > diff --git a/drivers/staging/fbtft/fb_ra8875.c
> > b/drivers/staging/fbtft/fb_ra8875.c
> > index 398bdbf53c9a..4b79fb48c5f0 100644
> > --- a/drivers/staging/fbtft/fb_ra8875.c
> > +++ b/drivers/staging/fbtft/fb_ra8875.c
> > @@ -50,7 +50,7 @@ static int init_display(struct fbtft_par *par)
> >
> > par->fbtftops.reset(par);
> >
> > - if ((par->info->var.xres == 320) && (par->info->var.yres ==
> > 240)) {
> > + if (par->info->var.xres == 320 && par->info->var.yres ==
> > 240)
> > {
> > /* PLL clock frequency */
> > write_reg(par, 0x88, 0x0A);
> > write_reg(par, 0x89, 0x02);
> > @@ -74,8 +74,8 @@ static int init_display(struct fbtft_par *par)
> > write_reg(par, 0x1D, 0x0E);
> > write_reg(par, 0x1E, 0x00);
> > write_reg(par, 0x1F, 0x02);
> > - } else if ((par->info->var.xres == 480) &&
> > - (par->info->var.yres == 272)) {
> > + } else if (par->info->var.xres == 480 &&
> > + par->info->var.yres == 272) {
> > /* PLL clock frequency */
> > write_reg(par, 0x88, 0x0A);
> > write_reg(par, 0x89, 0x02);
> > @@ -111,7 +111,7 @@ static int init_display(struct fbtft_par *par)
> > write_reg(par, 0x04, 0x01);
> > mdelay(1);
> > /* horizontal settings */
> > - write_reg(par, 0x14, 0x4F);
> > +write_reg(par, 0x14, 0x4F);
> > write_reg(par, 0x15, 0x05);
> > write_reg(par, 0x16, 0x0F);
> > write_reg(par, 0x17, 0x01);
> > diff --git a/drivers/staging/fbtft/fb_ssd1325.c
> > b/drivers/staging/fbtft/fb_ssd1325.c
> > index 796a2ac3e194..69aa808c7e23 100644
> > --- a/drivers/staging/fbtft/fb_ssd1325.c
> > +++ b/drivers/staging/fbtft/fb_ssd1325.c
> > @@ -109,8 +109,6 @@ static int set_gamma(struct fbtft_par *par, u32
> > *curves)
> > {
> > int i;
> >
> > - fbtft_par_dbg(DEBUG_INIT_DISPLAY, par, "%s()\n", __func__);
> > -
> > for (i = 0; i < GAMMA_LEN; i++) {
> > if (i > 0 && curves[i] < 1) {
> > dev_err(par->info->device,
> > diff --git a/drivers/staging/fbtft/fb_tinylcd.c
> > b/drivers/staging/fbtft/fb_tinylcd.c
> > index 9469248f2c50..60cda57bcb33 100644
> > --- a/drivers/staging/fbtft/fb_tinylcd.c
> > +++ b/drivers/staging/fbtft/fb_tinylcd.c
> > @@ -38,7 +38,7 @@ static int init_display(struct fbtft_par *par)
> > write_reg(par, 0xE5, 0x00);
> >
[linux-next:master] BUILD REGRESSION 4eab358930711bbeb85bf5ee267d0d42d3394c2c
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://lore.kernel.org/oe-kbuild-all/202404171745.zd13ydca-...@intel.com https://lore.kernel.org/oe-kbuild-all/202404172024.abf4kjuo-...@intel.com Error/Warning: (recently discovered and may have been fixed) arch/xtensa/include/asm/irqflags.h:47:(.text+0xf5c): dangerous relocation: windowed longcall crosses 1GB boundary; return may fail: (.xiptext+0x210) mm/page_table_check.c:192:17: error: use of undeclared identifier 'SWP_DEVICE_EXCLUSIVE_WRITE' mm/page_table_check.c:192:24: error: 'SWP_DEVICE_EXCLUSIVE_WRITE' undeclared (first use in this function) mm/page_table_check.c:193:14: error: use of undeclared identifier 'SWP_MIGRATION_WRITE' mm/page_table_check.c:194:1: warning: control reaches end of non-void function [-Wreturn-type] xtensa-linux-ld: clk-cv18xx-pll.c:(.text+0x2f8): undefined reference to `__udivdi3' xtensa-linux-ld: clk-cv18xx-pll.c:(.text+0x6c8): undefined reference to `__umoddi3' Unverified Error/Warning (likely false positive, please contact us if interested): fs/9p/vfs_inode.c:513 v9fs_remove() error: uninitialized symbol 'v9fid'. Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-allyesconfig | |-- drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and | `-- drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size |-- alpha-randconfig-r081-20240417 | `-- fs-9p-vfs_inode.c-v9fs_remove()-error:uninitialized-symbol-v9fid-. |-- arc-allmodconfig | `-- arch-arc-include-asm-cmpxchg.h:error:implicit-declaration-of-function-cmpxchg_emu_u8 |-- arc-allnoconfig | `-- arch-arc-include-asm-cmpxchg.h:error:implicit-declaration-of-function-cmpxchg_emu_u8 |-- arc-allyesconfig | `-- arch-arc-include-asm-cmpxchg.h:error:implicit-declaration-of-function-cmpxchg_emu_u8 |-- arc-defconfig | `-- arch-arc-include-asm-cmpxchg.h:error:implicit-declaration-of-function-cmpxchg_emu_u8 |-- arc-randconfig-001-20240417 | `-- arch-arc-include-asm-cmpxchg.h:error:implicit-declaration-of-function-cmpxchg_emu_u8 |-- arc-randconfig-002-20240417 | `-- arch-arc-include-asm-cmpxchg.h:error:implicit-declaration-of-function-cmpxchg_emu_u8 |-- arc-randconfig-r112-20240417 | `-- arch-arc-include-asm-cmpxchg.h:error:implicit-declaration-of-function-cmpxchg_emu_u8 |-- arm-allmodconfig | |-- drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and | `-- drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size |-- arm-allyesconfig | |-- drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and | `-- drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size |-- arm-randconfig-004-20240417 | `-- clk-cv18xx-pll.c:(.text):undefined-reference-to-__aeabi_uldivmod |-- csky-allmodconfig | |-- drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and | `-- drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size |-- csky-allyesconfig | |-- drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and | `-- drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size |-- i386-randconfig-003-20240417 | |-- drivers-net-netdevsim-netdev.c:(.text):undefined-reference-to-page_pool_create | `-- include-net-page_pool-helpers.h:(.text):undefined-reference-to-page_pool_alloc_pages |-- loongarch-allmodconfig | |-- drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and | `-- drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size |-- loongarch-allyesconfig | |-- drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and | `-- drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size |-- microblaze-allmodconfig | |-- drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between
Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
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 12, 2024 at 11:08 AM Pekka Paalanen wrote: On Fri, 12 Apr 2024 10:28:52 -0400 Leo Li wrote: On 2024-04-12 04:03, Pekka Paalanen wrote: On Thu, 11 Apr 2024 16:33:57 -0400 Leo Li wrote: ... That begs the question of what can be nailed down and what can left to independent implementation. I guess things like which plane should be enabled first (PRIMARY), and how zpos should be interpreted (overlay, underlay, mixed) can be defined. How to handle atomic test failures could be as well. What room is there for the interpretation of zpos values? I thought they are unambiguous already: only the relative numerical order matters, and that uniquely defines the KMS plane ordering. The zpos value of the PRIMARY plane relative to OVERLAYS, for example, as a way for vendors to communicate overlay, underlay, or mixed-arrangement support. I don't think allowing OVERLAYs to be placed under the PRIMARY is currently documented as a way to support underlay. I always thought it's obvious that the zpos numbers dictate the plane order without any other rules. After all, we have the universal planes concept, where the plane type is only informational to aid heuristics rather than defining anything. Only if the zpos property does not exist, the plane types would come into play. Of course, if there actually exists userspace that fails if zpos allows an overlay type plane to be placed below primary, or fails if primary zpos is not zero, then DRM needs a new client cap. Right, it wasn't immediately clear to me that the API allowed placement of things beneath the PRIMARY. But reading the docs for drm_plane_create_zpos*, there's nothing that forbids it. libliftoff for example, assumes that the PRIMARY has the lowest zpos. So underlay arrangements will use an OVERLAY for the scanout plane, and the PRIMARY for the underlay view. That's totally ok. It works, right? Plane type does not matter if the KMS driver accepts the configuration. What is a "scanout plane"? Aren't all KMS planes by definition scanout planes? Pardon my terminology, I thought the scanout plane was where weston rendered non-offloadable surfaces to. I guess it's more correct to call it the "render plane". On weston, it seems to be always assigned to the PRIMARY. The assignment restriction is just technical design debt. It is limiting. There is no other good reason for it, than when lighting up a CRTC for the first time, Weston should do it with the renderer FB only, on the plane that is most likely to succeed i.e. PRIMARY. After the CRTC is lit, there should be no built-in limitations in what can go where. The reason for this is that if a CRTC can be activated, it must always be able to show the renderer FB without incurring a modeset. This is important for ensuring that the fallback compositing (renderer) is always possible. So we start with that configuration, and everything else is optional bonus. Genuinely curious - What exactly is limiting with keeping the renderer FB on PRIMARY? IOW, what is the additional benefit of placing the renderer FB on something other than PRIMARY? The limitations come from a combination of hardware limitations. Perhaps zpos is not mutable, or maybe other planes cannot arbitrarily move between above and below the primary. This reduces the number of possible configurations, which might cause off-loading to fail. I think older hardware has more of these arbitrary restrictions. I see. I was thinking that drivers can do under-the-hood stuff to present a mutable zpos to clients, even if their hardware planes cannot be arbitrarily rearranged, by mapping the PRIMARY to a different hardware plane. But not all planes have the same function, so this sounds more complicated than helpful. For libliftoff, using OVERLAYs as the render plane and PRIMARY as the underlay plane would work. But I think keeping the render plane on PRIMARY (a la weston) makes underlay arrangements easier to allocate, and would be nice to incorporate into a shared algorithm. If zpos exists, I don't think such limitation is a good idea. It will just limit the possible configurations for no reason. With zpos, the KMS plane type should be irrelevant for their z-ordering. Underlay vs. overlay completely loses its meaning at the KMS level. Right, the plane types loose their meanings. But at least with the way libliftoff builds the plane arrangement, where we first allocate the renderer fb matters. libliftoff incrementally builds the atomic state by adding a single plane to the atomic state, then testing it. It essentially does a depth-first-search of all possible arrangements, pruning the search on atomic test
Re: [PATCH v2 12/18] dt-bindings: pwm: mediatek,pwm-disp: add compatible for mt8365 SoC
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 > --- > Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH v2 10/18] dt-bindings: display: mediatek: rdma: add compatible for MT8365 SoC
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 changed, 1 insertion(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH v2 09/18] dt-bindings: display: mediatek: ovl: add compatible for MT8365 SoC
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 insertion(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH v2 08/18] dt-bindings: display: mediatek: gamma: add compatible for MT8365 SoC
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 insertion(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH v2 06/18] dt-bindings: display: mediatek: dpi: add power-domains property
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. > > Signed-off-by: Fabien Parent > Signed-off-by: Alexandre Mergnat > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml | 5 > + > 1 file changed, 5 insertions(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH v2 05/18] dt-bindings: display: mediatek: dsi: add compatible for MT8365 SoC
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 changed, 1 insertion(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH v2 04/18] dt-bindings: display: mediatek: dither: add compatible for MT8365 SoC
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 insertion(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH v2 03/18] dt-bindings: display: mediatek: color: add compatible for MT8365 SoC
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 insertion(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH v2 01/18] dt-bindings: display: mediatek: aal: add compatible for MT8365 SoC
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 changed, 1 insertion(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH v2 02/18] dt-bindings: display: mediatek: ccorr: add compatible for MT8365 SoC
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 file changed, 3 insertions(+) > Acked-by: Rob Herring (Arm)
[PATCH v2 2/2] gpu: ipu-v3: pre: add dynamic buffer layout reconfiguration
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 reconfiguration of the buffer layout from
one frame to another. As switching between (super-)tiled and linear
prefetch needs to touch the CTRL register make sure to do the
reconfiguration inside the safe window.
Signed-off-by: Lucas Stach
---
v2:
- move modifier configuration into separate function
- move safe window update to occur after flip has been queued
---
drivers/gpu/ipu-v3/ipu-pre.c | 89
drivers/gpu/ipu-v3/ipu-prg.c | 2 +-
drivers/gpu/ipu-v3/ipu-prv.h | 2 +-
3 files changed, 63 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-pre.c b/drivers/gpu/ipu-v3/ipu-pre.c
index 0d4e882fe8f1..8a47c3d8abda 100644
--- a/drivers/gpu/ipu-v3/ipu-pre.c
+++ b/drivers/gpu/ipu-v3/ipu-pre.c
@@ -99,8 +99,12 @@ struct ipu_pre {
struct {
boolin_use;
+ uint64_tmodifier;
+ unsigned intheight;
unsigned intsafe_window_end;
unsigned intbufaddr;
+ u32 ctrl;
+ u8 cpp;
} cur;
};
@@ -165,6 +169,40 @@ void ipu_pre_put(struct ipu_pre *pre)
pre->cur.in_use = false;
}
+static inline void
+ipu_pre_update_safe_window(struct ipu_pre *pre)
+{
+ if (pre->cur.modifier == DRM_FORMAT_MOD_LINEAR)
+ pre->cur.safe_window_end = pre->cur.height - 2;
+ else
+ pre->cur.safe_window_end = DIV_ROUND_UP(pre->cur.height, 4) - 1;
+}
+
+static void
+ipu_pre_configure_modifier(struct ipu_pre *pre, uint64_t modifier)
+{
+ u32 val;
+
+ val = readl(pre->regs + IPU_PRE_TPR_CTRL);
+ val &= ~IPU_PRE_TPR_CTRL_TILE_FORMAT_MASK;
+ if (modifier != DRM_FORMAT_MOD_LINEAR) {
+ /* only support single buffer formats for now */
+ val |= IPU_PRE_TPR_CTRL_TILE_FORMAT_SINGLE_BUF;
+ if (modifier == DRM_FORMAT_MOD_VIVANTE_SUPER_TILED)
+ val |= IPU_PRE_TPR_CTRL_TILE_FORMAT_SUPER_TILED;
+ if (pre->cur.cpp == 2)
+ val |= IPU_PRE_TPR_CTRL_TILE_FORMAT_16_BIT;
+ }
+ writel(val, pre->regs + IPU_PRE_TPR_CTRL);
+
+ if (modifier == DRM_FORMAT_MOD_LINEAR)
+ pre->cur.ctrl &= ~IPU_PRE_CTRL_BLOCK_EN;
+ else
+ pre->cur.ctrl |= IPU_PRE_CTRL_BLOCK_EN;
+
+ pre->cur.modifier = modifier;
+}
+
void ipu_pre_configure(struct ipu_pre *pre, unsigned int width,
unsigned int height, unsigned int stride, u32 format,
uint64_t modifier, unsigned int bufaddr)
@@ -173,15 +211,16 @@ void ipu_pre_configure(struct ipu_pre *pre, unsigned int
width,
u32 active_bpp = info->cpp[0] >> 1;
u32 val;
+ pre->cur.bufaddr = bufaddr;
+ pre->cur.height = height;
+ pre->cur.cpp = info->cpp[0];
+ pre->cur.ctrl = readl(pre->regs + IPU_PRE_CTRL);
+
/* calculate safe window for ctrl register updates */
- if (modifier == DRM_FORMAT_MOD_LINEAR)
- pre->cur.safe_window_end = height - 2;
- else
- pre->cur.safe_window_end = DIV_ROUND_UP(height, 4) - 1;
+ ipu_pre_update_safe_window(pre);
writel(bufaddr, pre->regs + IPU_PRE_CUR_BUF);
writel(bufaddr, pre->regs + IPU_PRE_NEXT_BUF);
- pre->cur.bufaddr = bufaddr;
val = IPU_PRE_PREF_ENG_CTRL_INPUT_PIXEL_FORMAT(0) |
IPU_PRE_PREF_ENG_CTRL_INPUT_ACTIVE_BPP(active_bpp) |
@@ -211,40 +250,30 @@ void ipu_pre_configure(struct ipu_pre *pre, unsigned int
width,
writel(pre->buffer_paddr, pre->regs + IPU_PRE_STORE_ENG_ADDR);
- val = readl(pre->regs + IPU_PRE_TPR_CTRL);
- val &= ~IPU_PRE_TPR_CTRL_TILE_FORMAT_MASK;
- if (modifier != DRM_FORMAT_MOD_LINEAR) {
- /* only support single buffer formats for now */
- val |= IPU_PRE_TPR_CTRL_TILE_FORMAT_SINGLE_BUF;
- if (modifier == DRM_FORMAT_MOD_VIVANTE_SUPER_TILED)
- val |= IPU_PRE_TPR_CTRL_TILE_FORMAT_SUPER_TILED;
- if (info->cpp[0] == 2)
- val |= IPU_PRE_TPR_CTRL_TILE_FORMAT_16_BIT;
- }
- writel(val, pre->regs + IPU_PRE_TPR_CTRL);
+ ipu_pre_configure_modifier(pre, modifier);
- val = readl(pre->regs + IPU_PRE_CTRL);
- val |= IPU_PRE_CTRL_EN_REPEAT | IPU_PRE_CTRL_ENABLE |
- IPU_PRE_CTRL_SDW_UPDATE;
- if (modifier == DRM_FORMAT_MOD_LINEAR)
- val &= ~IPU_PRE_CTRL_BLOCK_EN;
- else
- val |= IPU_PRE_CTRL_BLOCK_EN;
- writel(val, pre->regs + IPU_PRE_CTRL);
+ pre->cur.ctrl |= IPU_PRE_CTRL_EN_REPEAT |
[PATCH v2 1/2] gpu: ipu-v3: pre: move state into struct
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 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-pre.c b/drivers/gpu/ipu-v3/ipu-pre.c
index aef984a43190..0d4e882fe8f1 100644
--- a/drivers/gpu/ipu-v3/ipu-pre.c
+++ b/drivers/gpu/ipu-v3/ipu-pre.c
@@ -96,9 +96,12 @@ struct ipu_pre {
dma_addr_t buffer_paddr;
void*buffer_virt;
- boolin_use;
- unsigned intsafe_window_end;
- unsigned intlast_bufaddr;
+
+ struct {
+ boolin_use;
+ unsigned intsafe_window_end;
+ unsigned intbufaddr;
+ } cur;
};
static DEFINE_MUTEX(ipu_pre_list_mutex);
@@ -138,7 +141,7 @@ int ipu_pre_get(struct ipu_pre *pre)
{
u32 val;
- if (pre->in_use)
+ if (pre->cur.in_use)
return -EBUSY;
/* first get the engine out of reset and remove clock gating */
@@ -151,7 +154,7 @@ int ipu_pre_get(struct ipu_pre *pre)
IPU_PRE_CTRL_SDW_UPDATE;
writel(val, pre->regs + IPU_PRE_CTRL);
- pre->in_use = true;
+ pre->cur.in_use = true;
return 0;
}
@@ -159,7 +162,7 @@ void ipu_pre_put(struct ipu_pre *pre)
{
writel(IPU_PRE_CTRL_SFTRST, pre->regs + IPU_PRE_CTRL);
- pre->in_use = false;
+ pre->cur.in_use = false;
}
void ipu_pre_configure(struct ipu_pre *pre, unsigned int width,
@@ -172,13 +175,13 @@ void ipu_pre_configure(struct ipu_pre *pre, unsigned int
width,
/* calculate safe window for ctrl register updates */
if (modifier == DRM_FORMAT_MOD_LINEAR)
- pre->safe_window_end = height - 2;
+ pre->cur.safe_window_end = height - 2;
else
- pre->safe_window_end = DIV_ROUND_UP(height, 4) - 1;
+ pre->cur.safe_window_end = DIV_ROUND_UP(height, 4) - 1;
writel(bufaddr, pre->regs + IPU_PRE_CUR_BUF);
writel(bufaddr, pre->regs + IPU_PRE_NEXT_BUF);
- pre->last_bufaddr = bufaddr;
+ pre->cur.bufaddr = bufaddr;
val = IPU_PRE_PREF_ENG_CTRL_INPUT_PIXEL_FORMAT(0) |
IPU_PRE_PREF_ENG_CTRL_INPUT_ACTIVE_BPP(active_bpp) |
@@ -236,11 +239,11 @@ void ipu_pre_update(struct ipu_pre *pre, unsigned int
bufaddr)
unsigned short current_yblock;
u32 val;
- if (bufaddr == pre->last_bufaddr)
+ if (bufaddr == pre->cur.bufaddr)
return;
writel(bufaddr, pre->regs + IPU_PRE_NEXT_BUF);
- pre->last_bufaddr = bufaddr;
+ pre->cur.bufaddr = bufaddr;
do {
if (time_after(jiffies, timeout)) {
@@ -252,7 +255,7 @@ void ipu_pre_update(struct ipu_pre *pre, unsigned int
bufaddr)
current_yblock =
(val >> IPU_PRE_STORE_ENG_STATUS_STORE_BLOCK_Y_SHIFT) &
IPU_PRE_STORE_ENG_STATUS_STORE_BLOCK_Y_MASK;
- } while (current_yblock == 0 || current_yblock >= pre->safe_window_end);
+ } while (current_yblock == 0 || current_yblock >=
pre->cur.safe_window_end);
writel(IPU_PRE_CTRL_SDW_UPDATE, pre->regs + IPU_PRE_CTRL_SET);
}
--
2.39.2
Re: [PATCH v4 1/2] dt-bindings: display: panel: Add Raydium RM69380
On Wed, 17 Apr 2024 18:29:33 +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 schema")
> ---
> .../bindings/display/panel/raydium,rm69380.yaml| 89
> ++
> 1 file changed, 89 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml:
Error in referenced schema matching $id:
http://devicetree.org/schemas/display/panel/panel-common-dual.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/raydium,rm69380.example.dtb:
panel@0: False schema does not allow {'compatible':
['lenovo,j716f-edo-rm69380', 'raydium,rm69380'], 'reg': [[0]], 'avdd-supply':
[[4294967295]], 'vddio-supply': [[4294967295]], 'reset-gpios': [[4294967295,
75, 1]], 'ports': {'#address-cells': [[1]], '#size-cells': [[0]], 'port@0':
{'reg': [[0]], 'endpoint': {'remote-endpoint': [[4294967295]]}}, 'port@1':
{'reg': [[1]], 'endpoint': {'remote-endpoint': [[4294967295]]}}}, '$nodename':
['panel@0']}
from schema $id:
http://devicetree.org/schemas/display/panel/raydium,rm69380.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/raydium,rm69380.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/patch/20240417-raydium-rm69380-driver-v4-1-e9c2337d0...@mainlining.org
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
[PATCH v4 2/2] drm/panel: Add driver for EDO RM69380 OLED panel
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| 1 +
drivers/gpu/drm/panel/panel-raydium-rm69380.c | 344 ++
3 files changed, 357 insertions(+)
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 154f5bf82980..e2a66c21349f 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -542,6 +542,18 @@ config DRM_PANEL_RAYDIUM_RM692E5
Say Y here if you want to enable support for Raydium RM692E5-based
display panels, such as the one found in the Fairphone 5 smartphone.
+config DRM_PANEL_RAYDIUM_RM69380
+ tristate "Raydium RM69380-based DSI panel"
+ depends on OF && GPIOLIB
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for Raydium RM69380-based
+ display panels.
+
+ This panel controller can be found in the Lenovo Xiaoxin Pad Pro 2021
+ in combination with an EDO OLED panel.
+
config DRM_PANEL_RONBO_RB070D30
tristate "Ronbo Electronics RB070D30 panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 24a02655d726..e2a2807d4ef0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) +=
panel-raspberrypi-touchscreen
obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM67191) += panel-raydium-rm67191.o
obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) += panel-raydium-rm68200.o
obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM692E5) += panel-raydium-rm692e5.o
+obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM69380) += panel-raydium-rm69380.o
obj-$(CONFIG_DRM_PANEL_RONBO_RB070D30) += panel-ronbo-rb070d30.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_ATNA33XC20) += panel-samsung-atna33xc20.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_DB7430) += panel-samsung-db7430.o
diff --git a/drivers/gpu/drm/panel/panel-raydium-rm69380.c
b/drivers/gpu/drm/panel/panel-raydium-rm69380.c
new file mode 100644
index ..4dca6802faef
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-raydium-rm69380.c
@@ -0,0 +1,344 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Generated with linux-mdss-dsi-panel-driver-generator from vendor device
tree.
+ * Copyright (c) 2024 David Wronek
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+
+struct rm69380_panel {
+ struct drm_panel panel;
+ struct mipi_dsi_device *dsi[2];
+ struct regulator_bulk_data supplies[2];
+ struct gpio_desc *reset_gpio;
+};
+
+static inline
+struct rm69380_panel *to_rm69380_panel(struct drm_panel *panel)
+{
+ return container_of(panel, struct rm69380_panel, panel);
+}
+
+static void rm69380_reset(struct rm69380_panel *ctx)
+{
+ gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+ usleep_range(15000, 16000);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+ usleep_range(1, 11000);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+ msleep(30);
+}
+
+static int rm69380_on(struct rm69380_panel *ctx)
+{
+ struct mipi_dsi_device *dsi = ctx->dsi[0];
+ struct device *dev = >dev;
+ int ret;
+
+ dsi->mode_flags |= MIPI_DSI_MODE_LPM;
+ if (ctx->dsi[1])
+ ctx->dsi[1]->mode_flags |= MIPI_DSI_MODE_LPM;
+
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0xd4);
+ mipi_dsi_dcs_write_seq(dsi, 0x00, 0x80);
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0xd0);
+ mipi_dsi_dcs_write_seq(dsi, 0x48, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0x26);
+ mipi_dsi_dcs_write_seq(dsi, 0x75, 0x3f);
+ mipi_dsi_dcs_write_seq(dsi, 0x1d, 0x1a);
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, MIPI_DCS_WRITE_CONTROL_DISPLAY, 0x28);
+ mipi_dsi_dcs_write_seq(dsi, 0xc2, 0x08);
+
+ ret = mipi_dsi_dcs_set_tear_on(dsi, MIPI_DSI_DCS_TEAR_MODE_VBLANK);
+ if (ret < 0) {
+ dev_err(dev, "Failed to set tear on: %d\n", ret);
+ return ret;
+ }
+
+ ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
+ if (ret < 0) {
+ dev_err(dev, "Failed to exit sleep mode: %d\n", ret);
+ return ret;
+ }
+ msleep(20);
+
+ ret = mipi_dsi_dcs_set_display_on(dsi);
+ if (ret < 0) {
+ dev_err(dev, "Failed to set display on: %d\n", ret);
+ return ret;
+ }
+ msleep(36);
+
+ return 0;
+}
+
+static int rm69380_off(struct rm69380_panel *ctx)
+{
+ struct mipi_dsi_device *dsi = ctx->dsi[0];
+ struct device *dev = >dev;
+ int ret;
+
+ dsi->mode_flags
[PATCH v4 0/2] Add driver for Raydium RM69380-based DSI panels
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 & Kala 2-in-1 Laptop with Sharp panel Signed-off-by: David Wronek --- Changes in v4: - Fix up Kconfig - Switch to devm_mipi_dsi_attach to benefit from automatic detaching - Initialize panel at a lower brightness - Dropped debug logs - Signify second DSI interface in mipi_dsi_device_info as "RM69380 DSI1" - Changed 'addtionalProperties' to 'unevaluatedProperties' in dt-binding - Dropped 'ports' in dt-binding - Link to v3: https://lore.kernel.org/r/20240416-raydium-rm69380-driver-v3-0-21600ac4c...@mainlining.org Changes in v3: - Removed unneeded curly brackets from some if statments - Fix error handling code in probe function - Include video/mipi_display.h and make use of MIPI command definitions - Removed DRM_MODE_TYPE_PREFERRED - Dropped 'prepared' bool entirely - Register second DSI host using mipi_dsi_device_register_full() - Link to v2: https://lore.kernel.org/r/20240415-raydium-rm69380-driver-v2-0-524216461...@mainlining.org Changes in v2: - Fixed typo in Kconfig - Removed ctx->prepared = true; in prepare function - Switched to drm_connector_helper_get_modes_fixed in get_modes function - Changed dev_notice() to dev_dbg() - Add description for compatible and reset-gpio in the dt-binding - Always require 'ports' node in the dt-binding regardless of compatible - Link to v1: https://lore.kernel.org/r/20240414-raydium-rm69380-driver-v1-0-5e86ba249...@mainlining.org --- David Wronek (2): dt-bindings: display: panel: Add Raydium RM69380 drm/panel: Add driver for EDO RM69380 OLED panel .../bindings/display/panel/raydium,rm69380.yaml| 89 ++ drivers/gpu/drm/panel/Kconfig | 12 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-raydium-rm69380.c | 344 + 4 files changed, 446 insertions(+) --- base-commit: 4eab358930711bbeb85bf5ee267d0d42d3394c2c change-id: 20240414-raydium-rm69380-driver-47f22b6f24fe Best regards, -- David Wronek
[PATCH v4 1/2] dt-bindings: display: panel: Add Raydium RM69380
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 ++
1 file changed, 89 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml
b/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml
new file mode 100644
index ..b17765b2b351
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml
@@ -0,0 +1,89 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/raydium,rm69380.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Raydium RM69380-based DSI display panels
+
+maintainers:
+ - David Wronek
+
+description:
+ The Raydium RM69380 is a generic DSI panel IC used to control
+ OLED panels.
+
+allOf:
+ - $ref: panel-common-dual.yaml#
+
+properties:
+ compatible:
+items:
+ - enum:
+ - lenovo,j716f-edo-rm69380
+ - const: raydium,rm69380
+description: This indicates the panel manufacturer of the panel
+ that is in turn using the RM69380 panel driver. The compatible
+ string determines how the RM69380 panel driver shall be configured
+ to work with the indicated panel. The raydium,rm69380 compatible shall
+ always be provided as a fallback.
+
+ avdd-supply:
+description: Analog voltage rail
+
+ vddio-supply:
+description: I/O voltage rail
+
+ reset-gpios:
+maxItems: 1
+description: phandle of gpio for reset line - This should be active low
+
+ reg: true
+
+required:
+ - compatible
+ - reg
+ - avdd-supply
+ - vddio-supply
+ - reset-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "lenovo,j716f-edo-rm69380", "raydium,rm69380";
+reg = <0>;
+
+avdd-supply = <_avdd_regulator>;
+vddio-supply = <_l14a>;
+reset-gpios = < 75 GPIO_ACTIVE_LOW>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+panel_in_0: endpoint {
+remote-endpoint = <_dsi0_out>;
+};
+};
+
+port@1 {
+reg = <1>;
+panel_in_1: endpoint {
+remote-endpoint = <_dsi1_out>;
+};
+};
+};
+};
+};
+
+...
--
2.44.0
[PATCH v1 1/1] backlight: mp3309c: fix leds flickering in pwm mode
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 pwm mode and reset in analog mode. But if the DIMS bit is set in pwm dimming mode and other devices are connected on the same i2c bus, every i2c commands on the bus generates a flickering on the LEDs powered by the mp3309c. This change concerns the chip initialization and does not impact any existing device-tree configuration. Signed-off-by: Flavio Suligoi --- drivers/video/backlight/mp3309c.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/video/backlight/mp3309c.c b/drivers/video/backlight/mp3309c.c index 016c1296841c..a28036c964af 100644 --- a/drivers/video/backlight/mp3309c.c +++ b/drivers/video/backlight/mp3309c.c @@ -97,15 +97,10 @@ static int mp3309c_enable_device(struct mp3309c_chip *chip) /* * I2C register #1 - Set working mode: -* - set one of the two dimming mode: -*- PWM dimming using an external PWM dimming signal -*- analog dimming using I2C commands * - enable/disable synchronous mode * - set overvoltage protection (OVP) */ reg_val = 0x00; - if (chip->pdata->dimming_mode == DIMMING_PWM) - reg_val |= REG_I2C_1_DIMS; if (chip->pdata->sync_mode) reg_val |= REG_I2C_1_SYNC; reg_val |= chip->pdata->over_voltage_protection; -- 2.34.1
[PATCH v1 0/1] backlight: mp3309c: fix leds flickering in pwm mode
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 pwm mode and reset in analog mode. But if the DIMS bit is set in pwm dimming mode and other devices are connected on the same i2c bus, every i2c commands on the bus generates a flickering on the LEDs powered by the mp3309c. This change concerns the chip initialization and does not impact any existing device-tree configuration. I created this device driver for one of our boards, where both dimming modes (pwm and analog by i2c commands) can be used. This board uses the same i2c bus for the mp3309c and for an at24cs32 eeprom. During further tests, I realized that, when the mp3309c is used in pwm mode, every read operation on the eeprom caused a backlight flickering. This is why I made this device driver modification. Flavio Suligoi (1): backlight: mp3309c: fix leds flickering in pwm mode drivers/video/backlight/mp3309c.c | 5 - 1 file changed, 5 deletions(-) -- 2.34.1
Re: [PATCH v3 2/2] drm/panel: Add driver for EDO RM69380 OLED panel
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/Kconfig | 14 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-raydium-rm69380.c | 367
++
3 files changed, 382 insertions(+)
diff --git a/drivers/gpu/drm/panel/Kconfig
b/drivers/gpu/drm/panel/Kconfig
index 154f5bf82980..5b3eeb93b1a2 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -542,6 +542,20 @@ config DRM_PANEL_RAYDIUM_RM692E5
Say Y here if you want to enable support for Raydium RM692E5-based
display panels, such as the one found in the Fairphone 5
smartphone.
+config DRM_PANEL_RAYDIUM_RM69380
+ tristate "Raydium RM69380-based DSI panel"
+ depends on BACKLIGHT_CLASS_DEVICE
+ depends on DRM_DISPLAY_DP_HELPER
"DRM DisplayPort helpers"
But you said that this is a DSI device?
Looking in -next from yesterday, Raydium-RM692E5 and Visionox-R66451
get this
wrong as well.
+ depends on DRM_DISPLAY_HELPER
This also looks unused? The only helpers in the non-DP non-HDMI helper
points
to more DP AUX code.
+ depends on DRM_MIPI_DSI
+ depends on OF
As I've shown in the SOFEF00 cleanup patch, devm_gpiod_get() is used
which is
behind GPIOLIB. This should probably be a dependency.
+ help
+ Say Y here if you want to enable support for Raydium RM69380-based
+ display panels.
+
+ This panel controller can be found in the Lenovo Xiaoxin Pad Pro
2021
+ in combination with an EDO OLED panel.
+
config DRM_PANEL_RONBO_RB070D30
tristate "Ronbo Electronics RB070D30 panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile
b/drivers/gpu/drm/panel/Makefile
index 24a02655d726..e2a2807d4ef0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) +=
panel-raspberrypi-touchscreen
obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM67191) += panel-raydium-rm67191.o
obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) += panel-raydium-rm68200.o
obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM692E5) += panel-raydium-rm692e5.o
+obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM69380) += panel-raydium-rm69380.o
obj-$(CONFIG_DRM_PANEL_RONBO_RB070D30) += panel-ronbo-rb070d30.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_ATNA33XC20) +=
panel-samsung-atna33xc20.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_DB7430) += panel-samsung-db7430.o
diff --git a/drivers/gpu/drm/panel/panel-raydium-rm69380.c
b/drivers/gpu/drm/panel/panel-raydium-rm69380.c
new file mode 100644
index ..f89230c969b7
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-raydium-rm69380.c
@@ -0,0 +1,367 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Generated with linux-mdss-dsi-panel-driver-generator from vendor
device tree.
+ * Copyright (c) 2024 David Wronek
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+
+struct rm69380_panel {
+ struct drm_panel panel;
+ struct mipi_dsi_device *dsi[2];
+ struct regulator_bulk_data supplies[2];
+ struct gpio_desc *reset_gpio;
+};
+
+static inline
+struct rm69380_panel *to_rm69380_panel(struct drm_panel *panel)
+{
+ return container_of(panel, struct rm69380_panel, panel);
+}
+
+static void rm69380_reset(struct rm69380_panel *ctx)
+{
+ gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+ usleep_range(15000, 16000);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+ usleep_range(1, 11000);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+ msleep(30);
+}
+
+static int rm69380_on(struct rm69380_panel *ctx)
+{
+ struct mipi_dsi_device *dsi = ctx->dsi[0];
+ struct device *dev = >dev;
+ int ret;
+
+ dsi->mode_flags |= MIPI_DSI_MODE_LPM;
+ if (ctx->dsi[1])
+ ctx->dsi[1]->mode_flags |= MIPI_DSI_MODE_LPM;
+
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0xd4);
+ mipi_dsi_dcs_write_seq(dsi, 0x00, 0x80);
Is this MIPI_DCS_NOP? Strange to see that with a parameter.
I don't think it is. 0xfe is the command to switch the 'manufacture
command set'. As you can see, it switches to a different MCS right after
this one. Given that I don't have a datasheet for this perticular driver
IC, I can't be absolutely certain, but considering that the drivers for
rm67191 and rm68200 are defining 0xfe as the command to switch the
commands sets, it's probably the same here.
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0xd0);
+ mipi_dsi_dcs_write_seq(dsi, 0x48, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0x26);
+ mipi_dsi_dcs_write_seq(dsi, 0x75, 0x3f);
+
Re: [PATCH 09/15] drm/gud: switch to struct drm_edid
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
Re: [REBASE 7/7] drm/edid: make drm_edid_are_equal() more convenient for its single user
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
Re: [PATCH v4 0/7] Managing live video input format for ZynqMP DPSUB
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
Re: [PATCH v4] drm/i915/hwmon: Get rid of devm
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; > > > > - hwmon_dev = devm_hwmon_device_register_with_info(dev, > > ddat_gt->name, > > -ddat_gt, > > - > > _gt_chip_info, > > -NULL); > > - if (!IS_ERR(hwmon_dev)) > > - ddat_gt->hwmon_dev = hwmon_dev; > > + hwmon_dev = hwmon_device_register_with_info(dev, ddat_gt->name, > > + ddat_gt, > > + _gt_chip_info, > > + NULL); > > + if (IS_ERR(hwmon_dev)) > > + goto err; > > here the logic is changing, though. Before we were not leaving if > hwmon_device_register_with_info() was returning error. > > Is this wanted? And why isn't it described in the log? Not sure if the previous logic was intentional or not, anyway I have restored it in v5 (where I once again forgot to add "PATCH v5" to the Subject but v5 is there in the version log :/). Thanks. -- Ashutosh
[PATCH] drm/i915/hwmon: Get rid of devm
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 the other. These code paths (for device unbind) are as
follows (see also the bug referenced below):
Call Trace:
release_nodes+0x11/0x70
devres_release_group+0xb2/0x110
component_unbind_all+0x8d/0xa0
component_del+0xa5/0x140
intel_pxp_tee_component_fini+0x29/0x40 [i915]
intel_pxp_fini+0x33/0x80 [i915]
i915_driver_remove+0x4c/0x120 [i915]
i915_pci_remove+0x19/0x30 [i915]
pci_device_remove+0x32/0xa0
device_release_driver_internal+0x19c/0x200
unbind_store+0x9c/0xb0
and
Call Trace:
release_nodes+0x11/0x70
devres_release_all+0x8a/0xc0
device_unbind_cleanup+0x9/0x70
device_release_driver_internal+0x1c1/0x200
unbind_store+0x9c/0xb0
This means that in i915, if use devm, we cannot gurantee that hwmon will
always be released before drvdata. Which means that we have a uaf if hwmon
sysfs is accessed when drvdata has been released but hwmon hasn't.
The only way out of this seems to be do get rid of devm_ and release/free
everything explicitly during device unbind.
v2: Change commit message and other minor code changes
v3: Cleanup from i915_hwmon_register on error (Armin Wolf)
v4: Eliminate potential static analyzer warning (Rodrigo)
Eliminate fetch_and_zero (Jani)
v5: Restore previous logic for ddat_gt->hwmon_dev error return (Andi)
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10366
Reviewed-by: Rodrigo Vivi
Signed-off-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_hwmon.c | 46 +--
1 file changed, 32 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index b758fd110c20..c0662a022f59 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -793,7 +793,7 @@ void i915_hwmon_register(struct drm_i915_private *i915)
if (!IS_DGFX(i915))
return;
- hwmon = devm_kzalloc(dev, sizeof(*hwmon), GFP_KERNEL);
+ hwmon = kzalloc(sizeof(*hwmon), GFP_KERNEL);
if (!hwmon)
return;
@@ -819,14 +819,12 @@ void i915_hwmon_register(struct drm_i915_private *i915)
hwm_get_preregistration_info(i915);
/* hwmon_dev points to device hwmon */
- hwmon_dev = devm_hwmon_device_register_with_info(dev, ddat->name,
-ddat,
-_chip_info,
-hwm_groups);
- if (IS_ERR(hwmon_dev)) {
- i915->hwmon = NULL;
- return;
- }
+ hwmon_dev = hwmon_device_register_with_info(dev, ddat->name,
+ ddat,
+ _chip_info,
+ hwm_groups);
+ if (IS_ERR(hwmon_dev))
+ goto err;
ddat->hwmon_dev = hwmon_dev;
@@ -839,16 +837,36 @@ void i915_hwmon_register(struct drm_i915_private *i915)
if (!hwm_gt_is_visible(ddat_gt, hwmon_energy,
hwmon_energy_input, 0))
continue;
- hwmon_dev = devm_hwmon_device_register_with_info(dev,
ddat_gt->name,
-ddat_gt,
-
_gt_chip_info,
-NULL);
+ hwmon_dev = hwmon_device_register_with_info(dev, ddat_gt->name,
+ ddat_gt,
+ _gt_chip_info,
+ NULL);
if (!IS_ERR(hwmon_dev))
ddat_gt->hwmon_dev = hwmon_dev;
}
+ return;
+err:
+ i915_hwmon_unregister(i915);
}
void i915_hwmon_unregister(struct drm_i915_private *i915)
{
- fetch_and_zero(>hwmon);
+ struct i915_hwmon *hwmon = i915->hwmon;
+ struct intel_gt *gt;
+ int i;
+
+ if (!hwmon)
+ return;
+
+ for_each_gt(gt, i915, i)
+ if (hwmon->ddat_gt[i].hwmon_dev)
+ hwmon_device_unregister(hwmon->ddat_gt[i].hwmon_dev);
+
+ if (hwmon->ddat.hwmon_dev)
+ hwmon_device_unregister(hwmon->ddat.hwmon_dev);
+
+ mutex_destroy(>hwmon_lock);
+
+ kfree(i915->hwmon);
+ i915->hwmon = NULL;
}
--
2.41.0
Re: [PATCH v3 1/2] dt-bindings: display: panel: Add Raydium RM69380
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 schema")
> ---
> .../bindings/display/panel/raydium,rm69380.yaml| 91
> ++
> 1 file changed, 91 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml
> b/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml
> new file mode 100644
> index ..0ac7d033cbe0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml
> @@ -0,0 +1,91 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/raydium,rm69380.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Raydium RM6380-based DSI display panels
RM69380-based
> +
> +maintainers:
> + - David Wronek
> +
> +description:
> + The Raydium RM69380 is a generic DSI panel IC used to control
> + OLED panels.
> +
> +allOf:
> + - $ref: panel-common-dual.yaml#
> +
> +properties:
> + compatible:
> +items:
> + - enum:
> + - lenovo,j716f-edo-rm69380
> + - const: raydium,rm69380
> +description: This indicates the panel manufacturer of the panel
> + that is in turn using the RM69380 panel driver. The compatible
> + string determines how the RM69380 panel driver shall be configured
> + to work with the indicated panel. The raydium,rm69380 compatible shall
> + always be provided as a fallback.
> +
> + avdd-supply:
> +description: Analog voltage rail
> +
> + vddio-supply:
> +description: I/O voltage rail
> +
> + reset-gpios:
> +maxItems: 1
> +description: phandle of gpio for reset line - This should be active low
> +
> + ports: true
> + reg: true
Drop these and change 'addtionalProperties' to 'unevaluatedProperties'.
Other properties in panel-common.yaml should be allowed. width-mm and
height-mm for example.
> +
> +required:
> + - compatible
> + - reg
> + - avdd-supply
> + - vddio-supply
> + - reset-gpios
> + - ports
Already required in panel-common-dual.yaml.
Rob
[PATCH v3 11/11] drm/i915/dp_mst: Enable HBLANK expansion quirk for UHBR rates
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 it and forcing it to enable the mode without compression
leads to the same problem above (which suggests a panel issue with
uncompressed mode).
The same 5k mode on non-UHBR link rates is not affected and lower
resolution modes are not affected either. The problem is similar to the
one fixed by the HBLANK expansion quirk on Synaptics hubs, with the
difference that the problematic mode has a longer HBLANK duration. Also
the monitor doesn't report supporting HBLANK expansion; either its
internal MST hub does the expansion internally - similarly to the
Synaptics hub - or the issue has another root cause, but still related
to the mode's short HBLANK duration. Enable the quirk for the monitor
adjusting the detection for the above differences.
v2: Rebase on drm_dp_128132b_supported() change.
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Ankit Nautiyal
Tested-by: Khaled Almahallawy
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_helper.c | 2 ++
drivers/gpu/drm/i915/display/intel_dp_mst.c | 22 +
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index 023907da98581..79a615667aab1 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -2281,6 +2281,8 @@ static const struct dpcd_quirk dpcd_quirk_list[] = {
{ OUI(0x90, 0xCC, 0x24), DEVICE_ID_ANY, true,
BIT(DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD) },
/* Synaptics DP1.4 MST hubs require DSC for some modes on which it
applies HBLANK expansion. */
{ OUI(0x90, 0xCC, 0x24), DEVICE_ID_ANY, true,
BIT(DP_DPCD_QUIRK_HBLANK_EXPANSION_REQUIRES_DSC) },
+ /* MediaTek panels (at least in U3224KBA) require DSC for modes with a
short HBLANK on UHBR links. */
+ { OUI(0x00, 0x0C, 0xE7), DEVICE_ID_ANY, false,
BIT(DP_DPCD_QUIRK_HBLANK_EXPANSION_REQUIRES_DSC) },
/* Apple MacBookPro 2017 15 inch eDP Retina panel reports too low
DP_MAX_LINK_RATE */
{ OUI(0x00, 0x10, 0xfa), DEVICE_ID(101, 68, 21, 101, 98, 97), false,
BIT(DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS) },
};
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index fb5e167c3c659..1cd375963f243 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -421,15 +421,22 @@ static int mode_hblank_period_ns(const struct
drm_display_mode *mode)
static bool
hblank_expansion_quirk_needs_dsc(const struct intel_connector *connector,
-const struct intel_crtc_state *crtc_state)
+const struct intel_crtc_state *crtc_state,
+const struct link_config_limits *limits)
{
const struct drm_display_mode *adjusted_mode =
_state->hw.adjusted_mode;
+ bool is_uhbr_sink = connector->mst_port &&
+
drm_dp_128b132b_supported(connector->mst_port->dpcd);
+ int hblank_limit = is_uhbr_sink ? 500 : 300;
if (!connector->dp.dsc_hblank_expansion_quirk)
return false;
- if (mode_hblank_period_ns(adjusted_mode) > 300)
+ if (is_uhbr_sink && !drm_dp_is_uhbr_rate(limits->max_rate))
+ return false;
+
+ if (mode_hblank_period_ns(adjusted_mode) > hblank_limit)
return false;
return true;
@@ -445,7 +452,7 @@ adjust_limits_for_dsc_hblank_expansion_quirk(const struct
intel_connector *conne
const struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
int min_bpp_x16 = limits->link.min_bpp_x16;
- if (!hblank_expansion_quirk_needs_dsc(connector, crtc_state))
+ if (!hblank_expansion_quirk_needs_dsc(connector, crtc_state, limits))
return true;
if (!dsc) {
@@ -1604,7 +1611,14 @@ static bool detect_dsc_hblank_expansion_quirk(const
struct intel_connector *conn
DP_DPCD_QUIRK_HBLANK_EXPANSION_REQUIRES_DSC))
return false;
- if (!(dpcd[DP_RECEIVE_PORT_0_CAP_0] & DP_HBLANK_EXPANSION_CAPABLE))
+ /*
+* UHBR (MST sink) devices requiring this quirk don't advertise the
+* HBLANK expansion support. Presuming that they perform HBLANK
+* expansion internally, or are affected by this issue on modes with a
+* short HBLANK for other reasons.
+*/
+ if (!drm_dp_128b132b_supported(dpcd) &&
+ !(dpcd[DP_RECEIVE_PORT_0_CAP_0] & DP_HBLANK_EXPANSION_CAPABLE))
return false;
drm_dbg_kms(>drm,
--
2.43.3
[PATCH v3 07/11] drm/dp: Add drm_dp_128b132b_supported()
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 Navare
Acked-by: Maarten Lankhorst
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
include/drm/display/drm_dp_helper.h | 6 ++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 23808e9d41d5d..e05e25cd4a940 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -225,7 +225,7 @@ static void intel_dp_set_dpcd_sink_rates(struct intel_dp
*intel_dp)
* Sink rates for 128b/132b. If set, sink should support all 8b/10b
* rates and 10 Gbps.
*/
- if (intel_dp->dpcd[DP_MAIN_LINK_CHANNEL_CODING] & DP_CAP_ANSI_128B132B)
{
+ if (drm_dp_128b132b_supported(intel_dp->dpcd)) {
u8 uhbr_rates = 0;
BUILD_BUG_ON(ARRAY_SIZE(intel_dp->sink_rates) <
ARRAY_SIZE(dp_rates) + 3);
diff --git a/include/drm/display/drm_dp_helper.h
b/include/drm/display/drm_dp_helper.h
index baf9949ff96fc..8bed890eec2c6 100644
--- a/include/drm/display/drm_dp_helper.h
+++ b/include/drm/display/drm_dp_helper.h
@@ -251,6 +251,12 @@ drm_dp_channel_coding_supported(const u8
dpcd[DP_RECEIVER_CAP_SIZE])
return dpcd[DP_MAIN_LINK_CHANNEL_CODING] & DP_CAP_ANSI_8B10B;
}
+static inline bool
+drm_dp_128b132b_supported(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+ return dpcd[DP_MAIN_LINK_CHANNEL_CODING] & DP_CAP_ANSI_128B132B;
+}
+
static inline bool
drm_dp_alternate_scrambler_reset_cap(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
{
--
2.43.3
Re: [PATCH v6 3/5] drm: Add support to get EDID from ACPI
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 wrote:
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1886,6 +1886,12 @@ struct drm_connector {
>
> /** @hdr_sink_metadata: HDR Metadata Information read from
> sink */
> struct hdr_sink_metadata hdr_sink_metadata;
> +
> + /**
> + * @acpi_edid_allowed: Get the EDID from the BIOS, if available.
> + * This is only applicable to eDP and LVDS displays.
> + */
> + bool acpi_edid_allowed;
> >>>
> >>> Aren't there other bools/small stuff in there for tighter packing?
> >>
> >> Does the compiler automatically do the packing if you put bools nearby
> >> in a struct? If so; TIL.
> >
> > Yes. Well, depends on the types and their alignment requirements
> > of course, and/or whether you specified __packed or not.
> >
> > You can use 'pahole' to find the holes in structures.
>
> Thanks! I don't see a __packed attribute on struct drm_connector, but
> I'll put it near by other bools in case that changes in the future.
FTR, don't add __packed unless you have a very good reason to do so.
With __packed, the compiler will emit multiple byte-accesses to
access multi-byte integrals on platforms that do not support unaligned
memory access.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v11 02/10] drm/ttm/tests: Delete unnecessary config option
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 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/ttm/tests/.kunitconfig b/drivers/gpu/drm/ttm/tests/.kunitconfig index 75fdce0cd98e..1ae1ffabd51e 100644 --- a/drivers/gpu/drm/ttm/tests/.kunitconfig +++ b/drivers/gpu/drm/ttm/tests/.kunitconfig @@ -1,4 +1,3 @@ CONFIG_KUNIT=y CONFIG_DRM=y -CONFIG_DRM_KUNIT_TEST_HELPERS=y CONFIG_DRM_TTM_KUNIT_TEST=y
Re: [PATCH v2 4/4] drm/xe/FLR: Support PCIe FLR
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 unbind and rebind as the driver needs to
> reinitialize the device afresh post FLR.
>
> v2:
> 1. separate out gt idle and pci save/restore to a separate patch (Lucas)
> 2. Fixed the warnings seen around xe_guc_submit_stop, xe_guc_puc_fini
>
> Cc: Rodrigo Vivi
> Cc: Lucas De Marchi
>
> Reviewed-by: Rodrigo Vivi
> Signed-off-by: Aravind Iddamsetty
> ---
> drivers/gpu/drm/xe/Makefile | 1 +
> drivers/gpu/drm/xe/xe_device_types.h | 3 +
> drivers/gpu/drm/xe/xe_guc_pc.c | 4 ++
> drivers/gpu/drm/xe/xe_pci.c | 9 ++-
> drivers/gpu/drm/xe/xe_pci.h | 2 +
> drivers/gpu/drm/xe/xe_pci_err.c | 93
> drivers/gpu/drm/xe/xe_pci_err.h | 13
> 7 files changed, 124 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/xe/xe_pci_err.c
> create mode 100644 drivers/gpu/drm/xe/xe_pci_err.h
>
> diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
> index 522bffa5c4e1..9686ea181ad1 100644
> --- a/drivers/gpu/drm/xe/Makefile
> +++ b/drivers/gpu/drm/xe/Makefile
> @@ -117,6 +117,7 @@ xe-y += xe_bb.o \
> xe_module.o \
> xe_pat.o \
> xe_pci.o \
> + xe_pci_err.o \
> xe_pcode.o \
> xe_pm.o \
> xe_preempt_fence.o \
> diff --git a/drivers/gpu/drm/xe/xe_device_types.h
> b/drivers/gpu/drm/xe/xe_device_types.h
> index 0a66555229e9..8c749b378a92 100644
> --- a/drivers/gpu/drm/xe/xe_device_types.h
> +++ b/drivers/gpu/drm/xe/xe_device_types.h
> @@ -465,6 +465,9 @@ struct xe_device {
> /** @pci_state: PCI state of device */
> struct pci_saved_state *pci_state;
>
> + /** @pci_device_is_reset: device went through PCIe FLR */
> + bool pci_device_is_reset;
> +
> /* private: */
>
> #if IS_ENABLED(CONFIG_DRM_XE_DISPLAY)
> diff --git a/drivers/gpu/drm/xe/xe_guc_pc.c b/drivers/gpu/drm/xe/xe_guc_pc.c
> index 521ae24f2314..6108a4dfa05f 100644
> --- a/drivers/gpu/drm/xe/xe_guc_pc.c
> +++ b/drivers/gpu/drm/xe/xe_guc_pc.c
> @@ -902,6 +902,10 @@ static void xe_guc_pc_fini(struct drm_device *drm, void
> *arg)
> return;
> }
>
> + /* We already have done this before going through a reset, so skip here
> */
> + if (xe->pci_device_is_reset)
> + return;
> +
> XE_WARN_ON(xe_force_wake_get(gt_to_fw(pc_to_gt(pc)), XE_FORCEWAKE_ALL));
> XE_WARN_ON(xe_guc_pc_gucrc_disable(pc));
> XE_WARN_ON(xe_guc_pc_stop(pc));
> diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
> index f9957cd16356..d986ae7fc7f7 100644
> --- a/drivers/gpu/drm/xe/xe_pci.c
> +++ b/drivers/gpu/drm/xe/xe_pci.c
> @@ -23,6 +23,7 @@
> #include "xe_macros.h"
> #include "xe_mmio.h"
> #include "xe_module.h"
> +#include "xe_pci_err.h"
> #include "xe_pci_types.h"
> #include "xe_pm.h"
> #include "xe_sriov.h"
> @@ -736,7 +737,7 @@ static void xe_pci_remove(struct pci_dev *pdev)
> pci_set_drvdata(pdev, NULL);
> }
>
> -static int xe_pci_probe(struct pci_dev *pdev, const struct pci_device_id
> *ent)
> +int xe_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> {
> const struct xe_device_desc *desc = (const void *)ent->driver_data;
> const struct xe_subplatform_desc *subplatform_desc;
> @@ -976,6 +977,11 @@ static const struct dev_pm_ops xe_pm_ops = {
> };
> #endif
>
> +const struct pci_error_handlers xe_pci_err_handlers = {
static ?
> + .reset_prepare = xe_pci_reset_prepare,
> + .reset_done = xe_pci_reset_done,
> +};
> +
> static struct pci_driver xe_pci_driver = {
> .name = DRIVER_NAME,
> .id_table = pciidlist,
> @@ -985,6 +991,7 @@ static struct pci_driver xe_pci_driver = {
> #ifdef CONFIG_PM_SLEEP
> .driver.pm = _pm_ops,
> #endif
> + .err_handler = _pci_err_handlers,
> };
>
> int xe_register_pci_driver(void)
> diff --git a/drivers/gpu/drm/xe/xe_pci.h b/drivers/gpu/drm/xe/xe_pci.h
> index 73b90a430d1f..9faf5380a09e 100644
> --- a/drivers/gpu/drm/xe/xe_pci.h
> +++ b/drivers/gpu/drm/xe/xe_pci.h
> @@ -7,8 +7,10 @@
> #define _XE_PCI_H_
>
> struct pci_dev;
> +struct pci_device_id;
>
> int xe_register_pci_driver(void);
> void xe_unregister_pci_driver(void);
> void xe_load_pci_state(struct pci_dev *pdev);
> +int xe_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent);
> #endif
> diff --git a/drivers/gpu/drm/xe/xe_pci_err.c b/drivers/gpu/drm/xe/xe_pci_err.c
> new file mode 100644
> index ..81c440e08fbc
> --- /dev/null
> +++ b/drivers/gpu/drm/xe/xe_pci_err.c
> @@ -0,0 +1,93 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2024 Intel Corporation
> + */
> +
> +#include
> +#include
> +
> +#include "xe_device.h"
> +#include
Re: [PATCH v2 1/4] drm: add devm release action
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
> helper (Rodrigo)
>
> Cc: Thomas Hellstr_m
> Cc: Rodrigo Vivi
>
> Reviewed-by: Rodrigo Vivi
Sima, Dave, or drm-misc, ack to get this through drm-xe-next?
> Signed-off-by: Aravind Iddamsetty
> ---
> drivers/gpu/drm/drm_drv.c | 6 ++
> include/drm/drm_drv.h | 2 ++
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 243cacb3575c..ba60cbb0725f 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -714,6 +714,12 @@ static int devm_drm_dev_init(struct device *parent,
> devm_drm_dev_init_release, dev);
> }
>
> +void devm_drm_dev_release_action(struct drm_device *dev)
> +{
> + devm_release_action(dev->dev, devm_drm_dev_init_release, dev);
> +}
> +EXPORT_SYMBOL(devm_drm_dev_release_action);
> +
> void *__devm_drm_dev_alloc(struct device *parent,
> const struct drm_driver *driver,
> size_t size, size_t offset)
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index 8878260d7529..fa9123684874 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -444,6 +444,8 @@ struct drm_driver {
> const struct file_operations *fops;
> };
>
> +void devm_drm_dev_release_action(struct drm_device *dev);
> +
> void *__devm_drm_dev_alloc(struct device *parent,
> const struct drm_driver *driver,
> size_t size, size_t offset);
> --
> 2.25.1
>
Re: [PATCH v11 03/10] drm/ttm/tests: Set DMA mask in KUnit device
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 tests.
Set the DMA mask for coherent mappings to unblock testing.
Signed-off-by: Karolina Stolarek
---
drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
index 7b7c1fa805fc..cb1cd676f8ae 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
@@ -98,6 +98,9 @@ struct ttm_test_devices *ttm_test_devices_basic(struct kunit
*test)
devs->dev = drm_kunit_helper_alloc_device(test);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, devs->dev);
+ /* Set mask for alloc_coherent mappings to enable ttm_pool_alloc testing */
+ devs->dev->coherent_dma_mask = -1;
DMA_BIT_MASK() would be nice here. I wonder if it make sense to move
that to kunit device related calls, anyway this is:
Reviewed-by: Nirmoy Das
+
devs->drm = __drm_kunit_helper_alloc_drm_device(test, devs->dev,
sizeof(*devs->drm), 0,
DRIVER_GEM);
Re: [PATCH v2] drm/mediatek/dp: fix mtk_dp_aux_transfer return value
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
constantly repeats the transfer request.
Fixes: f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort driver")
Signed-off-by: Wojciech Macek
Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH 3/4] drm/xe: Extract xe_gt_idle() helper
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/xe/xe_gt.h | 1 +
> 2 files changed, 22 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_gt.c b/drivers/gpu/drm/xe/xe_gt.c
> index cfa5da900461..59f497d575ad 100644
> --- a/drivers/gpu/drm/xe/xe_gt.c
> +++ b/drivers/gpu/drm/xe/xe_gt.c
> @@ -629,6 +629,26 @@ static int do_gt_restart(struct xe_gt *gt)
> return 0;
> }
>
> +/* Idle the GT */
as this is a public function, can we have a proper kernel-doc here?
and maybe some hint what should be done if this function fails?
> +int xe_gt_idle(struct xe_gt *gt)
> +{
> + int err;
> +
> + xe_gt_sanitize(gt);
> +
> + xe_uc_gucrc_disable(>uc);
> + xe_uc_stop_prepare(>uc);
> + xe_gt_pagefault_reset(gt);
> +
> + err = xe_uc_stop(>uc);
> + if (err)
> + return err;
> +
> + xe_gt_tlb_invalidation_reset(gt);
> +
> + return err;
> +}
> +
> static int gt_reset(struct xe_gt *gt)
> {
> int err;
> @@ -645,21 +665,12 @@ static int gt_reset(struct xe_gt *gt)
> }
>
> xe_pm_runtime_get(gt_to_xe(gt));
> - xe_gt_sanitize(gt);
>
> err = xe_force_wake_get(gt_to_fw(gt), XE_FORCEWAKE_ALL);
> if (err)
> goto err_msg;
>
> - xe_uc_gucrc_disable(>uc);
> - xe_uc_stop_prepare(>uc);
> - xe_gt_pagefault_reset(gt);
> -
> - err = xe_uc_stop(>uc);
> - if (err)
> - goto err_out;
> -
> - xe_gt_tlb_invalidation_reset(gt);
> + xe_gt_idle(gt);
>
> err = do_gt_reset(gt);
> if (err)
> diff --git a/drivers/gpu/drm/xe/xe_gt.h b/drivers/gpu/drm/xe/xe_gt.h
> index ed6ea8057e35..d62af1725ff6 100644
> --- a/drivers/gpu/drm/xe/xe_gt.h
> +++ b/drivers/gpu/drm/xe/xe_gt.h
> @@ -43,6 +43,7 @@ int xe_gt_resume(struct xe_gt *gt);
> void xe_gt_reset_async(struct xe_gt *gt);
> void xe_gt_sanitize(struct xe_gt *gt);
> void xe_gt_remove(struct xe_gt *gt);
> +int xe_gt_idle(struct xe_gt *gt);
>
> /**
> * xe_gt_any_hw_engine_by_reset_domain - scan the list of engines and return
> the
Re: [PATCH v2 11/18] dt-bindings: pwm: mediatek,pwm-disp: add power-domains property
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 Mergnat It's the same for at least MT8195, MT8183 and I think MT8192 as well... so not having that from the beginning is actually a mistake. Please add a Fixes tag and resend, after which: Reviewed-by: AngeloGioacchino Del Regno You mean similar to: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=fb7c3d8ba039df877886fd457538d8b24ca9c84b ? It seems someone you know well was quicker :-) Best regards Uwe LOL! I totally forgot that I fixed that already :-D I need more coffee! Cheers, Angelo
Re: [PATCH v2 9/9] drm/xe: Add a shrinker for xe bos
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/exynos-drm-next
drm-intel/for-linux-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Thomas-Hellstr-m/drm-ttm-Allow-TTM-LRU-list-nodes-of-different-types/20240416-181717
base: https://gitlab.freedesktop.org/drm/xe/kernel.git drm-xe-next
patch link:
https://lore.kernel.org/r/20240416100730.-10-thomas.hellstrom%40linux.intel.com
patch subject: [PATCH v2 9/9] drm/xe: Add a shrinker for xe bos
config: powerpc-randconfig-001-20240417
(https://download.01.org/0day-ci/archive/20240417/202404172100.qxirere7-...@intel.com/config)
compiler: powerpc-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240417/202404172100.qxirere7-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202404172100.qxirere7-...@intel.com/
All warnings (new ones prefixed by >>):
In file included from include/asm-generic/bug.h:22,
from arch/powerpc/include/asm/bug.h:116,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/mm.h:6,
from include/linux/pagemap.h:8,
from include/drm/ttm/ttm_tt.h:30,
from drivers/gpu/drm/xe/xe_bo.h:9,
from drivers/gpu/drm/xe/xe_bo.c:6:
drivers/gpu/drm/xe/tests/xe_bo.c: In function 'shrink_test_run_device':
include/linux/kern_levels.h:5:25: warning: format '%lu' expects argument of
type 'long unsigned int', but argument 3 has type 'size_t' {aka 'unsigned int'}
[-Wformat=]
5 | #define KERN_SOH"\001" /* ASCII Start Of Header */
| ^~
include/linux/printk.h:429:25: note: in definition of macro
'printk_index_wrap'
429 | _p_func(_fmt, ##__VA_ARGS__);
\
| ^~~~
include/kunit/test.h:527:17: note: in expansion of macro 'printk'
527 | printk(lvl fmt, ##__VA_ARGS__);
\
| ^~
include/kunit/test.h:533:9: note: in expansion of macro 'kunit_log'
533 | kunit_log(lvl, test, KUNIT_SUBTEST_INDENT "# %s: " fmt,
\
| ^
include/kunit/test.h:546:9: note: in expansion of macro 'kunit_printk'
546 | kunit_printk(KERN_INFO, test, fmt, ##__VA_ARGS__)
| ^~~~
include/linux/kern_levels.h:14:25: note: in expansion of macro 'KERN_SOH'
14 | #define KERN_INFO KERN_SOH "6"/* informational */
| ^~~~
include/kunit/test.h:546:22: note: in expansion of macro 'KERN_INFO'
546 | kunit_printk(KERN_INFO, test, fmt, ##__VA_ARGS__)
| ^
drivers/gpu/drm/xe/tests/xe_bo.c:381:9: note: in expansion of macro
'kunit_info'
381 | kunit_info(test, "Free ram is %lu bytes. Will allocate twice
of that.\n",
| ^~
In file included from drivers/gpu/drm/xe/tests/xe_bo.c:6,
from drivers/gpu/drm/xe/xe_bo.c:2420:
>> include/kunit/test.h:50:41: warning: format '%lu' expects argument of type
>> 'long unsigned int', but argument 4 has type 'size_t' {aka 'unsigned int'}
>> [-Wformat=]
50 | #define KUNIT_SUBTEST_INDENT""
| ^~
include/kunit/test.h:528:57: note: in definition of macro 'kunit_log'
528 | kunit_log_append((test_or_suite)->log, fmt,
\
| ^~~
include/kunit/test.h:533:30: note: in expansion of macro
'KUNIT_SUBTEST_INDENT'
533 | kunit_log(lvl, test, KUNIT_SUBTEST_INDENT "# %s: " fmt,
\
| ^~~~
include/kunit/test.h:546:9: note: in expansion of macro 'kunit_printk'
546 | kunit_printk(KERN_INFO, test, fmt, ##__VA_ARGS__)
| ^~~~
drivers/gpu/drm/xe/tests/xe_bo.c:381:9: note: in expansion of macro
'kunit_info'
381 | kunit_info(test, "Free ram is %lu bytes. Wi
[PULL] drm-intel-next
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 that easier for us:
https://gitlab.freedesktop.org/drm/maintainer-tools/-/merge_requests/52
)
Another thing that it is important to highlight is that we have 3 drm level
patches in this pull request where I didn't see any explicit recorded
ack from you (drm maintainers) nor from drm-misc maintainers.
The patches looks good to me and shouldn't cause conflict, so I hope it
is okay to continue with them here instead of a big removal at this
point.
Thanks,
Rodrigo.
drm-intel-next-2024-04-17-1:
Core Changes (DRM):
- Fix documentation of DP tunnel functions (Imre)
- DP MST read sideband messaging cap (Jani)
- Preparation patches for Adaptive Sync SDP Support for DP (Mitul)
Driver Changes:
i915 core (non-display):
- Documentation improvements (Nirmoy)
- Add includes for BUG_ON/BUILD_BUG_ON in i915_memcpy.c (Joonas)
- Do not print 'pxp init failed with 0' when it succeed (Jose)
- Clean-up, including removal of dead code for unsupported platforms (Lucas)
- Adding new DG2 PCI ID (Ravi)
{i915,xe} display:
- Spelling fix (Colin Ian)
- Document CDCLK components (Gustavo)
- Lunar Lake display enabling, including cdclk and other refactors (Gustavo,
Bala)
- BIOS/VBT/opregion related refactor (Jani, Ville, RK)
- Save a few bytes of memory using {kstrdup,kfree}_const variant (Christophe)
- Digital port related refactor/clean-up (Ville)
- Fix 2s boot time regression on DP panel replay init (Animesh)
- Remove redundant drm_rect_visible() overlay use (Arthur)
- DSC HW state readout fixes (Imre)
- Remove duplication on audio enable/disable on SDVO and g4x+ DP (Ville)
- Disable AuxCCS framebuffers if built for Xe (Juha-Pekka)
- Fix DSI init order (Ville)
- DRRS related refactor and fixes (Bhanuprakash)
- Fix DSB vblank waits with VRR (Ville)
- General improvements on register name and use of REG_BIT (Ville)
- Some display power well related improvements (Ville)
- FBC changes for better w/a handling (Ville)
- Make crtc disable more atomic (Ville)
- Fix hwmon locking inversion in sysfs getter (Janusz)
- Increase DP idle pattern wait timeout to 2ms (Shekhar)
- PSR related fixes and improvents (Jouni)
- Start using container_of_const() for some extra const safety (Ville)
- Use drm_printer more on display code (Ville)
- Fix Jasper Lake boot freeze (Jonathon)
- Update Pipe src size check in skl_update_scaler (Ankit)
- Enable MST mode for 128b/132b single-stream sideband (Jani)
- Pass encoder around more for port/phy checks (Jani)
- Some initial work to make display code more independent from i915 (Jani)
- Pre-populate the cursor physical dma address (Ville)
- Do not bump min backlight brightness to max on enable (Gareth)
- Fix MTL supported DP rates - removal of UHBR13.5 (Arun)
- Fix the computation for compressed_bpp for DISPLAY < 1 (Ankit)
- Bigjoiner modeset sequence redesign and MST support (Ville)
- Enable Adaptive Sync SDP Support for DP (Mitul)
- Implemnt vblank sycnhronized mbus joining changes (Ville, Stanislav)
- HDCP related fixes (Suraj)
- Fix i915_display_info debugfs when connectors are not active (Ville)
- Clean up on Xe compat layer (Jani)
- Add jitter WAs for MST/FEC/DSC links (Imre)
- DMC wakelock implementation (Luca)
The following changes since commit 39cd87c4eb2b893354f3b850f916353f2658ae6f:
Linux 6.9-rc2 (2024-03-31 14:32:39 -0700)
are available in the Git repository at:
https://anongit.freedesktop.org/git/drm/drm-intel
tags/drm-intel-next-2024-04-17-1
for you to fetch changes up to 700c34019555392a348f8c03237c1ebb5bf53eb4:
drm/i915/display: tie DMC wakelock to DC5/6 state transitions (2024-04-17
11:41:23 +0300)
Core Changes (DRM):
- Fix documentation of DP tunnel functions (Imre)
- DP MST read sideband messaging cap (Jani)
- Preparation patches for Adaptive Sync SDP Support for DP (Mitul)
Driver Changes:
i915 core (non-display):
- Documentation improvements (Nirmoy)
- Add includes for BUG_ON/BUILD_BUG_ON in i915_memcpy.c (Joonas)
- Do not print 'pxp init failed with 0' when it succeed (Jose)
- Clean-up, including removal of dead code for unsupported platforms (Lucas)
- Adding new DG2 PCI ID (Ravi)
{i915,xe} display:
- Spelling fix (Colin Ian)
- Document CDCLK components (Gustavo)
- Lunar Lake display enabling, including cdclk and other refactors (Gustavo,
Bala)
- BIOS/VBT/opregion related refactor (Jani, Ville, RK)
- Save a few bytes of memory using {kstrdup,kfree}_const variant (Christophe)
- Digital port related refactor/clean-up (Ville)
- Fix 2s boot time regression on DP panel replay init (Animesh)
- Remove redundant drm_rect_visible() overlay use (Arthur)
- DSC HW state readout fixes (Imre)
- Remove duplication on audio
Re: [PATCH v2 11/18] dt-bindings: pwm: mediatek,pwm-disp: add power-domains property
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 least MT8195, MT8183 and I think MT8192 as well... so > not having that from the beginning is actually a mistake. > > Please add a Fixes tag and resend, after which: > > Reviewed-by: AngeloGioacchino Del Regno > You mean similar to: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=fb7c3d8ba039df877886fd457538d8b24ca9c84b ? It seems someone you know well was quicker :-) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
[PATCH v11 07/10] drm/ttm/tests: Add test cases dependent on fence signaling
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/ttm/tests/ttm_bo_validate_test.c | 305 ++
1 file changed, 305 insertions(+)
diff --git a/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
b/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
index 4e93076cf36c..27ab09aa8311 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
@@ -2,6 +2,8 @@
/*
* Copyright © 2023 Intel Corporation
*/
+#include
+#include
#include
#include
@@ -13,11 +15,14 @@
#define BO_SIZESZ_4K
#define MANAGER_SIZE SZ_1M
+static struct spinlock fence_lock;
+
struct ttm_bo_validate_test_case {
const char *description;
enum ttm_bo_type bo_type;
uint32_t mem_type;
bool with_ttm;
+ bool no_gpu_wait;
};
static struct ttm_placement *ttm_placement_kunit_init(struct kunit *test,
@@ -35,6 +40,43 @@ static struct ttm_placement *ttm_placement_kunit_init(struct
kunit *test,
return placement;
}
+static const char *fence_name(struct dma_fence *f)
+{
+ return "ttm-bo-validate-fence";
+}
+
+static const struct dma_fence_ops fence_ops = {
+ .get_driver_name = fence_name,
+ .get_timeline_name = fence_name,
+};
+
+static struct dma_fence *alloc_mock_fence(struct kunit *test)
+{
+ struct dma_fence *fence;
+
+ fence = kunit_kzalloc(test, sizeof(*fence), GFP_KERNEL);
+ KUNIT_ASSERT_NOT_NULL(test, fence);
+
+ dma_fence_init(fence, _ops, _lock, 0, 0);
+
+ return fence;
+}
+
+static void dma_resv_kunit_active_fence_init(struct kunit *test,
+struct dma_resv *resv,
+enum dma_resv_usage usage)
+{
+ struct dma_fence *fence;
+
+ fence = alloc_mock_fence(test);
+ dma_fence_enable_sw_signaling(fence);
+
+ dma_resv_lock(resv, NULL);
+ dma_resv_reserve_fences(resv, 1);
+ dma_resv_add_fence(resv, fence, usage);
+ dma_resv_unlock(resv);
+}
+
static void ttm_bo_validate_case_desc(const struct ttm_bo_validate_test_case
*t,
char *desc)
{
@@ -460,6 +502,262 @@ static void ttm_bo_validate_multihop(struct kunit *test)
ttm_mock_manager_fini(priv->ttm_dev, tmp_mem);
}
+static const struct ttm_bo_validate_test_case ttm_bo_no_placement_cases[] = {
+ {
+ .description = "Buffer object in system domain, no page vector",
+ },
+ {
+ .description = "Buffer object in system domain with an existing
page vector",
+ .with_ttm = true,
+ },
+};
+
+KUNIT_ARRAY_PARAM(ttm_bo_no_placement, ttm_bo_no_placement_cases,
+ ttm_bo_validate_case_desc);
+
+static void ttm_bo_validate_no_placement_signaled(struct kunit *test)
+{
+ const struct ttm_bo_validate_test_case *params = test->param_value;
+ enum ttm_bo_type bo_type = ttm_bo_type_device;
+ struct ttm_test_devices *priv = test->priv;
+ uint32_t size = ALIGN(BO_SIZE, PAGE_SIZE);
+ struct ttm_operation_ctx ctx = { };
+ uint32_t mem_type = TTM_PL_SYSTEM;
+ struct ttm_resource_manager *man;
+ struct ttm_placement *placement;
+ struct ttm_buffer_object *bo;
+ struct ttm_place *place;
+ struct ttm_tt *old_tt;
+ uint32_t flags;
+ int err;
+
+ place = ttm_place_kunit_init(test, mem_type, 0);
+ man = ttm_manager_type(priv->ttm_dev, mem_type);
+
+ bo = ttm_bo_kunit_init(test, test->priv, size);
+ bo->type = bo_type;
+
+ if (params->with_ttm) {
+ old_tt = priv->ttm_dev->funcs->ttm_tt_create(bo, 0);
+ ttm_pool_alloc(>ttm_dev->pool, old_tt, );
+ bo->ttm = old_tt;
+ }
+
+ err = ttm_resource_alloc(bo, place, >resource);
+ KUNIT_EXPECT_EQ(test, err, 0);
+ KUNIT_ASSERT_EQ(test, man->usage, size);
+
+ placement = kunit_kzalloc(test, sizeof(*placement), GFP_KERNEL);
+ KUNIT_ASSERT_NOT_NULL(test, placement);
+
+ ttm_bo_reserve(bo, false, false, NULL);
+ err = ttm_bo_validate(bo, placement, );
+ ttm_bo_unreserve(bo);
+
+ KUNIT_EXPECT_EQ(test, err, 0);
+ KUNIT_ASSERT_EQ(test, man->usage, 0);
+ KUNIT_ASSERT_NOT_NULL(test, bo->ttm);
+ KUNIT_EXPECT_EQ(test, ctx.bytes_moved, 0);
+
+ if (params->with_ttm) {
+ flags = bo->ttm->page_flags;
+
+ KUNIT_ASSERT_PTR_EQ(test, bo->ttm, old_tt);
+ KUNIT_ASSERT_FALSE(test, flags & TTM_TT_FLAG_PRIV_POPULATED);
+ KUNIT_ASSERT_TRUE(test, flags & TTM_TT_FLAG_ZERO_ALLOC);
+ }
+
+ ttm_bo_put(bo);
+}
+
+static int
[PATCH v11 10/10] drm/ttm/tests: Add TODO file
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/drm/ttm/tests/TODO new file mode 100644 index ..b29d55167d56 --- /dev/null +++ b/drivers/gpu/drm/ttm/tests/TODO @@ -0,0 +1,25 @@ +TODO += + +- Add a test case where the only evictable BO is busy +- Update eviction tests so they use parametrized "from" memory type +- Improve mock manager's implementation, e.g. allocate a block of + dummy memory that can be used when testing page mapping functions +- Suggestion: Add test cases with external BOs +- Suggestion: randomize the number and size of tested buffers in + ttm_bo_validate() +- Agree on the naming convention + +Notes and gotchas += + +- These tests are built and run with a UML kernel, because + 1) We are interested in hardware-independent testing + 2) We don't want to have actual DRM devices interacting with TTM + at the same time as the test one. Getting these to work in + parallel would require some time (...and that's a "todo" in itself!) +- Triggering ttm_bo_vm_ops callbacks from KUnit (i.e. kernel) might be + a challenge, but is worth trying. Look at selftests like + i915/gem/selftests/i915_gem_mman.c for inspiration +- The test suite uses UML where ioremap() call returns NULL, meaning that + ttm_bo_ioremap() can't be tested, unless we find a way to stub it -- 2.34.1
[PATCH v11 09/10] drm/ttm/tests: Add tests for ttm_tt_populate
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/drm/ttm/tests/ttm_tt_test.c | 119
drivers/gpu/drm/ttm/ttm_tt.c| 3 +
2 files changed, 122 insertions(+)
diff --git a/drivers/gpu/drm/ttm/tests/ttm_tt_test.c
b/drivers/gpu/drm/ttm/tests/ttm_tt_test.c
index a33a426a814d..b626228124aa 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_tt_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_tt_test.c
@@ -256,6 +256,120 @@ static void ttm_tt_destroy_basic(struct kunit *test)
ttm_tt_destroy(devs->ttm_dev, bo->ttm);
}
+static void ttm_tt_populate_null_ttm(struct kunit *test)
+{
+ const struct ttm_test_devices *devs = test->priv;
+ struct ttm_operation_ctx ctx = { };
+ int err;
+
+ err = ttm_tt_populate(devs->ttm_dev, NULL, );
+ KUNIT_ASSERT_EQ(test, err, -EINVAL);
+}
+
+static void ttm_tt_populate_populated_ttm(struct kunit *test)
+{
+ const struct ttm_test_devices *devs = test->priv;
+ struct ttm_operation_ctx ctx = { };
+ struct ttm_buffer_object *bo;
+ struct ttm_tt *tt;
+ struct page *populated_page;
+ int err;
+
+ bo = ttm_bo_kunit_init(test, test->priv, BO_SIZE);
+
+ tt = kunit_kzalloc(test, sizeof(*tt), GFP_KERNEL);
+ KUNIT_ASSERT_NOT_NULL(test, tt);
+
+ err = ttm_tt_init(tt, bo, 0, ttm_cached, 0);
+ KUNIT_ASSERT_EQ(test, err, 0);
+
+ err = ttm_tt_populate(devs->ttm_dev, tt, );
+ KUNIT_ASSERT_EQ(test, err, 0);
+ populated_page = *tt->pages;
+
+ err = ttm_tt_populate(devs->ttm_dev, tt, );
+ KUNIT_ASSERT_PTR_EQ(test, populated_page, *tt->pages);
+}
+
+static void ttm_tt_unpopulate_basic(struct kunit *test)
+{
+ const struct ttm_test_devices *devs = test->priv;
+ struct ttm_operation_ctx ctx = { };
+ struct ttm_buffer_object *bo;
+ struct ttm_tt *tt;
+ int err;
+
+ bo = ttm_bo_kunit_init(test, test->priv, BO_SIZE);
+
+ tt = kunit_kzalloc(test, sizeof(*tt), GFP_KERNEL);
+ KUNIT_ASSERT_NOT_NULL(test, tt);
+
+ err = ttm_tt_init(tt, bo, 0, ttm_cached, 0);
+ KUNIT_ASSERT_EQ(test, err, 0);
+
+ err = ttm_tt_populate(devs->ttm_dev, tt, );
+ KUNIT_ASSERT_EQ(test, err, 0);
+ KUNIT_ASSERT_TRUE(test, ttm_tt_is_populated(tt));
+
+ ttm_tt_unpopulate(devs->ttm_dev, tt);
+ KUNIT_ASSERT_FALSE(test, ttm_tt_is_populated(tt));
+}
+
+static void ttm_tt_unpopulate_empty_ttm(struct kunit *test)
+{
+ const struct ttm_test_devices *devs = test->priv;
+ struct ttm_buffer_object *bo;
+ struct ttm_tt *tt;
+ int err;
+
+ bo = ttm_bo_kunit_init(test, test->priv, BO_SIZE);
+
+ tt = kunit_kzalloc(test, sizeof(*tt), GFP_KERNEL);
+ KUNIT_ASSERT_NOT_NULL(test, tt);
+
+ err = ttm_tt_init(tt, bo, 0, ttm_cached, 0);
+ KUNIT_ASSERT_EQ(test, err, 0);
+
+ ttm_tt_unpopulate(devs->ttm_dev, tt);
+ /* Expect graceful handling of unpopulated TTs */
+}
+
+static void ttm_tt_swapin_basic(struct kunit *test)
+{
+ const struct ttm_test_devices *devs = test->priv;
+ int expected_num_pages = BO_SIZE >> PAGE_SHIFT;
+ struct ttm_operation_ctx ctx = { };
+ struct ttm_buffer_object *bo;
+ struct ttm_tt *tt;
+ int err, num_pages;
+
+ bo = ttm_bo_kunit_init(test, test->priv, BO_SIZE);
+
+ tt = kunit_kzalloc(test, sizeof(*tt), GFP_KERNEL);
+ KUNIT_ASSERT_NOT_NULL(test, tt);
+
+ err = ttm_tt_init(tt, bo, 0, ttm_cached, 0);
+ KUNIT_ASSERT_EQ(test, err, 0);
+
+ err = ttm_tt_populate(devs->ttm_dev, tt, );
+ KUNIT_ASSERT_EQ(test, err, 0);
+ KUNIT_ASSERT_TRUE(test, ttm_tt_is_populated(tt));
+
+ num_pages = ttm_tt_swapout(devs->ttm_dev, tt, GFP_KERNEL);
+ KUNIT_ASSERT_EQ(test, num_pages, expected_num_pages);
+ KUNIT_ASSERT_NOT_NULL(test, tt->swap_storage);
+ KUNIT_ASSERT_TRUE(test, tt->page_flags & TTM_TT_FLAG_SWAPPED);
+
+ /* Swapout depopulates TT, allocate pages and then swap them in */
+ err = ttm_pool_alloc(>ttm_dev->pool, tt, );
+ KUNIT_ASSERT_EQ(test, err, 0);
+
+ err = ttm_tt_swapin(tt);
+ KUNIT_ASSERT_EQ(test, err, 0);
+ KUNIT_ASSERT_NULL(test, tt->swap_storage);
+ KUNIT_ASSERT_FALSE(test, tt->page_flags & TTM_TT_FLAG_SWAPPED);
+}
+
static struct kunit_case ttm_tt_test_cases[] = {
KUNIT_CASE_PARAM(ttm_tt_init_basic, ttm_tt_init_basic_gen_params),
KUNIT_CASE(ttm_tt_init_misaligned),
@@ -267,6 +381,11 @@ static struct kunit_case ttm_tt_test_cases[] = {
KUNIT_CASE(ttm_tt_create_ttm_exists),
KUNIT_CASE(ttm_tt_create_failed),
KUNIT_CASE(ttm_tt_destroy_basic),
+ KUNIT_CASE(ttm_tt_populate_null_ttm),
+
[PATCH v11 06/10] drm/ttm/tests: Add tests with mock resource managers
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
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/ttm/tests/.kunitconfig| 1 +
drivers/gpu/drm/ttm/tests/Makefile| 1 +
.../gpu/drm/ttm/tests/ttm_bo_validate_test.c | 274 ++
drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c | 38 ++-
drivers/gpu/drm/ttm/tests/ttm_mock_manager.c | 207 +
drivers/gpu/drm/ttm/tests/ttm_mock_manager.h | 31 ++
7 files changed, 551 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/ttm/tests/ttm_mock_manager.c
create mode 100644 drivers/gpu/drm/ttm/tests/ttm_mock_manager.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 959b19a04101..3cb5021aae77 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -234,6 +234,7 @@ config DRM_TTM_KUNIT_TEST
default n
depends on DRM && KUNIT && MMU && (UML || COMPILE_TEST)
select DRM_TTM
+select DRM_BUDDY
select DRM_EXPORT_FOR_TESTS if m
select DRM_KUNIT_TEST_HELPERS
default KUNIT_ALL_TESTS
diff --git a/drivers/gpu/drm/ttm/tests/.kunitconfig
b/drivers/gpu/drm/ttm/tests/.kunitconfig
index 1ae1ffabd51e..772f0e1f4103 100644
--- a/drivers/gpu/drm/ttm/tests/.kunitconfig
+++ b/drivers/gpu/drm/ttm/tests/.kunitconfig
@@ -1,3 +1,4 @@
CONFIG_KUNIT=y
CONFIG_DRM=y
CONFIG_DRM_TTM_KUNIT_TEST=y
+CONFIG_DRM_BUDDY=y
diff --git a/drivers/gpu/drm/ttm/tests/Makefile
b/drivers/gpu/drm/ttm/tests/Makefile
index 2e5ed63fb414..f3149de77541 100644
--- a/drivers/gpu/drm/ttm/tests/Makefile
+++ b/drivers/gpu/drm/ttm/tests/Makefile
@@ -7,4 +7,5 @@ obj-$(CONFIG_DRM_TTM_KUNIT_TEST) += \
ttm_tt_test.o \
ttm_bo_test.o \
ttm_bo_validate_test.o \
+ttm_mock_manager.o \
ttm_kunit_helpers.o
diff --git a/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
b/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
index 969796902b4f..4e93076cf36c 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
@@ -8,12 +8,15 @@
#include
#include "ttm_kunit_helpers.h"
+#include "ttm_mock_manager.h"
#define BO_SIZESZ_4K
+#define MANAGER_SIZE SZ_1M
struct ttm_bo_validate_test_case {
const char *description;
enum ttm_bo_type bo_type;
+ uint32_t mem_type;
bool with_ttm;
};
@@ -102,6 +105,49 @@ static void ttm_bo_init_reserved_sys_man(struct kunit
*test)
ttm_bo_put(bo);
}
+static void ttm_bo_init_reserved_mock_man(struct kunit *test)
+{
+ const struct ttm_bo_validate_test_case *params = test->param_value;
+ enum ttm_bo_type bo_type = params->bo_type;
+ struct ttm_test_devices *priv = test->priv;
+ uint32_t size = ALIGN(BO_SIZE, PAGE_SIZE);
+ struct ttm_operation_ctx ctx = { };
+ struct ttm_placement *placement;
+ uint32_t mem_type = TTM_PL_VRAM;
+ struct ttm_buffer_object *bo;
+ struct ttm_place *place;
+ int err;
+
+ ttm_mock_manager_init(priv->ttm_dev, mem_type, MANAGER_SIZE);
+
+ bo = kunit_kzalloc(test, sizeof(*bo), GFP_KERNEL);
+ KUNIT_ASSERT_NOT_NULL(test, bo);
+
+ place = ttm_place_kunit_init(test, mem_type, 0);
+ placement = ttm_placement_kunit_init(test, place, 1);
+
+ drm_gem_private_object_init(priv->drm, >base, size);
+
+ err = ttm_bo_init_reserved(priv->ttm_dev, bo, bo_type, placement,
+ PAGE_SIZE, , NULL, NULL,
+ _ttm_bo_destroy);
+ dma_resv_unlock(bo->base.resv);
+
+ KUNIT_EXPECT_EQ(test, err, 0);
+ KUNIT_EXPECT_EQ(test, kref_read(>kref), 1);
+ KUNIT_EXPECT_PTR_EQ(test, bo->bdev, priv->ttm_dev);
+ KUNIT_EXPECT_EQ(test, bo->type, bo_type);
+ KUNIT_EXPECT_EQ(test, ctx.bytes_moved, size);
+
+ if (bo_type != ttm_bo_type_kernel)
+ KUNIT_EXPECT_TRUE(test,
+
drm_mm_node_allocated(>base.vma_node.vm_node));
+
+ ttm_resource_free(bo, >resource);
+ ttm_bo_put(bo);
+ ttm_mock_manager_fini(priv->ttm_dev, mem_type);
+}
+
static void ttm_bo_init_reserved_resv(struct kunit *test)
{
enum ttm_bo_type bo_type = ttm_bo_type_device;
@@ -136,6 +182,51 @@ static void ttm_bo_init_reserved_resv(struct kunit *test)
ttm_bo_put(bo);
}
+static void ttm_bo_validate_basic(struct kunit *test)
+{
+ const struct ttm_bo_validate_test_case *params = test->param_value;
+ uint32_t fst_mem = TTM_PL_SYSTEM, snd_mem = TTM_PL_VRAM;
+ struct ttm_operation_ctx ctx_init = { }, ctx_val = { };
+ struct ttm_placement *fst_placement, *snd_placement;
+ struct
[PATCH v11 08/10] drm/ttm/tests: Add eviction testing
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 ttm_device init into a function.
Signed-off-by: Karolina Stolarek
Reviewed-by: Somalapuram, Amaranath
Tested-by: Somalapuram, Amaranath
---
.../gpu/drm/ttm/tests/ttm_bo_validate_test.c | 433 ++
drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c | 106 -
drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h | 8 +
drivers/gpu/drm/ttm/tests/ttm_mock_manager.c | 28 ++
drivers/gpu/drm/ttm/tests/ttm_mock_manager.h | 2 +
5 files changed, 569 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
b/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
index 27ab09aa8311..3b87d837e26a 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
@@ -758,6 +758,431 @@ static void
ttm_bo_validate_move_fence_not_signaled(struct kunit *test)
ttm_mock_manager_fini(priv->ttm_dev, snd_mem);
}
+static void ttm_bo_validate_swapout(struct kunit *test)
+{
+ unsigned long size_big, size = ALIGN(BO_SIZE, PAGE_SIZE);
+ enum ttm_bo_type bo_type = ttm_bo_type_device;
+ struct ttm_buffer_object *bo_small, *bo_big;
+ struct ttm_test_devices *priv = test->priv;
+ struct ttm_operation_ctx ctx = { };
+ struct ttm_placement *placement;
+ uint32_t mem_type = TTM_PL_TT;
+ struct ttm_place *place;
+ struct sysinfo si;
+ int err;
+
+ si_meminfo();
+ size_big = ALIGN(((uint64_t)si.totalram * si.mem_unit / 2), PAGE_SIZE);
+
+ ttm_mock_manager_init(priv->ttm_dev, mem_type, size_big + size);
+
+ place = ttm_place_kunit_init(test, mem_type, 0);
+ placement = ttm_placement_kunit_init(test, place, 1);
+
+ bo_small = kunit_kzalloc(test, sizeof(*bo_small), GFP_KERNEL);
+ KUNIT_ASSERT_NOT_NULL(test, bo_small);
+
+ drm_gem_private_object_init(priv->drm, _small->base, size);
+
+ err = ttm_bo_init_reserved(priv->ttm_dev, bo_small, bo_type, placement,
+ PAGE_SIZE, , NULL, NULL,
+ _ttm_bo_destroy);
+ KUNIT_EXPECT_EQ(test, err, 0);
+ dma_resv_unlock(bo_small->base.resv);
+
+ bo_big = ttm_bo_kunit_init(test, priv, size_big);
+
+ dma_resv_lock(bo_big->base.resv, NULL);
+ err = ttm_bo_validate(bo_big, placement, );
+ dma_resv_unlock(bo_big->base.resv);
+
+ KUNIT_EXPECT_EQ(test, err, 0);
+ KUNIT_EXPECT_NOT_NULL(test, bo_big->resource);
+ KUNIT_EXPECT_EQ(test, bo_big->resource->mem_type, mem_type);
+ KUNIT_EXPECT_EQ(test, bo_small->resource->mem_type, TTM_PL_SYSTEM);
+ KUNIT_EXPECT_TRUE(test, bo_small->ttm->page_flags &
TTM_TT_FLAG_SWAPPED);
+
+ ttm_bo_put(bo_big);
+ ttm_bo_put(bo_small);
+
+ ttm_mock_manager_fini(priv->ttm_dev, mem_type);
+}
+
+static void ttm_bo_validate_happy_evict(struct kunit *test)
+{
+ uint32_t mem_type = TTM_PL_VRAM, mem_multihop = TTM_PL_TT,
+mem_type_evict = TTM_PL_SYSTEM;
+ struct ttm_operation_ctx ctx_init = { }, ctx_val = { };
+ enum ttm_bo_type bo_type = ttm_bo_type_device;
+ uint32_t small = SZ_8K, medium = SZ_512K,
+big = MANAGER_SIZE - (small + medium);
+ uint32_t bo_sizes[] = { small, medium, big };
+ struct ttm_test_devices *priv = test->priv;
+ struct ttm_buffer_object *bos, *bo_val;
+ struct ttm_placement *placement;
+ struct ttm_place *place;
+ uint32_t bo_no = 3;
+ int i, err;
+
+ ttm_mock_manager_init(priv->ttm_dev, mem_type, MANAGER_SIZE);
+ ttm_mock_manager_init(priv->ttm_dev, mem_multihop, MANAGER_SIZE);
+
+ place = ttm_place_kunit_init(test, mem_type, 0);
+ placement = ttm_placement_kunit_init(test, place, 1);
+
+ bos = kunit_kmalloc_array(test, bo_no, sizeof(*bos), GFP_KERNEL);
+ KUNIT_ASSERT_NOT_NULL(test, bos);
+
+ memset(bos, 0, sizeof(*bos) * bo_no);
+ for (i = 0; i < bo_no; i++) {
+ drm_gem_private_object_init(priv->drm, [i].base,
bo_sizes[i]);
+ err = ttm_bo_init_reserved(priv->ttm_dev, [i], bo_type,
placement,
+ PAGE_SIZE, _init, NULL, NULL,
+ _ttm_bo_destroy);
+ dma_resv_unlock(bos[i].base.resv);
+ }
+
+ bo_val = ttm_bo_kunit_init(test, test->priv, BO_SIZE);
+ bo_val->type = bo_type;
+
+ ttm_bo_reserve(bo_val, false, false, NULL);
+ err = ttm_bo_validate(bo_val, placement, _val);
+ ttm_bo_unreserve(bo_val);
+
+ KUNIT_EXPECT_EQ(test, err, 0);
+ KUNIT_EXPECT_EQ(test, bos[0].resource->mem_type, mem_type_evict);
+
[PATCH v11 05/10] drm/ttm/tests: Test simple BO creation and validation
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
Reviewed-by: Somalapuram, Amaranath
Tested-by: Somalapuram, Amaranath
---
drivers/gpu/drm/ttm/tests/Makefile| 1 +
.../gpu/drm/ttm/tests/ttm_bo_validate_test.c | 213 ++
drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c | 14 +-
drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h | 1 +
4 files changed, 228 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
diff --git a/drivers/gpu/drm/ttm/tests/Makefile
b/drivers/gpu/drm/ttm/tests/Makefile
index 468535f7eed2..2e5ed63fb414 100644
--- a/drivers/gpu/drm/ttm/tests/Makefile
+++ b/drivers/gpu/drm/ttm/tests/Makefile
@@ -6,4 +6,5 @@ obj-$(CONFIG_DRM_TTM_KUNIT_TEST) += \
ttm_resource_test.o \
ttm_tt_test.o \
ttm_bo_test.o \
+ttm_bo_validate_test.o \
ttm_kunit_helpers.o
diff --git a/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
b/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
new file mode 100644
index ..969796902b4f
--- /dev/null
+++ b/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
@@ -0,0 +1,213 @@
+// SPDX-License-Identifier: GPL-2.0 AND MIT
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include "ttm_kunit_helpers.h"
+
+#define BO_SIZESZ_4K
+
+struct ttm_bo_validate_test_case {
+ const char *description;
+ enum ttm_bo_type bo_type;
+ bool with_ttm;
+};
+
+static struct ttm_placement *ttm_placement_kunit_init(struct kunit *test,
+ struct ttm_place *places,
+ unsigned int num_places)
+{
+ struct ttm_placement *placement;
+
+ placement = kunit_kzalloc(test, sizeof(*placement), GFP_KERNEL);
+ KUNIT_ASSERT_NOT_NULL(test, placement);
+
+ placement->num_placement = num_places;
+ placement->placement = places;
+
+ return placement;
+}
+
+static void ttm_bo_validate_case_desc(const struct ttm_bo_validate_test_case
*t,
+ char *desc)
+{
+ strscpy(desc, t->description, KUNIT_PARAM_DESC_SIZE);
+}
+
+static const struct ttm_bo_validate_test_case ttm_bo_type_cases[] = {
+ {
+ .description = "Buffer object for userspace",
+ .bo_type = ttm_bo_type_device,
+ },
+ {
+ .description = "Kernel buffer object",
+ .bo_type = ttm_bo_type_kernel,
+ },
+ {
+ .description = "Shared buffer object",
+ .bo_type = ttm_bo_type_sg,
+ },
+};
+
+KUNIT_ARRAY_PARAM(ttm_bo_types, ttm_bo_type_cases,
+ ttm_bo_validate_case_desc);
+
+static void ttm_bo_init_reserved_sys_man(struct kunit *test)
+{
+ const struct ttm_bo_validate_test_case *params = test->param_value;
+ struct ttm_test_devices *priv = test->priv;
+ enum ttm_bo_type bo_type = params->bo_type;
+ uint32_t size = ALIGN(BO_SIZE, PAGE_SIZE);
+ struct ttm_operation_ctx ctx = { };
+ struct ttm_placement *placement;
+ struct ttm_buffer_object *bo;
+ struct ttm_place *place;
+ int err;
+
+ bo = kunit_kzalloc(test, sizeof(*bo), GFP_KERNEL);
+ KUNIT_ASSERT_NOT_NULL(test, bo);
+
+ place = ttm_place_kunit_init(test, TTM_PL_SYSTEM, 0);
+ placement = ttm_placement_kunit_init(test, place, 1);
+
+ drm_gem_private_object_init(priv->drm, >base, size);
+
+ err = ttm_bo_init_reserved(priv->ttm_dev, bo, bo_type, placement,
+ PAGE_SIZE, , NULL, NULL,
+ _ttm_bo_destroy);
+ dma_resv_unlock(bo->base.resv);
+
+ KUNIT_EXPECT_EQ(test, err, 0);
+ KUNIT_EXPECT_EQ(test, kref_read(>kref), 1);
+ KUNIT_EXPECT_PTR_EQ(test, bo->bdev, priv->ttm_dev);
+ KUNIT_EXPECT_EQ(test, bo->type, bo_type);
+ KUNIT_EXPECT_EQ(test, bo->page_alignment, PAGE_SIZE);
+ KUNIT_EXPECT_PTR_EQ(test, bo->destroy, _ttm_bo_destroy);
+ KUNIT_EXPECT_EQ(test, bo->pin_count, 0);
+ KUNIT_EXPECT_NULL(test, bo->bulk_move);
+ KUNIT_EXPECT_NOT_NULL(test, bo->ttm);
+ KUNIT_EXPECT_FALSE(test, ttm_tt_is_populated(bo->ttm));
+ KUNIT_EXPECT_NOT_NULL(test, (void *)bo->base.resv->fences);
+ KUNIT_EXPECT_EQ(test, ctx.bytes_moved, size);
+
+ if (bo_type != ttm_bo_type_kernel)
+ KUNIT_EXPECT_TRUE(test,
+
drm_mm_node_allocated(>base.vma_node.vm_node));
+
+ ttm_resource_free(bo, >resource);
+ ttm_bo_put(bo);
+}
+
+static void ttm_bo_init_reserved_resv(struct kunit *test)
+{
+ enum ttm_bo_type bo_type =
[PATCH v11 02/10] drm/ttm/tests: Delete unnecessary config option
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/.kunitconfig b/drivers/gpu/drm/ttm/tests/.kunitconfig index 75fdce0cd98e..1ae1ffabd51e 100644 --- a/drivers/gpu/drm/ttm/tests/.kunitconfig +++ b/drivers/gpu/drm/ttm/tests/.kunitconfig @@ -1,4 +1,3 @@ CONFIG_KUNIT=y CONFIG_DRM=y -CONFIG_DRM_KUNIT_TEST_HELPERS=y CONFIG_DRM_TTM_KUNIT_TEST=y -- 2.34.1
[PATCH v11 04/10] drm/ttm/tests: Use an init function from the helpers lib
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/gpu/drm/ttm/tests/ttm_kunit_helpers.h | 1 +
drivers/gpu/drm/ttm/tests/ttm_tt_test.c | 15 +--
3 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
index cb1cd676f8ae..2fe0c66f31a9 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
@@ -153,6 +153,20 @@ int ttm_test_devices_init(struct kunit *test)
}
EXPORT_SYMBOL_GPL(ttm_test_devices_init);
+int ttm_test_devices_all_init(struct kunit *test)
+{
+ struct ttm_test_devices *priv;
+
+ priv = kunit_kzalloc(test, sizeof(*priv), GFP_KERNEL);
+ KUNIT_ASSERT_NOT_NULL(test, priv);
+
+ priv = ttm_test_devices_all(test);
+ test->priv = priv;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(ttm_test_devices_all_init);
+
void ttm_test_devices_fini(struct kunit *test)
{
ttm_test_devices_put(test, test->priv);
diff --git a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
index 2f51c833a536..53bb5834939f 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
+++ b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
@@ -39,6 +39,7 @@ void ttm_test_devices_put(struct kunit *test, struct
ttm_test_devices *devs);
/* Generic init/fini for tests that only need DRM/TTM devices */
int ttm_test_devices_init(struct kunit *test);
+int ttm_test_devices_all_init(struct kunit *test);
void ttm_test_devices_fini(struct kunit *test);
#endif // TTM_KUNIT_HELPERS_H
diff --git a/drivers/gpu/drm/ttm/tests/ttm_tt_test.c
b/drivers/gpu/drm/ttm/tests/ttm_tt_test.c
index fd4502c18de6..a33a426a814d 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_tt_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_tt_test.c
@@ -15,19 +15,6 @@ struct ttm_tt_test_case {
uint32_t extra_pages_num;
};
-static int ttm_tt_test_init(struct kunit *test)
-{
- struct ttm_test_devices *priv;
-
- priv = kunit_kzalloc(test, sizeof(*priv), GFP_KERNEL);
- KUNIT_ASSERT_NOT_NULL(test, priv);
-
- priv = ttm_test_devices_all(test);
- test->priv = priv;
-
- return 0;
-}
-
static const struct ttm_tt_test_case ttm_tt_init_basic_cases[] = {
{
.description = "Page-aligned size",
@@ -285,7 +272,7 @@ static struct kunit_case ttm_tt_test_cases[] = {
static struct kunit_suite ttm_tt_test_suite = {
.name = "ttm_tt",
- .init = ttm_tt_test_init,
+ .init = ttm_test_devices_all_init,
.exit = ttm_test_devices_fini,
.test_cases = ttm_tt_test_cases,
};
--
2.34.1
[PATCH v11 00/10] Improve test coverage of TTM
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 also
includes some updates to the helpers and more definitions used to define
"special" memory domains (e.g., one that can't allocate resources or is busy),
as well as drive-by fixes for the tests.
There are a couple of areas in which this test suite can be improved.
Suggestions for future work can be found in the TODO file.
Use kunit_tool script to manually run all the tests:
$ ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/gpu/drm/ttm/tests
To build a kernel with TTM KUnit tests, use a UML configuration,
enable CONFIG_KUNIT, and then select CONFIG_DRM_TTM_KUNIT_TEST.
Many thanks,
Karolina
v11:
- Delete CONFIG_DRM_KUNIT_TEST_HELPERS from .kunitconfig file, as it gets
automatically selected when TTM KUnit tests are enabled
- Call ttm_bo_put() in ttm_bo_validate_pinned() test case (Matt)
- Fix a copy-paste mistake in ttm_mem_type_cases definition (Matt)
- Update mock_move definition to do a hop on VRAM -> sysmem move and
delete a dummy multihop domain. Fix the eviction tests accordingly (Matt)
- Update ttm_bo_validate_swapout() to use TT domain instead of VRAM
- Update eviction test cases to create TT domain, so they can perform multihop
- Update TODO file, as it got outdated already
v10:
Many things have happened over the course of three months, so the series
had to be slightly reworked and expanded to accommodate these changes:
- Set DMA coherent mapping mask in the KUnit device so ttm_pool_alloc
tests can be executed
- Update ttm_bo_validate_invalid_placement() test case to check against
the right return error. It's no longer -EINVAL (which only is returned
for pinned buffers), but -ENOMEM. The behaviour has changed in
commit cc941c70df39 ("drm/ttm: improve idle/busy handling v5")
- Rework ttm_placement_kunit_init() to accept only one array of places
and update the tests that use that helper
- Set fallback flags in eviction domains defined in TTM KUnit helpers
- Fix a warning raised by ttm_bo_unreserve_bulk() test case
- Scrap all r-bs and tested-by, as many things were updated and should
be checked again
v9:
- Drop tests with basic test cases, they are merged now
- Add three final patches -- tests for ttm_tt_(un)populate, eviction testing
and a TODO file, with suggestions on how to improve these tests
- Delete the initialization of spinlock in
ttm_bo_validate_move_fence_signaled(), it not used at all (Andi)
- Just return the error code threaded_fence_signal(), don't save it to a
local variable (Andi)
- Use ttm_bo_unreserve() in tests checking different move fence states (Andi)
Karolina Stolarek (10):
drm/ttm/tests: Fix a warning in ttm_bo_unreserve_bulk
drm/ttm/tests: Delete unnecessary config option
drm/ttm/tests: Set DMA mask in KUnit device
drm/ttm/tests: Use an init function from the helpers lib
drm/ttm/tests: Test simple BO creation and validation
drm/ttm/tests: Add tests with mock resource managers
drm/ttm/tests: Add test cases dependent on fence signaling
drm/ttm/tests: Add eviction testing
drm/ttm/tests: Add tests for ttm_tt_populate
drm/ttm/tests: Add TODO file
drivers/gpu/drm/Kconfig |1 +
drivers/gpu/drm/ttm/tests/.kunitconfig|2 +-
drivers/gpu/drm/ttm/tests/Makefile|2 +
drivers/gpu/drm/ttm/tests/TODO| 25 +
drivers/gpu/drm/ttm/tests/ttm_bo_test.c |3 +
.../gpu/drm/ttm/tests/ttm_bo_validate_test.c | 1225 +
drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c | 171 ++-
drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h | 10 +
drivers/gpu/drm/ttm/tests/ttm_mock_manager.c | 235
drivers/gpu/drm/ttm/tests/ttm_mock_manager.h | 33 +
drivers/gpu/drm/ttm/tests/ttm_tt_test.c | 134 +-
drivers/gpu/drm/ttm/ttm_tt.c |3 +
12 files changed, 1820 insertions(+), 24 deletions(-)
create mode 100644 drivers/gpu/drm/ttm/tests/TODO
create mode 100644 drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
create mode 100644 drivers/gpu/drm/ttm/tests/ttm_mock_manager.c
create mode 100644 drivers/gpu/drm/ttm/tests/ttm_mock_manager.h
--
2.34.1
[PATCH v11 03/10] drm/ttm/tests: Set DMA mask in KUnit device
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 unblock testing.
Signed-off-by: Karolina Stolarek
---
drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
index 7b7c1fa805fc..cb1cd676f8ae 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
@@ -98,6 +98,9 @@ struct ttm_test_devices *ttm_test_devices_basic(struct kunit
*test)
devs->dev = drm_kunit_helper_alloc_device(test);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, devs->dev);
+ /* Set mask for alloc_coherent mappings to enable ttm_pool_alloc
testing */
+ devs->dev->coherent_dma_mask = -1;
+
devs->drm = __drm_kunit_helper_alloc_drm_device(test, devs->dev,
sizeof(*devs->drm), 0,
DRIVER_GEM);
--
2.34.1
[PATCH v11 01/10] drm/ttm/tests: Fix a warning in ttm_bo_unreserve_bulk
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/ttm/tests/ttm_bo_test.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/ttm/tests/ttm_bo_test.c
b/drivers/gpu/drm/ttm/tests/ttm_bo_test.c
index 1f8a4f8adc92..632306adc4a1 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_bo_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_bo_test.c
@@ -339,6 +339,9 @@ static void ttm_bo_unreserve_bulk(struct kunit *test)
bo1 = ttm_bo_kunit_init(test, test->priv, BO_SIZE);
bo2 = ttm_bo_kunit_init(test, test->priv, BO_SIZE);
+ /* Share the reservation object in the same bulk move */
+ bo1->base.resv = bo2->base.resv;
+
dma_resv_lock(bo1->base.resv, NULL);
ttm_bo_set_bulk_move(bo1, _bulk_move);
dma_resv_unlock(bo1->base.resv);
--
2.34.1
Re: [PATCH 6/7] drm/msm/dsi: Set PHY usescase before registering DSI host
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 to the slave PLL in > > bonded-DSI mode to source from a clock parent (dsi1vco) that is off. > > > > This should seemingly not be a problem as the actual dispcc clocks from > > DSI1 that are muxed in the clock tree of DSI0 are way further down, this > > bit still seems to have an effect on them somehow and causes the right > > side of the panel controlled by DSI1 to not function. > > > > In an ideal world this code is refactored to no longer have such > > error-prone calls "across subsystems", and instead model the "PLL src" > > register field as a regular mux so that changing the clock parents > > programmatically or in DTS via `assigned-clock-parents` has the > > desired effect. > > But for the avid reader, the clocks that we *are* muxing into DSI0's > > tree are way further down, so if this bit turns out to be a simple mux > > between dsiXvco and out_div, that shouldn't have any effect as this > > whole tree is off anyway. > > > > Signed-off-by: Marijn Suijten > > --- > > drivers/gpu/drm/msm/dsi/dsi_manager.c | 15 +++ > > 1 file changed, 11 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c > > b/drivers/gpu/drm/msm/dsi/dsi_manager.c > > index af2a287cb3bd..17f43b3c0494 100644 > > --- a/drivers/gpu/drm/msm/dsi/dsi_manager.c > > +++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c > > @@ -85,6 +85,17 @@ static int dsi_mgr_setup_components(int id) > > msm_dsi : other_dsi; > > struct msm_dsi *slave_link_dsi = IS_MASTER_DSI_LINK(id) ? > > other_dsi : msm_dsi; > > + > > + /* PLL0 is to drive both 2 DSI link clocks in bonded DSI > > mode. > > +* > > +* Set the usecase before calling msm_dsi_host_register() > > to prevent it from > > +* enabling and configuring the usecase (which is just a > > mux bit) first. > > +*/ > > + msm_dsi_phy_set_usecase(clk_master_dsi->phy, > > + MSM_DSI_PHY_MASTER); > > + msm_dsi_phy_set_usecase(clk_slave_dsi->phy, > > + MSM_DSI_PHY_SLAVE); > > + > > /* Register slave host first, so that slave DSI device > > * has a chance to probe, and do not block the master > > * DSI device's probe. > > @@ -100,10 +111,6 @@ static int dsi_mgr_setup_components(int id) > > return ret; > > > > /* PLL0 is to drive both 2 DSI link clocks in bonded DSI > > mode. */ > > - msm_dsi_phy_set_usecase(clk_master_dsi->phy, > > - MSM_DSI_PHY_MASTER); > > - msm_dsi_phy_set_usecase(clk_slave_dsi->phy, > > - MSM_DSI_PHY_SLAVE); > > msm_dsi_host_set_phy_mode(msm_dsi->host, msm_dsi->phy); > > msm_dsi_host_set_phy_mode(other_dsi->host, other_dsi->phy); > > Please move msm_dsi_host_set_phy_mode() calls too. Ack. Yeah, given that msm_dsi_host_register() causes a modeset and finally the PLL turning on, these should be set up as well. For anyone else following along, I have pasted the stacktrace that showcases the execution flow in the drm/msm tracker: https://gitlab.freedesktop.org/drm/msm/-/issues/41#note_2376115 Abhinav also pointed out that this PLL source was correctly set in earlier devcoredump reports, so it might have been a recent development/regression? This seems to be the only issue originating from it, but folks were adamant that dsi_mgr_setup_components() (ultimately) would never turn the PLL on, which is "debunked" by said stacktrace. Maybe other assumptions are affected by this change? > Also please update the non-bonded case. Definitely, as suggested in the cover letter. A similar stacktrace to the above is acquired on a non-bonded setup, which is also relying on the variable to be initialized to 0 to select the "local PLL source", rather than being correctly set via this msm_dsi_phy_set_usecase() configuration. - Marijn > > } > > > > -- > > 2.44.0 > > > > > -- > With best wishes > Dmitry
Re: [PATCH 4/7] drm/msm/dpu: Allow configuring multiple active DSC blocks
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 overwriting the blocks that are enabled.
>
> This pattern is observed in an active-CTL scenario since DPU 5.0.0 where
> for example bonded-DSI uses a single CTL to drive multiple INTFs, and
> each encoder calls this function individually with the INTF (hence the
> pre-existing update instead of overwrite of this bitmask) and DSC blocks
> it wishes to be enabled, and expects them to be OR'd into the bitmask.
>
> The reverse already exists in reset_intf_cfg_v1() where only specified
> DSC blocks are removed out of the CTL_DSC_ACTIVE bitmask (same for all
> other blocks and ACTIVE bitmasks), leaving the rest enabled.
>
> Fixes: 77f6da90487c ("drm/msm/disp/dpu1: Add DSC support in hw_ctl")
> Signed-off-by: Marijn Suijten
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
Reviewed-by: Dmitry Baryshkov
--
With best wishes
Dmitry
Re: [PATCH 3/7] drm/msm/dpu: Always flush the slave INTF on the CTL
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 ripped out before submission), but
> this clause was incorrectly ported from the original SDE driver. Given
> that there is no support for PPSPLIT (currently), flushing the slave
> INTF should /never/ be skipped (as the `if (ppsplit && !master) goto
> skip;` clause downstream never becomes true).
>
> [1]:
> https://git.codelinaro.org/clo/la/platform/vendor/opensource/display-drivers/-/blob/display-kernel.lnx.5.4.r1-rel/msm/sde/sde_encoder_phys_cmd.c?ref_type=heads#L1131-1139
>
> Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
> Signed-off-by: Marijn Suijten
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 3 ---
> 1 file changed, 3 deletions(-)
Reviewed-by: Dmitry Baryshkov
--
With best wishes
Dmitry
Re: [PATCH 2/7] drm/msm/dsi: Pass bonded-DSI hdisplay/2 to DSC timing configuration
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 hosts), but the full width
> instead of the interface width is passed as hdisplay parameter to
> dsi_update_dsc_timing().
>
> Currently only msm_dsc_get_slices_per_intf() is called within
> dsi_update_dsc_timing() with the `hdisplay` argument which clearly
> documents that it wants the width of a single interface (which, again,
> in bonded DSI mode is half the total width of the mode). Thus pass the
> bonded-mode-adjusted hdisplay parameter into dsi_update_dsc_timing()
> otherwise all values written to registers by this function (i.e. the
> number of slices per interface or packet, and derived from this the EOL
> byte number) are twice too large.
>
> Inversely the panel driver is expected to only set the slice width and
> number of slices for half the panel, i.e. what will be sent by each
> host individually, rather than fixing that up like hdisplay here.
>
> Fixes: 08802f515c3c ("drm/msm/dsi: Add support for DSC configuration")
> Signed-off-by: Marijn Suijten
> ---
> drivers/gpu/drm/msm/dsi/dsi_host.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Dmitry Baryshkov
--
With best wishes
Dmitry
Re: [PATCH 1/7] drm/msm/dsi: Print dual-DSI-adjusted pclk instead of original mode pclk
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 clock divided by two, though more
> recently also adjusted for DSC compression) msm_host->pixel_clk_rate
> which is passed to clk_set_rate() just below. Fix that by printing the
> actual pixel_clk_rate that is being set.
>
> Fixes: ed9976a09b48 ("drm/msm/dsi: adjust dsi timing for dual dsi mode")
> Signed-off-by: Marijn Suijten
> ---
> drivers/gpu/drm/msm/dsi/dsi_host.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
Reviewed-by: Dmitry Baryshkov
--
With best wishes
Dmitry
Re: [PATCH v2 07/11] drm/dp: Add drm_dp_uhbr_channel_coding_supported()
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
> > Reviewed-by: Manasi Navare
> > Acked-by: Maarten Lankhorst
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
> > include/drm/display/drm_dp_helper.h | 6 ++
> > 2 files changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 23808e9d41d5d..41127069b55e4 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -225,7 +225,7 @@ static void intel_dp_set_dpcd_sink_rates(struct
> > intel_dp *intel_dp)
> > * Sink rates for 128b/132b. If set, sink should support all 8b/10b
> > * rates and 10 Gbps.
> > */
> > - if (intel_dp->dpcd[DP_MAIN_LINK_CHANNEL_CODING] & DP_CAP_ANSI_128B132B)
> > {
> > + if (drm_dp_uhbr_channel_coding_supported(intel_dp->dpcd)) {
> > u8 uhbr_rates = 0;
> >
> > BUILD_BUG_ON(ARRAY_SIZE(intel_dp->sink_rates) <
> > ARRAY_SIZE(dp_rates) + 3);
> > diff --git a/include/drm/display/drm_dp_helper.h
> > b/include/drm/display/drm_dp_helper.h
> > index baf9949ff96fc..8a64fe8d97af2 100644
> > --- a/include/drm/display/drm_dp_helper.h
> > +++ b/include/drm/display/drm_dp_helper.h
> > @@ -251,6 +251,12 @@ drm_dp_channel_coding_supported(const u8
> > dpcd[DP_RECEIVER_CAP_SIZE])
> > return dpcd[DP_MAIN_LINK_CHANNEL_CODING] & DP_CAP_ANSI_8B10B;
> > }
> >
> > +static inline bool
> > +drm_dp_uhbr_channel_coding_supported(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> > +{
> > + return dpcd[DP_MAIN_LINK_CHANNEL_CODING] & DP_CAP_ANSI_128B132B;
> > +}
>
> Nitpick, "uhbr channel coding" is not pedantically correct, and it does
> rub me the wrong way.
>
> Yes, using 128b/132b channel coding implies UHBR, and UHBR requires
> 128b/132b channel coding, but they are not the same thing. We do
> conflate the two quite a bit in the code, checking for UHBR when we
> really mean 128b/132b, but embedding this confusion in the function name
> directly is a bit much.
>
> I've named the link training functions drm_dp_128b132b_* in the same
> file, and I think this one should be named similarly. Maybe just
> drm_dp_128b132b_supported(), and rename
> drm_dp_channel_coding_supported() to drm_dp_8b10b_supported() to unify?
Ok, makes sense, will rename it to drm_dp_128b132b_supported() and
can do the same - as a follow-up - for 8b10b.
> BR,
> Jani.
>
>
>
> > +
> > static inline bool
> > drm_dp_alternate_scrambler_reset_cap(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> > {
>
> --
> Jani Nikula, Intel
Re: [PATCH v2 11/11] drm/i915/dp_mst: Enable HBLANK expansion quirk for UHBR rates
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 values. Enabling compression
> > fixes the problem, so do that for now. Windows enables DSC always if the
> > sink supports it and forcing it to enable the mode without compression
> > leads to the same problem above (which suggests a panel issue with
> > uncompressed mode).
> >
> > The same 5k mode on non-UHBR link rates is not affected and lower
> > resolution modes are not affected either. The problem is similar to the
> > one fixed by the HBLANK expansion quirk on Synaptics hubs, with the
> > difference that the problematic mode has a longer HBLANK duration. Also
> > the monitor doesn't report supporting HBLANK expansion; either its
> > internal MST hub does the expansion internally - similarly to the
> > Synaptics hub - or the issue has another root cause, but still related
> > to the mode's short HBLANK duration. Enable the quirk for the monitor
> > adjusting the detection for the above differences.
> >
> > Cc: dri-devel@lists.freedesktop.org
> > Reviewed-by: Ankit Nautiyal
> > Tested-by: Khaled Almahallawy
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/display/drm_dp_helper.c | 2 ++
> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 22 +
> > 2 files changed, 20 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> > b/drivers/gpu/drm/display/drm_dp_helper.c
> > index 023907da98581..79a615667aab1 100644
> > --- a/drivers/gpu/drm/display/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> > @@ -2281,6 +2281,8 @@ static const struct dpcd_quirk dpcd_quirk_list[] = {
> > { OUI(0x90, 0xCC, 0x24), DEVICE_ID_ANY, true,
> > BIT(DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD) },
> > /* Synaptics DP1.4 MST hubs require DSC for some modes on which it
> > applies HBLANK expansion. */
> > { OUI(0x90, 0xCC, 0x24), DEVICE_ID_ANY, true,
> > BIT(DP_DPCD_QUIRK_HBLANK_EXPANSION_REQUIRES_DSC) },
> > + /* MediaTek panels (at least in U3224KBA) require DSC for modes with a
> > short HBLANK on UHBR links. */
> > + { OUI(0x00, 0x0C, 0xE7), DEVICE_ID_ANY, false,
> > BIT(DP_DPCD_QUIRK_HBLANK_EXPANSION_REQUIRES_DSC) },
> > /* Apple MacBookPro 2017 15 inch eDP Retina panel reports too low
> > DP_MAX_LINK_RATE */
> > { OUI(0x00, 0x10, 0xfa), DEVICE_ID(101, 68, 21, 101, 98, 97), false,
> > BIT(DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS) },
> > };
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > index fb5e167c3c659..71b01f7631919 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > @@ -421,15 +421,22 @@ static int mode_hblank_period_ns(const struct
> > drm_display_mode *mode)
> >
> > static bool
> > hblank_expansion_quirk_needs_dsc(const struct intel_connector *connector,
> > -const struct intel_crtc_state *crtc_state)
> > +const struct intel_crtc_state *crtc_state,
> > +const struct link_config_limits *limits)
> > {
> > const struct drm_display_mode *adjusted_mode =
> > _state->hw.adjusted_mode;
> > + bool is_uhbr_sink = connector->mst_port &&
> > +
> > drm_dp_uhbr_channel_coding_supported(connector->mst_port->dpcd);
>
> Why do you combine connector->mst_port to "is uhbr sink"? I think it's
> confusing.
It is a way to get the DPCD of the root port, to determine if it
supports UHBR.
> > + int hblank_limit = is_uhbr_sink ? 500 : 300;
> >
> > if (!connector->dp.dsc_hblank_expansion_quirk)
> > return false;
> >
> > - if (mode_hblank_period_ns(adjusted_mode) > 300)
> > + if (is_uhbr_sink && !drm_dp_is_uhbr_rate(limits->max_rate))
>
> I'm not saying that's not correct, but I find that condition a bit
> surprising. "This does not apply to sinks capable of 128b/132b, but not
> running at UHBR."
>
> IOW, this applies to sinks not capable of 128b/132b, and sinks capable
> of 128b/132b and running at UHBR.
Yes, on the particular monitor I tested and enabled the quirk for - DELL
U3224KBA - all the modes work fine in decompressed mode on non-UHBR link
rates, so it remains possible to enable those modes without DSC on non-UHBR
link rates.
> A head scratcher.
>
> > + return false;
> > +
> > + if (mode_hblank_period_ns(adjusted_mode) > hblank_limit)
> > return false;
> >
> > return true;
> > @@ -445,7 +452,7 @@ adjust_limits_for_dsc_hblank_expansion_quirk(const
> > struct intel_connector *conne
> > const struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > int min_bpp_x16 =
Re: [PATCH 3/3] drm/fourcc: Add documentation around drm_format_info
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 for someone not used to video
> > > formats and drm internals.
> > >
> > > Signed-off-by: Louis Chauvet
> > > ---
> > > include/drm/drm_fourcc.h | 45
> > > ++---
> > > 1 file changed, 38 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> > > index ccf91daa4307..66cc30e28f79 100644
> > > --- a/include/drm/drm_fourcc.h
> > > +++ b/include/drm/drm_fourcc.h
> > > @@ -58,6 +58,44 @@ struct drm_mode_fb_cmd2;
> > >
> > > /**
> > > * struct drm_format_info - information about a DRM format
> > > + *
> > > + * A drm_format_info describes how planes and pixels are stored in
> > > memory.
> > > + *
> > > + * Some format like YUV can have multiple planes, counted in
> > > @num_planes. It
> > > + * means that a full pixel can be stored in multiple non-continuous
> > > buffers.
> > > + * For example, NV12 is a YUV format using two planes: one for the Y
> > > values and
> > > + * one for the UV values.
> > > + *
> > > + * On each plane, the "pixel" unit can be different in case of
> > > subsampling. For
> > > + * example with the NV12 format, a pixel in the UV plane is used for
> > > four pixels
> > > + * in the Y plane.
> > > + * The fields @hsub and @vsub are the relation between the size of the
> > > main
> > > + * plane and the size of the subsampled planes in pixels:
> > > + * plane[0] width = hsub * plane[1] width
> > > + * plane[0] height = vsub * plane[1] height
> >
> > This makes it sound like plane[1] would be the one determining the
> > image size. It is plane[0] that determines the image size (I don't know
> > of a format that would have it otherwise), and vsub and hsub are used
> > as divisors. It's in their name, too: horizontal/vertical sub-sampling.
> >
> > This is important for images with odd dimensions. If plane[1]
> > determined the image size, it would be impossible to have odd sized
> > NV12 images, for instance.
> >
> > Odd dimensions also imply something about rounding the size of the
> > sub-sampled planes. I guess the rounding is up, not down?
>
> I will change the equation to:
>
> plane[1] = plane[0] / hsub (round up)
>
> Can a DRM maintainer confirm the rounding up?
>
> > > + *
> > > + * In some formats, pixels are not independent in memory. It can be a
> > > packed
> >
> > "Independent in memory" sounds to me like it describes sub-sampling:
> > some pixel components are shared between multiple pixels. Here you seem
> > to refer to just packing: one pixel's data may take a fractional number
> > of bytes.
>
> * In some formats, pixels are not individually addressable. It ...
>
> > > + * representation to store more pixels per byte (for example P030 uses 4
> > > bytes
> > > + * for three 10 bit pixels). It can also be used to represent tiled
> > > formats,
> >
> > s/tiled/block/
> >
> > Tiling is given by format modifiers rather than formats.
>
> Fixed in the v2.
>
> > > + * where a continuous buffer in memory can represent a rectangle of
> > > pixels (for
> > > + * example, in DRM_FORMAT_Y0L0, a buffer of 8 bytes represents a 2x2
> > > pixel
> > > + * region of the picture).
> > > + * The field @char_per_block is the size of a block on a specific
> > > plane, in
> > > + * bytes.
> > > + * The fields @block_w and @block_h are the size of a block in
> > > pixels.
> > > + *
> > > + * The older format representation (which only uses @cpp, kept for
> > > historical
> >
> > Move the paren to: representation which only uses @cpp (kept
> >
> > so that the sentence is still understandable if one skips the
> > parenthesised part.
>
> Fixed in v2.
>
> > > + * reasons because there are a lot of places in drivers where it's used)
> > > is
> > > + * assuming that a block is always 1x1 pixel.
> > > + *
> > > + * To keep the compatibility with older format representations and treat
> > > block
> > > + * and non-block formats in the same way one should use:
> > > + * - @char_per_block to access the size of a block on a specific
> > > plane, in
> > > + * bytes.
> > > + * - drm_format_info_block_width() to access the width of a block
> > > of a
> > > + * specific plane, in pixels.
> > > + * - drm_format_info_block_height() to access the height of a
> > > block of a
> > > + * specific plane, in pixels.
> > > */
> > > struct drm_format_info {
> > > /** @format: 4CC format identifier (DRM_FORMAT_*) */
> > > @@ -97,13 +135,6 @@ struct drm_format_info {
> > >* formats for which the memory needed for a single pixel is not
> > >* byte aligned.
> > >*
> > > -
Re: [PATCH] component: Support masters with no subcomponents
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. Yours, Linus Walleij
Re: [PATCH] drm/gma500: Remove lid code
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 Jakobsson
> :
>>
>> On Mon, Apr 15, 2024 at 1:45 PM Thomas Zimmermann
>> wrote:
>> >
>> > Hi
>> >
>> > Am 15.04.24 um 13:27 schrieb Patrik Jakobsson:
>> > > Due to a change in the order of initialization, the lid timer got
>> > > started before proper setup was made. This resulted in a crash during
>> > > boot.
>> > >
>> > > The lid switch is handled by gma500 through a timer that periodically
>> > > polls the opregion for changes. These types of ACPI events shouldn't be
>> > > handled by the graphics driver so let's get rid of the lid code. This
>> > > fixes the crash during boot.
>> > >
>> > > Fixes: 8f1aaccb04b7 ("drm/gma500: Implement client-based fbdev
>> > > emulation")
>> > > Cc: Enrico Bartky
>> >
>> > The patch deserves a Reported-by: from Enrico.
>>
>> Enrico, can you test this patch to make sure it works for you as well?
>>
>> Thanks
>> Patrik
>>
>> >
>> > With this fixed:
>> >
>> > Reviewed-by: Thomas Zimmermann
>> >
>> > Best regards
>> > Thomas
>> >
>> > > Cc: Thomas Zimmermann
>> > > Signed-off-by: Patrik Jakobsson
>> > > ---
>> > > drivers/gpu/drm/gma500/Makefile | 1 -
>> > > drivers/gpu/drm/gma500/psb_device.c | 5 +-
>> > > drivers/gpu/drm/gma500/psb_drv.h| 9
>> > > drivers/gpu/drm/gma500/psb_lid.c| 80 -
>> > > 4 files changed, 1 insertion(+), 94 deletions(-)
>> > > delete mode 100644 drivers/gpu/drm/gma500/psb_lid.c
>> > >
>> > > diff --git a/drivers/gpu/drm/gma500/Makefile
>> > > b/drivers/gpu/drm/gma500/Makefile
>> > > index 4f302cd5e1a6..58fed80c7392 100644
>> > > --- a/drivers/gpu/drm/gma500/Makefile
>> > > +++ b/drivers/gpu/drm/gma500/Makefile
>> > > @@ -34,7 +34,6 @@ gma500_gfx-y += \
>> > > psb_intel_lvds.o \
>> > > psb_intel_modes.o \
>> > > psb_intel_sdvo.o \
>> > > - psb_lid.o \
>> > > psb_irq.o
>> > >
>> > > gma500_gfx-$(CONFIG_ACPI) += opregion.o
>> > > diff --git a/drivers/gpu/drm/gma500/psb_device.c
>> > > b/drivers/gpu/drm/gma500/psb_device.c
>> > > index dcfcd7b89d4a..6dece8f0e380 100644
>> > > --- a/drivers/gpu/drm/gma500/psb_device.c
>> > > +++ b/drivers/gpu/drm/gma500/psb_device.c
>> > > @@ -73,8 +73,7 @@ static int psb_backlight_setup(struct drm_device *dev)
>> > > }
>> > >
>> > > psb_intel_lvds_set_brightness(dev, PSB_MAX_BRIGHTNESS);
>> > > - /* This must occur after the backlight is properly initialised */
>> > > - psb_lid_timer_init(dev_priv);
>> > > +
>> > > return 0;
>> > > }
>> > >
>> > > @@ -259,8 +258,6 @@ static int psb_chip_setup(struct drm_device *dev)
>> > >
>> > > static void psb_chip_teardown(struct drm_device *dev)
>> > > {
>> > > - struct drm_psb_private *dev_priv = to_drm_psb_private(dev);
>> > > - psb_lid_timer_takedown(dev_priv);
>> > > gma_intel_teardown_gmbus(dev);
>> > > }
>> > >
>> > > diff --git a/drivers/gpu/drm/gma500/psb_drv.h
>> > > b/drivers/gpu/drm/gma500/psb_drv.h
>> > > index c5edfa4aa4cc..83c17689c454 100644
>> > > --- a/drivers/gpu/drm/gma500/psb_drv.h
>> > > +++ b/drivers/gpu/drm/gma500/psb_drv.h
>> > > @@ -162,7 +162,6 @@
>> > > #define PSB_NUM_VBLANKS 2
>> > >
>> > > #define PSB_WATCHDOG_DELAY (HZ * 2)
>> > > -#define PSB_LID_DELAY (HZ / 10)
>> > >
>> > > #define PSB_MAX_BRIGHTNESS 100
>> > >
>> > > @@ -491,11 +490,7 @@ struct drm_psb_private {
>> > > /* Hotplug handling */
>> > > struct work_struct hotplug_work;
>> > >
>> > > - /* LID-Switch */
>> > > - spinlock_t lid_lock;
>> > > - struct timer_list lid_timer;
>> > > struct psb_intel_opregion opregion;
>> > > - u32 lid_last_state;
>> > >
>> > > /* Watchdog */
>> > > uint32_t apm_reg;
>> > > @@ -591,10 +586,6 @@ struct psb_ops {
>> > > int i2c_bus;/* I2C bus identifier for Moorestown */
>> > > };
>> > >
>> > > -/* psb_lid.c */
>> > > -extern void psb_lid_timer_init(struct drm_psb_private *dev_priv);
>> > > -extern void psb_lid_timer_takedown(struct drm_psb_private *dev_priv);
>> > > -
>> > > /* modesetting */
>> > > extern void psb_modeset_init(struct drm_device *dev);
>> > > extern void psb_modeset_cleanup(struct drm_device *dev);
>> > > diff --git a/drivers/gpu/drm/gma500/psb_lid.c
>> > > b/drivers/gpu/drm/gma500/psb_lid.c
>> > > deleted file mode 100644
>> > > index 58a7fe392636..
>> > > --- a/drivers/gpu/drm/gma500/psb_lid.c
>> > > +++ /dev/null
>> > > @@ -1,80 +0,0 @@
>> > > -// SPDX-License-Identifier: GPL-2.0-only
>> > > -/**
>> > > - * Copyright (c) 2007, Intel Corporation.
>> > > - *
>> > > - * Authors: Thomas Hellstrom
>> > > -
>> > >
Re: [PATCH 2/3] drm: drm_blend.c: Improve drm_plane_create_rotation_property kernel doc
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 expected result. > > > > > > Signed-off-by: Louis Chauvet > > > --- > > > drivers/gpu/drm/drm_blend.c | 52 > > > + > > > 1 file changed, 38 insertions(+), 14 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c > > > index 8d4b317eb9d7..6fbb8730d8b0 100644 > > > --- a/drivers/gpu/drm/drm_blend.c > > > +++ b/drivers/gpu/drm/drm_blend.c > > > @@ -104,6 +104,9 @@ > > > * Without this property the rectangle is only scaled, but not > > > rotated or > > > * reflected. > > > * > > > + * See drm_plane_create_rotation_property() for details about the > > > expected rotation and > > > + * reflection behavior. > > > > I think internal function docs should be referring to UAPI docs, and > > not vice versa. Internal functions can change, but UAPI cannot. > > > > > + * > > > * Possbile values: > > > * > > > * "rotate-": > > > @@ -114,18 +117,6 @@ > > > * Signals that the contents of a drm plane is reflected > > > along the > > > *axis, in the same way as mirroring. > > > * > > > - * reflect-x:: > > > - * > > > - * |o || o| > > > - * | | -> | | > > > - * | v||v | > > > - * > > > - * reflect-y:: > > > - * > > > - * |o || ^| > > > - * | | -> | | > > > - * | v||o | > > > - * > > > * zpos: > > > * Z position is set up with > > > drm_plane_create_zpos_immutable_property() and > > > * drm_plane_create_zpos_property(). It controls the visibility of > > > overlapping > > > @@ -266,8 +257,41 @@ EXPORT_SYMBOL(drm_plane_create_alpha_property); > > > * > > > * Rotation is the specified amount in degrees in counter clockwise > > > direction, > > > * the X and Y axis are within the source rectangle, i.e. the X/Y axis > > > before > > > - * rotation. After reflection, the rotation is applied to the image > > > sampled from > > > - * the source rectangle, before scaling it to fit the destination > > > rectangle. > > > + * rotation. > > > + * > > > + * Here are some examples of rotation and reflections: > > > + * > > > + * |o +| REFLECT_X |+ o| > > > + * || > || > > > + * || || > > > + * > > > + * |o | REFLECT_Y |+ | > > > + * || > || > > > + * |+ | |o | > > > + * > > > + * |o +| ROTATE_90 |+ | > > > + * || > || > > > + * || |o | > > > + * > > > + * |o | ROTATE_180 | +| > > > + * || > || > > > + * |+ | | o| > > > + * > > > + * |o | ROTATE_270 |+ o| > > > + * || > || > > > + * |+ | || > > > + * > > > + * Rotation and reflection can be combined to handle more situations. In > > > this condition, the > > > + * reflection is applied first and the rotation in second. > > > > When going in which direction? Is the first image the FB source > > rectangle contents, and the second image what the plane looks like in > > CRTC frame of reference? > > The first is the FB source, the second is the expected result on the CRTC > output. > > I will add a sentence before the schemas: > > * Here are some examples of rotation and reflections, on the left it is > * the content of the source frame buffer, on the right is the expected > * result on the CRTC output. > > > > > > + * > > > + * For example the expected result for DRM_MODE_ROTATE_90 | > > > DRM_MODE_REFLECT_X is: > > > + * > > > + * |o +| REFLECT_X |+ o| ROTATE_90 |o | > > > + * || > || > || > > > + * || || |+ | > > > + * > > > + * It is not possible to pass multiple rotation at the same time. (i.e > > > ROTATE_90 | ROTATE_180 is > > > + * not the same as ROTATE_270 and is not accepted). > > > */ > > > int drm_plane_create_rotation_property(struct drm_plane *plane, > > > unsigned int rotation, > > > > > > > These are definitely improvements. I think they should just be in the > > UAPI section rather than implementation details. > > So, somewhere in [1]? It feel strange because this is in the `GPU Driver > Developer’s Guide` section, not a `UAPI interfaces`. The whole kernel documentation layout is a big mess. I *still* spend ages trying to find the pages I know exist. https://docs.kernel.org/gpu/drm-kms.html#plane-composition-properties is where properties are documented for userspace developers
Re: [REBASE 7/7] drm/edid: make drm_edid_are_equal() more convenient for its single user
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 single user, and rename drm_edid_eq(). Functionally deduce the length from the blob size, not the blob data, making it more robust against any errors. Could be squashed into patch 6. Ack. Thanks for the review. I'll hold of on resending these until there are some R-b's... I've send them a few times already with no comments. :( Feel free to add Reviewed-by: Thomas Zimmermann to the series. 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. Best regards Thomas BR, Jani. -- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)
[PATCH v2] drm/mediatek/dp: fix mtk_dp_aux_transfer return value
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: f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort driver")
Signed-off-by: Wojciech Macek
---
Changelog v2-v1:
- added "Fixes" tag
- corrected e-mail address
V1:
https://patchwork.kernel.org/project/linux-mediatek/patch/20240402071113.3135903-1-wma...@chromium.org/
drivers/gpu/drm/mediatek/mtk_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c
b/drivers/gpu/drm/mediatek/mtk_dp.c
index 0ba72102636a..536366956447 100644
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -2104,7 +2104,7 @@ static ssize_t mtk_dp_aux_transfer(struct drm_dp_aux
*mtk_aux,
if (mtk_dp->bridge.type != DRM_MODE_CONNECTOR_eDP &&
!mtk_dp->train_info.cable_plugged_in) {
- ret = -EAGAIN;
+ ret = -EIO;
goto err;
}
--
2.44.0.683.g7961c838ac-goog
Re: [PATCH v4 6/7] drm: xlnx: zynqmp_dpsub: Set input live format
On 16/04/2024 23:31, Anatoliy Klymenko wrote:
Program live video input format according to selected media bus format.
In the bridge mode of operation, DPSUB is connected to FPGA CRTC which
almost certainly supports a single media bus format as its output. Expect
this to be delivered via the new bridge atomic state. Program DPSUB
registers accordingly.
Signed-off-by: Anatoliy Klymenko
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 92 --
drivers/gpu/drm/xlnx/zynqmp_disp.h | 2 +
drivers/gpu/drm/xlnx/zynqmp_dp.c | 13 --
3 files changed, 90 insertions(+), 17 deletions(-)
Reviewed-by: Tomi Valkeinen
Tomi
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 8cdd74a9b772..13157da0089e 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -436,19 +436,29 @@ static void zynqmp_disp_avbuf_set_format(struct
zynqmp_disp *disp,
const struct zynqmp_disp_format *fmt)
{
unsigned int i;
- u32 val;
+ u32 val, reg;
- val = zynqmp_disp_avbuf_read(disp, ZYNQMP_DISP_AV_BUF_FMT);
- val &= zynqmp_disp_layer_is_video(layer)
- ? ~ZYNQMP_DISP_AV_BUF_FMT_NL_VID_MASK
- : ~ZYNQMP_DISP_AV_BUF_FMT_NL_GFX_MASK;
- val |= fmt->buf_fmt;
- zynqmp_disp_avbuf_write(disp, ZYNQMP_DISP_AV_BUF_FMT, val);
+ layer->disp_fmt = fmt;
+ if (layer->mode == ZYNQMP_DPSUB_LAYER_NONLIVE) {
+ reg = ZYNQMP_DISP_AV_BUF_FMT;
+ val = zynqmp_disp_avbuf_read(disp, ZYNQMP_DISP_AV_BUF_FMT);
+ val &= zynqmp_disp_layer_is_video(layer)
+ ? ~ZYNQMP_DISP_AV_BUF_FMT_NL_VID_MASK
+ : ~ZYNQMP_DISP_AV_BUF_FMT_NL_GFX_MASK;
+ val |= fmt->buf_fmt;
+ zynqmp_disp_avbuf_write(disp, reg, val);
+ } else {
+ reg = zynqmp_disp_layer_is_video(layer)
+ ? ZYNQMP_DISP_AV_BUF_LIVE_VID_CONFIG
+ : ZYNQMP_DISP_AV_BUF_LIVE_GFX_CONFIG;
+ val = fmt->buf_fmt;
+ zynqmp_disp_avbuf_write(disp, reg, val);
+ }
for (i = 0; i < ZYNQMP_DISP_AV_BUF_NUM_SF; i++) {
- unsigned int reg = zynqmp_disp_layer_is_video(layer)
-? ZYNQMP_DISP_AV_BUF_VID_COMP_SF(i)
-: ZYNQMP_DISP_AV_BUF_GFX_COMP_SF(i);
+ reg = zynqmp_disp_layer_is_video(layer)
+ ? ZYNQMP_DISP_AV_BUF_VID_COMP_SF(i)
+ : ZYNQMP_DISP_AV_BUF_GFX_COMP_SF(i);
zynqmp_disp_avbuf_write(disp, reg, fmt->sf[i]);
}
@@ -926,6 +936,31 @@ zynqmp_disp_layer_find_format(struct zynqmp_disp_layer
*layer,
return NULL;
}
+/**
+ * zynqmp_disp_layer_find_live_format - Find format information for given
+ * media bus format
+ * @layer: The layer
+ * @drm_fmt: Media bus format to search
+ *
+ * Search display subsystem format information corresponding to the given media
+ * bus format @media_bus_format for the @layer, and return a pointer to the
+ * format descriptor.
+ *
+ * Return: A pointer to the format descriptor if found, NULL otherwise
+ */
+static const struct zynqmp_disp_format *
+zynqmp_disp_layer_find_live_format(struct zynqmp_disp_layer *layer,
+ u32 media_bus_format)
+{
+ unsigned int i;
+
+ for (i = 0; i < layer->info->num_formats; i++)
+ if (layer->info->formats[i].bus_fmt == media_bus_format)
+ return >info->formats[i];
+
+ return NULL;
+}
+
/**
* zynqmp_disp_layer_drm_formats - Return the DRM formats supported by the
layer
* @layer: The layer
@@ -1040,6 +1075,9 @@ void zynqmp_disp_layer_disable(struct zynqmp_disp_layer
*layer)
* @layer: The layer
* @info: The format info
*
+ * NOTE: Use zynqmp_disp_layer_set_live_format() to set media bus format for
+ * live video layers.
+ *
* Set the format for @layer to @info. The layer must be disabled.
*/
void zynqmp_disp_layer_set_format(struct zynqmp_disp_layer *layer,
@@ -1047,14 +1085,16 @@ void zynqmp_disp_layer_set_format(struct
zynqmp_disp_layer *layer,
{
unsigned int i;
+ if (WARN_ON(layer->mode != ZYNQMP_DPSUB_LAYER_NONLIVE))
+ return;
+
layer->disp_fmt = zynqmp_disp_layer_find_format(layer, info->format);
+ if (WARN_ON(!layer->disp_fmt))
+ return;
layer->drm_fmt = info;
zynqmp_disp_avbuf_set_format(layer->disp, layer, layer->disp_fmt);
- if (layer->mode == ZYNQMP_DPSUB_LAYER_LIVE)
- return;
-
/*
* Set pconfig for each DMA channel to indicate they're part of a
* video group.
@@ -1074,6 +1114,32 @@ void zynqmp_disp_layer_set_format(struct
zynqmp_disp_layer *layer,
}
}
+/**
+ * zynqmp_disp_layer_set_live_format - Set the live video layer format
+ * @layer: The layer
+ * @info:
Re: [PATCH v2 18/18] arm64: dts: mediatek: add display support for mt8365-evk
Il 16/04/24 17:53, Alexandre Mergnat ha scritto:
MIPI DSI:
- Add "vsys_lcm_reg" regulator support and setup the "mt6357_vsim1_reg",
to power the pannel plugged to the DSI connector.
- Setup the Display Parallel Interface.
- Add the startek kd070fhfid015 pannel support.
HDMI:
- Add HDMI connector support.
- Add the "ite,it66121" HDMI bridge support, driven by I2C1.
- Setup the Display Parallel Interface.
Signed-off-by: Alexandre Mergnat
---
arch/arm64/boot/dts/mediatek/mt8365-evk.dts | 182
1 file changed, 182 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8365-evk.dts
b/arch/arm64/boot/dts/mediatek/mt8365-evk.dts
index 50cbaefa1a99..4afdcbefc481 100644
--- a/arch/arm64/boot/dts/mediatek/mt8365-evk.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8365-evk.dts
@@ -26,6 +26,18 @@ chosen {
stdout-path = "serial0:921600n8";
};
+ connector {
+ compatible = "hdmi-connector";
+ label = "hdmi";
+ type = "d";
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <_connector_out>;
+ };
+ };
+ };
+
firmware {
optee {
compatible = "linaro,optee-tz";
@@ -86,6 +98,56 @@ optee_reserved: optee@4320 {
reg = <0 0x4320 0 0x00c0>;
};
};
+
+ vsys_lcm_reg: regulator-vsys-lcm {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = < 129 GPIO_ACTIVE_HIGH>;
+ regulator-max-microvolt = <500>;
+ regulator-min-microvolt = <500>;
+ regulator-name = "vsys_lcm";
+ };
+};
+
+ {
+ pinctrl-0 = <_default_pins>;
+ pinctrl-1 = <_idle_pins>;
+ pinctrl-names = "default", "sleep";
+ status = "okay";
+
+ port {
+ dpi_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+};
+
+ {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ panel@0 {
+ compatible = "startek,kd070fhfid015";
+ status = "okay";
status is always okay, unless it's disabled.
+ reg = <0>;
+ enable-gpios = < 67 GPIO_ACTIVE_HIGH>;
+ reset-gpios = < 20 GPIO_ACTIVE_HIGH>;
+ iovcc-supply = <_vsim1_reg>;
+ power-supply = <_lcm_reg>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+
+ port {
+ dsi_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
};
{
@@ -138,6 +200,50 @@ {
status = "okay";
};
+ {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-div = <2>;
+ clock-frequency = <10>;
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ it66121hdmitx: it66121hdmitx@4c {
Can we please get an actually readable name for this node?
Just a suggestion (you're free to rename however you want)
it66121_hdmi: hdmi@4c {
+ #sound-dai-cells = <0>;
+ compatible = "ite,it66121";
+ interrupt-parent = <>;
+ interrupts = <68 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+ reg = <0x4c>;
+ reset-gpios = < 69 GPIO_ACTIVE_LOW>;
+ vcn18-supply = <_vsim2_reg>;
+ vcn33-supply = <_vibr_reg>;
+ vrf12-supply = <_vrf12_reg>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ it66121_in: endpoint {
+ bus-width = <12>;
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ hdmi_connector_out: endpoint {
+ remote-endpoint = <_connector_in>;
+ };
+ };
+ };
+ };
+};
+
{
assigned-clock-parents = < CLK_TOP_MSDCPLL>;
assigned-clocks = < CLK_TOP_MSDC50_0_SEL>;
@@ -180,7 +286,55 @@ _pmic {
#interrupt-cells = <2>;
};
+_vsim1_reg {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+};
+
{
+ dpi_default_pins: dpi-default-pins {
+ pins {
+ pinmux = ,
+
Re: [PATCH v2 17/18] arm64: dts: mediatek: add display blocks support for the MT8365 SoC
Il 16/04/24 17:53, Alexandre Mergnat ha scritto:
- Add aliases for each display components to help display drivers.
- Add the Display Pulse Width Modulation (DISP_PWM) to provide PWM signals
for the LED driver of mobile LCM.
- Add the MIPI Display Serial Interface (DSI) PHY support. (up to 4-lane
output)
- Add the display mutex support.
- Add the following display component support:
- OVL0 (Overlay)
- RDMA0 (Data Path Read DMA)
- Color0
- CCorr0 (Color Correction)
- AAL0 (Adaptive Ambient Light)
- GAMMA0
- Dither0
- DSI0 (Display Serial Interface)
- RDMA1 (Data Path Read DMA)
- DPI0 (Display Parallel Interface)
Signed-off-by: Alexandre Mergnat
---
arch/arm64/boot/dts/mediatek/mt8365.dtsi | 146 +++
1 file changed, 146 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8365.dtsi
b/arch/arm64/boot/dts/mediatek/mt8365.dtsi
index 24581f7410aa..a95f90da4491 100644
--- a/arch/arm64/boot/dts/mediatek/mt8365.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8365.dtsi
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
@@ -17,6 +18,19 @@ / {
#address-cells = <2>;
#size-cells = <2>;
+ aliases {
+ aal0 =
+ ccorr0 =
+ color0 =
+ dither0 =
+ dpi0 =
+ dsi0 =
+ gamma0 =
+ ovl0 =
+ rdma0 =
+ rdma1 =
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -607,6 +621,17 @@ spi: spi@1100a000 {
status = "disabled";
};
+ disp_pwm: pwm@1100e000 {
+ compatible = "mediatek,mt8365-disp-pwm",
+"mediatek,mt8183-disp-pwm";
Fits in a single line
+ reg = <0 0x1100e000 0 0x1000>;
+ clock-names = "main", "mm";
+ clocks = < CLK_TOP_DISP_PWM_SEL>,
+< CLK_IFR_DISP_PWM>;
same
+ power-domains = < MT8365_POWER_DOMAIN_MM>;
+ #pwm-cells = <2>;
+ };
+
i2c3: i2c@1100f000 {
compatible = "mediatek,mt8365-i2c",
"mediatek,mt8168-i2c";
reg = <0 0x1100f000 0 0xa0>, <0 0x11000200 0 0x80>;
@@ -703,6 +728,15 @@ ethernet: ethernet@112a {
status = "disabled";
};
+ mipi_tx0: dsi-phy@11c0 {
+ compatible = "mediatek,mt8365-mipi-tx",
"mediatek,mt8183-mipi-tx";
+ reg = <0 0x11c0 0 0x800>;
+ clock-output-names = "mipi_tx0_pll";
+ clocks = <>;
+ #clock-cells = <0>;
+ #phy-cells = <0>;
+ };
+
u3phy: t-phy@11cc {
compatible = "mediatek,mt8365-tphy",
"mediatek,generic-tphy-v2";
#address-cells = <1>;
@@ -732,6 +766,13 @@ mmsys: syscon@1400 {
#clock-cells = <1>;
};
+ mutex: mutex@14001000 {
+ compatible = "mediatek,mt8365-disp-mutex";
+ reg = <0 0x14001000 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8365_POWER_DOMAIN_MM>;
+ };
+
smi_common: smi@14002000 {
compatible = "mediatek,mt8365-smi-common";
reg = <0 0x14002000 0 0x1000>;
@@ -755,6 +796,111 @@ larb0: larb@14003000 {
mediatek,larb-id = <0>;
};
+ ovl0: ovl@1400b000 {
+ compatible = "mediatek,mt8365-disp-ovl",
+"mediatek,mt8192-disp-ovl";
single line
+ reg = <0 0x1400b000 0 0x1000>;
+ clocks = < CLK_MM_MM_DISP_OVL0>;
+ interrupts = ;
+ iommus = < M4U_PORT_DISP_OVL0>;
+ power-domains = < MT8365_POWER_DOMAIN_MM>;
+ };
+
+ rdma0: rdma@1400d000 {
+ compatible = "mediatek,mt8365-disp-rdma",
+"mediatek,mt8183-disp-rdma";
ditto
+ reg = <0 0x1400d000 0 0x1000>;
+ clocks = < CLK_MM_MM_DISP_RDMA0>;
+ interrupts = ;
+ iommus = < M4U_PORT_DISP_RDMA0>;
+ mediatek,rdma-fifo-size = <5120>;
+ power-domains = < MT8365_POWER_DOMAIN_MM>;
+ };
+
+ color0: color@1400f000 {
+ compatible = "mediatek,mt8365-disp-color",
+"mediatek,mt8173-disp-color";
...and all the others too (maybe not
Re: [PATCH v4 4/7] drm: xlnx: zynqmp_dpsub: Anounce supported input formats
On 16/04/2024 23:31, Anatoliy Klymenko wrote:
DPSUB in bridge mode supports multiple input media bus formats.
Announce the list of supported input media bus formats via
drm_bridge.atomic_get_input_bus_fmts callback. Introduce a set of live
input formats supported by DPSUB. Add safeguards to format list functions
to prevent their misuse in the different layer modes contexts.
Reviewed-by: Laurent Pinchart
Signed-off-by: Anatoliy Klymenko
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 110 +++--
drivers/gpu/drm/xlnx/zynqmp_disp.h | 2 +
drivers/gpu/drm/xlnx/zynqmp_dp.c | 31 +++
3 files changed, 139 insertions(+), 4 deletions(-)
Reviewed-by: Tomi Valkeinen
Tomi
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 891577475349..24f1f367b1d3 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -77,12 +78,14 @@ enum zynqmp_dpsub_layer_mode {
/**
* struct zynqmp_disp_format - Display subsystem format information
* @drm_fmt: DRM format (4CC)
+ * @bus_fmt: Media bus format
* @buf_fmt: AV buffer format
* @swap: Flag to swap R & B for RGB formats, and U & V for YUV formats
* @sf: Scaling factors for color components
*/
struct zynqmp_disp_format {
u32 drm_fmt;
+ u32 bus_fmt;
u32 buf_fmt;
bool swap;
const u32 *sf;
@@ -182,6 +185,12 @@ static const u32 scaling_factors_565[] = {
ZYNQMP_DISP_AV_BUF_5BIT_SF,
};
+static const u32 scaling_factors_666[] = {
+ ZYNQMP_DISP_AV_BUF_6BIT_SF,
+ ZYNQMP_DISP_AV_BUF_6BIT_SF,
+ ZYNQMP_DISP_AV_BUF_6BIT_SF,
+};
+
static const u32 scaling_factors_888[] = {
ZYNQMP_DISP_AV_BUF_8BIT_SF,
ZYNQMP_DISP_AV_BUF_8BIT_SF,
@@ -364,6 +373,41 @@ static const struct zynqmp_disp_format avbuf_gfx_fmts[] = {
},
};
+/* List of live video layer formats */
+static const struct zynqmp_disp_format avbuf_live_fmts[] = {
+ {
+ .drm_fmt= DRM_FORMAT_RGB565,
+ .bus_fmt= MEDIA_BUS_FMT_RGB666_1X18,
+ .buf_fmt= ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_BPC_6 |
+ ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_RGB,
+ .sf = scaling_factors_666,
+ }, {
+ .drm_fmt= DRM_FORMAT_RGB888,
+ .bus_fmt= MEDIA_BUS_FMT_RGB888_1X24,
+ .buf_fmt= ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_BPC_8 |
+ ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_RGB,
+ .sf = scaling_factors_888,
+ }, {
+ .drm_fmt= DRM_FORMAT_YUV422,
+ .bus_fmt= MEDIA_BUS_FMT_UYVY8_1X16,
+ .buf_fmt= ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_BPC_8 |
+ ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_YUV422,
+ .sf = scaling_factors_888,
+ }, {
+ .drm_fmt= DRM_FORMAT_YUV444,
+ .bus_fmt= MEDIA_BUS_FMT_VUY8_1X24,
+ .buf_fmt= ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_BPC_8 |
+ ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_YUV444,
+ .sf = scaling_factors_888,
+ }, {
+ .drm_fmt= DRM_FORMAT_P210,
+ .bus_fmt= MEDIA_BUS_FMT_UYVY10_1X20,
+ .buf_fmt= ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_BPC_10 |
+ ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_YUV422,
+ .sf = scaling_factors_101010,
+ },
+};
+
static u32 zynqmp_disp_avbuf_read(struct zynqmp_disp *disp, int reg)
{
return readl(disp->avbuf.base + reg);
@@ -887,6 +931,11 @@ zynqmp_disp_layer_find_format(struct zynqmp_disp_layer
*layer,
* @layer: The layer
* @num_formats: Pointer to the returned number of formats
*
+ * NOTE: This function doesn't make sense for live video layers and will
+ * always return an empty list in such cases. zynqmp_disp_live_layer_formats()
+ * should be used to query a list of media bus formats supported by the live
+ * video input layer.
+ *
* Return: A newly allocated u32 array that stores all the DRM formats
* supported by the layer. The number of formats in the array is returned
* through the num_formats argument.
@@ -897,10 +946,17 @@ u32 *zynqmp_disp_layer_drm_formats(struct
zynqmp_disp_layer *layer,
unsigned int i;
u32 *formats;
+ if (WARN_ON(!layer->mode == ZYNQMP_DPSUB_LAYER_NONLIVE)) {
+ *num_formats = 0;
+ return NULL;
+ }
+
formats = kcalloc(layer->info->num_formats, sizeof(*formats),
GFP_KERNEL);
- if (!formats)
+ if (!formats) {
+ *num_formats = 0;
