Re: [PATCH 2/2] phy: mtk-mipi-csi: add driver for CSI phy
On Mon, 2023-04-03 at 09:19 +0200, Julien Stephan wrote: > External email : Please do not click links or open attachments until > you have verified the sender or the content. > > > From: Phi-bang Nguyen > > This is a new driver that supports the MIPI CSI CD-PHY for mediatek > mt8365 soc > > Signed-off-by: Louis Kuo > Signed-off-by: Phi-bang Nguyen > [Julien Stephan: use regmap] > [Julien Stephan: use GENMASK] > Co-developed-by: Julien Stephan > Signed-off-by: Julien Stephan > --- > .../bindings/phy/mediatek,csi-phy.yaml| 9 +- > MAINTAINERS | 1 + > drivers/phy/mediatek/Kconfig | 8 + > drivers/phy/mediatek/Makefile | 2 + > .../phy/mediatek/phy-mtk-mipi-csi-rx-reg.h| 435 > ++ > drivers/phy/mediatek/phy-mtk-mipi-csi.c | 392 > 6 files changed, 845 insertions(+), 2 deletions(-) > create mode 100644 drivers/phy/mediatek/phy-mtk-mipi-csi-rx-reg.h > create mode 100644 drivers/phy/mediatek/phy-mtk-mipi-csi.c Please cc linux-media...@lists.infradead.org > > ... > diff --git a/MAINTAINERS b/MAINTAINERS > index 9308b4bb88bf..b3077eddd0bf 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -13103,6 +13103,7 @@ M: Julien Stephan > > M: Andy Hsieh > S: Supported > F: Documentation/devicetree/bindings/phy/mediatek,csi-phy.yaml > +F: drivers/phy/mediatek/phy-mtk-mipi-csi* > > MEDIATEK MMC/SD/SDIO DRIVER > M: Chaotian Jing separate a new patch for MAINTAINERS change? > diff --git a/drivers/phy/mediatek/Kconfig > b/drivers/phy/mediatek/Kconfig > index 3125ecb5d119..63fb0fa77573 100644 > --- a/drivers/phy/mediatek/Kconfig > +++ b/drivers/phy/mediatek/Kconfig > @@ -74,3 +74,11 @@ config PHY_MTK_DP > select GENERIC_PHY > help > Support DisplayPort PHY for MediaTek SoCs. > + > +config PHY_MTK_MIPI_CSI > + tristate "MediaTek CSI CD-PHY Driver" > + depends on ARCH_MEDIATEK && OF > + select GENERIC_PHY > + help > + Enable this to support the MIPI CSI CD-PHY receiver. > + The driver supports multiple CSI cdphy ports > simultaneously. > diff --git a/drivers/phy/mediatek/Makefile > b/drivers/phy/mediatek/Makefile > index fb1f8edaffa7..9a178c1c2628 100644 > --- a/drivers/phy/mediatek/Makefile > +++ b/drivers/phy/mediatek/Makefile > @@ -18,3 +18,5 @@ phy-mtk-mipi-dsi-drv-y:= > phy-mtk-mipi-dsi.o > phy-mtk-mipi-dsi-drv-y += phy-mtk-mipi-dsi-mt8173.o > phy-mtk-mipi-dsi-drv-y += phy-mtk-mipi-dsi-mt8183.o > obj-$(CONFIG_PHY_MTK_MIPI_DSI) += phy-mtk-mipi-dsi-drv.o > + > +obj-$(CONFIG_PHY_MTK_MIPI_CSI) += phy-mtk-mipi-csi.o > diff --git a/drivers/phy/mediatek/phy-mtk-mipi-csi-rx-reg.h > b/drivers/phy/mediatek/phy-mtk-mipi-csi-rx-reg.h > new file mode 100644 > index ..f360e807e3d1 > --- /dev/null > +++ b/drivers/phy/mediatek/phy-mtk-mipi-csi-rx-reg.h > @@ -0,0 +1,435 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > + > +#ifndef __MIPI_CDPHY_RX_REG_H__ > +#define __MIPI_CDPHY_RX_REG_H__ > + > +/* > + * CSI1 and CSI2 are identical, and similar to CSI0. All CSIx macros > are > + * applicable to the three PHYs. Where differences exist, they are > denoted by > + * macro names using CSI0 and CSI1, the latter being applicable to > CSI1 and > + * CSI2 alike. > + */ > + > +/* > + * Due to lanes supporting C-PHY mode on CSI0, register fields that > control the > + * behaviour of lanes are named differently between CSI0 and > CSI1/CSI2, even > + * when they control parameters that are agnostic to the PHY mode. > In those > + * cases, the macros below use the CSI0 field names (e.g. > + * MIPI_RX_ANA08_CSIxA_RG_CSIxA_L0P_T0A_HSRT_CODE_SHIFT). > + */ > + > > > +#define > MIPI_RX_ANA24_CSIxA_RG_CSIxA_RESERVE_SHIFT > 24 > +#define > MIPI_RX_ANA24_CSIxA_RG_CSIxA_RESERVE_MASK > (0xff << 24) Use GENMASK() > + > +/* CSI0-specific register. */ > +#define > MIPI_RX_ANA28_CSI0A > 0x0028 > +#define > MIPI_RX_ANA28_CSI0A_RG_CSI0A_CPHY_T0_CDR_DIRECT_EN_SHIFT > 0 > > > +#define > MIPI_RX_ANA48_CSIxA_RGS_CSI1A_DPHY_L2_OS_CAL_CPLT_SHIFT > 5 > +#define > MIPI_RX_ANA48_CSIxA_RGS_CSI1A_DPHY_L2_OS_CAL_CPLT_MASK > BIT(5) > +/* Common fields. */ > +#define > MIPI_RX_ANA48_CSIxA_RGS_CSIxA_OS_CAL_CODE_SHIFT > 8 > +#define > MIPI_RX_ANA48_CSIxA_RGS_CSIxA_OS_CAL_CODE_MASK > GENMASK(15, 8) > + > +#define > MIPI_RX_WRAPPER80_CSIxA > 0x0080 > +#define > MIPI_RX_WRAPPER80_CSIxA_CSR_CSI_CLK_MON_SHIFT > 0 > +#define > MIPI_RX_WRAPPER80_CSIxA_CSR_CSI_CLK_MON_MASK > BIT(0) > +#define >
Re: [PATCH 2/2] phy: mtk-mipi-csi: add driver for CSI phy
On Mon, 2023-04-03 at 09:19 +0200, Julien Stephan wrote: > External email : Please do not click links or open attachments until > you have verified the sender or the content. > > > From: Phi-bang Nguyen > > This is a new driver that supports the MIPI CSI CD-PHY for mediatek > mt8365 soc > > Signed-off-by: Louis Kuo > Signed-off-by: Phi-bang Nguyen > [Julien Stephan: use regmap] > [Julien Stephan: use GENMASK] > Co-developed-by: Julien Stephan > Signed-off-by: Julien Stephan > --- > .../bindings/phy/mediatek,csi-phy.yaml| 9 +- > MAINTAINERS | 1 + > drivers/phy/mediatek/Kconfig | 8 + > drivers/phy/mediatek/Makefile | 2 + > .../phy/mediatek/phy-mtk-mipi-csi-rx-reg.h| 435 > ++ > drivers/phy/mediatek/phy-mtk-mipi-csi.c | 392 > 6 files changed, 845 insertions(+), 2 deletions(-) > create mode 100644 drivers/phy/mediatek/phy-mtk-mipi-csi-rx-reg.h > create mode 100644 drivers/phy/mediatek/phy-mtk-mipi-csi.c Please cc linux-media...@lists.infradead.org > > ... > diff --git a/MAINTAINERS b/MAINTAINERS > index 9308b4bb88bf..b3077eddd0bf 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -13103,6 +13103,7 @@ M: Julien Stephan > > > M: Andy Hsieh > S: Supported > F: Documentation/devicetree/bindings/phy/mediatek,csi-phy.yaml > +F: drivers/phy/mediatek/phy-mtk-mipi-csi* > > MEDIATEK MMC/SD/SDIO DRIVER > M: Chaotian Jing separate a new patch for MAINTAINERS change? > diff --git a/drivers/phy/mediatek/Kconfig > b/drivers/phy/mediatek/Kconfig > index 3125ecb5d119..63fb0fa77573 100644 > --- a/drivers/phy/mediatek/Kconfig > +++ b/drivers/phy/mediatek/Kconfig > @@ -74,3 +74,11 @@ config PHY_MTK_DP > select GENERIC_PHY > help > Support DisplayPort PHY for MediaTek SoCs. > + > +config PHY_MTK_MIPI_CSI > + tristate "MediaTek CSI CD-PHY Driver" > + depends on ARCH_MEDIATEK && OF > + select GENERIC_PHY > + help > + Enable this to support the MIPI CSI CD-PHY receiver. > + The driver supports multiple CSI cdphy ports > simultaneously. > diff --git a/drivers/phy/mediatek/Makefile > b/drivers/phy/mediatek/Makefile > index fb1f8edaffa7..9a178c1c2628 100644 > --- a/drivers/phy/mediatek/Makefile > +++ b/drivers/phy/mediatek/Makefile > @@ -18,3 +18,5 @@ phy-mtk-mipi-dsi-drv-y:= > phy-mtk-mipi-dsi.o > phy-mtk-mipi-dsi-drv-y += phy-mtk-mipi-dsi-mt8173.o > phy-mtk-mipi-dsi-drv-y += phy-mtk-mipi-dsi-mt8183.o > obj-$(CONFIG_PHY_MTK_MIPI_DSI) += phy-mtk-mipi-dsi-drv.o > + > +obj-$(CONFIG_PHY_MTK_MIPI_CSI) += phy-mtk-mipi-csi.o > diff --git a/drivers/phy/mediatek/phy-mtk-mipi-csi-rx-reg.h > b/drivers/phy/mediatek/phy-mtk-mipi-csi-rx-reg.h > new file mode 100644 > index ..f360e807e3d1 > --- /dev/null > +++ b/drivers/phy/mediatek/phy-mtk-mipi-csi-rx-reg.h > @@ -0,0 +1,435 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > + > +#ifndef __MIPI_CDPHY_RX_REG_H__ > +#define __MIPI_CDPHY_RX_REG_H__ > + > +/* > + * CSI1 and CSI2 are identical, and similar to CSI0. All CSIx macros > are > + * applicable to the three PHYs. Where differences exist, they are > denoted by > + * macro names using CSI0 and CSI1, the latter being applicable to > CSI1 and > + * CSI2 alike. > + */ > + > +/* > + * Due to lanes supporting C-PHY mode on CSI0, register fields that > control the > + * behaviour of lanes are named differently between CSI0 and > CSI1/CSI2, even > + * when they control parameters that are agnostic to the PHY mode. > In those > + * cases, the macros below use the CSI0 field names (e.g. > + * MIPI_RX_ANA08_CSIxA_RG_CSIxA_L0P_T0A_HSRT_CODE_SHIFT). > + */ > + > > > +#define > MIPI_RX_ANA24_CSIxA_RG_CSIxA_RESERVE_SHIFT > 24 > +#define > MIPI_RX_ANA24_CSIxA_RG_CSIxA_RESERVE_MASK > (0xff << 24) Use GENMASK() > + > +/* CSI0-specific register. */ > +#define > MIPI_RX_ANA28_CSI0A > 0x0028 > +#define > MIPI_RX_ANA28_CSI0A_RG_CSI0A_CPHY_T0_CDR_DIRECT_EN_SHIFT > 0 > > > +#define > MIPI_RX_ANA48_CSIxA_RGS_CSI1A_DPHY_L2_OS_CAL_CPLT_SHIFT > 5 > +#define > MIPI_RX_ANA48_CSIxA_RGS_CSI1A_DPHY_L2_OS_CAL_CPLT_MASK > BIT(5) > +/* Common fields. */ > +#define > MIPI_RX_ANA48_CSIxA_RGS_CSIxA_OS_CAL_CODE_SHIFT > 8 > +#define > MIPI_RX_ANA48_CSIxA_RGS_CSIxA_OS_CAL_CODE_MASK > GENMASK(15, 8) > + > +#define > MIPI_RX_WRAPPER80_CSIxA > 0x0080 > +#define > MIPI_RX_WRAPPER80_CSIxA_CSR_CSI_CLK_MON_SHIFT > 0 > +#define > MIPI_RX_WRAPPER80_CSIxA_CSR_CSI_CLK_MON_MASK > BIT(0) > +#define >
RE: [PATCH 0/7] Enable YCbCr420 format for VDSC
Hi Dmitry > -Original Message- > From: Dmitry Baryshkov > Sent: Friday, April 7, 2023 8:28 AM > To: Kandpal, Suraj ; Jani Nikula > ; dri-devel@lists.freedesktop.org; intel- > g...@lists.freedesktop.org > Cc: Nautiyal, Ankit K ; Shankar, Uma > ; Maarten Lankhorst > > Subject: Re: [PATCH 0/7] Enable YCbCr420 format for VDSC > > Hi Suraj > > On 28/03/2023 16:20, Kandpal, Suraj wrote: > > > > > >> -Original Message- > >> From: dri-devel On Behalf > >> Of Jani Nikula > >> Sent: Wednesday, March 8, 2023 5:00 PM > >> To: Kandpal, Suraj ; dri- > >> de...@lists.freedesktop.org; intel-...@lists.freedesktop.org > >> Cc: Dmitry Baryshkov ; Nautiyal, Ankit K > >> ; Shankar, Uma ; > >> Kandpal, Suraj > >> Subject: Re: [PATCH 0/7] Enable YCbCr420 format for VDSC > >> > >> On Wed, 22 Feb 2023, Suraj Kandpal wrote: > >>> This patch series aims to enable the YCbCr420 format for DSC. > >>> Changes are mostly compute params related for hdmi,dp and dsi along > >>> with the addition of new rc_tables for native_420 and corresponding > >>> changes to macros used to fetch them. > >>> There have been discussions prior to this series in which some > >>> patches have gotten rb and can be found in the below link > >>> https://patchwork.freedesktop.org/series/113729 > >> > >> I think it would be useful to get [1] from Dmitry merged to > >> drm-misc-next first, have that in drm-next, and again backmerged to > >> drm-intel-next before this. At least patches 1-5. > >> > >> There's not much point in all drivers duplicating the parameters, and > >> we need to move towards common code. Dmitry has been helpful in > >> contributing this to us. > >> > >> BR, > >> Jani. > >> > >> > > > > Hi Jani, > > Maarten has acked the patch series to be merged through drm-intel and > > in the meantime I will work with Dmitry to pull the common code to > > avoid duplication > > I wanted to check, are there any updates from your side regarding the series > at [1] ? > Will have a look and float comments if any by Monday > > > > Regards, > > Suraj Kandpal > > > >> [1] https://patchwork.freedesktop.org/series/114473/ > > > > -- > With best wishes > Dmitry Regards, Suraj Kandpal
Re: [PATCH 0/7] Enable YCbCr420 format for VDSC
Hi Suraj On 28/03/2023 16:20, Kandpal, Suraj wrote: -Original Message- From: dri-devel On Behalf Of Jani Nikula Sent: Wednesday, March 8, 2023 5:00 PM To: Kandpal, Suraj ; dri- de...@lists.freedesktop.org; intel-...@lists.freedesktop.org Cc: Dmitry Baryshkov ; Nautiyal, Ankit K ; Shankar, Uma ; Kandpal, Suraj Subject: Re: [PATCH 0/7] Enable YCbCr420 format for VDSC On Wed, 22 Feb 2023, Suraj Kandpal wrote: This patch series aims to enable the YCbCr420 format for DSC. Changes are mostly compute params related for hdmi,dp and dsi along with the addition of new rc_tables for native_420 and corresponding changes to macros used to fetch them. There have been discussions prior to this series in which some patches have gotten rb and can be found in the below link https://patchwork.freedesktop.org/series/113729 I think it would be useful to get [1] from Dmitry merged to drm-misc-next first, have that in drm-next, and again backmerged to drm-intel-next before this. At least patches 1-5. There's not much point in all drivers duplicating the parameters, and we need to move towards common code. Dmitry has been helpful in contributing this to us. BR, Jani. Hi Jani, Maarten has acked the patch series to be merged through drm-intel and in the meantime I will work with Dmitry to pull the common code to avoid duplication I wanted to check, are there any updates from your side regarding the series at [1] ? Regards, Suraj Kandpal [1] https://patchwork.freedesktop.org/series/114473/ -- With best wishes Dmitry
Re: [PATCH] drm/ast: Fix ARM compatibility
Hi Thomas,
Could you help review this patch??
We met some problem on nvidia's ARM platfrom and need this patch to fix it.
On 2023/3/2 上午 10:19, Jammy Huang wrote:
ARM architecture only has 'memory', so all devices are accessed by MMIO.
Signed-off-by: Jammy Huang
---
drivers/gpu/drm/ast/ast_main.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 794ffd4a29c5..f86d01e9f024 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -424,22 +424,7 @@ struct ast_device *ast_device_create(const struct
drm_driver *drv,
if (!ast->regs)
return ERR_PTR(-EIO);
- /*
-* If we don't have IO space at all, use MMIO now and
-* assume the chip has MMIO enabled by default (rev 0x20
-* and higher).
-*/
- if (!(pci_resource_flags(pdev, 2) & IORESOURCE_IO)) {
- drm_info(dev, "platform has no IO space, trying MMIO\n");
- ast->ioregs = ast->regs + AST_IO_MM_OFFSET;
- }
-
- /* "map" IO regs if the above hasn't done so already */
- if (!ast->ioregs) {
- ast->ioregs = pcim_iomap(pdev, 2, 0);
- if (!ast->ioregs)
- return ERR_PTR(-EIO);
- }
+ ast->ioregs = ast->regs + AST_IO_MM_OFFSET;
ast_detect_chip(dev, _post);
base-commit: 254986e324add8a30d0019c6da59f81adc8b565f
--
Best Regards
Jammy
[PATCH] drm/msm/adreno: fix sparse warnings in a6xx code
Sparse reports plenty of warnings against the a6xx code because of
a6xx_gmu::mmio and a6xx_gmu::rscc members. For some reason they were
defined as __iomem pointers rather than pointers to __iomem memory.
Correct the __iomem attribute.
Fixes: 02ef80c54e7c ("drm/msm/a6xx: update pdc/rscc GMU registers for
A640/A650")
Reported-by: kernel test robot
Link: https://lore.kernel.org/oe-kbuild-all/202304070550.nrbhjcvp-...@intel.com/
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index 0bc3eb443fec..84d345af126f 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
@@ -51,8 +51,8 @@ struct a6xx_gmu {
struct msm_gem_address_space *aspace;
- void * __iomem mmio;
- void * __iomem rscc;
+ void __iomem * mmio;
+ void __iomem * rscc;
int hfi_irq;
int gmu_irq;
--
2.39.2
Re: [CI] drm/i915/mtl: Define GuC firmware version for MTL
On Fri, Mar 31, 2023 at 03:52:16PM -0700, john.c.harri...@intel.com wrote: From: John Harrison First release of GuC for Meteorlake. NB: As this is still pre-release and likely to change, use explicit versioning for now. The official, full release will use reduced version naming. Signed-off-by: John Harrison Applied to topic/core-for-CI with acks by Rodrigo and Tvrtko. Reference issue: https://gitlab.freedesktop.org/drm/intel/-/issues/8343 Going forward we should plan to have these kind of patches in drm-intel-gt-next itself rather than using the CI branch. The CI branch is not the proper place. To be clear, since MTL is under force probe and not normally enabled, it's ok to bump the major version without retaining compabibility with the previous version, as per https://docs.kernel.org/driver-api/firmware/firmware-usage-guidelines.html I think the main blocker right now to use drm-intel-gt-next would be because MODULE_FIRMWARE() is unaware of force_probe. Then distros would start getting a warning when creating their initrd that they may have missed a firmware. But that firmware itself is not present in the upstream linux-firmware repo. We can think about a way to hide the fw def for *new* firmware (not the legacy ones) that are using the mmp version. For now, let's keep this as is and use the CI branch to assess the driver health with GuC. thanks Lucas De Marchi --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c index 264c952f777bb..1ac6f9f340e31 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c @@ -79,6 +79,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, * security fixes, etc. to be enabled. */ #define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_maj, guc_mmp) \ + fw_def(METEORLAKE, 0, guc_mmp(mtl, 70, 6, 5)) \ fw_def(DG2, 0, guc_maj(dg2, 70, 5)) \ fw_def(ALDERLAKE_P, 0, guc_maj(adlp, 70, 5)) \ fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 70, 1, 1)) \ -- 2.39.1
RE: [RFC PATCH 00/10] Xe DRM scheduler and long running workload plans
So this series basically go with option 2. The part that option2 makes me uncomfortable is, dma-fence doesn't work for long running workload, why we generate it in the first place? As long as dma-fence is generated, it will become a source of confusion in the future. It doesn't matter how much you annotate it/document it. So if we decide to go with option2, the bottom line is, don't generate dma-fence for long running workload during job submission. This requires some rework in drm scheduler. The cleanest solution to me is option3. Dma-fence is a very old technology. When it was created, no gpu support page fault. Obviously this is not a good technology for modern gpu with page fault support. I think the best way is to create a new scheduler and dependency tracking mechanism works for both page fault enabled and page fault disabled context. I think this matches what Christian said below. Maybe nobody think this is easy? Thanks, Oak > -Original Message- > From: Brost, Matthew > Sent: April 5, 2023 2:53 PM > To: Zeng, Oak > Cc: Christian König ; Vetter, Daniel > ; Thomas Hellström > ; dri-devel@lists.freedesktop.org; intel- > x...@lists.freedesktop.org; robdcl...@chromium.org; airl...@linux.ie; > l...@asahilina.net; boris.brezil...@collabora.com; > faith.ekstr...@collabora.com > Subject: Re: [RFC PATCH 00/10] Xe DRM scheduler and long running workload > plans > > On Wed, Apr 05, 2023 at 12:06:53PM -0600, Zeng, Oak wrote: > > Hi, > > > > Using dma-fence for completion/dependency tracking for long-run > workload(more precisely on-demand paging/page fault enabled workload) can > cause deadlock. This seems the significant issue here. Other issues such as > the > drm scheduler completion order implication etc are minors which can be solve > inside the framework of drm scheduler. We need to evaluate below paths: > > > > 1) still use drm scheduler for job submission, and use dma-fence for job > completion waiting/dependency tracking. This is solution proposed in this > series. > Annotate dma-fence for long-run workload: user can still wait dma-fence for > job > completion but can't wait dma-fence while holding any memory management > locks. We still use dma-fence for dependency tracking. But it is just very > easily > run into deadlock when on-demand paging is in the picture. The annotation > helps > us to detect deadlock but not solve deadlock problems. Seems *not* a complete > solution: It is almost impossible to completely avoid dependency deadlock in > complex runtime environment > > > > No one can wait on LR fence, so it is impossible to deadlock. The > annotations enforce this. Literally this is only for flow controling the > ring / hold pending jobs in in the DRM schedule list. > > > 2) Still use drm scheduler but not use dma-fence for completion > > signaling > and dependency tracking. This way we still get some free functions (reset, err > handling ring flow control as Matt said)from drm scheduler, but push the > dependency/completion tracking completely to user space using techniques such > as user space fence. User space doesn't have chance to wait fence while > holding > a kernel memory management lock, thus the dma-fence deadlock issue is solved. > > > > We use user space fence for syncs. > > > 3) Completely discard drm scheduler and dma-fence for long-run > workload. Use user queue/doorbell for super fast submission, directly interact > with fw scheduler. Use user fence for completion/dependency tracking. > > > > This is a hard no from me, I want 1 submission path in Xe. Either we use > the DRM scheduler or we don't. > > Matt > > > Thanks, > > Oak > > > > > -Original Message- > > > From: Christian König > > > Sent: April 5, 2023 3:30 AM > > > To: Brost, Matthew ; Zeng, Oak > > > > > > Cc: dri-devel@lists.freedesktop.org; intel...@lists.freedesktop.org; > > > robdcl...@chromium.org; thomas.hellst...@linux.intel.com; > airl...@linux.ie; > > > l...@asahilina.net; boris.brezil...@collabora.com; > faith.ekstr...@collabora.com > > > Subject: Re: [RFC PATCH 00/10] Xe DRM scheduler and long running workload > > > plans > > > > > > Am 04.04.23 um 20:08 schrieb Matthew Brost: > > > > On Tue, Apr 04, 2023 at 12:02:03PM -0600, Zeng, Oak wrote: > > > >> Hi Matt, Thomas, > > > >> > > > >> Some very bold out of box thinking in this area: > > > >> > > > >> 1. so you want to use drm scheduler and dma-fence for long running > workload. > > > Why you want to do this in the first place? What is the benefit? Drm > > > scheduler > is > > > pretty much a software scheduler. Modern gpu has scheduler built at fw/hw > > > level, as you said below for intel this is Guc. Can xe driver just > > > directly submit > job > > > to Guc, bypassing drm scheduler? > > > >> > > > > If we did that now we have 2 paths for dependency track, flow controling > > > > the ring, resets / error handling / backend submission implementations. > > > > We don't want this. > > > > > >
Re: [Regression] drm/scheduler: track GPU active time per entity
On 2023-04-06 06:45, Lucas Stach wrote:
> Am Donnerstag, dem 06.04.2023 um 10:27 +0200 schrieb Daniel Vetter:
>> On Thu, 6 Apr 2023 at 10:22, Christian König
>> wrote:
>>>
>>> Am 05.04.23 um 18:09 schrieb Luben Tuikov:
On 2023-04-05 10:05, Danilo Krummrich wrote:
> On 4/4/23 06:31, Luben Tuikov wrote:
>> On 2023-03-28 04:54, Lucas Stach wrote:
>>> Hi Danilo,
>>>
>>> Am Dienstag, dem 28.03.2023 um 02:57 +0200 schrieb Danilo Krummrich:
Hi all,
Commit df622729ddbf ("drm/scheduler: track GPU active time per entity")
tries to track the accumulated time that a job was active on the GPU
writing it to the entity through which the job was deployed to the
scheduler originally. This is done within drm_sched_get_cleanup_job()
which fetches a job from the schedulers pending_list.
Doing this can result in a race condition where the entity is already
freed, but the entity's newly added elapsed_ns field is still accessed
once the job is fetched from the pending_list.
After drm_sched_entity_destroy() being called it should be safe to free
the structure that embeds the entity. However, a job originally handed
over to the scheduler by this entity might still reside in the
schedulers pending_list for cleanup after drm_sched_entity_destroy()
already being called and the entity being freed. Hence, we can run into
a UAF.
>>> Sorry about that, I clearly didn't properly consider this case.
>>>
In my case it happened that a job, as explained above, was just picked
from the schedulers pending_list after the entity was freed due to the
client application exiting. Meanwhile this freed up memory was already
allocated for a subsequent client applications job structure again.
Hence, the new jobs memory got corrupted. Luckily, I was able to
reproduce the same corruption over and over again by just using
deqp-runner to run a specific set of VK test cases in parallel.
Fixing this issue doesn't seem to be very straightforward though
(unless
I miss something), which is why I'm writing this mail instead of
sending
a fix directly.
Spontaneously, I see three options to fix it:
1. Rather than embedding the entity into driver specific structures
(e.g. tied to file_priv) we could allocate the entity separately and
reference count it, such that it's only freed up once all jobs that
were
deployed through this entity are fetched from the schedulers pending
list.
>>> My vote is on this or something in similar vain for the long term. I
>>> have some hope to be able to add a GPU scheduling algorithm with a bit
>>> more fairness than the current one sometime in the future, which
>>> requires execution time tracking on the entities.
>> Danilo,
>>
>> Using kref is preferable, i.e. option 1 above.
> I think the only real motivation for doing that would be for generically
> tracking job statistics within the entity a job was deployed through. If
> we all agree on tracking job statistics this way I am happy to prepare a
> patch for this option and drop this one:
> https://lore.kernel.org/all/20230331000622.4156-1-d...@redhat.com/T/#u
Hmm, I never thought about "job statistics" when I preferred using kref
above.
The reason kref is attractive is because one doesn't need to worry about
it--when the last user drops the kref, the release is called to do
housekeeping. If this never happens, we know that we have a bug to debug.
>>>
>>> Yeah, reference counting unfortunately have some traps as well. For
>>> example rarely dropping the last reference from interrupt context or
>>> with some unexpected locks help when the cleanup function doesn't expect
>>> that is a good recipe for problems as well.
>>>
> Fully agreed.
>
Regarding the patch above--I did look around the code, and it seems safe,
as per your analysis, I didn't see any reference to entity after job
submission,
but I'll comment on that thread as well for the record.
>>>
>>> Reference counting the entities was suggested before. The intentionally
>>> avoided that so far because the entity might be the tip of the iceberg
>>> of stuff you need to keep around.
>>>
>>> For example for command submission you also need the VM and when you
>>> keep the VM alive you also need to keep the file private alive
>>
>> Yeah refcounting looks often like the easy way out to avoid
>> use-after-free issue, until you realize you've just made lifetimes
>> unbounded and have some enourmous leaks: entity keeps vm alive, vm
>> keeps all the bo alives, somehow every crash wastes more memory
>> because vk_device_lost means
Re: [Regression] drm/scheduler: track GPU active time per entity
On 2023-04-06 04:22, Christian König wrote:
> Am 05.04.23 um 18:09 schrieb Luben Tuikov:
>> On 2023-04-05 10:05, Danilo Krummrich wrote:
>>> On 4/4/23 06:31, Luben Tuikov wrote:
On 2023-03-28 04:54, Lucas Stach wrote:
> Hi Danilo,
>
> Am Dienstag, dem 28.03.2023 um 02:57 +0200 schrieb Danilo Krummrich:
>> Hi all,
>>
>> Commit df622729ddbf ("drm/scheduler: track GPU active time per entity")
>> tries to track the accumulated time that a job was active on the GPU
>> writing it to the entity through which the job was deployed to the
>> scheduler originally. This is done within drm_sched_get_cleanup_job()
>> which fetches a job from the schedulers pending_list.
>>
>> Doing this can result in a race condition where the entity is already
>> freed, but the entity's newly added elapsed_ns field is still accessed
>> once the job is fetched from the pending_list.
>>
>> After drm_sched_entity_destroy() being called it should be safe to free
>> the structure that embeds the entity. However, a job originally handed
>> over to the scheduler by this entity might still reside in the
>> schedulers pending_list for cleanup after drm_sched_entity_destroy()
>> already being called and the entity being freed. Hence, we can run into
>> a UAF.
>>
> Sorry about that, I clearly didn't properly consider this case.
>
>> In my case it happened that a job, as explained above, was just picked
>> from the schedulers pending_list after the entity was freed due to the
>> client application exiting. Meanwhile this freed up memory was already
>> allocated for a subsequent client applications job structure again.
>> Hence, the new jobs memory got corrupted. Luckily, I was able to
>> reproduce the same corruption over and over again by just using
>> deqp-runner to run a specific set of VK test cases in parallel.
>>
>> Fixing this issue doesn't seem to be very straightforward though (unless
>> I miss something), which is why I'm writing this mail instead of sending
>> a fix directly.
>>
>> Spontaneously, I see three options to fix it:
>>
>> 1. Rather than embedding the entity into driver specific structures
>> (e.g. tied to file_priv) we could allocate the entity separately and
>> reference count it, such that it's only freed up once all jobs that were
>> deployed through this entity are fetched from the schedulers pending
>> list.
>>
> My vote is on this or something in similar vain for the long term. I
> have some hope to be able to add a GPU scheduling algorithm with a bit
> more fairness than the current one sometime in the future, which
> requires execution time tracking on the entities.
Danilo,
Using kref is preferable, i.e. option 1 above.
>>> I think the only real motivation for doing that would be for generically
>>> tracking job statistics within the entity a job was deployed through. If
>>> we all agree on tracking job statistics this way I am happy to prepare a
>>> patch for this option and drop this one:
>>> https://lore.kernel.org/all/20230331000622.4156-1-d...@redhat.com/T/#u
>> Hmm, I never thought about "job statistics" when I preferred using kref
>> above.
>> The reason kref is attractive is because one doesn't need to worry about
>> it--when the last user drops the kref, the release is called to do
>> housekeeping. If this never happens, we know that we have a bug to debug.
>
> Yeah, reference counting unfortunately have some traps as well. For
> example rarely dropping the last reference from interrupt context or
> with some unexpected locks help when the cleanup function doesn't expect
> that is a good recipe for problems as well.
>
>> Regarding the patch above--I did look around the code, and it seems safe,
>> as per your analysis, I didn't see any reference to entity after job
>> submission,
>> but I'll comment on that thread as well for the record.
>
> Reference counting the entities was suggested before. The intentionally
> avoided that so far because the entity might be the tip of the iceberg
> of stuff you need to keep around.
>
> For example for command submission you also need the VM and when you
> keep the VM alive you also need to keep the file private alive
>
> Additional to that we have some ugly inter dependencies between tearing
> down an application (potential with a KILL signal from the OOM killer)
> and backward compatibility for some applications which render something
> and quit before the rendering is completed in the hardware.
In my experience, ref counting has worked--just worked, even in
completely untested and unimagined circumstances. You pull
a cable (back end), or kill an app (front end) and everything
gracefully shuts down and gets freed.
(Behind that cable, you can have thousands of hardware entities,
(represented in the kernel), each processing thousands of work
[PATCH 0/5] Improvements to GuC error capture list processing
From: John Harrison The GuC error capture list creation was including Gen8 registers on Xe platforms. While fixing that, it was noticed that there were other issues. The platform naming was wrong, the naming of lists was misleading, the steered register code was duplicated and steered registers were not included on all supported platforms. NB: The changes are being sent as multiple patches to make code review simpler. However, before merging it may be better to squash into a single patch, especially if it going to be sent with a 'fixes' tag. Signed-off-by: John Harrison John Harrison (5): drm/i915/guc: Don't capture Gen8 regs on Xe devices drm/i915/guc: Capture list clean up - 1 drm/i915/guc: Capture list clean up - 2 drm/i915/guc: Capture list clean up - 3 drm/i915/guc: Capture list clean up - 4 .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 199 +++--- 1 file changed, 73 insertions(+), 126 deletions(-) -- 2.39.1
[PATCH 5/5] drm/i915/guc: Capture list clean up - 4
From: John Harrison
Don't use GEN9 as a prefix for register lists that contain all GEN8
registers.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index fbd0be4afc6d5..c1a75a2d17f1e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -30,12 +30,12 @@
#define COMMON_BASE_GLOBAL \
{ FORCEWAKE_MT, 0, 0, "FORCEWAKE" }
-#define COMMON_GEN9BASE_GLOBAL \
+#define COMMON_GEN8BASE_GLOBAL \
{ ERROR_GEN6, 0, 0, "ERROR_GEN6" }, \
{ DONE_REG, 0, 0, "DONE_REG" }, \
{ HSW_GTT_CACHE_EN, 0, 0, "HSW_GTT_CACHE_EN" }
-#define GEN9_GLOBAL \
+#define GEN8_GLOBAL \
{ GEN8_FAULT_TLB_DATA0, 0, 0, "GEN8_FAULT_TLB_DATA0" }, \
{ GEN8_FAULT_TLB_DATA1, 0, 0, "GEN8_FAULT_TLB_DATA1" }
@@ -99,7 +99,7 @@
/* XE_LP Global */
static const struct __guc_mmio_reg_descr xe_lp_global_regs[] = {
COMMON_BASE_GLOBAL,
- COMMON_GEN9BASE_GLOBAL,
+ COMMON_GEN8BASE_GLOBAL,
COMMON_GEN12BASE_GLOBAL,
};
@@ -140,11 +140,11 @@ static const struct __guc_mmio_reg_descr
xe_lp_gsc_inst_regs[] = {
COMMON_BASE_ENGINE_INSTANCE,
};
-/* GEN9 - Global */
+/* GEN8 - Global */
static const struct __guc_mmio_reg_descr default_global_regs[] = {
COMMON_BASE_GLOBAL,
- COMMON_GEN9BASE_GLOBAL,
- GEN9_GLOBAL,
+ COMMON_GEN8BASE_GLOBAL,
+ GEN8_GLOBAL,
};
static const struct __guc_mmio_reg_descr default_rc_class_regs[] = {
--
2.39.1
[PATCH 3/5] drm/i915/guc: Capture list clean up - 2
From: John Harrison
Don't use 'xe_lp*' prefixes for register lists that are common with
Gen8.
Signed-off-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 30 +--
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index 9184d2595e4ce..7968a495fcfa8 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -111,12 +111,12 @@ static const struct __guc_mmio_reg_descr
xe_lpd_rc_class_regs[] = {
};
/* GEN9/XE_LPD - Render / Compute Per-Engine-Instance */
-static const struct __guc_mmio_reg_descr xe_lpd_rc_inst_regs[] = {
+static const struct __guc_mmio_reg_descr gen8_rc_inst_regs[] = {
COMMON_BASE_ENGINE_INSTANCE,
};
/* GEN9/XE_LPD - Media Decode/Encode Per-Engine-Instance */
-static const struct __guc_mmio_reg_descr xe_lpd_vd_inst_regs[] = {
+static const struct __guc_mmio_reg_descr gen8_vd_inst_regs[] = {
COMMON_BASE_ENGINE_INSTANCE,
};
@@ -126,12 +126,12 @@ static const struct __guc_mmio_reg_descr
xe_lpd_vec_class_regs[] = {
};
/* GEN9/XE_LPD - Video Enhancement Per-Engine-Instance */
-static const struct __guc_mmio_reg_descr xe_lpd_vec_inst_regs[] = {
+static const struct __guc_mmio_reg_descr gen8_vec_inst_regs[] = {
COMMON_BASE_ENGINE_INSTANCE,
};
/* GEN9/XE_LPD - Blitter Per-Engine-Instance */
-static const struct __guc_mmio_reg_descr xe_lpd_blt_inst_regs[] = {
+static const struct __guc_mmio_reg_descr gen8_blt_inst_regs[] = {
COMMON_BASE_ENGINE_INSTANCE,
};
@@ -177,32 +177,32 @@ static const struct __guc_mmio_reg_descr
empty_regs_list[] = {
static const struct __guc_mmio_reg_descr_group default_lists[] = {
MAKE_REGLIST(default_global_regs, PF, GLOBAL, 0),
MAKE_REGLIST(default_rc_class_regs, PF, ENGINE_CLASS, GUC_RENDER_CLASS),
- MAKE_REGLIST(xe_lpd_rc_inst_regs, PF, ENGINE_INSTANCE,
GUC_RENDER_CLASS),
+ MAKE_REGLIST(gen8_rc_inst_regs, PF, ENGINE_INSTANCE, GUC_RENDER_CLASS),
MAKE_REGLIST(default_rc_class_regs, PF, ENGINE_CLASS,
GUC_COMPUTE_CLASS),
- MAKE_REGLIST(xe_lpd_rc_inst_regs, PF, ENGINE_INSTANCE,
GUC_COMPUTE_CLASS),
+ MAKE_REGLIST(gen8_rc_inst_regs, PF, ENGINE_INSTANCE, GUC_COMPUTE_CLASS),
MAKE_REGLIST(empty_regs_list, PF, ENGINE_CLASS, GUC_VIDEO_CLASS),
- MAKE_REGLIST(xe_lpd_vd_inst_regs, PF, ENGINE_INSTANCE, GUC_VIDEO_CLASS),
+ MAKE_REGLIST(gen8_vd_inst_regs, PF, ENGINE_INSTANCE, GUC_VIDEO_CLASS),
MAKE_REGLIST(empty_regs_list, PF, ENGINE_CLASS, GUC_VIDEOENHANCE_CLASS),
- MAKE_REGLIST(xe_lpd_vec_inst_regs, PF, ENGINE_INSTANCE,
GUC_VIDEOENHANCE_CLASS),
+ MAKE_REGLIST(gen8_vec_inst_regs, PF, ENGINE_INSTANCE,
GUC_VIDEOENHANCE_CLASS),
MAKE_REGLIST(empty_regs_list, PF, ENGINE_CLASS, GUC_BLITTER_CLASS),
- MAKE_REGLIST(xe_lpd_blt_inst_regs, PF, ENGINE_INSTANCE,
GUC_BLITTER_CLASS),
+ MAKE_REGLIST(gen8_blt_inst_regs, PF, ENGINE_INSTANCE,
GUC_BLITTER_CLASS),
MAKE_REGLIST(empty_regs_list, PF, ENGINE_CLASS, GUC_GSC_OTHER_CLASS),
- MAKE_REGLIST(xe_lpd_gsc_inst_regs, PF, ENGINE_INSTANCE,
GUC_GSC_OTHER_CLASS),
+ MAKE_REGLIST(empty_regs_list, PF, ENGINE_INSTANCE, GUC_GSC_OTHER_CLASS),
{}
};
static const struct __guc_mmio_reg_descr_group xe_lpd_lists[] = {
MAKE_REGLIST(xe_lpd_global_regs, PF, GLOBAL, 0),
MAKE_REGLIST(xe_lpd_rc_class_regs, PF, ENGINE_CLASS, GUC_RENDER_CLASS),
- MAKE_REGLIST(xe_lpd_rc_inst_regs, PF, ENGINE_INSTANCE,
GUC_RENDER_CLASS),
+ MAKE_REGLIST(gen8_rc_inst_regs, PF, ENGINE_INSTANCE, GUC_RENDER_CLASS),
MAKE_REGLIST(xe_lpd_rc_class_regs, PF, ENGINE_CLASS, GUC_COMPUTE_CLASS),
- MAKE_REGLIST(xe_lpd_rc_inst_regs, PF, ENGINE_INSTANCE,
GUC_COMPUTE_CLASS),
+ MAKE_REGLIST(gen8_rc_inst_regs, PF, ENGINE_INSTANCE, GUC_COMPUTE_CLASS),
MAKE_REGLIST(empty_regs_list, PF, ENGINE_CLASS, GUC_VIDEO_CLASS),
- MAKE_REGLIST(xe_lpd_vd_inst_regs, PF, ENGINE_INSTANCE, GUC_VIDEO_CLASS),
+ MAKE_REGLIST(gen8_vd_inst_regs, PF, ENGINE_INSTANCE, GUC_VIDEO_CLASS),
MAKE_REGLIST(xe_lpd_vec_class_regs, PF, ENGINE_CLASS,
GUC_VIDEOENHANCE_CLASS),
- MAKE_REGLIST(xe_lpd_vec_inst_regs, PF, ENGINE_INSTANCE,
GUC_VIDEOENHANCE_CLASS),
+ MAKE_REGLIST(gen8_vec_inst_regs, PF, ENGINE_INSTANCE,
GUC_VIDEOENHANCE_CLASS),
MAKE_REGLIST(empty_regs_list, PF, ENGINE_CLASS, GUC_BLITTER_CLASS),
- MAKE_REGLIST(xe_lpd_blt_inst_regs, PF, ENGINE_INSTANCE,
GUC_BLITTER_CLASS),
+ MAKE_REGLIST(gen8_blt_inst_regs, PF, ENGINE_INSTANCE,
GUC_BLITTER_CLASS),
MAKE_REGLIST(empty_regs_list, PF, ENGINE_CLASS, GUC_GSC_OTHER_CLASS),
MAKE_REGLIST(xe_lpd_gsc_inst_regs, PF, ENGINE_INSTANCE,
GUC_GSC_OTHER_CLASS),
{}
--
2.39.1
[PATCH 4/5] drm/i915/guc: Capture list clean up - 3
From: John Harrison
Fix Xe_LP name.
Signed-off-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 44 +--
1 file changed, 21 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index 7968a495fcfa8..fbd0be4afc6d5 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -96,47 +96,47 @@
{ GEN12_SFC_DONE(2),0, 0, "SFC_DONE[2]" }, \
{ GEN12_SFC_DONE(3),0, 0, "SFC_DONE[3]" }
-/* XE_LPD - Global */
-static const struct __guc_mmio_reg_descr xe_lpd_global_regs[] = {
+/* XE_LP Global */
+static const struct __guc_mmio_reg_descr xe_lp_global_regs[] = {
COMMON_BASE_GLOBAL,
COMMON_GEN9BASE_GLOBAL,
COMMON_GEN12BASE_GLOBAL,
};
-/* XE_LPD - Render / Compute Per-Class */
-static const struct __guc_mmio_reg_descr xe_lpd_rc_class_regs[] = {
+/* XE_LP Render / Compute Per-Class */
+static const struct __guc_mmio_reg_descr xe_lp_rc_class_regs[] = {
COMMON_BASE_HAS_EU,
COMMON_BASE_RENDER,
COMMON_GEN12BASE_RENDER,
};
-/* GEN9/XE_LPD - Render / Compute Per-Engine-Instance */
+/* GEN8+ Render / Compute Per-Engine-Instance */
static const struct __guc_mmio_reg_descr gen8_rc_inst_regs[] = {
COMMON_BASE_ENGINE_INSTANCE,
};
-/* GEN9/XE_LPD - Media Decode/Encode Per-Engine-Instance */
+/* GEN8+ Media Decode/Encode Per-Engine-Instance */
static const struct __guc_mmio_reg_descr gen8_vd_inst_regs[] = {
COMMON_BASE_ENGINE_INSTANCE,
};
-/* XE_LPD - Video Enhancement Per-Class */
-static const struct __guc_mmio_reg_descr xe_lpd_vec_class_regs[] = {
+/* XE_LP Video Enhancement Per-Class */
+static const struct __guc_mmio_reg_descr xe_lp_vec_class_regs[] = {
COMMON_GEN12BASE_VEC,
};
-/* GEN9/XE_LPD - Video Enhancement Per-Engine-Instance */
+/* GEN8+ Video Enhancement Per-Engine-Instance */
static const struct __guc_mmio_reg_descr gen8_vec_inst_regs[] = {
COMMON_BASE_ENGINE_INSTANCE,
};
-/* GEN9/XE_LPD - Blitter Per-Engine-Instance */
+/* GEN8+ Blitter Per-Engine-Instance */
static const struct __guc_mmio_reg_descr gen8_blt_inst_regs[] = {
COMMON_BASE_ENGINE_INSTANCE,
};
-/* XE_LPD - GSC Per-Engine-Instance */
-static const struct __guc_mmio_reg_descr xe_lpd_gsc_inst_regs[] = {
+/* XE_LP - GSC Per-Engine-Instance */
+static const struct __guc_mmio_reg_descr xe_lp_gsc_inst_regs[] = {
COMMON_BASE_ENGINE_INSTANCE,
};
@@ -153,10 +153,8 @@ static const struct __guc_mmio_reg_descr
default_rc_class_regs[] = {
};
/*
- * Empty lists:
- * GEN9/XE_LPD - Blitter Per-Class
- * GEN9/XE_LPD - Media Decode/Encode Per-Class
- * GEN9 - VEC Class
+ * Empty list to prevent warnings about unknown class/instance types
+ * as not all class/instanace types have entries on all platforms.
*/
static const struct __guc_mmio_reg_descr empty_regs_list[] = {
};
@@ -191,20 +189,20 @@ static const struct __guc_mmio_reg_descr_group
default_lists[] = {
{}
};
-static const struct __guc_mmio_reg_descr_group xe_lpd_lists[] = {
- MAKE_REGLIST(xe_lpd_global_regs, PF, GLOBAL, 0),
- MAKE_REGLIST(xe_lpd_rc_class_regs, PF, ENGINE_CLASS, GUC_RENDER_CLASS),
+static const struct __guc_mmio_reg_descr_group xe_lp_lists[] = {
+ MAKE_REGLIST(xe_lp_global_regs, PF, GLOBAL, 0),
+ MAKE_REGLIST(xe_lp_rc_class_regs, PF, ENGINE_CLASS, GUC_RENDER_CLASS),
MAKE_REGLIST(gen8_rc_inst_regs, PF, ENGINE_INSTANCE, GUC_RENDER_CLASS),
- MAKE_REGLIST(xe_lpd_rc_class_regs, PF, ENGINE_CLASS, GUC_COMPUTE_CLASS),
+ MAKE_REGLIST(xe_lp_rc_class_regs, PF, ENGINE_CLASS, GUC_COMPUTE_CLASS),
MAKE_REGLIST(gen8_rc_inst_regs, PF, ENGINE_INSTANCE, GUC_COMPUTE_CLASS),
MAKE_REGLIST(empty_regs_list, PF, ENGINE_CLASS, GUC_VIDEO_CLASS),
MAKE_REGLIST(gen8_vd_inst_regs, PF, ENGINE_INSTANCE, GUC_VIDEO_CLASS),
- MAKE_REGLIST(xe_lpd_vec_class_regs, PF, ENGINE_CLASS,
GUC_VIDEOENHANCE_CLASS),
+ MAKE_REGLIST(xe_lp_vec_class_regs, PF, ENGINE_CLASS,
GUC_VIDEOENHANCE_CLASS),
MAKE_REGLIST(gen8_vec_inst_regs, PF, ENGINE_INSTANCE,
GUC_VIDEOENHANCE_CLASS),
MAKE_REGLIST(empty_regs_list, PF, ENGINE_CLASS, GUC_BLITTER_CLASS),
MAKE_REGLIST(gen8_blt_inst_regs, PF, ENGINE_INSTANCE,
GUC_BLITTER_CLASS),
MAKE_REGLIST(empty_regs_list, PF, ENGINE_CLASS, GUC_GSC_OTHER_CLASS),
- MAKE_REGLIST(xe_lpd_gsc_inst_regs, PF, ENGINE_INSTANCE,
GUC_GSC_OTHER_CLASS),
+ MAKE_REGLIST(xe_lp_gsc_inst_regs, PF, ENGINE_INSTANCE,
GUC_GSC_OTHER_CLASS),
{}
};
@@ -366,7 +364,7 @@ guc_capture_get_device_reglist(struct intel_guc *guc)
const struct __guc_mmio_reg_descr_group *lists;
if (GRAPHICS_VER(i915) >= 12)
- lists = xe_lpd_lists;
+ lists = xe_lp_lists;
else
lists = default_lists;
--
2.39.1
[PATCH 2/5] drm/i915/guc: Capture list clean up - 1
From: John Harrison
Remove 99% duplicated steered register list code. Also, include the
pre-Xe steered registers in the pre-Xe list generation.
Signed-off-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 112 +-
1 file changed, 29 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index e0e793167d61b..9184d2595e4ce 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -260,11 +260,15 @@ struct __ext_steer_reg {
i915_mcr_reg_t reg;
};
-static const struct __ext_steer_reg xe_extregs[] = {
+static const struct __ext_steer_reg gen8_extregs[] = {
{"GEN8_SAMPLER_INSTDONE", GEN8_SAMPLER_INSTDONE},
{"GEN8_ROW_INSTDONE", GEN8_ROW_INSTDONE}
};
+static const struct __ext_steer_reg xehpg_extregs[] = {
+ {"XEHPG_INSTDONE_GEOM_SVG", XEHPG_INSTDONE_GEOM_SVG}
+};
+
static void __fill_ext_reg(struct __guc_mmio_reg_descr *ext,
const struct __ext_steer_reg *extlist,
int slice_id, int subslice_id)
@@ -295,8 +299,8 @@ __alloc_ext_regs(struct __guc_mmio_reg_descr_group *newlist,
}
static void
-guc_capture_alloc_steered_lists_xe_lpd(struct intel_guc *guc,
- const struct __guc_mmio_reg_descr_group
*lists)
+guc_capture_alloc_steered_lists(struct intel_guc *guc,
+ const struct __guc_mmio_reg_descr_group *lists)
{
struct intel_gt *gt = guc_to_gt(guc);
int slice, subslice, iter, i, num_steer_regs, num_tot_regs = 0;
@@ -304,74 +308,19 @@ guc_capture_alloc_steered_lists_xe_lpd(struct intel_guc
*guc,
struct __guc_mmio_reg_descr_group *extlists;
struct __guc_mmio_reg_descr *extarray;
struct sseu_dev_info *sseu;
+ bool has_xehpg_extregs;
- /* In XE_LPD we only have steered registers for the render-class */
+ /* steered registers currently only exist for the render-class */
list = guc_capture_get_one_list(lists, GUC_CAPTURE_LIST_INDEX_PF,
GUC_CAPTURE_LIST_TYPE_ENGINE_CLASS,
GUC_RENDER_CLASS);
/* skip if extlists was previously allocated */
if (!list || guc->capture->extlists)
return;
- num_steer_regs = ARRAY_SIZE(xe_extregs);
-
- sseu = >info.sseu;
- for_each_ss_steering(iter, gt, slice, subslice)
- num_tot_regs += num_steer_regs;
-
- if (!num_tot_regs)
- return;
-
- /* allocate an extra for an end marker */
- extlists = kcalloc(2, sizeof(struct __guc_mmio_reg_descr_group),
GFP_KERNEL);
- if (!extlists)
- return;
-
- if (__alloc_ext_regs([0], list, num_tot_regs)) {
- kfree(extlists);
- return;
- }
-
- extarray = extlists[0].extlist;
- for_each_ss_steering(iter, gt, slice, subslice) {
- for (i = 0; i < num_steer_regs; ++i) {
- __fill_ext_reg(extarray, _extregs[i], slice,
subslice);
- ++extarray;
- }
- }
-
- guc->capture->extlists = extlists;
-}
-
-static const struct __ext_steer_reg xehpg_extregs[] = {
- {"XEHPG_INSTDONE_GEOM_SVG", XEHPG_INSTDONE_GEOM_SVG}
-};
-
-static bool __has_xehpg_extregs(u32 ipver)
-{
- return (ipver >= IP_VER(12, 55));
-}
-
-static void
-guc_capture_alloc_steered_lists_xe_hpg(struct intel_guc *guc,
- const struct __guc_mmio_reg_descr_group
*lists,
- u32 ipver)
-{
- struct intel_gt *gt = guc_to_gt(guc);
- struct sseu_dev_info *sseu;
- int slice, subslice, i, iter, num_steer_regs, num_tot_regs = 0;
- const struct __guc_mmio_reg_descr_group *list;
- struct __guc_mmio_reg_descr_group *extlists;
- struct __guc_mmio_reg_descr *extarray;
-
- /* In XE_LP / HPG we only have render-class steering registers during
error-capture */
- list = guc_capture_get_one_list(lists, GUC_CAPTURE_LIST_INDEX_PF,
- GUC_CAPTURE_LIST_TYPE_ENGINE_CLASS,
GUC_RENDER_CLASS);
- /* skip if extlists was previously allocated */
- if (!list || guc->capture->extlists)
- return;
+ has_xehpg_extregs = GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 55);
- num_steer_regs = ARRAY_SIZE(xe_extregs);
- if (__has_xehpg_extregs(ipver))
+ num_steer_regs = ARRAY_SIZE(gen8_extregs);
+ if (has_xehpg_extregs)
num_steer_regs += ARRAY_SIZE(xehpg_extregs);
sseu = >info.sseu;
@@ -393,11 +342,12 @@ guc_capture_alloc_steered_lists_xe_hpg(struct intel_guc
*guc,
extarray = extlists[0].extlist;
for_each_ss_steering(iter, gt, slice, subslice) {
- for (i = 0; i < ARRAY_SIZE(xe_extregs);
[PATCH 1/5] drm/i915/guc: Don't capture Gen8 regs on Xe devices
From: John Harrison
A pair of pre-Xe registers were being included in the Xe capture list.
GuC was rejecting those as being invalid and logging errors about
them. So, stop doing it.
Signed-off-by: John Harrison
Fixes: dce2bd542337 ("drm/i915/guc: Add Gen9 registers for GuC error state
capture.")
Cc: Alan Previn
Cc: Umesh Nerlige Ramappa
Cc: Lucas De Marchi
Cc: John Harrison
Cc: Jani Nikula
Cc: Matt Roper
Cc: Balasubramani Vivekanandan
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index cf49188db6a6e..e0e793167d61b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -31,12 +31,14 @@
{ FORCEWAKE_MT, 0, 0, "FORCEWAKE" }
#define COMMON_GEN9BASE_GLOBAL \
- { GEN8_FAULT_TLB_DATA0, 0, 0, "GEN8_FAULT_TLB_DATA0" }, \
- { GEN8_FAULT_TLB_DATA1, 0, 0, "GEN8_FAULT_TLB_DATA1" }, \
{ ERROR_GEN6, 0, 0, "ERROR_GEN6" }, \
{ DONE_REG, 0, 0, "DONE_REG" }, \
{ HSW_GTT_CACHE_EN, 0, 0, "HSW_GTT_CACHE_EN" }
+#define GEN9_GLOBAL \
+ { GEN8_FAULT_TLB_DATA0, 0, 0, "GEN8_FAULT_TLB_DATA0" }, \
+ { GEN8_FAULT_TLB_DATA1, 0, 0, "GEN8_FAULT_TLB_DATA1" }
+
#define COMMON_GEN12BASE_GLOBAL \
{ GEN12_FAULT_TLB_DATA0,0, 0, "GEN12_FAULT_TLB_DATA0" }, \
{ GEN12_FAULT_TLB_DATA1,0, 0, "GEN12_FAULT_TLB_DATA1" }, \
@@ -142,6 +144,7 @@ static const struct __guc_mmio_reg_descr
xe_lpd_gsc_inst_regs[] = {
static const struct __guc_mmio_reg_descr default_global_regs[] = {
COMMON_BASE_GLOBAL,
COMMON_GEN9BASE_GLOBAL,
+ GEN9_GLOBAL,
};
static const struct __guc_mmio_reg_descr default_rc_class_regs[] = {
--
2.39.1
Re: [Regression] drm/scheduler: track GPU active time per entity
On 2023-04-06 11:58, Lucas Stach wrote:
> Am Mittwoch, dem 05.04.2023 um 16:44 -0400 schrieb Luben Tuikov:
>> On 2023-04-05 13:44, Lucas Stach wrote:
>>> Hi Luben,
>>>
>>> Am Dienstag, dem 04.04.2023 um 00:31 -0400 schrieb Luben Tuikov:
On 2023-03-28 04:54, Lucas Stach wrote:
> Hi Danilo,
>
> Am Dienstag, dem 28.03.2023 um 02:57 +0200 schrieb Danilo Krummrich:
>> Hi all,
>>
>> Commit df622729ddbf ("drm/scheduler: track GPU active time per entity")
>> tries to track the accumulated time that a job was active on the GPU
>> writing it to the entity through which the job was deployed to the
>> scheduler originally. This is done within drm_sched_get_cleanup_job()
>> which fetches a job from the schedulers pending_list.
>>
>> Doing this can result in a race condition where the entity is already
>> freed, but the entity's newly added elapsed_ns field is still accessed
>> once the job is fetched from the pending_list.
>>
>> After drm_sched_entity_destroy() being called it should be safe to free
>> the structure that embeds the entity. However, a job originally handed
>> over to the scheduler by this entity might still reside in the
>> schedulers pending_list for cleanup after drm_sched_entity_destroy()
>> already being called and the entity being freed. Hence, we can run into
>> a UAF.
>>
> Sorry about that, I clearly didn't properly consider this case.
>
>> In my case it happened that a job, as explained above, was just picked
>> from the schedulers pending_list after the entity was freed due to the
>> client application exiting. Meanwhile this freed up memory was already
>> allocated for a subsequent client applications job structure again.
>> Hence, the new jobs memory got corrupted. Luckily, I was able to
>> reproduce the same corruption over and over again by just using
>> deqp-runner to run a specific set of VK test cases in parallel.
>>
>> Fixing this issue doesn't seem to be very straightforward though (unless
>> I miss something), which is why I'm writing this mail instead of sending
>> a fix directly.
>>
>> Spontaneously, I see three options to fix it:
>>
>> 1. Rather than embedding the entity into driver specific structures
>> (e.g. tied to file_priv) we could allocate the entity separately and
>> reference count it, such that it's only freed up once all jobs that were
>> deployed through this entity are fetched from the schedulers pending
>> list.
>>
> My vote is on this or something in similar vain for the long term. I
> have some hope to be able to add a GPU scheduling algorithm with a bit
> more fairness than the current one sometime in the future, which
> requires execution time tracking on the entities.
Danilo,
Using kref is preferable, i.e. option 1 above.
Lucas, can you shed some light on,
1. In what way the current FIFO scheduling is unfair, and
2. shed some details on this "scheduling algorithm with a bit
more fairness than the current one"?
>>>
>>> I don't have a specific implementation in mind yet. However the current
>>> FIFO algorithm can be very unfair if you have a sparse workload compete
>>> with one that generates a lot of jobs without any throttling aside from
>>> the entity queue length.
>>
>> Ah, that's interesting, let's see, a "sparse workload compete with one that
>> generates a lot of jobs", so basically we have a sparse workload compete
>> with a dense workload. So we can represent this with two entities, A, B,
>> whose jobs we're going to represent by the entities, names A and B.
>> So if we let A be the sparse workload and B the dense workload,
>> we have this, wlog,
>>
>> First/oldest job, .., latter/new jobs.
>> Subm: A, B, B, B, B, B, A, B, B, B, B, B, A, B, B, B, B, B, A, ...
>> Time: t0,t1,t2,t3,t4,t5,t6,t7,t8,t9, .
>>
>> The current FIFO algorithm, would prefer to execute those jobs
>> in order of submission, i.e. oldest-ready-first job. Assume
>> that all jobs are ready. Then we'll execute them in order.
>> This is desirable and fair. We want to execute the jobs
>> in the order they were submitted, given also that they are
>> ready to be executed. So perhaps we want to execute them like this:
>>
>> First/oldest job, .., latter/new jobs.
>> Subm: A, B, B, B, B, B, A, B, B, B, B, B, A, B, B, B, B, B, A, ...
>> Time: t0,t1,t2,t3,t4,t5,t6,t7,t8,t9,
>> Exec: A, B, B, B, B, B, A, B, B, B, B, B, A, B, B, B, B, B, A, ...
>>
>>
>> Any other ordering would starve either A, or B. If we executed the 2nd A
>> job at t6 or t7, then that would starve the 3rd/4th job in B, since the 2nd
>> A job
>> arrives at the same time as that of the 3rd B job, at time t6.
>> The time t3-t0 is some delta > 0, some initial scheduler-start up time.
>>
[RFC 2/2] drm/msm: Add memory stats to fdinfo
From: Rob Clark
Use the new helper to export stats about memory usage.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 26 +-
drivers/gpu/drm/msm/msm_gpu.c | 2 --
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 9b6f17b1261f..385776f6a531 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1043,17 +1043,40 @@ static const struct drm_ioctl_desc msm_ioctls[] = {
DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_QUERY, msm_ioctl_submitqueue_query,
DRM_RENDER_ALLOW),
};
+enum drm_gem_object_status gem_status(struct drm_gem_object *obj)
+{
+ struct msm_gem_object *msm_obj = to_msm_bo(obj);
+ enum drm_gem_object_status status = 0;
+
+ if (!dma_resv_test_signaled(obj->resv, dma_resv_usage_rw(true)))
+ status |= DRM_GEM_OBJECT_ACTIVE;
+
+ if (msm_obj->pages)
+ status |= DRM_GEM_OBJECT_RESIDENT;
+
+ if (msm_obj->madv == MSM_MADV_DONTNEED)
+ status |= DRM_GEM_OBJECT_PURGEABLE;
+
+ return status;
+}
+
static void msm_fop_show_fdinfo(struct seq_file *m, struct file *f)
{
struct drm_file *file = f->private_data;
struct drm_device *dev = file->minor->dev;
struct msm_drm_private *priv = dev->dev_private;
+ struct msm_file_private *ctx = file->driver_priv;
struct drm_printer p = drm_seq_file_printer(m);
if (!priv->gpu)
return;
- msm_gpu_show_fdinfo(priv->gpu, file->driver_priv, );
+ drm_printf(, "drm-driver:\t%s\n", dev->driver->name);
+ drm_printf(, "drm-client-id:\t%u\n", ctx->seqno);
+
+ msm_gpu_show_fdinfo(priv->gpu, ctx, );
+
+ drm_print_memory_stats(file, , gem_status);
}
static const struct file_operations fops = {
@@ -1067,6 +1090,7 @@ static const struct drm_driver msm_driver = {
DRIVER_RENDER |
DRIVER_ATOMIC |
DRIVER_MODESET |
+ DRIVER_SYNCOBJ_TIMELINE |
DRIVER_SYNCOBJ,
.open = msm_open,
.postclose = msm_postclose,
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 26ebda40be4f..c403912d13ab 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -151,8 +151,6 @@ int msm_gpu_pm_suspend(struct msm_gpu *gpu)
void msm_gpu_show_fdinfo(struct msm_gpu *gpu, struct msm_file_private *ctx,
struct drm_printer *p)
{
- drm_printf(p, "drm-driver:\t%s\n", gpu->dev->driver->name);
- drm_printf(p, "drm-client-id:\t%u\n", ctx->seqno);
drm_printf(p, "drm-engine-gpu:\t%llu ns\n", ctx->elapsed_ns);
drm_printf(p, "drm-cycles-gpu:\t%llu\n", ctx->cycles);
drm_printf(p, "drm-maxfreq-gpu:\t%u Hz\n", gpu->fast_rate);
--
2.39.2
[RFC 1/2] drm: Add fdinfo memory stats
From: Rob Clark
Add a helper to dump memory stats to fdinfo. For the things the drm
core isn't aware of, use a callback.
Signed-off-by: Rob Clark
---
Documentation/gpu/drm-usage-stats.rst | 21 +++
drivers/gpu/drm/drm_file.c| 79 +++
include/drm/drm_file.h| 10
3 files changed, 110 insertions(+)
diff --git a/Documentation/gpu/drm-usage-stats.rst
b/Documentation/gpu/drm-usage-stats.rst
index b46327356e80..56e3c95b6e0a 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -105,6 +105,27 @@ object belong to this client, in the respective memory
region.
Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
indicating kibi- or mebi-bytes.
+- drm-shared-memory: [KiB|MiB]
+
+The total size of buffers that are shared with another file (ie. have more
+than a single handle).
+
+- drm-private-memory: [KiB|MiB]
+
+The total size of buffers that are not shared with another file.
+
+- drm-resident-memory: [KiB|MiB]
+
+The total size of buffers that are resident in system memory.
+
+- drm-purgeable-memory: [KiB|MiB]
+
+The total size of buffers that are purgable.
+
+- drm-active-memory: [KiB|MiB]
+
+The total size of buffers that are active on one or more rings.
+
- drm-cycles-
Engine identifier string must be the same as the one specified in the
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index a51ff8cee049..21911d6ff38d 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
#include "drm_crtc_internal.h"
@@ -868,6 +869,84 @@ void drm_send_event(struct drm_device *dev, struct
drm_pending_event *e)
}
EXPORT_SYMBOL(drm_send_event);
+static void print_size(struct drm_printer *p, const char *stat, size_t sz)
+{
+ const char *units[] = {"B", "KiB", "MiB", "GiB"};
+ unsigned u;
+
+ for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
+ if (sz < SZ_1K)
+ break;
+ sz /= SZ_1K;
+ }
+
+ drm_printf(p, "%s:\t%lu %s\n", stat, sz, units[u]);
+}
+
+/**
+ * drm_print_memory_stats - Helper to print standard fdinfo memory stats
+ * @file: the DRM file
+ * @p: the printer to print output to
+ * @status: callback to get driver tracked object status
+ *
+ * Helper to iterate over GEM objects with a handle allocated in the specified
+ * file. The optional status callback can return additional object state which
+ * determines which stats the object is counted against. The callback is
called
+ * under table_lock. Racing against object status change is "harmless", and
the
+ * callback can expect to not race against object destroy.
+ */
+void drm_print_memory_stats(struct drm_file *file, struct drm_printer *p,
+ enum drm_gem_object_status (*status)(struct
drm_gem_object *))
+{
+ struct drm_gem_object *obj;
+ struct {
+ size_t shared;
+ size_t private;
+ size_t resident;
+ size_t purgeable;
+ size_t active;
+ } size = {0};
+ int id;
+
+ spin_lock(>table_lock);
+ idr_for_each_entry (>object_idr, obj, id) {
+ enum drm_gem_object_status s = 0;
+
+ if (status)
+ s = status(obj);
+
+ if (obj->handle_count > 1) {
+ size.shared += obj->size;
+ } else {
+ size.private += obj->size;
+ }
+
+ if (s & DRM_GEM_OBJECT_RESIDENT) {
+ size.resident += obj->size;
+ s &= ~DRM_GEM_OBJECT_PURGEABLE;
+ }
+
+ if (s & DRM_GEM_OBJECT_ACTIVE) {
+ size.active += obj->size;
+ s &= ~DRM_GEM_OBJECT_PURGEABLE;
+ }
+
+ if (s & DRM_GEM_OBJECT_PURGEABLE)
+ size.purgeable += obj->size;
+ }
+ spin_unlock(>table_lock);
+
+ print_size(p, "drm-shared-memory", size.shared);
+ print_size(p, "drm-private-memory", size.private);
+
+ if (status) {
+ print_size(p, "drm-resident-memory", size.resident);
+ print_size(p, "drm-purgeable-memory", size.purgeable);
+ print_size(p, "drm-active-memory", size.active);
+ }
+}
+EXPORT_SYMBOL(drm_print_memory_stats);
+
/**
* mock_drm_getfile - Create a new struct file for the drm device
* @minor: drm minor to wrap (e.g. #drm_device.primary)
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 0d1f853092ab..7bd8a1374f39 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -41,6 +41,7 @@
struct dma_fence;
struct drm_file;
struct drm_device;
+struct drm_printer;
struct device;
struct file;
@@ -438,6 +439,15 @@ void
[RFC 0/2] drm: fdinfo memory stats
From: Rob Clark Similar motivation to other similar recent attempt[1]. But with an attempt to have some shared code for this. As well as documentation. It is probably a bit UMA-centric, I guess devices with VRAM might want some placement stats as well. But this seems like a reasonable start. TODO gputop support? [1] https://patchwork.freedesktop.org/series/112397/ Rob Clark (2): drm: Add fdinfo memory stats drm/msm: Add memory stats to fdinfo Documentation/gpu/drm-usage-stats.rst | 21 +++ drivers/gpu/drm/drm_file.c| 79 +++ drivers/gpu/drm/msm/msm_drv.c | 26 - drivers/gpu/drm/msm/msm_gpu.c | 2 - include/drm/drm_file.h| 10 5 files changed, 135 insertions(+), 3 deletions(-) -- 2.39.2
Re: [PATCH] drm/vkms: add module parameter to set background color
Hi Maíra,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm-intel/for-linux-next
drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.3-rc5
next-20230406]
[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/Ma-ra-Canal/drm-vkms-add-module-parameter-to-set-background-color/20230407-012233
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20230406172002.124456-1-mcanal%40igalia.com
patch subject: [PATCH] drm/vkms: add module parameter to set background color
config: powerpc-allmodconfig
(https://download.01.org/0day-ci/archive/20230407/202304070429.b1akot5a-...@intel.com/config)
compiler: powerpc-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/d725068207852d3b6a0dd795bf224422804101e1
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Ma-ra-Canal/drm-vkms-add-module-parameter-to-set-background-color/20230407-012233
git checkout d725068207852d3b6a0dd795bf224422804101e1
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=powerpc olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=powerpc SHELL=/bin/bash drivers/gpu/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Link:
https://lore.kernel.org/oe-kbuild-all/202304070429.b1akot5a-...@intel.com/
All warnings (new ones prefixed by >>):
drivers/gpu/drm/vkms/vkms_composer.c: In function 'blend':
>> drivers/gpu/drm/vkms/vkms_composer.c:93:59: warning: right shift count >=
>> width of type [-Wshift-count-overflow]
93 | .r = (*vkms_dev->config->background_color >> 32) &
0x,
| ^~
vim +93 drivers/gpu/drm/vkms/vkms_composer.c
70
71 /**
72 * @wb_frame_info: The writeback frame buffer metadata
73 * @crtc_state: The crtc state
74 * @crc32: The crc output of the final frame
75 * @output_buffer: A buffer of a row that will receive the result of
the blend(s)
76 * @stage_buffer: The line with the pixels from plane being blend to
the output
77 *
78 * This function blends the pixels (Using the `pre_mul_alpha_blend`)
79 * from all planes, calculates the crc32 of the output from the former
step,
80 * and, if necessary, convert and store the output to the writeback
buffer.
81 */
82 static void blend(struct vkms_device *vkms_dev,
83struct vkms_writeback_job *wb,
84struct vkms_crtc_state *crtc_state,
85u32 *crc32, struct line_buffer *stage_buffer,
86struct line_buffer *output_buffer, size_t row_size)
87 {
88 struct vkms_plane_state **plane = crtc_state->active_planes;
89 u32 n_active_planes = crtc_state->num_active_planes;
90
91 const struct pixel_argb_u16 background_color = {
92 .a = 0x,
> 93 .r = (*vkms_dev->config->background_color >> 32) &
0x,
94 .g = (*vkms_dev->config->background_color >> 16) &
0x,
95 .b = *vkms_dev->config->background_color & 0x,
96 };
97
98 size_t crtc_y_limit = crtc_state->base.crtc->mode.vdisplay;
99
100 for (size_t y = 0; y < crtc_y_limit; y++) {
101 fill_background(_color, output_buffer);
102
103 /* The active planes are composed associatively in
z-order. */
104 for (size_t i = 0; i < n_active_planes; i++) {
105 if (!check_y_limit(plane[i]->frame_info, y))
106 continue;
107
108 plane[i]->plane_read(stage_buffer,
plane[i]->frame_info, y);
109 pre_mul_alpha_blend(plane[i]->frame_info,
stage_buffer,
110 output_buffer);
111 }
112
113 *crc32 = crc32_le(*crc32, (void
*)output_buffer->pixels, row_size);
11
[PATCH 68/68] hwmon: w83773g: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/w83773g.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/w83773g.c b/drivers/hwmon/w83773g.c
index 88d11dc5feb9..8dbcd05abd9a 100644
--- a/drivers/hwmon/w83773g.c
+++ b/drivers/hwmon/w83773g.c
@@ -233,7 +233,7 @@ static umode_t w83773_is_visible(const void *data, enum
hwmon_sensor_types type,
return 0;
}
-static const struct hwmon_channel_info *w83773_info[] = {
+static const struct hwmon_channel_info * const w83773_info[] = {
HWMON_CHANNEL_INFO(chip,
HWMON_C_REGISTER_TZ | HWMON_C_UPDATE_INTERVAL),
HWMON_CHANNEL_INFO(temp,
--
2.34.1
[PATCH 67/68] hwmon: w83627ehf: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/w83627ehf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/w83627ehf.c b/drivers/hwmon/w83627ehf.c
index 939d4c35e713..fe960c0a624f 100644
--- a/drivers/hwmon/w83627ehf.c
+++ b/drivers/hwmon/w83627ehf.c
@@ -1640,7 +1640,7 @@ static const struct hwmon_ops w83627ehf_ops = {
.write = w83627ehf_write,
};
-static const struct hwmon_channel_info *w83627ehf_info[] = {
+static const struct hwmon_channel_info * const w83627ehf_info[] = {
HWMON_CHANNEL_INFO(fan,
HWMON_F_ALARM | HWMON_F_DIV | HWMON_F_INPUT | HWMON_F_MIN,
HWMON_F_ALARM | HWMON_F_DIV | HWMON_F_INPUT | HWMON_F_MIN,
--
2.34.1
[PATCH 66/68] hwmon: tps23861: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/tps23861.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/tps23861.c b/drivers/hwmon/tps23861.c
index 68c77c493270..85a75f551148 100644
--- a/drivers/hwmon/tps23861.c
+++ b/drivers/hwmon/tps23861.c
@@ -341,7 +341,7 @@ static int tps23861_read_string(struct device *dev,
return 0;
}
-static const struct hwmon_channel_info *tps23861_info[] = {
+static const struct hwmon_channel_info * const tps23861_info[] = {
HWMON_CHANNEL_INFO(chip,
HWMON_C_REGISTER_TZ),
HWMON_CHANNEL_INFO(temp,
--
2.34.1
[PATCH 65/68] hwmon: tmp513: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/tmp513.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/tmp513.c b/drivers/hwmon/tmp513.c
index 7d5f7441aceb..0693eaee054f 100644
--- a/drivers/hwmon/tmp513.c
+++ b/drivers/hwmon/tmp513.c
@@ -491,7 +491,7 @@ static umode_t tmp51x_is_visible(const void *_data,
return 0;
}
-static const struct hwmon_channel_info *tmp51x_info[] = {
+static const struct hwmon_channel_info * const tmp51x_info[] = {
HWMON_CHANNEL_INFO(temp,
HWMON_T_INPUT | HWMON_T_CRIT | HWMON_T_CRIT_ALARM |
HWMON_T_CRIT_HYST,
--
2.34.1
[PATCH 64/68] hwmon: tmp464: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/tmp464.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/tmp464.c b/drivers/hwmon/tmp464.c
index 7814f39bd1a3..9213a493a590 100644
--- a/drivers/hwmon/tmp464.c
+++ b/drivers/hwmon/tmp464.c
@@ -589,7 +589,7 @@ static const struct hwmon_ops tmp464_ops = {
.write = tmp464_write,
};
-static const struct hwmon_channel_info *tmp464_info[] = {
+static const struct hwmon_channel_info * const tmp464_info[] = {
HWMON_CHANNEL_INFO(chip,
HWMON_C_UPDATE_INTERVAL),
HWMON_CHANNEL_INFO(temp,
--
2.34.1
[PATCH 63/68] hwmon: tmp108: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/tmp108.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/tmp108.c b/drivers/hwmon/tmp108.c
index acb4ba750b09..43784c289a9e 100644
--- a/drivers/hwmon/tmp108.c
+++ b/drivers/hwmon/tmp108.c
@@ -272,7 +272,7 @@ static umode_t tmp108_is_visible(const void *data, enum
hwmon_sensor_types type,
}
}
-static const struct hwmon_channel_info *tmp108_info[] = {
+static const struct hwmon_channel_info * const tmp108_info[] = {
HWMON_CHANNEL_INFO(chip,
HWMON_C_REGISTER_TZ | HWMON_C_UPDATE_INTERVAL),
HWMON_CHANNEL_INFO(temp,
--
2.34.1
[PATCH 62/68] hwmon: tmp103: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/tmp103.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/tmp103.c b/drivers/hwmon/tmp103.c
index 56d5cbf36a45..d257bb91fc69 100644
--- a/drivers/hwmon/tmp103.c
+++ b/drivers/hwmon/tmp103.c
@@ -119,7 +119,7 @@ static umode_t tmp103_is_visible(const void *data, enum
hwmon_sensor_types type,
}
}
-static const struct hwmon_channel_info *tmp103_info[] = {
+static const struct hwmon_channel_info * const tmp103_info[] = {
HWMON_CHANNEL_INFO(chip,
HWMON_C_REGISTER_TZ),
HWMON_CHANNEL_INFO(temp,
--
2.34.1
[PATCH 61/68] hwmon: tmp102: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/tmp102.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
index 2bf496a62206..e271556efe0b 100644
--- a/drivers/hwmon/tmp102.c
+++ b/drivers/hwmon/tmp102.c
@@ -141,7 +141,7 @@ static umode_t tmp102_is_visible(const void *data, enum
hwmon_sensor_types type,
}
}
-static const struct hwmon_channel_info *tmp102_info[] = {
+static const struct hwmon_channel_info * const tmp102_info[] = {
HWMON_CHANNEL_INFO(chip,
HWMON_C_REGISTER_TZ),
HWMON_CHANNEL_INFO(temp,
--
2.34.1
[PATCH 60/68] hwmon: sy7636a: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/sy7636a-hwmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/sy7636a-hwmon.c b/drivers/hwmon/sy7636a-hwmon.c
index 6dd9c2a0f0e0..ed110884786b 100644
--- a/drivers/hwmon/sy7636a-hwmon.c
+++ b/drivers/hwmon/sy7636a-hwmon.c
@@ -52,7 +52,7 @@ static const struct hwmon_ops sy7636a_hwmon_ops = {
.read = sy7636a_read,
};
-static const struct hwmon_channel_info *sy7636a_info[] = {
+static const struct hwmon_channel_info * const sy7636a_info[] = {
HWMON_CHANNEL_INFO(chip, HWMON_C_REGISTER_TZ),
HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT),
NULL
--
2.34.1
[PATCH 59/68] hwmon: sparx5-temp: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/sparx5-temp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/sparx5-temp.c b/drivers/hwmon/sparx5-temp.c
index 04fd8505e5d6..d640904939cd 100644
--- a/drivers/hwmon/sparx5-temp.c
+++ b/drivers/hwmon/sparx5-temp.c
@@ -86,7 +86,7 @@ static umode_t s5_is_visible(const void *_data, enum
hwmon_sensor_types type,
}
}
-static const struct hwmon_channel_info *s5_info[] = {
+static const struct hwmon_channel_info * const s5_info[] = {
HWMON_CHANNEL_INFO(chip, HWMON_C_REGISTER_TZ),
HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT),
NULL
--
2.34.1
[PATCH 58/68] hwmon: smpro: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/smpro-hwmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/smpro-hwmon.c b/drivers/hwmon/smpro-hwmon.c
index a76c49dd8438..d320adbd47f4 100644
--- a/drivers/hwmon/smpro-hwmon.c
+++ b/drivers/hwmon/smpro-hwmon.c
@@ -385,7 +385,7 @@ static umode_t smpro_is_visible(const void *data, enum
hwmon_sensor_types type,
return 0444;
}
-static const struct hwmon_channel_info *smpro_info[] = {
+static const struct hwmon_channel_info * const smpro_info[] = {
HWMON_CHANNEL_INFO(temp,
HWMON_T_INPUT | HWMON_T_LABEL,
HWMON_T_INPUT | HWMON_T_LABEL | HWMON_T_CRIT,
--
2.34.1
[PATCH 57/68] hwmon: sl28cpld: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/sl28cpld-hwmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/sl28cpld-hwmon.c b/drivers/hwmon/sl28cpld-hwmon.c
index 9ce4899a81a5..e020f25c9300 100644
--- a/drivers/hwmon/sl28cpld-hwmon.c
+++ b/drivers/hwmon/sl28cpld-hwmon.c
@@ -67,7 +67,7 @@ static int sl28cpld_hwmon_read(struct device *dev,
return 0;
}
-static const struct hwmon_channel_info *sl28cpld_hwmon_info[] = {
+static const struct hwmon_channel_info * const sl28cpld_hwmon_info[] = {
HWMON_CHANNEL_INFO(fan, HWMON_F_INPUT),
NULL
};
--
2.34.1
[PATCH 56/68] hwmon: sht4x: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/sht4x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/sht4x.c b/drivers/hwmon/sht4x.c
index 13e042927bf8..5bbe09135ab9 100644
--- a/drivers/hwmon/sht4x.c
+++ b/drivers/hwmon/sht4x.c
@@ -214,7 +214,7 @@ static int sht4x_hwmon_write(struct device *dev, enum
hwmon_sensor_types type,
}
}
-static const struct hwmon_channel_info *sht4x_info[] = {
+static const struct hwmon_channel_info * const sht4x_info[] = {
HWMON_CHANNEL_INFO(chip, HWMON_C_UPDATE_INTERVAL),
HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT),
HWMON_CHANNEL_INFO(humidity, HWMON_H_INPUT),
--
2.34.1
[PATCH 55/68] hwmon: sch5627: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/sch5627.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/sch5627.c b/drivers/hwmon/sch5627.c
index 25fbbd4c9a2b..1bbda3b05532 100644
--- a/drivers/hwmon/sch5627.c
+++ b/drivers/hwmon/sch5627.c
@@ -379,7 +379,7 @@ static const struct hwmon_ops sch5627_ops = {
.write = sch5627_write,
};
-static const struct hwmon_channel_info *sch5627_info[] = {
+static const struct hwmon_channel_info * const sch5627_info[] = {
HWMON_CHANNEL_INFO(chip, HWMON_C_REGISTER_TZ),
HWMON_CHANNEL_INFO(temp,
HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_CRIT |
HWMON_T_FAULT,
--
2.34.1
[PATCH 54/68] hwmon: sbtsi_temp: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/sbtsi_temp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/sbtsi_temp.c b/drivers/hwmon/sbtsi_temp.c
index 4c37de846f93..7049d9464ac6 100644
--- a/drivers/hwmon/sbtsi_temp.c
+++ b/drivers/hwmon/sbtsi_temp.c
@@ -182,7 +182,7 @@ static umode_t sbtsi_is_visible(const void *data,
return 0;
}
-static const struct hwmon_channel_info *sbtsi_info[] = {
+static const struct hwmon_channel_info * const sbtsi_info[] = {
HWMON_CHANNEL_INFO(chip, HWMON_C_REGISTER_TZ),
HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT | HWMON_T_MIN | HWMON_T_MAX),
NULL
--
2.34.1
[PATCH 53/68] hwmon: sbrmi: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/sbrmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/sbrmi.c b/drivers/hwmon/sbrmi.c
index 8ea5a4d3219f..529f0e766319 100644
--- a/drivers/hwmon/sbrmi.c
+++ b/drivers/hwmon/sbrmi.c
@@ -265,7 +265,7 @@ static umode_t sbrmi_is_visible(const void *data,
return 0;
}
-static const struct hwmon_channel_info *sbrmi_info[] = {
+static const struct hwmon_channel_info * const sbrmi_info[] = {
HWMON_CHANNEL_INFO(power,
HWMON_P_INPUT | HWMON_P_CAP | HWMON_P_CAP_MAX),
NULL
--
2.34.1
[PATCH 52/68] hwmon: raspberrypi: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/raspberrypi-hwmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/raspberrypi-hwmon.c
b/drivers/hwmon/raspberrypi-hwmon.c
index 1650d3b4c26e..65cc52e47db0 100644
--- a/drivers/hwmon/raspberrypi-hwmon.c
+++ b/drivers/hwmon/raspberrypi-hwmon.c
@@ -87,7 +87,7 @@ static umode_t rpi_is_visible(const void *_data, enum
hwmon_sensor_types type,
return 0444;
}
-static const struct hwmon_channel_info *rpi_info[] = {
+static const struct hwmon_channel_info * const rpi_info[] = {
HWMON_CHANNEL_INFO(in,
HWMON_I_LCRIT_ALARM),
NULL
--
2.34.1
[PATCH 51/68] hwmon: powr1220: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/powr1220.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/powr1220.c b/drivers/hwmon/powr1220.c
index f77dc6db31ac..9cb0c2de5219 100644
--- a/drivers/hwmon/powr1220.c
+++ b/drivers/hwmon/powr1220.c
@@ -248,7 +248,7 @@ powr1220_read(struct device *dev, enum hwmon_sensor_types
type, u32
return 0;
}
-static const struct hwmon_channel_info *powr1220_info[] = {
+static const struct hwmon_channel_info * const powr1220_info[] = {
HWMON_CHANNEL_INFO(in,
HWMON_I_INPUT | HWMON_I_HIGHEST | HWMON_I_LABEL,
HWMON_I_INPUT | HWMON_I_HIGHEST | HWMON_I_LABEL,
--
2.34.1
[PATCH 50/68] hwmon: peci: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/peci/cputemp.c | 2 +-
drivers/hwmon/peci/dimmtemp.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hwmon/peci/cputemp.c b/drivers/hwmon/peci/cputemp.c
index 87d56f0fc888..e5b65a382772 100644
--- a/drivers/hwmon/peci/cputemp.c
+++ b/drivers/hwmon/peci/cputemp.c
@@ -447,7 +447,7 @@ static const struct hwmon_ops peci_cputemp_ops = {
.read = cputemp_read,
};
-static const struct hwmon_channel_info *peci_cputemp_info[] = {
+static const struct hwmon_channel_info * const peci_cputemp_info[] = {
HWMON_CHANNEL_INFO(temp,
/* Die temperature */
HWMON_T_LABEL | HWMON_T_INPUT | HWMON_T_MAX |
diff --git a/drivers/hwmon/peci/dimmtemp.c b/drivers/hwmon/peci/dimmtemp.c
index 0a633bda3668..ed968401f93c 100644
--- a/drivers/hwmon/peci/dimmtemp.c
+++ b/drivers/hwmon/peci/dimmtemp.c
@@ -300,7 +300,7 @@ static int create_dimm_temp_label(struct peci_dimmtemp
*priv, int chan)
return 0;
}
-static const struct hwmon_channel_info *peci_dimmtemp_temp_info[] = {
+static const struct hwmon_channel_info * const peci_dimmtemp_temp_info[] = {
HWMON_CHANNEL_INFO(temp,
[0 ... DIMM_NUMS_MAX - 1] = HWMON_T_LABEL |
HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_CRIT),
--
2.34.1
[PATCH 49/68] hwmon: oxp-sensors: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/oxp-sensors.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/oxp-sensors.c b/drivers/hwmon/oxp-sensors.c
index 36872b57912a..ae67207030e8 100644
--- a/drivers/hwmon/oxp-sensors.c
+++ b/drivers/hwmon/oxp-sensors.c
@@ -239,7 +239,7 @@ static int oxp_platform_write(struct device *dev, enum
hwmon_sensor_types type,
}
/* Known sensors in the OXP EC controllers */
-static const struct hwmon_channel_info *oxp_platform_sensors[] = {
+static const struct hwmon_channel_info * const oxp_platform_sensors[] = {
HWMON_CHANNEL_INFO(fan,
HWMON_F_INPUT),
HWMON_CHANNEL_INFO(pwm,
--
2.34.1
[PATCH 48/68] hwmon: nzxt: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/nzxt-kraken2.c | 2 +-
drivers/hwmon/nzxt-smart2.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hwmon/nzxt-kraken2.c b/drivers/hwmon/nzxt-kraken2.c
index 89f7ea4f42d4..428c77b5fce5 100644
--- a/drivers/hwmon/nzxt-kraken2.c
+++ b/drivers/hwmon/nzxt-kraken2.c
@@ -86,7 +86,7 @@ static const struct hwmon_ops kraken2_hwmon_ops = {
.read_string = kraken2_read_string,
};
-static const struct hwmon_channel_info *kraken2_info[] = {
+static const struct hwmon_channel_info * const kraken2_info[] = {
HWMON_CHANNEL_INFO(temp,
HWMON_T_INPUT | HWMON_T_LABEL),
HWMON_CHANNEL_INFO(fan,
diff --git a/drivers/hwmon/nzxt-smart2.c b/drivers/hwmon/nzxt-smart2.c
index e5edf8071f39..7aa586eb74be 100644
--- a/drivers/hwmon/nzxt-smart2.c
+++ b/drivers/hwmon/nzxt-smart2.c
@@ -663,7 +663,7 @@ static const struct hwmon_ops nzxt_smart2_hwmon_ops = {
.write = nzxt_smart2_hwmon_write,
};
-static const struct hwmon_channel_info *nzxt_smart2_channel_info[] = {
+static const struct hwmon_channel_info * const nzxt_smart2_channel_info[] = {
HWMON_CHANNEL_INFO(fan, HWMON_F_INPUT | HWMON_F_LABEL,
HWMON_F_INPUT | HWMON_F_LABEL,
HWMON_F_INPUT | HWMON_F_LABEL),
--
2.34.1
[PATCH 47/68] hwmon: ntc_thermistor: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/ntc_thermistor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/ntc_thermistor.c b/drivers/hwmon/ntc_thermistor.c
index 9c9e9f4ccb9e..ef75b63f5894 100644
--- a/drivers/hwmon/ntc_thermistor.c
+++ b/drivers/hwmon/ntc_thermistor.c
@@ -546,7 +546,7 @@ static umode_t ntc_is_visible(const void *data, enum
hwmon_sensor_types type,
return 0;
}
-static const struct hwmon_channel_info *ntc_info[] = {
+static const struct hwmon_channel_info * const ntc_info[] = {
HWMON_CHANNEL_INFO(chip, HWMON_C_REGISTER_TZ),
HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT | HWMON_T_TYPE),
NULL
--
2.34.1
[PATCH 46/68] hwmon: npcm750-pwm: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/npcm750-pwm-fan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/npcm750-pwm-fan.c b/drivers/hwmon/npcm750-pwm-fan.c
index 11a28609da3c..10ed3f4335d4 100644
--- a/drivers/hwmon/npcm750-pwm-fan.c
+++ b/drivers/hwmon/npcm750-pwm-fan.c
@@ -629,7 +629,7 @@ static umode_t npcm7xx_is_visible(const void *data,
}
}
-static const struct hwmon_channel_info *npcm7xx_info[] = {
+static const struct hwmon_channel_info * const npcm7xx_info[] = {
HWMON_CHANNEL_INFO(pwm,
HWMON_PWM_INPUT,
HWMON_PWM_INPUT,
--
2.34.1
[PATCH 45/68] hwmon: nct7904: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/nct7904.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/nct7904.c b/drivers/hwmon/nct7904.c
index ecc5db0011a3..007bae4c7028 100644
--- a/drivers/hwmon/nct7904.c
+++ b/drivers/hwmon/nct7904.c
@@ -803,7 +803,7 @@ static int nct7904_detect(struct i2c_client *client,
return 0;
}
-static const struct hwmon_channel_info *nct7904_info[] = {
+static const struct hwmon_channel_info * const nct7904_info[] = {
HWMON_CHANNEL_INFO(in,
/* dummy, skipped in is_visible */
HWMON_I_INPUT | HWMON_I_MIN | HWMON_I_MAX |
--
2.34.1
[PATCH 44/68] hwmon: mlxreg: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/mlxreg-fan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/mlxreg-fan.c b/drivers/hwmon/mlxreg-fan.c
index 96017cc8da7e..c2a96468c9b4 100644
--- a/drivers/hwmon/mlxreg-fan.c
+++ b/drivers/hwmon/mlxreg-fan.c
@@ -285,7 +285,7 @@ static char *mlxreg_fan_name[] = {
"mlxreg_fan3",
};
-static const struct hwmon_channel_info *mlxreg_fan_hwmon_info[] = {
+static const struct hwmon_channel_info * const mlxreg_fan_hwmon_info[] = {
HWMON_CHANNEL_INFO(fan,
HWMON_F_INPUT | HWMON_F_FAULT,
HWMON_F_INPUT | HWMON_F_FAULT,
--
2.34.1
[PATCH 43/68] hwmon: mcp3021: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/mcp3021.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/mcp3021.c b/drivers/hwmon/mcp3021.c
index e093b1998296..a5f7a294f33d 100644
--- a/drivers/hwmon/mcp3021.c
+++ b/drivers/hwmon/mcp3021.c
@@ -102,7 +102,7 @@ static umode_t mcp3021_is_visible(const void *_data,
return 0444;
}
-static const struct hwmon_channel_info *mcp3021_info[] = {
+static const struct hwmon_channel_info * const mcp3021_info[] = {
HWMON_CHANNEL_INFO(in, HWMON_I_INPUT),
NULL
};
--
2.34.1
(Attn. Skeggsb) Re: [PATCH] drm/nouveau/gr/tu102: remove unused tu102_gr_load function
Hey Ben - this patch looks fine to me but I figured I should check before
giving it the OK: I assume we're not planning on using tu102_gr_load for
anything in the future? (if we are, do we want to just #if 0 this for the time
being?)
On Thu, 2023-04-06 at 08:51 -0400, Tom Rix wrote:
> smatch reports
> drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c:210:1: warning: symbol
> 'tu102_gr_load' was not declared. Should it be static?
>
> This function is not used so remove it.
>
> Signed-off-by: Tom Rix
> ---
> drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c | 13 -
> 1 file changed, 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c
> index 3b6c8100a242..a7775aa18541 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c
> @@ -206,19 +206,6 @@ tu102_gr_av_to_init_veid(struct nvkm_blob *blob, struct
> gf100_gr_pack **ppack)
> return gk20a_gr_av_to_init_(blob, 64, 0x0010, ppack);
> }
>
> -int
> -tu102_gr_load(struct gf100_gr *gr, int ver, const struct gf100_gr_fwif *fwif)
> -{
> - int ret;
> -
> - ret = gm200_gr_load(gr, ver, fwif);
> - if (ret)
> - return ret;
> -
> - return gk20a_gr_load_net(gr, "gr/", "sw_veid_bundle_init", ver,
> tu102_gr_av_to_init_veid,
> - >bundle_veid);
> -}
> -
> static const struct gf100_gr_fwif
> tu102_gr_fwif[] = {
> { 0, gm200_gr_load, _gr, _gr_fecs_acr, _gr_gpccs_acr
> },
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
[PATCH 42/68] hwmon: mc34vr500: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/mc34vr500.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/mc34vr500.c b/drivers/hwmon/mc34vr500.c
index 6268e973049c..6a7a950a9332 100644
--- a/drivers/hwmon/mc34vr500.c
+++ b/drivers/hwmon/mc34vr500.c
@@ -138,7 +138,7 @@ static int mc34vr500_read(struct device *dev, enum
hwmon_sensor_types type,
}
}
-static const struct hwmon_channel_info *mc34vr500_info[] = {
+static const struct hwmon_channel_info * const mc34vr500_info[] = {
HWMON_CHANNEL_INFO(in, HWMON_I_MIN_ALARM),
HWMON_CHANNEL_INFO(temp, HWMON_T_MAX_ALARM | HWMON_T_CRIT_ALARM
| HWMON_T_EMERGENCY_ALARM),
--
2.34.1
[PATCH 41/68] hwmon: max6650: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/max6650.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/max6650.c b/drivers/hwmon/max6650.c
index f8d4534ce172..19e2c762ed2d 100644
--- a/drivers/hwmon/max6650.c
+++ b/drivers/hwmon/max6650.c
@@ -737,7 +737,7 @@ static umode_t max6650_is_visible(const void *_data,
return 0;
}
-static const struct hwmon_channel_info *max6650_info[] = {
+static const struct hwmon_channel_info * const max6650_info[] = {
HWMON_CHANNEL_INFO(fan, HWMON_F_INPUT | HWMON_F_TARGET | HWMON_F_DIV |
HWMON_F_MIN_ALARM | HWMON_F_MAX_ALARM |
HWMON_F_FAULT,
--
2.34.1
[PATCH 40/68] hwmon: max6621: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/max6621.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/max6621.c b/drivers/hwmon/max6621.c
index 7821132e17fa..0656eb1e7959 100644
--- a/drivers/hwmon/max6621.c
+++ b/drivers/hwmon/max6621.c
@@ -449,7 +449,7 @@ static const struct regmap_config max6621_regmap_config = {
.num_reg_defaults = ARRAY_SIZE(max6621_regmap_default),
};
-static const struct hwmon_channel_info *max6621_info[] = {
+static const struct hwmon_channel_info * const max6621_info[] = {
HWMON_CHANNEL_INFO(chip,
HWMON_C_REGISTER_TZ),
HWMON_CHANNEL_INFO(temp,
--
2.34.1
[PATCH 38/68] hwmon: max31790: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/max31790.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/max31790.c b/drivers/hwmon/max31790.c
index 20bf5ffadefe..6caba6e8ee8f 100644
--- a/drivers/hwmon/max31790.c
+++ b/drivers/hwmon/max31790.c
@@ -445,7 +445,7 @@ static umode_t max31790_is_visible(const void *data,
}
}
-static const struct hwmon_channel_info *max31790_info[] = {
+static const struct hwmon_channel_info * const max31790_info[] = {
HWMON_CHANNEL_INFO(fan,
HWMON_F_INPUT | HWMON_F_TARGET | HWMON_F_FAULT |
HWMON_F_ENABLE,
HWMON_F_INPUT | HWMON_F_TARGET | HWMON_F_FAULT |
HWMON_F_ENABLE,
--
2.34.1
[PATCH 39/68] hwmon: max6620: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/max6620.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/max6620.c b/drivers/hwmon/max6620.c
index 202b6438179d..0f277d945ea2 100644
--- a/drivers/hwmon/max6620.c
+++ b/drivers/hwmon/max6620.c
@@ -401,7 +401,7 @@ max6620_write(struct device *dev, enum hwmon_sensor_types
type, u32 attr,
return ret;
}
-static const struct hwmon_channel_info *max6620_info[] = {
+static const struct hwmon_channel_info * const max6620_info[] = {
HWMON_CHANNEL_INFO(fan,
HWMON_F_INPUT | HWMON_F_DIV | HWMON_F_TARGET |
HWMON_F_ALARM,
HWMON_F_INPUT | HWMON_F_DIV | HWMON_F_TARGET |
HWMON_F_ALARM,
--
2.34.1
[PATCH 36/68] hwmon: max31730: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/max31730.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/max31730.c b/drivers/hwmon/max31730.c
index 746a767c9fc6..924333d89ce4 100644
--- a/drivers/hwmon/max31730.c
+++ b/drivers/hwmon/max31730.c
@@ -248,7 +248,7 @@ static umode_t max31730_is_visible(const void *data,
return 0;
}
-static const struct hwmon_channel_info *max31730_info[] = {
+static const struct hwmon_channel_info * const max31730_info[] = {
HWMON_CHANNEL_INFO(chip,
HWMON_C_REGISTER_TZ),
HWMON_CHANNEL_INFO(temp,
--
2.34.1
[PATCH 35/68] hwmon: max127: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/max127.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/max127.c b/drivers/hwmon/max127.c
index 0e21e7e6bbd2..49de1d2be294 100644
--- a/drivers/hwmon/max127.c
+++ b/drivers/hwmon/max127.c
@@ -285,7 +285,7 @@ static const struct hwmon_ops max127_hwmon_ops = {
.write = max127_write,
};
-static const struct hwmon_channel_info *max127_info[] = {
+static const struct hwmon_channel_info * const max127_info[] = {
HWMON_CHANNEL_INFO(in,
HWMON_I_INPUT | HWMON_I_MIN | HWMON_I_MAX,
HWMON_I_INPUT | HWMON_I_MIN | HWMON_I_MAX,
--
2.34.1
[PATCH 37/68] hwmon: max31760: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/max31760.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/max31760.c b/drivers/hwmon/max31760.c
index 06d5f39dc33d..4489110f109c 100644
--- a/drivers/hwmon/max31760.c
+++ b/drivers/hwmon/max31760.c
@@ -318,7 +318,7 @@ static int max31760_write(struct device *dev, enum
hwmon_sensor_types type,
}
}
-static const struct hwmon_channel_info *max31760_info[] = {
+static const struct hwmon_channel_info * const max31760_info[] = {
HWMON_CHANNEL_INFO(chip,
HWMON_C_REGISTER_TZ),
HWMON_CHANNEL_INFO(fan,
--
2.34.1
[PATCH 32/68] hwmon: ltc2992: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/ltc2992.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/ltc2992.c b/drivers/hwmon/ltc2992.c
index 69341de397cb..429a7f5837f0 100644
--- a/drivers/hwmon/ltc2992.c
+++ b/drivers/hwmon/ltc2992.c
@@ -812,7 +812,7 @@ static const struct hwmon_ops ltc2992_hwmon_ops = {
.write = ltc2992_write,
};
-static const struct hwmon_channel_info *ltc2992_info[] = {
+static const struct hwmon_channel_info * const ltc2992_info[] = {
HWMON_CHANNEL_INFO(chip,
HWMON_C_IN_RESET_HISTORY),
HWMON_CHANNEL_INFO(in,
--
2.34.1
[PATCH 34/68] hwmon: ltq-cputemp: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/ltq-cputemp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/ltq-cputemp.c b/drivers/hwmon/ltq-cputemp.c
index 019e770d4c0c..08e09a82acab 100644
--- a/drivers/hwmon/ltq-cputemp.c
+++ b/drivers/hwmon/ltq-cputemp.c
@@ -65,7 +65,7 @@ static umode_t ltq_is_visible(const void *_data, enum
hwmon_sensor_types type,
}
}
-static const struct hwmon_channel_info *ltq_info[] = {
+static const struct hwmon_channel_info * const ltq_info[] = {
HWMON_CHANNEL_INFO(chip,
HWMON_C_REGISTER_TZ),
HWMON_CHANNEL_INFO(temp,
--
2.34.1
[PATCH 33/68] hwmon: ltc4245: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/ltc4245.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/ltc4245.c b/drivers/hwmon/ltc4245.c
index 57cbaf3b39fa..fb9bc8dbe99b 100644
--- a/drivers/hwmon/ltc4245.c
+++ b/drivers/hwmon/ltc4245.c
@@ -387,7 +387,7 @@ static umode_t ltc4245_is_visible(const void *_data,
}
}
-static const struct hwmon_channel_info *ltc4245_info[] = {
+static const struct hwmon_channel_info * const ltc4245_info[] = {
HWMON_CHANNEL_INFO(in,
HWMON_I_INPUT,
HWMON_I_INPUT | HWMON_I_MIN_ALARM,
--
2.34.1
[PATCH 31/68] hwmon: ltc2947: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/ltc2947-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/ltc2947-core.c b/drivers/hwmon/ltc2947-core.c
index 2dbbbac9de09..d2ff6e700770 100644
--- a/drivers/hwmon/ltc2947-core.c
+++ b/drivers/hwmon/ltc2947-core.c
@@ -901,7 +901,7 @@ static umode_t ltc2947_is_visible(const void *data,
}
}
-static const struct hwmon_channel_info *ltc2947_info[] = {
+static const struct hwmon_channel_info * const ltc2947_info[] = {
HWMON_CHANNEL_INFO(in,
HWMON_I_INPUT | HWMON_I_LOWEST | HWMON_I_HIGHEST |
HWMON_I_MAX | HWMON_I_MIN | HWMON_I_RESET_HISTORY |
--
2.34.1
[PATCH 30/68] hwmon: lochnagar: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/lochnagar-hwmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/lochnagar-hwmon.c b/drivers/hwmon/lochnagar-hwmon.c
index 8b19adf2eeb0..9948e2f7208d 100644
--- a/drivers/hwmon/lochnagar-hwmon.c
+++ b/drivers/hwmon/lochnagar-hwmon.c
@@ -321,7 +321,7 @@ static const struct hwmon_ops lochnagar_ops = {
.write = lochnagar_write,
};
-static const struct hwmon_channel_info *lochnagar_info[] = {
+static const struct hwmon_channel_info * const lochnagar_info[] = {
HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT),
HWMON_CHANNEL_INFO(in,HWMON_I_INPUT | HWMON_I_LABEL,
HWMON_I_INPUT | HWMON_I_LABEL,
--
2.34.1
[PATCH 29/68] hwmon: lm95245: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/lm95245.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/lm95245.c b/drivers/hwmon/lm95245.c
index c433f0af2d31..4236d1e0544d 100644
--- a/drivers/hwmon/lm95245.c
+++ b/drivers/hwmon/lm95245.c
@@ -523,7 +523,7 @@ static const struct regmap_config lm95245_regmap_config = {
.use_single_write = true,
};
-static const struct hwmon_channel_info *lm95245_info[] = {
+static const struct hwmon_channel_info * const lm95245_info[] = {
HWMON_CHANNEL_INFO(chip,
HWMON_C_UPDATE_INTERVAL),
HWMON_CHANNEL_INFO(temp,
--
2.34.1
[PATCH 28/68] hwmon: lm95241: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/lm95241.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/lm95241.c b/drivers/hwmon/lm95241.c
index f1ed777a8735..647a90570bc6 100644
--- a/drivers/hwmon/lm95241.c
+++ b/drivers/hwmon/lm95241.c
@@ -409,7 +409,7 @@ static void lm95241_init_client(struct i2c_client *client,
data->model);
}
-static const struct hwmon_channel_info *lm95241_info[] = {
+static const struct hwmon_channel_info * const lm95241_info[] = {
HWMON_CHANNEL_INFO(chip,
HWMON_C_UPDATE_INTERVAL),
HWMON_CHANNEL_INFO(temp,
--
2.34.1
[PATCH 27/68] hwmon: lm83: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/lm83.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/lm83.c b/drivers/hwmon/lm83.c
index 616449f2cc50..bcaf31ec176e 100644
--- a/drivers/hwmon/lm83.c
+++ b/drivers/hwmon/lm83.c
@@ -337,7 +337,7 @@ static umode_t lm83_is_visible(const void *_data, enum
hwmon_sensor_types type,
return 0;
}
-static const struct hwmon_channel_info *lm83_info[] = {
+static const struct hwmon_channel_info * const lm83_info[] = {
HWMON_CHANNEL_INFO(chip, HWMON_C_ALARMS),
HWMON_CHANNEL_INFO(temp,
HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_CRIT |
--
2.34.1
[PATCH 26/68] hwmon: lm75: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/lm75.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index bcc3adcb3af1..dbb99ea4a0ec 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -512,7 +512,7 @@ static umode_t lm75_is_visible(const void *data, enum
hwmon_sensor_types type,
return 0;
}
-static const struct hwmon_channel_info *lm75_info[] = {
+static const struct hwmon_channel_info * const lm75_info[] = {
HWMON_CHANNEL_INFO(chip,
HWMON_C_REGISTER_TZ | HWMON_C_UPDATE_INTERVAL),
HWMON_CHANNEL_INFO(temp,
--
2.34.1
[PATCH 25/68] hwmon: lan966x: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/lan966x-hwmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/lan966x-hwmon.c b/drivers/hwmon/lan966x-hwmon.c
index f41df053ac31..f8658359a098 100644
--- a/drivers/hwmon/lan966x-hwmon.c
+++ b/drivers/hwmon/lan966x-hwmon.c
@@ -260,7 +260,7 @@ static umode_t lan966x_hwmon_is_visible(const void *data,
return mode;
}
-static const struct hwmon_channel_info *lan966x_hwmon_info[] = {
+static const struct hwmon_channel_info * const lan966x_hwmon_info[] = {
HWMON_CHANNEL_INFO(chip, HWMON_C_REGISTER_TZ),
HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT),
HWMON_CHANNEL_INFO(fan, HWMON_F_INPUT),
--
2.34.1
[PATCH 24/68] hwmon: k8temp: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/k8temp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/k8temp.c b/drivers/hwmon/k8temp.c
index f73bd4eceb28..2b80ac410cd1 100644
--- a/drivers/hwmon/k8temp.c
+++ b/drivers/hwmon/k8temp.c
@@ -118,7 +118,7 @@ static const struct hwmon_ops k8temp_ops = {
.read = k8temp_read,
};
-static const struct hwmon_channel_info *k8temp_info[] = {
+static const struct hwmon_channel_info * const k8temp_info[] = {
HWMON_CHANNEL_INFO(temp,
HWMON_T_INPUT, HWMON_T_INPUT, HWMON_T_INPUT, HWMON_T_INPUT),
NULL
--
2.34.1
[PATCH 23/68] hwmon: k10temp: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/k10temp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/k10temp.c b/drivers/hwmon/k10temp.c
index 5a9d47a229e4..df8f08740c1c 100644
--- a/drivers/hwmon/k10temp.c
+++ b/drivers/hwmon/k10temp.c
@@ -332,7 +332,7 @@ static bool has_erratum_319(struct pci_dev *pdev)
(boot_cpu_data.x86_model == 4 && boot_cpu_data.x86_stepping <=
2);
}
-static const struct hwmon_channel_info *k10temp_info[] = {
+static const struct hwmon_channel_info * const k10temp_info[] = {
HWMON_CHANNEL_INFO(temp,
HWMON_T_INPUT | HWMON_T_MAX |
HWMON_T_CRIT | HWMON_T_CRIT_HYST |
--
2.34.1
[PATCH 19/68] hwmon: ina238: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/ina238.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/ina238.c b/drivers/hwmon/ina238.c
index 50eb9c5e132e..8af07bc0c50e 100644
--- a/drivers/hwmon/ina238.c
+++ b/drivers/hwmon/ina238.c
@@ -501,7 +501,7 @@ static umode_t ina238_is_visible(const void *drvdata,
HWMON_I_MAX | HWMON_I_MAX_ALARM | \
HWMON_I_MIN | HWMON_I_MIN_ALARM)
-static const struct hwmon_channel_info *ina238_info[] = {
+static const struct hwmon_channel_info * const ina238_info[] = {
HWMON_CHANNEL_INFO(in,
/* 0: shunt voltage */
INA238_HWMON_IN_CONFIG,
--
2.34.1
[PATCH 22/68] hwmon: jc42: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/jc42.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/jc42.c b/drivers/hwmon/jc42.c
index 8523bf974310..4c60dc520b12 100644
--- a/drivers/hwmon/jc42.c
+++ b/drivers/hwmon/jc42.c
@@ -450,7 +450,7 @@ static int jc42_detect(struct i2c_client *client, struct
i2c_board_info *info)
return -ENODEV;
}
-static const struct hwmon_channel_info *jc42_info[] = {
+static const struct hwmon_channel_info * const jc42_info[] = {
HWMON_CHANNEL_INFO(chip,
HWMON_C_REGISTER_TZ | HWMON_C_UPDATE_INTERVAL),
HWMON_CHANNEL_INFO(temp,
--
2.34.1
[PATCH 20/68] hwmon: ina3221: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/ina3221.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/ina3221.c b/drivers/hwmon/ina3221.c
index f3a4c5633b1e..2735e3782ffb 100644
--- a/drivers/hwmon/ina3221.c
+++ b/drivers/hwmon/ina3221.c
@@ -650,7 +650,7 @@ static umode_t ina3221_is_visible(const void *drvdata,
HWMON_C_CRIT | HWMON_C_CRIT_ALARM | \
HWMON_C_MAX | HWMON_C_MAX_ALARM)
-static const struct hwmon_channel_info *ina3221_info[] = {
+static const struct hwmon_channel_info * const ina3221_info[] = {
HWMON_CHANNEL_INFO(chip,
HWMON_C_SAMPLES,
HWMON_C_UPDATE_INTERVAL),
--
2.34.1
[PATCH 21/68] hwmon: intel-m10-bmc: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/intel-m10-bmc-hwmon.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/hwmon/intel-m10-bmc-hwmon.c
b/drivers/hwmon/intel-m10-bmc-hwmon.c
index 2f0323c14bab..6512f4bec79a 100644
--- a/drivers/hwmon/intel-m10-bmc-hwmon.c
+++ b/drivers/hwmon/intel-m10-bmc-hwmon.c
@@ -24,7 +24,7 @@ struct m10bmc_sdata {
struct m10bmc_hwmon_board_data {
const struct m10bmc_sdata *tables[hwmon_max];
- const struct hwmon_channel_info **hinfo;
+ const struct hwmon_channel_info * const *hinfo;
};
struct m10bmc_hwmon {
@@ -67,7 +67,7 @@ static const struct m10bmc_sdata n3000bmc_power_tbl[] = {
{ 0x160, 0x0, 0x0, 0x0, 0x0, 1000, "Board Power" },
};
-static const struct hwmon_channel_info *n3000bmc_hinfo[] = {
+static const struct hwmon_channel_info * const n3000bmc_hinfo[] = {
HWMON_CHANNEL_INFO(temp,
HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_LABEL,
@@ -154,7 +154,7 @@ static const struct m10bmc_hwmon_board_data
n3000bmc_hwmon_bdata = {
.hinfo = n3000bmc_hinfo,
};
-static const struct hwmon_channel_info *d5005bmc_hinfo[] = {
+static const struct hwmon_channel_info * const d5005bmc_hinfo[] = {
HWMON_CHANNEL_INFO(temp,
HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_LABEL,
@@ -280,7 +280,7 @@ static const struct m10bmc_sdata n5010bmc_curr_tbl[] = {
{ 0x1a0, 0x0, 0x0, 0x0, 0x0, 1, "CVL2 0.8V Current" },
};
-static const struct hwmon_channel_info *n5010bmc_hinfo[] = {
+static const struct hwmon_channel_info * const n5010bmc_hinfo[] = {
HWMON_CHANNEL_INFO(temp,
HWMON_T_INPUT | HWMON_T_CRIT | HWMON_T_LABEL,
HWMON_T_INPUT | HWMON_T_CRIT | HWMON_T_LABEL,
@@ -432,7 +432,7 @@ static const struct m10bmc_sdata n6000bmc_power_tbl[] = {
{ 0x724, 0x0, 0x0, 0x0, 0x0, 1, "Board Power" },
};
-static const struct hwmon_channel_info *n6000bmc_hinfo[] = {
+static const struct hwmon_channel_info * const n6000bmc_hinfo[] = {
HWMON_CHANNEL_INFO(temp,
HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_CRIT |
HWMON_T_LABEL,
--
2.34.1
[PATCH 18/68] hwmon: i5500_temp: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/i5500_temp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/i5500_temp.c b/drivers/hwmon/i5500_temp.c
index 23b9f94fe0a9..7b00b38c7f7b 100644
--- a/drivers/hwmon/i5500_temp.c
+++ b/drivers/hwmon/i5500_temp.c
@@ -88,7 +88,7 @@ static const struct hwmon_ops i5500_ops = {
.read = i5500_read,
};
-static const struct hwmon_channel_info *i5500_info[] = {
+static const struct hwmon_channel_info * const i5500_info[] = {
HWMON_CHANNEL_INFO(chip, HWMON_C_REGISTER_TZ),
HWMON_CHANNEL_INFO(temp,
HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
HWMON_T_CRIT |
--
2.34.1
[PATCH 17/68] hwmon: gxp-fan: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/gxp-fan-ctrl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/gxp-fan-ctrl.c b/drivers/hwmon/gxp-fan-ctrl.c
index 0014b8b0fd41..2e05bc2f627a 100644
--- a/drivers/hwmon/gxp-fan-ctrl.c
+++ b/drivers/hwmon/gxp-fan-ctrl.c
@@ -168,7 +168,7 @@ static const struct hwmon_ops gxp_fan_ctrl_ops = {
.write = gxp_fan_ctrl_write,
};
-static const struct hwmon_channel_info *gxp_fan_ctrl_info[] = {
+static const struct hwmon_channel_info * const gxp_fan_ctrl_info[] = {
HWMON_CHANNEL_INFO(fan,
HWMON_F_FAULT | HWMON_F_ENABLE,
HWMON_F_FAULT | HWMON_F_ENABLE,
--
2.34.1
[PATCH 15/68] hwmon: emc2305: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/emc2305.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/emc2305.c b/drivers/hwmon/emc2305.c
index f65467fbd86c..723f57518c9a 100644
--- a/drivers/hwmon/emc2305.c
+++ b/drivers/hwmon/emc2305.c
@@ -479,7 +479,7 @@ static const struct hwmon_ops emc2305_ops = {
.write = emc2305_write,
};
-static const struct hwmon_channel_info *emc2305_info[] = {
+static const struct hwmon_channel_info * const emc2305_info[] = {
HWMON_CHANNEL_INFO(fan,
HWMON_F_INPUT | HWMON_F_FAULT,
HWMON_F_INPUT | HWMON_F_FAULT,
--
2.34.1
[PATCH 16/68] hwmon: ftsteutates: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/ftsteutates.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/ftsteutates.c b/drivers/hwmon/ftsteutates.c
index 25afd9167a34..f5a4d91a7e90 100644
--- a/drivers/hwmon/ftsteutates.c
+++ b/drivers/hwmon/ftsteutates.c
@@ -520,7 +520,7 @@ static const struct hwmon_ops fts_ops = {
.write = fts_write,
};
-static const struct hwmon_channel_info *fts_info[] = {
+static const struct hwmon_channel_info * const fts_info[] = {
HWMON_CHANNEL_INFO(chip, HWMON_C_REGISTER_TZ),
HWMON_CHANNEL_INFO(temp,
HWMON_T_INPUT | HWMON_T_ALARM | HWMON_T_FAULT,
--
2.34.1
[PATCH 09/68] hwmon: as370: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/as370-hwmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/as370-hwmon.c b/drivers/hwmon/as370-hwmon.c
index 63b5b2d6e593..fffbf385a57f 100644
--- a/drivers/hwmon/as370-hwmon.c
+++ b/drivers/hwmon/as370-hwmon.c
@@ -76,7 +76,7 @@ as370_hwmon_is_visible(const void *data, enum
hwmon_sensor_types type,
}
}
-static const struct hwmon_channel_info *as370_hwmon_info[] = {
+static const struct hwmon_channel_info * const as370_hwmon_info[] = {
HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT),
NULL
};
--
2.34.1
[PATCH 14/68] hwmon: drivetemp: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/drivetemp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/drivetemp.c b/drivers/hwmon/drivetemp.c
index 8e5759b42390..e73b7bfc6af3 100644
--- a/drivers/hwmon/drivetemp.c
+++ b/drivers/hwmon/drivetemp.c
@@ -526,7 +526,7 @@ static umode_t drivetemp_is_visible(const void *data,
return 0;
}
-static const struct hwmon_channel_info *drivetemp_info[] = {
+static const struct hwmon_channel_info * const drivetemp_info[] = {
HWMON_CHANNEL_INFO(chip,
HWMON_C_REGISTER_TZ),
HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT |
--
2.34.1
[PATCH 10/68] hwmon: axi-fan: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/axi-fan-control.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/axi-fan-control.c b/drivers/hwmon/axi-fan-control.c
index 6724e0dd3088..5fd136baf1cd 100644
--- a/drivers/hwmon/axi-fan-control.c
+++ b/drivers/hwmon/axi-fan-control.c
@@ -394,7 +394,7 @@ static int axi_fan_control_init(struct axi_fan_control_data
*ctl,
return ret;
}
-static const struct hwmon_channel_info *axi_fan_control_info[] = {
+static const struct hwmon_channel_info * const axi_fan_control_info[] = {
HWMON_CHANNEL_INFO(pwm, HWMON_PWM_INPUT),
HWMON_CHANNEL_INFO(fan, HWMON_F_INPUT | HWMON_F_FAULT | HWMON_F_LABEL),
HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT | HWMON_T_LABEL),
--
2.34.1
[PATCH 13/68] hwmon: dell-smm: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/dell-smm-hwmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/dell-smm-hwmon.c b/drivers/hwmon/dell-smm-hwmon.c
index 7ac778aedc68..44aaf9b9191d 100644
--- a/drivers/hwmon/dell-smm-hwmon.c
+++ b/drivers/hwmon/dell-smm-hwmon.c
@@ -920,7 +920,7 @@ static const struct hwmon_ops dell_smm_ops = {
.write = dell_smm_write,
};
-static const struct hwmon_channel_info *dell_smm_info[] = {
+static const struct hwmon_channel_info * const dell_smm_info[] = {
HWMON_CHANNEL_INFO(chip, HWMON_C_REGISTER_TZ),
HWMON_CHANNEL_INFO(temp,
HWMON_T_INPUT | HWMON_T_LABEL,
--
2.34.1
[PATCH 08/68] hwmon: aquacomputer: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/aquacomputer_d5next.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/aquacomputer_d5next.c
b/drivers/hwmon/aquacomputer_d5next.c
index 17fad3142118..3bd35d833e69 100644
--- a/drivers/hwmon/aquacomputer_d5next.c
+++ b/drivers/hwmon/aquacomputer_d5next.c
@@ -1038,7 +1038,7 @@ static const struct hwmon_ops aqc_hwmon_ops = {
.write = aqc_write
};
-static const struct hwmon_channel_info *aqc_info[] = {
+static const struct hwmon_channel_info * const aqc_info[] = {
HWMON_CHANNEL_INFO(temp,
HWMON_T_INPUT | HWMON_T_LABEL | HWMON_T_OFFSET,
HWMON_T_INPUT | HWMON_T_LABEL | HWMON_T_OFFSET,
--
2.34.1
[PATCH 12/68] hwmon: corsair: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/corsair-cpro.c | 2 +-
drivers/hwmon/corsair-psu.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hwmon/corsair-cpro.c b/drivers/hwmon/corsair-cpro.c
index fa6aa4fc8b52..463ab4296ede 100644
--- a/drivers/hwmon/corsair-cpro.c
+++ b/drivers/hwmon/corsair-cpro.c
@@ -385,7 +385,7 @@ static const struct hwmon_ops ccp_hwmon_ops = {
.write = ccp_write,
};
-static const struct hwmon_channel_info *ccp_info[] = {
+static const struct hwmon_channel_info * const ccp_info[] = {
HWMON_CHANNEL_INFO(chip,
HWMON_C_REGISTER_TZ),
HWMON_CHANNEL_INFO(temp,
diff --git a/drivers/hwmon/corsair-psu.c b/drivers/hwmon/corsair-psu.c
index 2210aa62e3d0..dc24c566d08b 100644
--- a/drivers/hwmon/corsair-psu.c
+++ b/drivers/hwmon/corsair-psu.c
@@ -571,7 +571,7 @@ static const struct hwmon_ops corsairpsu_hwmon_ops = {
.read_string= corsairpsu_hwmon_ops_read_string,
};
-static const struct hwmon_channel_info *corsairpsu_info[] = {
+static const struct hwmon_channel_info * const corsairpsu_info[] = {
HWMON_CHANNEL_INFO(chip,
HWMON_C_REGISTER_TZ),
HWMON_CHANNEL_INFO(temp,
--
2.34.1
[PATCH 11/68] hwmon: bt1-pvt: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/bt1-pvt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hwmon/bt1-pvt.c b/drivers/hwmon/bt1-pvt.c
index 21ab172774ec..8d402a627306 100644
--- a/drivers/hwmon/bt1-pvt.c
+++ b/drivers/hwmon/bt1-pvt.c
@@ -379,7 +379,7 @@ static int pvt_read_alarm(struct pvt_hwmon *pvt, enum
pvt_sensor_type type,
return 0;
}
-static const struct hwmon_channel_info *pvt_channel_info[] = {
+static const struct hwmon_channel_info * const pvt_channel_info[] = {
HWMON_CHANNEL_INFO(chip,
HWMON_C_REGISTER_TZ | HWMON_C_UPDATE_INTERVAL),
HWMON_CHANNEL_INFO(temp,
@@ -523,7 +523,7 @@ static int pvt_read_alarm(struct pvt_hwmon *pvt, enum
pvt_sensor_type type,
return -EOPNOTSUPP;
}
-static const struct hwmon_channel_info *pvt_channel_info[] = {
+static const struct hwmon_channel_info * const pvt_channel_info[] = {
HWMON_CHANNEL_INFO(chip,
HWMON_C_REGISTER_TZ | HWMON_C_UPDATE_INTERVAL),
HWMON_CHANNEL_INFO(temp,
--
2.34.1
[PATCH 07/68] hwmon: aht10: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/aht10.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/aht10.c b/drivers/hwmon/aht10.c
index 9babd69d54a3..b8fe3f7248ba 100644
--- a/drivers/hwmon/aht10.c
+++ b/drivers/hwmon/aht10.c
@@ -270,7 +270,7 @@ static int aht10_hwmon_write(struct device *dev, enum
hwmon_sensor_types type,
}
}
-static const struct hwmon_channel_info *aht10_info[] = {
+static const struct hwmon_channel_info * const aht10_info[] = {
HWMON_CHANNEL_INFO(chip, HWMON_C_UPDATE_INTERVAL),
HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT),
HWMON_CHANNEL_INFO(humidity, HWMON_H_INPUT),
--
2.34.1
[PATCH 06/68] hwmon: adt7x10: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/adt7x10.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/adt7x10.c b/drivers/hwmon/adt7x10.c
index da67734edafd..6701920de17f 100644
--- a/drivers/hwmon/adt7x10.c
+++ b/drivers/hwmon/adt7x10.c
@@ -309,7 +309,7 @@ static int adt7x10_write(struct device *dev, enum
hwmon_sensor_types type,
}
}
-static const struct hwmon_channel_info *adt7x10_info[] = {
+static const struct hwmon_channel_info * const adt7x10_info[] = {
HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MIN |
HWMON_T_CRIT | HWMON_T_MAX_HYST | HWMON_T_MIN_HYST |
HWMON_T_CRIT_HYST | HWMON_T_MIN_ALARM |
--
2.34.1
[PATCH 05/68] hwmon: adt7470: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/adt7470.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/adt7470.c b/drivers/hwmon/adt7470.c
index 927f8df05b7c..64f801b859ff 100644
--- a/drivers/hwmon/adt7470.c
+++ b/drivers/hwmon/adt7470.c
@@ -1187,7 +1187,7 @@ static const struct hwmon_ops adt7470_hwmon_ops = {
.write = adt7470_write,
};
-static const struct hwmon_channel_info *adt7470_info[] = {
+static const struct hwmon_channel_info * const adt7470_info[] = {
HWMON_CHANNEL_INFO(temp,
HWMON_T_INPUT | HWMON_T_MIN | HWMON_T_MAX |
HWMON_T_ALARM,
HWMON_T_INPUT | HWMON_T_MIN | HWMON_T_MAX |
HWMON_T_ALARM,
--
2.34.1
[PATCH 03/68] hwmon: adm9240: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/adm9240.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/adm9240.c b/drivers/hwmon/adm9240.c
index 40e3558d3709..9eb973a38e4b 100644
--- a/drivers/hwmon/adm9240.c
+++ b/drivers/hwmon/adm9240.c
@@ -731,7 +731,7 @@ static const struct hwmon_ops adm9240_hwmon_ops = {
.write = adm9240_write,
};
-static const struct hwmon_channel_info *adm9240_info[] = {
+static const struct hwmon_channel_info * const adm9240_info[] = {
HWMON_CHANNEL_INFO(chip, HWMON_C_ALARMS),
HWMON_CHANNEL_INFO(intrusion, HWMON_INTRUSION_ALARM),
HWMON_CHANNEL_INFO(temp,
--
2.34.1
[PATCH 04/68] hwmon: adt7411: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/adt7411.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/adt7411.c b/drivers/hwmon/adt7411.c
index bf5c5618f8d0..6ba84921614f 100644
--- a/drivers/hwmon/adt7411.c
+++ b/drivers/hwmon/adt7411.c
@@ -636,7 +636,7 @@ static int adt7411_init_device(struct adt7411_data *data)
return i2c_smbus_write_byte_data(data->client, ADT7411_REG_CFG1, val);
}
-static const struct hwmon_channel_info *adt7411_info[] = {
+static const struct hwmon_channel_info * const adt7411_info[] = {
HWMON_CHANNEL_INFO(in,
HWMON_I_INPUT | HWMON_I_MIN | HWMON_I_MAX |
HWMON_I_ALARM,
HWMON_I_INPUT | HWMON_I_MIN | HWMON_I_MAX |
HWMON_I_ALARM,
--
2.34.1
[PATCH 02/68] hwmon: adm1177: constify pointers to hwmon_channel_info
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/hwmon/adm1177.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/adm1177.c b/drivers/hwmon/adm1177.c
index be17a26a84f1..bfe070a1b501 100644
--- a/drivers/hwmon/adm1177.c
+++ b/drivers/hwmon/adm1177.c
@@ -168,7 +168,7 @@ static umode_t adm1177_is_visible(const void *data,
return 0;
}
-static const struct hwmon_channel_info *adm1177_info[] = {
+static const struct hwmon_channel_info * const adm1177_info[] = {
HWMON_CHANNEL_INFO(curr,
HWMON_C_INPUT | HWMON_C_MAX_ALARM),
HWMON_CHANNEL_INFO(in,
--
2.34.1
[PATCH 01/68] hwmon: constify pointers to hwmon_channel_info
HWmon core receives an array of pointers to hwmon_channel_info and it
does not modify it, thus it can be array of const pointers for safety.
This allows drivers to make them also const.
Signed-off-by: Krzysztof Kozlowski
---
Documentation/hwmon/hwmon-kernel-api.rst | 6 +++---
drivers/accel/habanalabs/common/hwmon.c | 2 +-
drivers/hwmon/hwmon.c| 4 ++--
include/linux/hwmon.h| 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/hwmon/hwmon-kernel-api.rst
b/Documentation/hwmon/hwmon-kernel-api.rst
index dbd68d7b033a..c2d1e0299d8d 100644
--- a/Documentation/hwmon/hwmon-kernel-api.rst
+++ b/Documentation/hwmon/hwmon-kernel-api.rst
@@ -107,7 +107,7 @@ The hwmon_chip_info structure looks as follows::
struct hwmon_chip_info {
const struct hwmon_ops *ops;
- const struct hwmon_channel_info **info;
+ const struct hwmon_channel_info * const *info;
};
It contains the following fields:
@@ -203,7 +203,7 @@ register (HWMON_T_MAX) as well as a maximum temperature
hysteresis register
.config = lm75_temp_config,
};
- static const struct hwmon_channel_info *lm75_info[] = {
+ static const struct hwmon_channel_info * const lm75_info[] = {
_chip,
_temp,
NULL
@@ -212,7 +212,7 @@ register (HWMON_T_MAX) as well as a maximum temperature
hysteresis register
The HWMON_CHANNEL_INFO() macro can and should be used when possible.
With this macro, the above example can be simplified to
- static const struct hwmon_channel_info *lm75_info[] = {
+ static const struct hwmon_channel_info * const lm75_info[] = {
HWMON_CHANNEL_INFO(chip,
HWMON_C_REGISTER_TZ | HWMON_C_UPDATE_INTERVAL),
HWMON_CHANNEL_INFO(temp,
diff --git a/drivers/accel/habanalabs/common/hwmon.c
b/drivers/accel/habanalabs/common/hwmon.c
index 55eb0203817f..8598056216e7 100644
--- a/drivers/accel/habanalabs/common/hwmon.c
+++ b/drivers/accel/habanalabs/common/hwmon.c
@@ -914,7 +914,7 @@ void hl_hwmon_fini(struct hl_device *hdev)
void hl_hwmon_release_resources(struct hl_device *hdev)
{
- const struct hwmon_channel_info **channel_info_arr;
+ const struct hwmon_channel_info * const *channel_info_arr;
int i = 0;
if (!hdev->hl_chip_info->info)
diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c
index dc2e3646f943..573b83b6c08c 100644
--- a/drivers/hwmon/hwmon.c
+++ b/drivers/hwmon/hwmon.c
@@ -173,7 +173,7 @@ static int hwmon_thermal_set_trips(struct
thermal_zone_device *tz, int low, int
struct hwmon_thermal_data *tdata = thermal_zone_device_priv(tz);
struct hwmon_device *hwdev = to_hwmon_device(tdata->dev);
const struct hwmon_chip_info *chip = hwdev->chip;
- const struct hwmon_channel_info **info = chip->info;
+ const struct hwmon_channel_info * const *info = chip->info;
unsigned int i;
int err;
@@ -252,7 +252,7 @@ static int hwmon_thermal_register_sensors(struct device
*dev)
{
struct hwmon_device *hwdev = to_hwmon_device(dev);
const struct hwmon_chip_info *chip = hwdev->chip;
- const struct hwmon_channel_info **info = chip->info;
+ const struct hwmon_channel_info * const *info = chip->info;
void *drvdata = dev_get_drvdata(dev);
int i;
diff --git a/include/linux/hwmon.h b/include/linux/hwmon.h
index c1b62384b6ee..492dd27a5dd8 100644
--- a/include/linux/hwmon.h
+++ b/include/linux/hwmon.h
@@ -430,7 +430,7 @@ struct hwmon_channel_info {
*/
struct hwmon_chip_info {
const struct hwmon_ops *ops;
- const struct hwmon_channel_info **info;
+ const struct hwmon_channel_info * const *info;
};
/* hwmon_device_register() is deprecated */
--
2.34.1
[PATCH 00/68] hwmon: constify pointers to hwmon_channel_info
Hi, The first patch constifies the hwmon_channel_info pointers in the core, so all the drivers can be updated - all patches here depend on the first one. If the approach is fine, I will later update other subsystems. Best regards, Krzysztof Krzysztof Kozlowski (68): hwmon: constify pointers to hwmon_channel_info hwmon: adm1177: constify pointers to hwmon_channel_info hwmon: adm9240: constify pointers to hwmon_channel_info hwmon: adt7411: constify pointers to hwmon_channel_info hwmon: adt7470: constify pointers to hwmon_channel_info hwmon: adt7x10: constify pointers to hwmon_channel_info hwmon: aht10: constify pointers to hwmon_channel_info hwmon: aquacomputer: constify pointers to hwmon_channel_info hwmon: as370: constify pointers to hwmon_channel_info hwmon: axi-fan: constify pointers to hwmon_channel_info hwmon: bt1-pvt: constify pointers to hwmon_channel_info hwmon: corsair: constify pointers to hwmon_channel_info hwmon: dell-smm: constify pointers to hwmon_channel_info hwmon: drivetemp: constify pointers to hwmon_channel_info hwmon: emc2305: constify pointers to hwmon_channel_info hwmon: ftsteutates: constify pointers to hwmon_channel_info hwmon: gxp-fan: constify pointers to hwmon_channel_info hwmon: i5500_temp: constify pointers to hwmon_channel_info hwmon: ina238: constify pointers to hwmon_channel_info hwmon: ina3221: constify pointers to hwmon_channel_info hwmon: intel-m10-bmc: constify pointers to hwmon_channel_info hwmon: jc42: constify pointers to hwmon_channel_info hwmon: k10temp: constify pointers to hwmon_channel_info hwmon: k8temp: constify pointers to hwmon_channel_info hwmon: lan966x: constify pointers to hwmon_channel_info hwmon: lm75: constify pointers to hwmon_channel_info hwmon: lm83: constify pointers to hwmon_channel_info hwmon: lm95241: constify pointers to hwmon_channel_info hwmon: lm95245: constify pointers to hwmon_channel_info hwmon: lochnagar: constify pointers to hwmon_channel_info hwmon: ltc2947: constify pointers to hwmon_channel_info hwmon: ltc2992: constify pointers to hwmon_channel_info hwmon: ltc4245: constify pointers to hwmon_channel_info hwmon: ltq-cputemp: constify pointers to hwmon_channel_info hwmon: max127: constify pointers to hwmon_channel_info hwmon: max31730: constify pointers to hwmon_channel_info hwmon: max31760: constify pointers to hwmon_channel_info hwmon: max31790: constify pointers to hwmon_channel_info hwmon: max6620: constify pointers to hwmon_channel_info hwmon: max6621: constify pointers to hwmon_channel_info hwmon: max6650: constify pointers to hwmon_channel_info hwmon: mc34vr500: constify pointers to hwmon_channel_info hwmon: mcp3021: constify pointers to hwmon_channel_info hwmon: mlxreg: constify pointers to hwmon_channel_info hwmon: nct7904: constify pointers to hwmon_channel_info hwmon: npcm750-pwm: constify pointers to hwmon_channel_info hwmon: ntc_thermistor: constify pointers to hwmon_channel_info hwmon: nzxt: constify pointers to hwmon_channel_info hwmon: oxp-sensors: constify pointers to hwmon_channel_info hwmon: peci: constify pointers to hwmon_channel_info hwmon: powr1220: constify pointers to hwmon_channel_info hwmon: raspberrypi: constify pointers to hwmon_channel_info hwmon: sbrmi: constify pointers to hwmon_channel_info hwmon: sbtsi_temp: constify pointers to hwmon_channel_info hwmon: sch5627: constify pointers to hwmon_channel_info hwmon: sht4x: constify pointers to hwmon_channel_info hwmon: sl28cpld: constify pointers to hwmon_channel_info hwmon: smpro: constify pointers to hwmon_channel_info hwmon: sparx5-temp: constify pointers to hwmon_channel_info hwmon: sy7636a: constify pointers to hwmon_channel_info hwmon: tmp102: constify pointers to hwmon_channel_info hwmon: tmp103: constify pointers to hwmon_channel_info hwmon: tmp108: constify pointers to hwmon_channel_info hwmon: tmp464: constify pointers to hwmon_channel_info hwmon: tmp513: constify pointers to hwmon_channel_info hwmon: tps23861: constify pointers to hwmon_channel_info hwmon: w83627ehf: constify pointers to hwmon_channel_info hwmon: w83773g: constify pointers to hwmon_channel_info Documentation/hwmon/hwmon-kernel-api.rst | 6 +++--- drivers/accel/habanalabs/common/hwmon.c | 2 +- drivers/hwmon/adm1177.c | 2 +- drivers/hwmon/adm9240.c | 2 +- drivers/hwmon/adt7411.c | 2 +- drivers/hwmon/adt7470.c | 2 +- drivers/hwmon/adt7x10.c | 2 +- drivers/hwmon/aht10.c| 2 +- drivers/hwmon/aquacomputer_d5next.c | 2 +- drivers/hwmon/as370-hwmon.c | 2 +- drivers/hwmon/axi-fan-control.c | 2 +- drivers/hwmon/bt1-pvt.c | 4 ++-- drivers/hwmon/corsair-cpro.c | 2 +- drivers/hwmon/corsair-psu.c | 2 +- drivers/hwmon/dell-smm-hwmon.c | 2 +-
[PATCH] drm/amd/display: set variables aperture_default_system and context0_default_system storage-class-specifier to static
smatch reports drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hubp.c:758:10: warning: symbol 'aperture_default_system' was not declared. Should it be static? drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hubp.c:759:10: warning: symbol 'context0_default_system' was not declared. Should it be static? These variables are only used in one file so should be static. Signed-off-by: Tom Rix --- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubp.c b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubp.c index a142a00bc432..bf399819ca80 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubp.c +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubp.c @@ -755,8 +755,8 @@ bool hubp1_is_flip_pending(struct hubp *hubp) return false; } -uint32_t aperture_default_system = 1; -uint32_t context0_default_system; /* = 0;*/ +static uint32_t aperture_default_system = 1; +static uint32_t context0_default_system; /* = 0;*/ static void hubp1_set_vm_system_aperture_settings(struct hubp *hubp, struct vm_system_aperture_param *apt) -- 2.27.0
Re: [PATCH 12/18] arch/parisc: Implement fb_is_primary_device() under arch/parisc
Am Mittwoch, 5. April 2023, 17:05:48 CEST schrieb Thomas Zimmermann:
> Move PARISC's implementation of fb_is_primary_device() into the
> architecture directory. This the place of the declaration and
> where other architectures implement this function. No functional
> changes.
> diff --git a/arch/parisc/video/fbdev.c b/arch/parisc/video/fbdev.c
> new file mode 100644
> index ..4a0ae08fc75b
> --- /dev/null
> +++ b/arch/parisc/video/fbdev.c
> @@ -0,0 +1,27 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2000 Philipp Rumpf
> + * Copyright (C) 2001-2020 Helge Deller
> + * Copyright (C) 2001-2002 Thomas Bogendoerfer
> + */
> +
> +#include
> +
> +#include
> +
> +#include
> +
> +int fb_is_primary_device(struct fb_info *info)
> +{
Looking at this makes me wonder why the argument to all of these functions
isn't const? Not your fault, but could be a candidate for patch #19?
Eike
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH 00/18] arch: Consolidate
Am Mittwoch, 5. April 2023, 17:05:36 CEST schrieb Thomas Zimmermann: > Various architectures provide with helpers for fbdev ^ *lol* Eike signature.asc Description: This is a digitally signed message part.
[PATCH v2 2/2] drm: bridge: samsung-dsim: Implement support for clock/data polarity swap
From: Marek Vasut
Implement support for DSI clock and data lane DN/DP polarity swap by
means of decoding 'lane-polarities' DT property. The controller does
support DN/DP swap of clock lane and all data lanes, the controller
does not support polarity swap of individual data lane bundles, add
a check which verifies all data lanes have the same polarity.
This has been validated on an imx8mm board that actually has the MIPI DSI
clock lanes inverted.
Signed-off-by: Marek Vasut
Signed-off-by: Fabio Estevam
Reviewed-by: Jagan Teki
---
Changes since v1:
- Use 'drm: bridge: samsung-dsim:' as prefix (Jagan).
- Collected Jagan's Reviewed-by tag.
drivers/gpu/drm/bridge/samsung-dsim.c | 27 ++-
include/drm/bridge/samsung-dsim.h | 2 ++
2 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index e0a402a85787..5791148e2da2 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -183,6 +183,8 @@
#define DSIM_AFC_CTL(x)(((x) & 0x7) << 5)
/* DSIM_PLLCTRL */
+#define DSIM_PLL_DPDNSWAP_CLK (1 << 25)
+#define DSIM_PLL_DPDNSWAP_DAT (1 << 24)
#define DSIM_FREQ_BAND(x) ((x) << 24)
#define DSIM_PLL_ENBIT(23)
#define DSIM_PLL_P(x, offset) ((x) << (offset))
@@ -622,6 +624,11 @@ static unsigned long samsung_dsim_set_pll(struct
samsung_dsim *dsi,
reg |= DSIM_FREQ_BAND(band);
}
+ if (dsi->swap_dn_dp_clk)
+ reg |= DSIM_PLL_DPDNSWAP_CLK;
+ if (dsi->swap_dn_dp_data)
+ reg |= DSIM_PLL_DPDNSWAP_DAT;
+
samsung_dsim_write(dsi, DSIM_PLLCTRL_REG, reg);
timeout = 1000;
@@ -1696,7 +1703,9 @@ static int samsung_dsim_parse_dt(struct samsung_dsim *dsi)
{
struct device *dev = dsi->dev;
struct device_node *node = dev->of_node;
- int ret;
+ u32 lane_polarities[5] = { 0 };
+ struct device_node *endpoint;
+ int i, nr_lanes, ret;
ret = samsung_dsim_of_read_u32(node, "samsung,pll-clock-frequency",
>pll_clk_rate);
@@ -1713,6 +1722,22 @@ static int samsung_dsim_parse_dt(struct samsung_dsim
*dsi)
if (ret < 0)
return ret;
+ endpoint = of_graph_get_endpoint_by_regs(node, 1, -1);
+ nr_lanes = of_property_count_u32_elems(endpoint, "data-lanes");
+ if (nr_lanes > 0 && nr_lanes <= 4) {
+ /* Polarity 0 is clock lane, 1..4 are data lanes. */
+ of_property_read_u32_array(endpoint, "lane-polarities",
+ lane_polarities, nr_lanes + 1);
+ for (i = 1; i <= nr_lanes; i++) {
+ if (lane_polarities[1] != lane_polarities[i])
+ DRM_DEV_ERROR(dsi->dev, "Data lanes polarities
do not match");
+ }
+ if (lane_polarities[0])
+ dsi->swap_dn_dp_clk = true;
+ if (lane_polarities[1])
+ dsi->swap_dn_dp_data = true;
+ }
+
return 0;
}
diff --git a/include/drm/bridge/samsung-dsim.h
b/include/drm/bridge/samsung-dsim.h
index ba5484de2b30..6a37d1e079bf 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -95,6 +95,8 @@ struct samsung_dsim {
u32 mode_flags;
u32 format;
+ bool swap_dn_dp_clk;
+ bool swap_dn_dp_data;
int state;
struct drm_property *brightness;
struct completion completed;
--
2.34.1
[PATCH v2 1/2] dt-bindings: samsung,mipi-dsim: Add 'lane-polarities'
From: Fabio Estevam The Samsung DSIM IP block allows the inversion of the clock and data lanes. Add an optional property called 'lane-polarities' that describes the polarities of the MIPI DSI clock and data lanes. This property is useful for properly describing the hardware when the board designer decided to switch the polarities of the MIPI DSI clock and/or data lanes. Signed-off-by: Fabio Estevam --- Changes since v1: - Rebased against drm-misc-next that has samsung,mipi-dsim.yaml. .../display/bridge/samsung,mipi-dsim.yaml | 29 +++ 1 file changed, 29 insertions(+) diff --git a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml index e841659e20cd..04eb440ade72 100644 --- a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml +++ b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml @@ -105,6 +105,35 @@ properties: DSI output port node to the panel or the next bridge in the chain. +properties: + endpoint: +$ref: /schemas/graph.yaml#/$defs/endpoint-base +unevaluatedProperties: false + +properties: + data-lanes: +oneOf: + - minItems: 1 +maxItems: 4 +uniqueItems: true +items: + enum: [ 1, 2, 3, 4 ] +description: + See ../../media/video-interfaces.yaml for details. + + lane-polarities: +minItems: 1 +maxItems: 5 +items: + enum: [ 0, 1 ] +description: + See ../../media/video-interfaces.yaml for details. + The Samsung MIPI DSI IP requires that all the data lanes have + the same polarity. + +dependencies: + lane-polarities: [data-lanes] + required: - clock-names - clocks -- 2.34.1
Re: [PATCH] drm/vkms: add module parameter to set background color
On 4/6/23 15:23, Daniel Vetter wrote:
On Thu, Apr 06, 2023 at 03:06:56PM -0300, Maíra Canal wrote:
On 4/6/23 14:28, Daniel Vetter wrote:
On Thu, 6 Apr 2023 at 19:20, Maíra Canal wrote:
After commit 8ba1648567e2 ("drm: vkms: Refactor the plane composer to
accept new formats") the composition is no longer performed on top of
the primary plane, but instead on top of the CRTC, which means that
now we have a background.
This opens to the possibility of coloring the background with a
personalized color. Therefore, create a module parameter that takes a
unsigned long number as an XRGB16161616 color and set the background
color to it. That said, the composition will be performed on top of
this background color. By default, the background color is black.
Signed-off-by: Maíra Canal
---
This patch intends to add a background color property to vkms through
a module parameter. Another option would be to implement this property
by adding a new KMS property that would indicate the background color.
It would be nice to hear other opinions on what would be the best
approach.
These patches (and I think even igts for them) have been floating
around for years. The hang-up is the userspace. Turns out all
compositors want for background is black, thus far no one has figured
out a real use-case for anything else.
Maybe some time ...
But, would it be okay to add this feature as a vkms' module parameter?
Yeah I think that's ok.
Moreover, I wrote some IGT tests to ensure that the functionality is
working correctly [1]. The tests take the CRC of a colored primary
plane, offset the primary plane out of the screen, and take the CRC
of the colored background. The two CRC must be equal.
[1]
https://gitlab.freedesktop.org/mairacanal/igt-gpu-tools/-/tree/vkms/background-color
I wonder whether it would be more useful to have this as a Kunit
validation test to very that the vkms composing code works correctly?
Still with the modparam and vkms_config to handle it all cleanly.
Not sure if this would fit as a unit test, as the vkms composing
code basically outputs a CRC, which can be better verified by
the userspace. The output_buffer and stage_buffer are internal
variables, so it would be difficult to evaluate them with a KUnit
test.
With the IGT test, we can assure that the background composition
is being performed properly using the CRC in a negative test and
also some positive tests.
I was just thinking of how you could keep the test, because igt is for
uapi in general. So doesn't fit all that well, validating internals is
more what kunit is supposed to do.
I'm not sure if testing the composition is an internal behavior, because
the output of the composition is a CRC that is exposed to the userspace.
Moreover, we need some sort of variable output to create a KUnit test,
which is not the case for vkms. The output_buffer and stage_buffer
are internal variables and they are overwritten on each iteration of
the blend loop.
As this property would be exclusive to vkms, I believe it would be okay
to add a vkms-specific IGT test to verify the correct behavior of the
background.
Best Regards,
- Maíra Canal
-Daniel
Best Regards,
- Maíra Canal
-Daniel
Best Regards,
- Maíra Canal
---
Documentation/gpu/vkms.rst | 2 --
drivers/gpu/drm/vkms/vkms_composer.c | 20 ++--
drivers/gpu/drm/vkms/vkms_drv.c | 6 ++
drivers/gpu/drm/vkms/vkms_drv.h | 4
4 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
index 49db221c0f52..dc01689d8c76 100644
--- a/Documentation/gpu/vkms.rst
+++ b/Documentation/gpu/vkms.rst
@@ -121,8 +121,6 @@ There's lots of plane features we could add support for:
- ARGB format on primary plane: blend the primary plane into background with
translucent alpha.
-- Add background color KMS property[Good to get started].
-
- Full alpha blending on all planes.
- Rotation, scaling.
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 8e53fa80742b..07345faee98a 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -79,7 +79,8 @@ static void fill_background(const struct pixel_argb_u16
*background_color,
* from all planes, calculates the crc32 of the output from the former step,
* and, if necessary, convert and store the output to the writeback buffer.
*/
-static void blend(struct vkms_writeback_job *wb,
+static void blend(struct vkms_device *vkms_dev,
+ struct vkms_writeback_job *wb,
struct vkms_crtc_state *crtc_state,
u32 *crc32, struct line_buffer *stage_buffer,
struct line_buffer *output_buffer, size_t row_size)
@@ -87,7 +88,12 @@ static void blend(struct vkms_writeback_job *wb,
struct vkms_plane_state **plane = crtc_state->active_planes;
u32 n_active_planes =
Re: [PULL] drm-fixes for -rc6
The pull request you sent on Thu, 6 Apr 2023 18:59:13 +0200: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-04-06 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/ac6c043391b266a360a53f933638003365bd10c9 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
[PATCH] drm/amd/display: set variable dcn3_14_soc storage-class-specifier to static
smatch reports
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/dcn314_fpu.c:100:37:
warning: symbol
'dcn3_14_soc' was not declared. Should it be static?
This variable is only used in one file so should be static.
Signed-off-by: Tom Rix
---
drivers/gpu/drm/amd/display/dc/dml/dcn314/dcn314_fpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn314/dcn314_fpu.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn314/dcn314_fpu.c
index c52b76610bd2..44082f65de1f 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn314/dcn314_fpu.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn314/dcn314_fpu.c
@@ -97,7 +97,7 @@ struct _vcs_dpi_ip_params_st dcn3_14_ip = {
.dcc_supported = true,
};
-struct _vcs_dpi_soc_bounding_box_st dcn3_14_soc = {
+static struct _vcs_dpi_soc_bounding_box_st dcn3_14_soc = {
/*TODO: correct dispclk/dppclk voltage level determination*/
.clock_limits = {
{
--
2.27.0
Re: [PATCH] drm/vkms: add module parameter to set background color
On Thu, Apr 06, 2023 at 03:06:56PM -0300, Maíra Canal wrote:
> On 4/6/23 14:28, Daniel Vetter wrote:
> > On Thu, 6 Apr 2023 at 19:20, Maíra Canal wrote:
> > >
> > > After commit 8ba1648567e2 ("drm: vkms: Refactor the plane composer to
> > > accept new formats") the composition is no longer performed on top of
> > > the primary plane, but instead on top of the CRTC, which means that
> > > now we have a background.
> > >
> > > This opens to the possibility of coloring the background with a
> > > personalized color. Therefore, create a module parameter that takes a
> > > unsigned long number as an XRGB16161616 color and set the background
> > > color to it. That said, the composition will be performed on top of
> > > this background color. By default, the background color is black.
> > >
> > > Signed-off-by: Maíra Canal
> > > ---
> > >
> > > This patch intends to add a background color property to vkms through
> > > a module parameter. Another option would be to implement this property
> > > by adding a new KMS property that would indicate the background color.
> > > It would be nice to hear other opinions on what would be the best
> > > approach.
> >
> > These patches (and I think even igts for them) have been floating
> > around for years. The hang-up is the userspace. Turns out all
> > compositors want for background is black, thus far no one has figured
> > out a real use-case for anything else.
> >
> > Maybe some time ...
> >
>
> But, would it be okay to add this feature as a vkms' module parameter?
Yeah I think that's ok.
> > > Moreover, I wrote some IGT tests to ensure that the functionality is
> > > working correctly [1]. The tests take the CRC of a colored primary
> > > plane, offset the primary plane out of the screen, and take the CRC
> > > of the colored background. The two CRC must be equal.
> > >
> > > [1]
> > > https://gitlab.freedesktop.org/mairacanal/igt-gpu-tools/-/tree/vkms/background-color
> >
> > I wonder whether it would be more useful to have this as a Kunit
> > validation test to very that the vkms composing code works correctly?
> > Still with the modparam and vkms_config to handle it all cleanly.
>
> Not sure if this would fit as a unit test, as the vkms composing
> code basically outputs a CRC, which can be better verified by
> the userspace. The output_buffer and stage_buffer are internal
> variables, so it would be difficult to evaluate them with a KUnit
> test.
>
> With the IGT test, we can assure that the background composition
> is being performed properly using the CRC in a negative test and
> also some positive tests.
I was just thinking of how you could keep the test, because igt is for
uapi in general. So doesn't fit all that well, validating internals is
more what kunit is supposed to do.
-Daniel
>
> Best Regards,
> - Maíra Canal
>
> > -Daniel
> >
> > >
> > > Best Regards,
> > > - Maíra Canal
> > >
> > > ---
> > > Documentation/gpu/vkms.rst | 2 --
> > > drivers/gpu/drm/vkms/vkms_composer.c | 20 ++--
> > > drivers/gpu/drm/vkms/vkms_drv.c | 6 ++
> > > drivers/gpu/drm/vkms/vkms_drv.h | 4
> > > 4 files changed, 24 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
> > > index 49db221c0f52..dc01689d8c76 100644
> > > --- a/Documentation/gpu/vkms.rst
> > > +++ b/Documentation/gpu/vkms.rst
> > > @@ -121,8 +121,6 @@ There's lots of plane features we could add support
> > > for:
> > > - ARGB format on primary plane: blend the primary plane into background
> > > with
> > > translucent alpha.
> > >
> > > -- Add background color KMS property[Good to get started].
> > > -
> > > - Full alpha blending on all planes.
> > >
> > > - Rotation, scaling.
> > > diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> > > b/drivers/gpu/drm/vkms/vkms_composer.c
> > > index 8e53fa80742b..07345faee98a 100644
> > > --- a/drivers/gpu/drm/vkms/vkms_composer.c
> > > +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> > > @@ -79,7 +79,8 @@ static void fill_background(const struct pixel_argb_u16
> > > *background_color,
> > >* from all planes, calculates the crc32 of the output from the former
> > > step,
> > >* and, if necessary, convert and store the output to the writeback
> > > buffer.
> > >*/
> > > -static void blend(struct vkms_writeback_job *wb,
> > > +static void blend(struct vkms_device *vkms_dev,
> > > + struct vkms_writeback_job *wb,
> > >struct vkms_crtc_state *crtc_state,
> > >u32 *crc32, struct line_buffer *stage_buffer,
> > >struct line_buffer *output_buffer, size_t row_size)
> > > @@ -87,7 +88,12 @@ static void blend(struct vkms_writeback_job *wb,
> > > struct vkms_plane_state **plane = crtc_state->active_planes;
> > > u32 n_active_planes = crtc_state->num_active_planes;
> > >
> > > - const struct pixel_argb_u16 background_color =
