Re: [PATCH] nvidiafb: detect the hardware support before removing console.
On Mon, 6 Feb 2023 at 17:52, Zeno Davatz wrote:
>
> Dear Dave
>
> Thank you for your patch.
>
> On Sun, Feb 5, 2023 at 10:07 PM Dave Airlie wrote:
> >
> > From: Dave Airlie
> >
> > This driver removed the console, but hasn't yet decided if it could
> > take over the console yet. Instead of doing that, probe the hw for
> > support and then remove the console afterwards.
> >
> > Signed-off-by: Dave Airlie
> > Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=216859
> > Reported-by: Zeno Davatz
> > ---
> > drivers/video/fbdev/nvidia/nvidia.c | 81 +++--
> > 1 file changed, 42 insertions(+), 39 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/nvidia/nvidia.c
> > b/drivers/video/fbdev/nvidia/nvidia.c
> > index 1960916098d4..e60a276b4855 100644
> > --- a/drivers/video/fbdev/nvidia/nvidia.c
> > +++ b/drivers/video/fbdev/nvidia/nvidia.c
> > @@ -1197,17 +1197,17 @@ static int nvidia_set_fbinfo(struct fb_info *info)
> > return nvidiafb_check_var(>var, info);
> > }
> >
> > -static u32 nvidia_get_chipset(struct fb_info *info)
> > +static u32 nvidia_get_chipset(struct pci_dev *pci_dev,
> > + volatile u32 __iomem *REGS)
> > {
> > - struct nvidia_par *par = info->par;
> > - u32 id = (par->pci_dev->vendor << 16) | par->pci_dev->device;
> > + u32 id = (pci_dev->vendor << 16) | pci_dev->device;
> >
> > printk(KERN_INFO PFX "Device ID: %x \n", id);
> >
> > if ((id & 0xfff0) == 0x00f0 ||
> > (id & 0xfff0) == 0x02e0) {
> > /* pci-e */
> > - id = NV_RD32(par->REGS, 0x1800);
> > + id = NV_RD32(REGS, 0x1800);
> >
> > if ((id & 0x) == 0x10DE)
> > id = 0x10DE | (id >> 16);
> > @@ -1220,12 +1220,11 @@ static u32 nvidia_get_chipset(struct fb_info *info)
> > return id;
> > }
> >
> > -static u32 nvidia_get_arch(struct fb_info *info)
> > +static u32 nvidia_get_arch(u32 Chipset)
> > {
> > - struct nvidia_par *par = info->par;
> > u32 arch = 0;
> >
> > - switch (par->Chipset & 0x0ff0) {
> > + switch (Chipset & 0x0ff0) {
> > case 0x0100:/* GeForce 256 */
> > case 0x0110:/* GeForce2 MX */
> > case 0x0150:/* GeForce2 */
> > @@ -1278,16 +1277,44 @@ static int nvidiafb_probe(struct pci_dev *pd, const
> > struct pci_device_id *ent)
> > struct fb_info *info;
> > unsigned short cmd;
> > int ret;
> > + volatile u32 __iomem *REGS;
> > + int Chipset;
> > + u32 Architecture;
> >
> > NVTRACE_ENTER();
> > assert(pd != NULL);
> >
> > + if (pci_enable_device(pd)) {
> > + printk(KERN_ERR PFX "cannot enable PCI device\n");
> > + return -ENODEV;
> > + }
> > +
> > + /* enable IO and mem if not already done */
> > + pci_read_config_word(pd, PCI_COMMAND, );
> > + cmd |= (PCI_COMMAND_IO | PCI_COMMAND_MEMORY);
> > + pci_write_config_word(pd, PCI_COMMAND, cmd);
> > +
> > + nvidiafb_fix.mmio_start = pci_resource_start(pd, 0);
> > + nvidiafb_fix.mmio_len = pci_resource_len(pd, 0);
> > +
> > + REGS = ioremap(nvidiafb_fix.mmio_start, nvidiafb_fix.mmio_len);
> > + if (!REGS) {
> > + printk(KERN_ERR PFX "cannot ioremap MMIO base\n");
> > + return -ENODEV;
> > + }
> > +
> > + Chipset = nvidia_get_chipset(pd, REGS);
> > + Architecture = nvidia_get_arch(Chipset);
> > + if (Architecture == 0) {
> > + printk(KERN_ERR PFX "unknown NV_ARCH\n");
> > + goto err_out;
> > + }
> > +
> > ret = aperture_remove_conflicting_pci_devices(pd, "nvidiafb");
> > if (ret)
> > - return ret;
> > + goto err_out;
> >
> > info = framebuffer_alloc(sizeof(struct nvidia_par), >dev);
> > -
> > if (!info)
> > goto err_out;
> >
> > @@ -1298,11 +1325,6 @@ static int nvidiafb_probe(struct pci_dev *pd, const
> > struct pci_device_id *ent)
> > if (info->pixmap.addr == NULL)
> > goto err_out_kfree;
> >
> > - if (pci_enable_device(pd)) {
> > - printk(KERN_ERR PFX "cannot enable PCI device\n");
> > - goto err_out_enable;
> > - }
> > -
> > if (pci_request_regions(pd, "nvidiafb")) {
> > printk(KERN_ERR PFX "cannot request PCI regions\n");
> > goto err_out_enable;
> > @@ -1318,34 +1340,17 @@ static int nvidiafb_probe(struct pci_dev *pd, const
> > struct pci_device_id *ent)
> > par->paneltweak = paneltweak;
> > par->reverse_i2c = reverse_i2c;
> >
> > - /* enable IO and mem if not already done */
> > - pci_read_config_word(pd, PCI_COMMAND, );
> > - cmd |= (PCI_COMMAND_IO | PCI_COMMAND_MEMORY);
> > - pci_write_config_word(pd, PCI_COMMAND, cmd);
> > -
> > -
Re: [PATCH] firmware: qcom_scm: Move qcom_scm.h to include/linux/firmware/qcom/
On 2/4/2023 2:39 AM, Elliot Berman wrote:
Move include/linux/qcom_scm.h to include/linux/firmware/qcom/qcom_scm.h.
This removes 1 of a few remaining Qualcomm-specific headers into a more
approciate subdirectory under include/.
s/approciate/appropriate
Suggested-by: Bjorn Andersson
Signed-off-by: Elliot Berman
Acked-by: Mukesh Ojha
-Mukesh
---
arch/arm/mach-qcom/platsmp.c | 2 +-
drivers/cpuidle/cpuidle-qcom-spm.c | 2 +-
drivers/firmware/qcom_scm-legacy.c | 2 +-
drivers/firmware/qcom_scm-smc.c | 2 +-
drivers/firmware/qcom_scm.c | 2 +-
drivers/gpu/drm/msm/adreno/a5xx_gpu.c| 2 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +-
drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c | 2 +-
drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c | 2 +-
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 2 +-
drivers/iommu/arm/arm-smmu/qcom_iommu.c | 2 +-
drivers/media/platform/qcom/venus/firmware.c | 2 +-
drivers/misc/fastrpc.c | 2 +-
drivers/mmc/host/sdhci-msm.c | 2 +-
drivers/net/ipa/ipa_main.c | 2 +-
drivers/net/wireless/ath/ath10k/qmi.c| 2 +-
drivers/pinctrl/qcom/pinctrl-msm.c | 2 +-
drivers/remoteproc/qcom_q6v5_mss.c | 2 +-
drivers/remoteproc/qcom_q6v5_pas.c | 2 +-
drivers/remoteproc/qcom_wcnss.c | 2 +-
drivers/soc/qcom/mdt_loader.c| 2 +-
drivers/soc/qcom/ocmem.c | 2 +-
drivers/soc/qcom/rmtfs_mem.c | 2 +-
drivers/thermal/qcom/lmh.c | 2 +-
drivers/ufs/host/ufs-qcom-ice.c | 2 +-
include/linux/{ => firmware/qcom}/qcom_scm.h | 0
26 files changed, 25 insertions(+), 25 deletions(-)
rename include/linux/{ => firmware/qcom}/qcom_scm.h (100%)
diff --git a/arch/arm/mach-qcom/platsmp.c b/arch/arm/mach-qcom/platsmp.c
index 5d2f386a46d8..eca2fe0f4314 100644
--- a/arch/arm/mach-qcom/platsmp.c
+++ b/arch/arm/mach-qcom/platsmp.c
@@ -14,7 +14,7 @@
#include
#include
#include
-#include
+#include
#include
diff --git a/drivers/cpuidle/cpuidle-qcom-spm.c b/drivers/cpuidle/cpuidle-qcom-spm.c
index beedf22cbe78..4ac83918edf2 100644
--- a/drivers/cpuidle/cpuidle-qcom-spm.c
+++ b/drivers/cpuidle/cpuidle-qcom-spm.c
@@ -17,7 +17,7 @@
#include
#include
#include
-#include
+#include
#include
#include
diff --git a/drivers/firmware/qcom_scm-legacy.c
b/drivers/firmware/qcom_scm-legacy.c
index 9f918b9e6f8f..029e6d117cb8 100644
--- a/drivers/firmware/qcom_scm-legacy.c
+++ b/drivers/firmware/qcom_scm-legacy.c
@@ -9,7 +9,7 @@
#include
#include
#include
-#include
+#include
#include
#include
diff --git a/drivers/firmware/qcom_scm-smc.c b/drivers/firmware/qcom_scm-smc.c
index bb3235a64b8f..16cf88acfa8e 100644
--- a/drivers/firmware/qcom_scm-smc.c
+++ b/drivers/firmware/qcom_scm-smc.c
@@ -8,7 +8,7 @@
#include
#include
#include
-#include
+#include
#include
#include
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 2000323722bf..468d4d5ab550 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -12,7 +12,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 660ba0db8900..d09221f97f71 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -5,7 +5,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 57586c794b84..89ff978b81bb 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -8,7 +8,7 @@
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c
b/drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c
index e7748461cffc..0752fe373351 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c
@@ -3,7 +3,7 @@
*/
#include "hdmi.h"
-#include
+#include
#define HDCP_REG_ENABLE 0x01
#define HDCP_REG_DISABLE 0x00
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c
index 74e9ef2fd580..b5b14108e086 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c
@@ -4,7 +4,7 @@
*/
#include
-#include
+#include
#include
#include "arm-smmu.h"
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 91d404deb115..ef42329e82ce 100644
---
[PATCH 6/8] arm64: dts: qcom: sm8350: finish reordering nodes
Finish reordering DT nodes. Move PDC, tsens, AOSS, SRAM, SPMI and TLMM
nodes to the proper position.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8350.dtsi | 764 +--
1 file changed, 382 insertions(+), 382 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi
b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index c327dc925793..e5b308957f88 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -1884,276 +1884,6 @@ compute-cb@3 {
};
};
- pdc: interrupt-controller@b22 {
- compatible = "qcom,sm8350-pdc", "qcom,pdc";
- reg = <0 0x0b22 0 0x3>, <0 0x17c000f0 0 0x60>;
- qcom,pdc-ranges = <0 480 40>, <40 140 14>, <54 263 1>,
<55 306 4>,
- <59 312 3>, <62 374 2>, <64 434 2>,
<66 438 3>,
- <69 86 1>, <70 520 54>, <124 609
31>, <155 63 1>,
- <156 716 12>;
- #interrupt-cells = <2>;
- interrupt-parent = <>;
- interrupt-controller;
- };
-
- tsens0: thermal-sensor@c263000 {
- compatible = "qcom,sm8350-tsens", "qcom,tsens-v2";
- reg = <0 0x0c263000 0 0x1ff>, /* TM */
- <0 0x0c222000 0 0x8>; /* SROT */
- #qcom,sensors = <15>;
- interrupts-extended = < 26 IRQ_TYPE_LEVEL_HIGH>,
-< 28 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "uplow", "critical";
- #thermal-sensor-cells = <1>;
- };
-
- tsens1: thermal-sensor@c265000 {
- compatible = "qcom,sm8350-tsens", "qcom,tsens-v2";
- reg = <0 0x0c265000 0 0x1ff>, /* TM */
- <0 0x0c223000 0 0x8>; /* SROT */
- #qcom,sensors = <14>;
- interrupts-extended = < 27 IRQ_TYPE_LEVEL_HIGH>,
-< 29 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "uplow", "critical";
- #thermal-sensor-cells = <1>;
- };
-
- aoss_qmp: power-management@c30 {
- compatible = "qcom,sm8350-aoss-qmp", "qcom,aoss-qmp";
- reg = <0 0x0c30 0 0x400>;
- interrupts-extended = < IPCC_CLIENT_AOP
IPCC_MPROC_SIGNAL_GLINK_QMP
-IRQ_TYPE_EDGE_RISING>;
- mboxes = < IPCC_CLIENT_AOP
IPCC_MPROC_SIGNAL_GLINK_QMP>;
-
- #clock-cells = <0>;
- };
-
- sram@c3f {
- compatible = "qcom,rpmh-stats";
- reg = <0 0x0c3f 0 0x400>;
- };
-
- spmi_bus: spmi@c44 {
- compatible = "qcom,spmi-pmic-arb";
- reg = <0x0 0x0c44 0x0 0x1100>,
- <0x0 0x0c60 0x0 0x200>,
- <0x0 0x0e60 0x0 0x10>,
- <0x0 0x0e70 0x0 0xa>,
- <0x0 0x0c40a000 0x0 0x26000>;
- reg-names = "core", "chnls", "obsrvr", "intr", "cnfg";
- interrupt-names = "periph_irq";
- interrupts-extended = < 1 IRQ_TYPE_LEVEL_HIGH>;
- qcom,ee = <0>;
- qcom,channel = <0>;
- #address-cells = <2>;
- #size-cells = <0>;
- interrupt-controller;
- #interrupt-cells = <4>;
- };
-
- tlmm: pinctrl@f10 {
- compatible = "qcom,sm8350-tlmm";
- reg = <0 0x0f10 0 0x30>;
- interrupts = ;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- gpio-ranges = < 0 0 204>;
- wakeup-parent = <>;
-
- sdc2_default_state: sdc2-default-state {
- clk-pins {
- pins = "sdc2_clk";
- drive-strength = <16>;
- bias-disable;
- };
-
- cmd-pins {
- pins = "sdc2_cmd";
- drive-strength = <16>;
- bias-pull-up;
-
[PATCH 7/8] arm64: dts: qcom: sm8350: add GPU, GMU, GPU CC and SMMU nodes
Add device nodes required to enable GPU on the SM8350 platform.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8350.dtsi | 179 +++
1 file changed, 179 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi
b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index e5b308957f88..a73cd9eb63e0 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1767,6 +1768,184 @@ tcsr_mutex: hwlock@1f4 {
#hwlock-cells = <1>;
};
+ gpu: gpu@3d0 {
+ compatible = "qcom,adreno-660.1",
+"qcom,adreno";
+
+ reg = <0 0x03d0 0 0x4>,
+ <0 0x03d9e000 0 0x1000>,
+ <0 0x03d61000 0 0x800>;
+ reg-names = "kgsl_3d0_reg_memory",
+ "cx_mem",
+ "cx_dbgc";
+
+ interrupts = ;
+
+ iommus = <_smmu 0 0x400>, <_smmu 1 0x400>;
+
+ operating-points-v2 = <_opp_table>;
+
+ qcom,gmu = <>;
+
+ status = "disabled";
+
+ zap-shader {
+ memory-region = <_gpu_mem>;
+ };
+
+ /* note: downstream checks gpu binning for 670 Mhz */
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ /* not for v1 */
+ opp-84000 {
+ opp-hz = /bits/ 64 <84000>;
+ opp-level =
;
+ };
+
+ /* not for v1 */
+ opp-77800 {
+ opp-hz = /bits/ 64 <77800>;
+ opp-level =
;
+ };
+
+ /* not for v1 */
+ opp-73800 {
+ opp-hz = /bits/ 64 <73800>;
+ opp-level =
;
+ };
+
+ /* for v1
+ opp-71000 {
+ opp-hz = /bits/ 64 <71000>;
+ opp-level =
;
+ };
+ */
+
+ opp-67600 {
+ opp-hz = /bits/ 64 <67600>;
+ opp-level = ;
+ };
+
+ opp-60800 {
+ opp-hz = /bits/ 64 <60800>;
+ opp-level =
;
+ };
+
+ opp-54000 {
+ opp-hz = /bits/ 64 <54000>;
+ opp-level =
;
+ };
+
+ /* not for v1 */
+ opp-49100 {
+ opp-hz = /bits/ 64 <49100>;
+ opp-level =
;
+ };
+
+ opp-44300 {
+ opp-hz = /bits/ 64 <44300>;
+ opp-level = ;
+ };
+
+ /* not for v1 */
+ opp-37900 {
+ opp-hz = /bits/ 64 <37900>;
+ opp-level =
;
+ };
+
+ opp-31500 {
+ opp-hz = /bits/ 64 <31500>;
+ opp-level =
;
+ };
+ };
+ };
+
+ gmu: gmu@3d6a000 {
+ compatible = "qcom,adreno-gmu-660.1", "qcom,adreno-gmu";
+
+ reg = <0 0x03d6a000 0 0x34000>,
+ <0 0x03de 0 0x1>,
+ <0 0x0b29 0 0x1>;
+ reg-names = "gmu", "rscc", "gmu_pdc";
+
+ interrupts = ,
+;
+ interrupt-names = "hfi", "gmu";
+
+ clocks = < GPU_CC_CX_GMU_CLK>,
+< GPU_CC_CXO_CLK>,
+
[PATCH 8/8] arm64: dts: qcom: sm8350-hdk: enable GPU
Enable the GPU on the SM8350-HDK device. The ZAP shader is required for
the GPU to function properly.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8350-hdk.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
b/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
index df841230d1b7..5e744423a673 100644
--- a/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
+++ b/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
@@ -284,6 +284,14 @@ _dma1 {
status = "okay";
};
+ {
+ status = "okay";
+
+ zap-shader {
+ firmware-name = "qcom/sm8350/a660_zap.mbn";
+ };
+};
+
{
clock-frequency = <40>;
status = "okay";
--
2.39.1
[PATCH 3/8] dt-bindings: display/msm/gmu: add Adreno 660 support
Add Adreno A660 to the A635 clause to define all version-specific properties. There is no need to add it to the top-level clause, since top-level compatible uses pattern to define compatible strings. Signed-off-by: Dmitry Baryshkov --- Documentation/devicetree/bindings/display/msm/gmu.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/msm/gmu.yaml b/Documentation/devicetree/bindings/display/msm/gmu.yaml index ab14e81cb050..d5ce0dff4220 100644 --- a/Documentation/devicetree/bindings/display/msm/gmu.yaml +++ b/Documentation/devicetree/bindings/display/msm/gmu.yaml @@ -122,6 +122,7 @@ allOf: contains: enum: - qcom,adreno-gmu-635.0 + - qcom,adreno-gmu-660.1 then: properties: reg: -- 2.39.1
[PATCH 5/8] arm64: dts: qcom: sm8350: move more nodes to correct place
Continue ordering DT nodes. Move RNG, UFS, system NoC and SLPI nodes
to the proper position.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8350.dtsi | 314 +--
1 file changed, 157 insertions(+), 157 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi
b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index 061aa3fec1c4..c327dc925793 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -1423,6 +1423,13 @@ spi13: spi@a94000 {
};
};
+ rng: rng@10d3000 {
+ compatible = "qcom,prng-ee";
+ reg = <0 0x010d3000 0 0x1000>;
+ clocks = < RPMH_HWKM_CLK>;
+ clock-names = "core";
+ };
+
config_noc: interconnect@150 {
compatible = "qcom,sm8350-config-noc";
reg = <0 0x0150 0 0xa580>;
@@ -1643,18 +1650,76 @@ pcie1_phy: phy@1c0f000 {
status = "disabled";
};
- lpass_ag_noc: interconnect@3c4 {
- compatible = "qcom,sm8350-lpass-ag-noc";
- reg = <0 0x03c4 0 0xf080>;
- #interconnect-cells = <2>;
- qcom,bcm-voters = <_bcm_voter>;
+ ufs_mem_hc: ufshc@1d84000 {
+ compatible = "qcom,sm8350-ufshc", "qcom,ufshc",
+"jedec,ufs-2.0";
+ reg = <0 0x01d84000 0 0x3000>;
+ interrupts = ;
+ phys = <_mem_phy_lanes>;
+ phy-names = "ufsphy";
+ lanes-per-direction = <2>;
+ #reset-cells = <1>;
+ resets = < GCC_UFS_PHY_BCR>;
+ reset-names = "rst";
+
+ power-domains = < UFS_PHY_GDSC>;
+
+ iommus = <_smmu 0xe0 0x0>;
+
+ clock-names =
+ "core_clk",
+ "bus_aggr_clk",
+ "iface_clk",
+ "core_clk_unipro",
+ "ref_clk",
+ "tx_lane0_sync_clk",
+ "rx_lane0_sync_clk",
+ "rx_lane1_sync_clk";
+ clocks =
+ < GCC_UFS_PHY_AXI_CLK>,
+ < GCC_AGGRE_UFS_PHY_AXI_CLK>,
+ < GCC_UFS_PHY_AHB_CLK>,
+ < GCC_UFS_PHY_UNIPRO_CORE_CLK>,
+ < RPMH_CXO_CLK>,
+ < GCC_UFS_PHY_TX_SYMBOL_0_CLK>,
+ < GCC_UFS_PHY_RX_SYMBOL_0_CLK>,
+ < GCC_UFS_PHY_RX_SYMBOL_1_CLK>;
+ freq-table-hz =
+ <7500 3>,
+ <0 0>,
+ <0 0>,
+ <7500 3>,
+ <0 0>,
+ <0 0>,
+ <0 0>,
+ <0 0>;
+ status = "disabled";
};
- compute_noc: interconnect@a0c {
- compatible = "qcom,sm8350-compute-noc";
- reg = <0 0x0a0c 0 0xa180>;
- #interconnect-cells = <2>;
- qcom,bcm-voters = <_bcm_voter>;
+ ufs_mem_phy: phy@1d87000 {
+ compatible = "qcom,sm8350-qmp-ufs-phy";
+ reg = <0 0x01d87000 0 0x1c4>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ clock-names = "ref",
+ "ref_aux";
+ clocks = < RPMH_CXO_CLK>,
+< GCC_UFS_PHY_PHY_AUX_CLK>;
+
+ resets = <_mem_hc 0>;
+ reset-names = "ufsphy";
+ status = "disabled";
+
+ ufs_mem_phy_lanes: phy@1d87400 {
+ reg = <0 0x01d87400 0 0x188>,
+ <0 0x01d87600 0 0x200>,
+ <0 0x01d87c00 0 0x200>,
+ <0 0x01d87800 0 0x188>,
+ <0 0x01d87a00 0 0x200>;
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+ };
};
ipa: ipa@1e4 {
@@ -1702,6 +1767,13 @@ tcsr_mutex: hwlock@1f4 {
#hwlock-cells =
[PATCH 4/8] arm64: dts: qcom: sm8350: reorder device nodes
Start ordering DT nodes according to agreed order. Move apps SMMU, GIC,
timer, apps RSC, cpufreq ADSP and cDSP nodes to the end to the proper
position at the end of /soc/.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8350.dtsi | 1228 +-
1 file changed, 614 insertions(+), 614 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi
b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index 0de42a333d32..061aa3fec1c4 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -1423,111 +1423,6 @@ spi13: spi@a94000 {
};
};
- apps_smmu: iommu@1500 {
- compatible = "qcom,sm8350-smmu-500", "arm,mmu-500";
- reg = <0 0x1500 0 0x10>;
- #iommu-cells = <2>;
- #global-interrupts = <2>;
- interrupts =,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
- ,
-
[PATCH 2/8] arm64: dts: qcom: sm8450: add RPMH_REGULATOR_LEVEL_LOW_SVS_L1
Add another power saving state used on SM8350. Signed-off-by: Dmitry Baryshkov --- include/dt-bindings/power/qcom-rpmpd.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/dt-bindings/power/qcom-rpmpd.h b/include/dt-bindings/power/qcom-rpmpd.h index 4a30d10e6b7d..1bf8e87ecd7e 100644 --- a/include/dt-bindings/power/qcom-rpmpd.h +++ b/include/dt-bindings/power/qcom-rpmpd.h @@ -211,6 +211,7 @@ #define RPMH_REGULATOR_LEVEL_MIN_SVS 48 #define RPMH_REGULATOR_LEVEL_LOW_SVS_D156 #define RPMH_REGULATOR_LEVEL_LOW_SVS 64 +#define RPMH_REGULATOR_LEVEL_LOW_SVS_L180 #define RPMH_REGULATOR_LEVEL_SVS 128 #define RPMH_REGULATOR_LEVEL_SVS_L0144 #define RPMH_REGULATOR_LEVEL_SVS_L1192 -- 2.39.1
[PATCH 2/8] arm64: dts: qcom: sm8350: add RPMH_REGULATOR_LEVEL_LOW_SVS_L1
Add another power saving state used on SM8350. Signed-off-by: Dmitry Baryshkov --- include/dt-bindings/power/qcom-rpmpd.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/dt-bindings/power/qcom-rpmpd.h b/include/dt-bindings/power/qcom-rpmpd.h index 4a30d10e6b7d..1bf8e87ecd7e 100644 --- a/include/dt-bindings/power/qcom-rpmpd.h +++ b/include/dt-bindings/power/qcom-rpmpd.h @@ -211,6 +211,7 @@ #define RPMH_REGULATOR_LEVEL_MIN_SVS 48 #define RPMH_REGULATOR_LEVEL_LOW_SVS_D156 #define RPMH_REGULATOR_LEVEL_LOW_SVS 64 +#define RPMH_REGULATOR_LEVEL_LOW_SVS_L180 #define RPMH_REGULATOR_LEVEL_SVS 128 #define RPMH_REGULATOR_LEVEL_SVS_L0144 #define RPMH_REGULATOR_LEVEL_SVS_L1192 -- 2.39.1
[PATCH 1/8] dt-bindings: clock: Merge qcom, gpucc-sm8350 into qcom, gpucc.yaml
The GPU clock controller bindings for the Qualcomm sm8350 platform are
not correct. The driver uses .fw_name instead of using indices to bind
parent clocks, thus demanding the clock-names usage. With the proper
clock-names in place, the bindings becomes equal to the bindings defined
by qcom,gpucc.yaml, so it is impractical to keep them in a separate
file.
Signed-off-by: Dmitry Baryshkov
---
.../bindings/clock/qcom,gpucc-sm8350.yaml | 71 ---
.../devicetree/bindings/clock/qcom,gpucc.yaml | 2 +
2 files changed, 2 insertions(+), 71 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/clock/qcom,gpucc-sm8350.yaml
diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc-sm8350.yaml
b/Documentation/devicetree/bindings/clock/qcom,gpucc-sm8350.yaml
deleted file mode 100644
index fb7ae3d18503..
--- a/Documentation/devicetree/bindings/clock/qcom,gpucc-sm8350.yaml
+++ /dev/null
@@ -1,71 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
-$id: http://devicetree.org/schemas/clock/qcom,gpucc-sm8350.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Qualcomm Graphics Clock & Reset Controller on SM8350
-
-maintainers:
- - Robert Foss
-
-description: |
- Qualcomm graphics clock control module provides the clocks, resets and power
- domains on Qualcomm SoCs.
-
- See also:: include/dt-bindings/clock/qcom,gpucc-sm8350.h
-
-properties:
- compatible:
-enum:
- - qcom,sm8350-gpucc
-
- clocks:
-items:
- - description: Board XO source
- - description: GPLL0 main branch source
- - description: GPLL0 div branch source
-
- '#clock-cells':
-const: 1
-
- '#reset-cells':
-const: 1
-
- '#power-domain-cells':
-const: 1
-
- reg:
-maxItems: 1
-
-required:
- - compatible
- - reg
- - clocks
- - '#clock-cells'
- - '#reset-cells'
- - '#power-domain-cells'
-
-additionalProperties: false
-
-examples:
- - |
-#include
-#include
-
-soc {
-#address-cells = <2>;
-#size-cells = <2>;
-
-clock-controller@3d9 {
-compatible = "qcom,sm8350-gpucc";
-reg = <0 0x03d9 0 0x9000>;
-clocks = < RPMH_CXO_CLK>,
- < GCC_GPU_GPLL0_CLK_SRC>,
- < GCC_GPU_GPLL0_DIV_CLK_SRC>;
-#clock-cells = <1>;
-#reset-cells = <1>;
-#power-domain-cells = <1>;
-};
-};
-...
diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
index 7256c438a4cf..db53eb288995 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
@@ -21,6 +21,7 @@ description: |
include/dt-bindings/clock/qcom,gpucc-sm6350.h
include/dt-bindings/clock/qcom,gpucc-sm8150.h
include/dt-bindings/clock/qcom,gpucc-sm8250.h
+include/dt-bindings/clock/qcom,gpucc-sm8350.h
properties:
compatible:
@@ -33,6 +34,7 @@ properties:
- qcom,sm6350-gpucc
- qcom,sm8150-gpucc
- qcom,sm8250-gpucc
+ - qcom,sm8350-gpucc
clocks:
items:
--
2.39.1
[PATCH 0/8] arm64: dts: qcom: sm8350: enable GPU on the HDK board
Add A660 device to the Qualcomm SM8350 platform and enable it for the sm8350-hdk board. Unfortunately while adding the GPU & related devices I noticed that DT nodes on SM8350 are greatly out of the preagreed order, so patches 4-6 reorder DT nodes to follow the agreement. Dmitry Baryshkov (8): dt-bindings: clock: Merge qcom,gpucc-sm8350 into qcom,gpucc.yaml arm64: dts: qcom: sm8350: add RPMH_REGULATOR_LEVEL_LOW_SVS_L1 dt-bindings: display/msm/gmu: add Adreno 660 support arm64: dts: qcom: sm8350: reorder device nodes arm64: dts: qcom: sm8350: move more nodes to correct place arm64: dts: qcom: sm8350: finish reordering nodes arm64: dts: qcom: sm8350: add GPU, GMU, GPU CC and SMMU nodes arm64: dts: qcom: sm8350-hdk: enable GPU .../bindings/clock/qcom,gpucc-sm8350.yaml | 71 - .../devicetree/bindings/clock/qcom,gpucc.yaml |2 + .../devicetree/bindings/display/msm/gmu.yaml |1 + arch/arm64/boot/dts/qcom/sm8350-hdk.dts |8 + arch/arm64/boot/dts/qcom/sm8350.dtsi | 2515 + include/dt-bindings/power/qcom-rpmpd.h|1 + 6 files changed, 1359 insertions(+), 1239 deletions(-) delete mode 100644 Documentation/devicetree/bindings/clock/qcom,gpucc-sm8350.yaml -- 2.39.1
Re: remove arch/sh
Hi Stephen! On Mon, 2023-02-06 at 10:08 +1100, Stephen Rothwell wrote: > Hi, > > On Fri, 3 Feb 2023 09:30:37 +0100 Christoph Hellwig wrote: > > > > On Fri, Feb 03, 2023 at 09:24:46AM +0100, John Paul Adrian Glaubitz wrote: > > > Since this is my very first time stepping up as a kernel maintainer, I > > > was hoping > > > to get some pointers on what to do to make this happen. > > > > > > So far, we have set up a new kernel tree and I have set up a local > > > development and > > > test environment for SH kernels using my SH7785LCR board as the target > > > platform. > > > > > > Do I just need to send a patch asking to change the corresponding entry > > > in the > > > MAINTAINERS file? > > > > I'm not sure a there is a document, but: > > > > - add the MAINTAINERS change to your tree > > - ask Stephen to get your tree included in linux-next > > And by "Stephen", Christoph means me. When you are ready, please send > me a request to include your tree/branch in linux-next (usually the > branch is called something like "for-next" or just "next") telling me > the git URL, and the contacts I should send email to if there are > conflicts/build issues with the branch. I will then fetch the branch > every time I create a new linux-next release (most work days), so all > you need to do is update that branch each time you are ready to publish > more commits. Thanks a lot! I will start with that tomorrow with Geert giving me some guidance. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: remove arch/sh
Hi, On Fri, 3 Feb 2023 09:30:37 +0100 Christoph Hellwig wrote: > > On Fri, Feb 03, 2023 at 09:24:46AM +0100, John Paul Adrian Glaubitz wrote: > > Since this is my very first time stepping up as a kernel maintainer, I was > > hoping > > to get some pointers on what to do to make this happen. > > > > So far, we have set up a new kernel tree and I have set up a local > > development and > > test environment for SH kernels using my SH7785LCR board as the target > > platform. > > > > Do I just need to send a patch asking to change the corresponding entry in > > the > > MAINTAINERS file? > > I'm not sure a there is a document, but: > > - add the MAINTAINERS change to your tree > - ask Stephen to get your tree included in linux-next And by "Stephen", Christoph means me. When you are ready, please send me a request to include your tree/branch in linux-next (usually the branch is called something like "for-next" or just "next") telling me the git URL, and the contacts I should send email to if there are conflicts/build issues with the branch. I will then fetch the branch every time I create a new linux-next release (most work days), so all you need to do is update that branch each time you are ready to publish more commits. -- Cheers, Stephen Rothwell pgpMJEDRfhR5G.pgp Description: OpenPGP digital signature
[drm-misc:drm-misc-next 8/15] drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:2316:8: warning: variable 'possible_crtcs' is used uninitialized whenever 'if' condition is false
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next head: 8ee3b0e85f6ccd9e6c527bc50eaba774c3bb18d0 commit: 368419a2d429e2438bef333959732c640310bdc7 [8/15] drm/rockchip: vop2: initialize possible_crtcs properly config: s390-buildonly-randconfig-r002-20230205 (https://download.01.org/0day-ci/archive/20230206/202302060541.tvqvzvyv-...@intel.com/config) compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project 4196ca3278f78c6e19246e54ab0ecb364e37d66a) 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 # install s390 cross compiling tool for clang build # apt-get install binutils-s390x-linux-gnu git remote add drm-misc git://anongit.freedesktop.org/drm/drm-misc git fetch --no-tags drm-misc drm-misc-next git checkout 368419a2d429e2438bef333959732c640310bdc7 # save the config file mkdir build_dir && cp config build_dir/.config COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=s390 olddefconfig COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=s390 SHELL=/bin/bash drivers/gpu/drm/rockchip/ If you fix the issue, kindly add following tag where applicable | Reported-by: kernel test robot All warnings (new ones prefixed by >>): In file included from drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:10: In file included from include/linux/iopoll.h:14: In file included from include/linux/io.h:13: In file included from arch/s390/include/asm/io.h:75: include/asm-generic/io.h:547:31: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] val = __raw_readb(PCI_IOBASE + addr); ~~ ^ include/asm-generic/io.h:560:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] val = __le16_to_cpu((__le16 __force)__raw_readw(PCI_IOBASE + addr)); ~~ ^ include/uapi/linux/byteorder/big_endian.h:37:59: note: expanded from macro '__le16_to_cpu' #define __le16_to_cpu(x) __swab16((__force __u16)(__le16)(x)) ^ include/uapi/linux/swab.h:102:54: note: expanded from macro '__swab16' #define __swab16(x) (__u16)__builtin_bswap16((__u16)(x)) ^ In file included from drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:10: In file included from include/linux/iopoll.h:14: In file included from include/linux/io.h:13: In file included from arch/s390/include/asm/io.h:75: include/asm-generic/io.h:573:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr)); ~~ ^ include/uapi/linux/byteorder/big_endian.h:35:59: note: expanded from macro '__le32_to_cpu' #define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x)) ^ include/uapi/linux/swab.h:115:54: note: expanded from macro '__swab32' #define __swab32(x) (__u32)__builtin_bswap32((__u32)(x)) ^ In file included from drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:10: In file included from include/linux/iopoll.h:14: In file included from include/linux/io.h:13: In file included from arch/s390/include/asm/io.h:75: include/asm-generic/io.h:584:33: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] __raw_writeb(value, PCI_IOBASE + addr); ~~ ^ include/asm-generic/io.h:594:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] __raw_writew((u16 __force)cpu_to_le16(value), PCI_IOBASE + addr); ~~ ^ include/asm-generic/io.h:604:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] __raw_writel((u32 __force)cpu_to_le32(value), PCI_IOBASE + addr); ~~ ^ include/asm-generic/io.h:692:20: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] readsb(PCI_IOBASE + addr, buffer, count); ~~ ^ include/asm-generic/io.h:700:20: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
Re: [PATCH v11 1/9] device property: Add remote endpoint to devcon matcher
Hi Pin-yen,
On Sat, Feb 04, 2023 at 09:30:32PM +0800, Pin-yen Lin wrote:
> From: Prashant Malani
>
> When searching the device graph for device matches, check the
> remote-endpoint itself for a match.
>
> Some drivers register devices for individual endpoints. This allows
> the matcher code to evaluate those for a match too, instead
> of only looking at the remote parent devices. This is required when a
> device supports two mode switches in its endpoints, so we can't simply
> register the mode switch with the parent node.
>
> Signed-off-by: Prashant Malani
> Signed-off-by: Pin-yen Lin
> Reviewed-by: Chen-Yu Tsai
> Tested-by: Chen-Yu Tsai
Thanks for the update.
I intended to give my Reviewed-by: but there's something still needs to be
addressed. See below.
>
> ---
>
> Changes in v11:
> - Added missing fwnode_handle_put in drivers/base/property.c
>
> Changes in v10:
> - Collected Reviewed-by and Tested-by tags
>
> Changes in v6:
> - New in v6
>
> drivers/base/property.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/base/property.c b/drivers/base/property.c
> index 2a5a37fcd998..e6f915b72eb7 100644
> --- a/drivers/base/property.c
> +++ b/drivers/base/property.c
> @@ -1223,6 +1223,22 @@ static unsigned int fwnode_graph_devcon_matches(struct
> fwnode_handle *fwnode,
> break;
> }
>
> + /*
> + * Some drivers may register devices for endpoints. Check
> + * the remote-endpoints for matches in addition to the remote
> + * port parent.
> + */
> + node = fwnode_graph_get_remote_endpoint(ep);
Here fwnode_graph_get_remote_endpoint() returns an endpoint...
> + if (fwnode_device_is_available(node)) {
and you're calling fwnode_device_is_available() on the endpoint node, which
always returns true.
Shouldn't you call this on the device node instead? What about match()
below?
> + ret = match(node, con_id, data);
> + if (ret) {
> + if (matches)
> + matches[count] = ret;
> + count++;
> + }
> + }
> + fwnode_handle_put(node);
> +
> node = fwnode_graph_get_remote_port_parent(ep);
> if (!fwnode_device_is_available(node)) {
> fwnode_handle_put(node);
--
Kind regards,
Sakari Ailus
[PATCH] nvidiafb: detect the hardware support before removing console.
From: Dave Airlie
This driver removed the console, but hasn't yet decided if it could
take over the console yet. Instead of doing that, probe the hw for
support and then remove the console afterwards.
Signed-off-by: Dave Airlie
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=216859
Reported-by: Zeno Davatz
---
drivers/video/fbdev/nvidia/nvidia.c | 81 +++--
1 file changed, 42 insertions(+), 39 deletions(-)
diff --git a/drivers/video/fbdev/nvidia/nvidia.c
b/drivers/video/fbdev/nvidia/nvidia.c
index 1960916098d4..e60a276b4855 100644
--- a/drivers/video/fbdev/nvidia/nvidia.c
+++ b/drivers/video/fbdev/nvidia/nvidia.c
@@ -1197,17 +1197,17 @@ static int nvidia_set_fbinfo(struct fb_info *info)
return nvidiafb_check_var(>var, info);
}
-static u32 nvidia_get_chipset(struct fb_info *info)
+static u32 nvidia_get_chipset(struct pci_dev *pci_dev,
+ volatile u32 __iomem *REGS)
{
- struct nvidia_par *par = info->par;
- u32 id = (par->pci_dev->vendor << 16) | par->pci_dev->device;
+ u32 id = (pci_dev->vendor << 16) | pci_dev->device;
printk(KERN_INFO PFX "Device ID: %x \n", id);
if ((id & 0xfff0) == 0x00f0 ||
(id & 0xfff0) == 0x02e0) {
/* pci-e */
- id = NV_RD32(par->REGS, 0x1800);
+ id = NV_RD32(REGS, 0x1800);
if ((id & 0x) == 0x10DE)
id = 0x10DE | (id >> 16);
@@ -1220,12 +1220,11 @@ static u32 nvidia_get_chipset(struct fb_info *info)
return id;
}
-static u32 nvidia_get_arch(struct fb_info *info)
+static u32 nvidia_get_arch(u32 Chipset)
{
- struct nvidia_par *par = info->par;
u32 arch = 0;
- switch (par->Chipset & 0x0ff0) {
+ switch (Chipset & 0x0ff0) {
case 0x0100:/* GeForce 256 */
case 0x0110:/* GeForce2 MX */
case 0x0150:/* GeForce2 */
@@ -1278,16 +1277,44 @@ static int nvidiafb_probe(struct pci_dev *pd, const
struct pci_device_id *ent)
struct fb_info *info;
unsigned short cmd;
int ret;
+ volatile u32 __iomem *REGS;
+ int Chipset;
+ u32 Architecture;
NVTRACE_ENTER();
assert(pd != NULL);
+ if (pci_enable_device(pd)) {
+ printk(KERN_ERR PFX "cannot enable PCI device\n");
+ return -ENODEV;
+ }
+
+ /* enable IO and mem if not already done */
+ pci_read_config_word(pd, PCI_COMMAND, );
+ cmd |= (PCI_COMMAND_IO | PCI_COMMAND_MEMORY);
+ pci_write_config_word(pd, PCI_COMMAND, cmd);
+
+ nvidiafb_fix.mmio_start = pci_resource_start(pd, 0);
+ nvidiafb_fix.mmio_len = pci_resource_len(pd, 0);
+
+ REGS = ioremap(nvidiafb_fix.mmio_start, nvidiafb_fix.mmio_len);
+ if (!REGS) {
+ printk(KERN_ERR PFX "cannot ioremap MMIO base\n");
+ return -ENODEV;
+ }
+
+ Chipset = nvidia_get_chipset(pd, REGS);
+ Architecture = nvidia_get_arch(Chipset);
+ if (Architecture == 0) {
+ printk(KERN_ERR PFX "unknown NV_ARCH\n");
+ goto err_out;
+ }
+
ret = aperture_remove_conflicting_pci_devices(pd, "nvidiafb");
if (ret)
- return ret;
+ goto err_out;
info = framebuffer_alloc(sizeof(struct nvidia_par), >dev);
-
if (!info)
goto err_out;
@@ -1298,11 +1325,6 @@ static int nvidiafb_probe(struct pci_dev *pd, const
struct pci_device_id *ent)
if (info->pixmap.addr == NULL)
goto err_out_kfree;
- if (pci_enable_device(pd)) {
- printk(KERN_ERR PFX "cannot enable PCI device\n");
- goto err_out_enable;
- }
-
if (pci_request_regions(pd, "nvidiafb")) {
printk(KERN_ERR PFX "cannot request PCI regions\n");
goto err_out_enable;
@@ -1318,34 +1340,17 @@ static int nvidiafb_probe(struct pci_dev *pd, const
struct pci_device_id *ent)
par->paneltweak = paneltweak;
par->reverse_i2c = reverse_i2c;
- /* enable IO and mem if not already done */
- pci_read_config_word(pd, PCI_COMMAND, );
- cmd |= (PCI_COMMAND_IO | PCI_COMMAND_MEMORY);
- pci_write_config_word(pd, PCI_COMMAND, cmd);
-
- nvidiafb_fix.mmio_start = pci_resource_start(pd, 0);
nvidiafb_fix.smem_start = pci_resource_start(pd, 1);
- nvidiafb_fix.mmio_len = pci_resource_len(pd, 0);
-
- par->REGS = ioremap(nvidiafb_fix.mmio_start, nvidiafb_fix.mmio_len);
- if (!par->REGS) {
- printk(KERN_ERR PFX "cannot ioremap MMIO base\n");
- goto err_out_free_base0;
- }
+ par->REGS = REGS;
- par->Chipset = nvidia_get_chipset(info);
- par->Architecture = nvidia_get_arch(info);
-
- if (par->Architecture == 0) {
- printk(KERN_ERR PFX "unknown NV_ARCH\n");
-
Re: [PATCH] Revert "fbdev: Remove conflicting devices on PCI bus"
On Sat, 4 Feb 2023 at 09:09, Bjorn Helgaas wrote:
>
> From: Bjorn Helgaas
>
> This reverts commit 145eed48de278007f646b908fd70ac59d24ed81a.
>
> Zeno Davatz reported that 145eed48de27 ("fbdev: Remove conflicting devices
> on PCI bus") caused a console hang. The machine was actually still usable
> via ssh, etc., but there was no activity on the console.
>
> Reverting 145eed48de27 for the nvidiafb on that system fixed the problem.
>
> Revert 145eed48de27 ("fbdev: Remove conflicting devices on PCI bus") since
> we don't know what caused the problem.
Why is the user using nvidiafb?
This exposes a bug in nvidiafb, The user shouldn't even be using the
driver, it does nothing on their hardware, but it does a lot of things
before it binds.
nvidiafb should be fixed to probe the hw to see if it supports it
before it removes the framebuffer. I don't think reverting this patch
in full is the right answer, though we could revert the core bits and
allow nvidia fb to limp along until it's fixed or shot.
Dave.
>
> Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=216859
> Reported-by: Zeno Davatz
> Tested-by: Zeno Davatz
> Signed-off-by: Bjorn Helgaas
> Cc: Helge Deller
> Cc: Thomas Zimmermann
> Cc: Javier Martinez Canillas
> Cc: linux-fb...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> ---
> drivers/video/fbdev/arkfb.c | 5 -
> drivers/video/fbdev/asiliantfb.c | 5 -
> drivers/video/fbdev/aty/aty128fb.c | 5 -
> drivers/video/fbdev/aty/atyfb_base.c | 7 +--
> drivers/video/fbdev/carminefb.c | 5 -
> drivers/video/fbdev/chipsfb.c| 7 +--
> drivers/video/fbdev/cirrusfb.c | 5 -
> drivers/video/fbdev/cyber2000fb.c| 5 -
> drivers/video/fbdev/geode/gx1fb_core.c | 5 -
> drivers/video/fbdev/geode/gxfb_core.c| 5 -
> drivers/video/fbdev/geode/lxfb_core.c| 5 -
> drivers/video/fbdev/gxt4500.c| 5 -
> drivers/video/fbdev/i740fb.c | 5 -
> drivers/video/fbdev/i810/i810_main.c | 5 -
> drivers/video/fbdev/imsttfb.c| 8 +---
> drivers/video/fbdev/intelfb/intelfbdrv.c | 5 -
> drivers/video/fbdev/kyro/fbdev.c | 5 -
> drivers/video/fbdev/matrox/matroxfb_base.c | 5 -
> drivers/video/fbdev/mb862xx/mb862xxfbdrv.c | 5 -
> drivers/video/fbdev/neofb.c | 5 -
> drivers/video/fbdev/nvidia/nvidia.c | 7 +--
> drivers/video/fbdev/pm2fb.c | 5 -
> drivers/video/fbdev/pm3fb.c | 5 -
> drivers/video/fbdev/pvr2fb.c | 5 -
> drivers/video/fbdev/riva/fbdev.c | 5 -
> drivers/video/fbdev/s3fb.c | 5 -
> drivers/video/fbdev/savage/savagefb_driver.c | 5 -
> drivers/video/fbdev/sis/sis_main.c | 5 -
> drivers/video/fbdev/skeletonfb.c | 8
> drivers/video/fbdev/sm712fb.c| 5 -
> drivers/video/fbdev/sstfb.c | 5 -
> drivers/video/fbdev/sunxvr2500.c | 5 -
> drivers/video/fbdev/sunxvr500.c | 5 -
> drivers/video/fbdev/tdfxfb.c | 5 -
> drivers/video/fbdev/tgafb.c | 7 ---
> drivers/video/fbdev/tridentfb.c | 5 -
> drivers/video/fbdev/vermilion/vermilion.c| 7 +--
> drivers/video/fbdev/via/via-core.c | 5 -
> drivers/video/fbdev/vt8623fb.c | 5 -
> 39 files changed, 5 insertions(+), 206 deletions(-)
>
> diff --git a/drivers/video/fbdev/arkfb.c b/drivers/video/fbdev/arkfb.c
> index 60a96fdb5dd8..41b9117c55bb 100644
> --- a/drivers/video/fbdev/arkfb.c
> +++ b/drivers/video/fbdev/arkfb.c
> @@ -11,7 +11,6 @@
> * Code is based on s3fb
> */
>
> -#include
> #include
> #include
> #include
> @@ -949,10 +948,6 @@ static int ark_pci_probe(struct pci_dev *dev, const
> struct pci_device_id *id)
> int rc;
> u8 regval;
>
> - rc = aperture_remove_conflicting_pci_devices(dev, "arkfb");
> - if (rc < 0)
> - return rc;
> -
> /* Ignore secondary VGA device because there is no VGA arbitration */
> if (! svga_primary_device(dev)) {
> dev_info(&(dev->dev), "ignoring secondary device\n");
> diff --git a/drivers/video/fbdev/asiliantfb.c
> b/drivers/video/fbdev/asiliantfb.c
> index 8383468f5577..4a98383eb274 100644
> --- a/drivers/video/fbdev/asiliantfb.c
> +++ b/drivers/video/fbdev/asiliantfb.c
> @@ -29,7 +29,6 @@
> * more details.
> */
>
> -#include
> #include
> #include
> #include
> @@ -546,10 +545,6 @@ static int asiliantfb_pci_init(struct pci_dev *dp,
> struct fb_info *p;
> int err;
>
> - err = aperture_remove_conflicting_pci_devices(dp, "asiliantfb");
> - if (err)
> -
Re: [PATCH v1 RFC] video/hdmi: Fix HDMI_VENDOR_INFOFRAME_SIZE
Hello Jani, Hello Ville, On Tue, Jan 10, 2023 at 7:20 PM Jani Nikula wrote: [...] > > I'm not an expert on this topic and I'm not sure if the size still > > depends on that if condition from long time ago. So please share your > > thoughts. > > I tried to look at this quickly, but it makes my brain hurt. I don't > think simply changing the size here is right either. I think I see what you're saying here: hdmi_vendor_infoframe_length() has logic to determine the "correct" size. My idea here is to use the maximum possible size for HDMI_VENDOR_INFOFRAME_SIZE so it can be used with the HDMI_INFOFRAME_SIZE macro (just like the other _SIZE definitions right above the vendor infoframe one). If you have suggestions on my patch then please let me know. Best regards, Martin
Re: [GIT PULL] fbdev fixes for v6.2-rc7
The pull request you sent on Sun, 5 Feb 2023 10:44:23 +0100: > http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git > tags/fbdev-for-6.2-rc7 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/870c3a9a2bc48bea0f954172aaff7ed489acaf64 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
[PATCH v2] drm: add kms driver for loongson display controller
From: suijingfeng Loongson display controller IP has been integrated in both Loongson North Bridge chipset(ls7a1000 and ls7a2000) and Loongson SoCs(ls2k1000 and ls2k2000 etc), it even been included in Loongson BMC products. The display controller is a PCI device, it has two display pipe. For the DC in LS7A1000 and LS2K1000 each way has a DVO output interface which provide RGB888 signals, vertical & horizontal synchronisations, and the pixel clock. Each CRTC is able to support 1920x1080@60Hz, the maximum resolution is 2048x2048 according to the hardware spec. For the DC in LS7A2000, each display pipe is connected with a built-in HDMI encoder which support 3840x2160@30Hz. the first display pipe is also equipped with a transparent vga encoder which is parallel with the hdmi encoder. The DC in LS7A2000 is more complete, besides above feature, it has two hardware cursors, two hardware vblank counter and two scanout position recoders. It also support hdmi audio and tiled format etc. v2: 1) Use hpd status reg when polling for ls7a2000 2) Fix all warnings emerged when compile with W=1 Signed-off-by: suijingfeng Signed-off-by: suijingfeng <15330273...@189.cn> --- drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile| 1 + drivers/gpu/drm/lsdc/Kconfig| 17 + drivers/gpu/drm/lsdc/Makefile | 14 + drivers/gpu/drm/lsdc/lsdc_crtc.c| 421 ++ drivers/gpu/drm/lsdc/lsdc_debugfs.c | 191 + drivers/gpu/drm/lsdc/lsdc_drv.c | 635 drivers/gpu/drm/lsdc/lsdc_drv.h | 274 drivers/gpu/drm/lsdc/lsdc_i2c.c | 201 + drivers/gpu/drm/lsdc/lsdc_irq.c | 86 drivers/gpu/drm/lsdc/lsdc_output.c | 452 drivers/gpu/drm/lsdc/lsdc_plane.c | 443 +++ drivers/gpu/drm/lsdc/lsdc_pll.c | 569 + drivers/gpu/drm/lsdc/lsdc_pll.h | 78 drivers/gpu/drm/lsdc/lsdc_regs.c| 29 ++ drivers/gpu/drm/lsdc/lsdc_regs.h| 296 + 16 files changed, 3709 insertions(+) create mode 100644 drivers/gpu/drm/lsdc/Kconfig create mode 100644 drivers/gpu/drm/lsdc/Makefile create mode 100644 drivers/gpu/drm/lsdc/lsdc_crtc.c create mode 100644 drivers/gpu/drm/lsdc/lsdc_debugfs.c create mode 100644 drivers/gpu/drm/lsdc/lsdc_drv.c create mode 100644 drivers/gpu/drm/lsdc/lsdc_drv.h create mode 100644 drivers/gpu/drm/lsdc/lsdc_i2c.c create mode 100644 drivers/gpu/drm/lsdc/lsdc_irq.c create mode 100644 drivers/gpu/drm/lsdc/lsdc_output.c create mode 100644 drivers/gpu/drm/lsdc/lsdc_plane.c create mode 100644 drivers/gpu/drm/lsdc/lsdc_pll.c create mode 100644 drivers/gpu/drm/lsdc/lsdc_pll.h create mode 100644 drivers/gpu/drm/lsdc/lsdc_regs.c create mode 100644 drivers/gpu/drm/lsdc/lsdc_regs.h diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index dc0f94f02a82..3baecd48930b 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -367,6 +367,8 @@ source "drivers/gpu/drm/solomon/Kconfig" source "drivers/gpu/drm/sprd/Kconfig" +source "drivers/gpu/drm/lsdc/Kconfig" + config DRM_HYPERV tristate "DRM Support for Hyper-V synthetic video device" depends on DRM && PCI && MMU && HYPERV diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index ab4460fcd63f..5a8e2fc8dd5d 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -190,3 +190,4 @@ obj-y += gud/ obj-$(CONFIG_DRM_HYPERV) += hyperv/ obj-y += solomon/ obj-$(CONFIG_DRM_SPRD) += sprd/ +obj-$(CONFIG_DRM_LSDC) += lsdc/ diff --git a/drivers/gpu/drm/lsdc/Kconfig b/drivers/gpu/drm/lsdc/Kconfig new file mode 100644 index ..8b9bb6996877 --- /dev/null +++ b/drivers/gpu/drm/lsdc/Kconfig @@ -0,0 +1,17 @@ +# SPDX-License-Identifier: GPL-2.0 + +config DRM_LSDC + tristate "DRM support for loongson display controller" + depends on DRM && PCI && (MACH_LOONGSON64 || LOONGARCH || MIPS) + select OF + select DRM_KMS_HELPER + select DRM_TTM + select DRM_TTM_HELPER + select DRM_VRAM_HELPER + default m + help + This is a KMS driver for loongson display controller in the + LS7A1000/LS7A2000 bridge chip and LS2K1000/LS2K0500 SoC. + If "M" is selected, the module will be called lsdc. + + If in doubt, say "Y". diff --git a/drivers/gpu/drm/lsdc/Makefile b/drivers/gpu/drm/lsdc/Makefile new file mode 100644 index ..d4b901ec09cf --- /dev/null +++ b/drivers/gpu/drm/lsdc/Makefile @@ -0,0 +1,14 @@ +# SPDX-License-Identifier: GPL-2.0 + +lsdc-y := \ + lsdc_drv.o \ + lsdc_crtc.o \ + lsdc_irq.o \ + lsdc_plane.o \ + lsdc_pll.o \ + lsdc_i2c.o \ + lsdc_output.o \ + lsdc_regs.o \ + lsdc_debugfs.o + +obj-$(CONFIG_DRM_LSDC) += lsdc.o diff --git a/drivers/gpu/drm/lsdc/lsdc_crtc.c b/drivers/gpu/drm/lsdc/lsdc_crtc.c new file mode 100644
Re: [PATCH] drm/rockchip: avoid duplicate mappings for IOMMU devices
On Thu, 10 Nov 2022 17:24:14 +, John Keeping wrote: > If a buffer is allocated with alloc_kmap, then it is vmap'd on creation > and there is no reason to map it again in rockchip_gem_prime_vmap() when > the existing mapping can be used. > > Applied, thanks! [1/1] drm/rockchip: avoid duplicate mappings for IOMMU devices commit: 0020d4cfa3eea0e5fad23af49411217da854fc83 Best regards, -- Heiko Stuebner
Re: (subset) [PATCH v3 0/6] drm/rockchip: vop2: add support for the rgb output block
On Tue, 24 Jan 2023 06:47:00 +0100, Michael Riesch wrote:
> This series adds support for the RGB output block that can be found in the
> Rockchip Video Output Processor (VOP) 2. Version 2 of this series
> incorporates the feedback by Dan Carpenter and Sascha Hauer. Version 3
> fixes a dumb mistake pointed out by Sascha :-) Thanks for your comments!
>
> Patches 1-4 clean up the code and make it more general.
>
> [...]
Applied, thanks!
[1/6] drm/rockchip: vop2: initialize possible_crtcs properly
commit: 368419a2d429e2438bef333959732c640310bdc7
[2/6] drm/rockchip: rgb: embed drm_encoder into rockchip_encoder
commit: f8a852f1f86391127ab57b1c41fe0e62bc14f27c
[3/6] drm/rockchip: rgb: add video_port parameter to init function
commit: 03db8f25cf16c579fe75fd2230bbe64c221bfe25
[4/6] drm/rockchip: vop2: use symmetric function pair
vop2_{create,destroy}_crtcs
commit: cc066b056e7bb629a8c4d99c9c4a8ca70a6a
[5/6] drm/rockchip: vop2: add support for the rgb output block
commit: c66c6d7c47058a72a00b50d7f5c4538e3fa49b1c
Best regards,
--
Heiko Stuebner
Re: [PATCH] drm/rockchip: Drop unbalanced obj unref
On Thu, 19 Jan 2023 15:17:34 -0800, Rob Clark wrote: > From: Rob Clark > > In the error path, rockchip_drm_gem_object_mmap() is dropping an obj > reference that it doesn't own. > > Applied, thanks! [1/1] drm/rockchip: Drop unbalanced obj unref commit: 8ee3b0e85f6ccd9e6c527bc50eaba774c3bb18d0 Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: vop: Quiet always-warning AFBC log
On Mon, 31 Oct 2022 10:16:01 -0700, Brian Norris wrote: > The downstream code from which this was derived didn't ever run through > this 'switch' block with non-AFBC formats, but the upstream code does -- > we use this function to probe whether a given format is supported. > > Demote the warning to eliminate this sort of warning seen on every > boot: > > [...] Applied, thanks! [1/1] drm/rockchip: vop: Quiet always-warning AFBC log commit: 582212ee1611f77e0360d249f11c0f703ed723dc Best regards, -- Heiko Stuebner
Re: [PATCH v7 3/6] drm/tidss: Add support for AM625 DSS
On 03-Feb-23 21:03, Tomi Valkeinen wrote: > On 25/01/2023 13:35, Aradhya Bhatia wrote: >> Add support for the DSS controller on TI's new AM625 SoC in the tidss >> driver. >> >> The first video port (VP0) in am625-dss can output OLDI signals through >> 2 OLDI TXes. A 3rd output port has been added with "DISPC_PORT_OLDI" bus >> type. > > Not a big thing here as you add support for a new SoC, but the ordering > of the patches is not optimal. Here you add the AM625 DSS support, but > then you continue actually adding the DSS support (well, mainly OLDI) in > the following patches. > > I think patch 6 could be before this patch. Parts of patch 4 could also > be before this patch. The AM65X renames from patch 5 could be before > this patch. I can move whole of Patch 6 and even of Patch 4 before this one. I have mentioned 'AM625-DSS' in a couple comments which I can make generic, and the rest everything is SoC-agnostic. I haven't tried this, but my concern is if we break patch 5 into 2 separate patches, i. AM65X rename plus SoC based switch case, and ii. Addition of AM625 SoC case then I might have to overwrite some changes implemented during (i) in (ii). I don't suppose that would be okay, would it? Also, is it important to keep the compatible-addition patches of DT-binding and driver next to each other in the series? Or should the DT-binding patches should be the first ones? Just curious! =) > > I'm mainly thinking of a case where someone uses AM625 and is bisecting > a problem. What happens if his board uses OLDI, and he happens to hit > one of these patches during bisect? If the display just stays black, but > otherwise everything works fine, then no problem. But if it crashes or > starts spamming sync losts or such or gives errors, it's not so nice. > You are right! This certainly makes sense. Regards Aradhya
Re: [PATCH AUTOSEL 5.15 12/12] amdgpu: fix build on non-DCN platforms.
On Tue, Jan 31, 2023 at 03:29:04PM -0500, Alex Deucher wrote: On Tue, Jan 31, 2023 at 10:01 AM Sasha Levin wrote: From: Dave Airlie [ Upstream commit f439a959dcfb6b39d6fd4b85ca1110a1d1de1587 ] This fixes the build here locally on my 32-bit arm build. Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin This patch is only applicable to kernel 6.1 and newer. Ack, I'll drop it on older kernels, thanks! -- Thanks, Sasha
Re: [PATCH v6 01/17] dt-bindings: display: rockchip: convert rockchip-lvds.txt to YAML
Hi, Am Freitag, 3. Februar 2023, 20:02:54 CET schrieb Johan Jonker: > > On 2/3/23 19:21, Rob Herring wrote: > > On Thu, Dec 22, 2022 at 03:22:14PM +0100, Johan Jonker wrote: > >> Convert rockchip-lvds.txt to YAML. > >> > >> Changed: > >> Add power-domains property. > >> Requirements between PX30 and RK3288 > >> > >> Signed-off-by: Johan Jonker > >> Reviewed-by: Rob Herring > >> --- > >> > >> Changed V3: > >> Filename matching compatible style > >> Drop "Regulator phandle for " > >> Specify properties and requirements per SoC > >> Sort order and restyle > >> > >> Changed V2: > >> Fix title > >> --- > >> .../display/rockchip/rockchip,lvds.yaml | 170 ++ > >> .../display/rockchip/rockchip-lvds.txt| 92 -- > >> 2 files changed, 170 insertions(+), 92 deletions(-) > >> create mode 100644 > >> Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml > >> delete mode 100644 > >> Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt > > > > > What's the plan for these patches? Don't see them in linux-next still. > > Do you want me to take patches 1-8? > > Hi, > > The display patches normally go through the DRM git. > Patch 2 must merge with grf.yaml. > Heiko has merged now 3 PHY related patches to grf.yaml first. > > [PATCH v6 02/17] dt-bindings: soc: rockchip: grf: add rockchip,lvds.yaml > > See current > https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/log/?h=for-next=grep=jonker > > Not sure what Heiko's plans are. > Patch 2 replaces only a description text and some accolades removal, so not > "too" important. > > I urgent then you could merge without conflict: > 1, 3-8 So I've applied patches 1-7 to the drm-tree now. For the GRF-patch, I've dropped the quotes changes, as they are somewhat unrelated to the lvds inclusion and so prevented any conflicts when applying the rest to the DRM tree. @Rob, if you could pick the fusb302 patch (number8), that would be great Thanks Heiko
Re: (subset) [PATCH v6 01/17] dt-bindings: display: rockchip: convert rockchip-lvds.txt to YAML
On Thu, 22 Dec 2022 15:22:14 +0100, Johan Jonker wrote: > Convert rockchip-lvds.txt to YAML. > > Changed: > Add power-domains property. > Requirements between PX30 and RK3288 > > > [...] Applied, thanks! [01/17] dt-bindings: display: rockchip: convert rockchip-lvds.txt to YAML commit: d567ca6ed9fd5fe594bca5e29717ff9e9631efba [02/17] dt-bindings: soc: rockchip: grf: add rockchip,lvds.yaml commit: cbfc73a3febdf14395ecdd738decd5383512 [03/17] dt-bindings: display: dsi-controller: move clock-master property commit: a1b7455dc4a399a565353ceb7cce605b4b9db41a [04/17] dt-bindings: display: bridge: snps,dw-mipi-dsi: fix clock properties commit: a90fa0adbeb07f11c08635364d206678d9e1b938 [05/17] dt-bindings: display: rockchip: convert dw_mipi_dsi_rockchip.txt to yaml commit: 0dac2102cf6baacba0d9d7804b0c163337f69839 [06/17] dt-bindings: display: bridge: convert analogix_dp.txt to yaml commit: 440112adadd3e273d2a2ff6e5d4b969ee03fda47 [07/17] dt-bindings: display: rockchip: convert analogix_dp-rockchip.txt to yaml commit: 9bb35d4c3230803345d5218676a7325b26823209 Best regards, -- Heiko Stuebner
Re: [PATCH v7 5/6] drm/tidss: Add IO CTRL and Power support for OLDI TX in am625
On 03-Feb-23 20:49, Tomi Valkeinen wrote:
> On 25/01/2023 13:35, Aradhya Bhatia wrote:
>> The ctrl mmr module of the AM625 is different from the AM65X SoC. Thus
>> the ctrl mmr registers that supported the OLDI TX power have become
>> different in AM625 SoC.
>>
>> The common mode voltage of the LVDS buffers becomes random when the
>> bandgap reference is turned off. This causes uncertainity in the LVDS
>> Data and Clock signal outputs, making it behave differently under
>> different conditions and panel setups. The bandgap reference must be
>> powered on before using the OLDI IOs, to keep the common voltage trimmed
>> down to desired levels.
>>
>> Add support to enable/disable OLDI IO signals as well as the bandgap
>> reference circuit for the LVDS signals.
>>
>> Signed-off-by: Aradhya Bhatia
>> ---
>>
>> Note:
>> - Dropped Tomi Valkeinen's reviewed-by tag in this patch because I did
>> not implement one of his comments which suggested to remove the
>> 'oldi_supported' variable. While the oldi support is indeed based on
>> SoC variations, keeping that variable helps take into account the case
>> where an OLDI supporting SoC by-passes OLDI TXes and gives out DPI
>> video signals straight from DSS.
>
> Hmm why is that relevent for this patch? It doesn't use oldi_supported
> or the new has_oldi.
It doesn't. Not directly atleast. In the previous version of this patch,
there was a mention of 'oldi_supported' and your tag was conditional to
that variable getting removed. Instead, I renamed the variable.
>
>> drivers/gpu/drm/tidss/tidss_dispc.c | 57 +++-
>> drivers/gpu/drm/tidss/tidss_dispc_regs.h | 40 -
>> 2 files changed, 76 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
>> b/drivers/gpu/drm/tidss/tidss_dispc.c
>> index 37a73e309330..0e03557bc142 100644
>> --- a/drivers/gpu/drm/tidss/tidss_dispc.c
>> +++ b/drivers/gpu/drm/tidss/tidss_dispc.c
>> @@ -934,21 +934,56 @@ int dispc_vp_bus_check(struct dispc_device *dispc, u32
>> hw_videoport,
>> static void dispc_oldi_tx_power(struct dispc_device *dispc, bool power)
>> {
>> - u32 val = power ? 0 : OLDI_PWRDN_TX;
>> + u32 val;
>> if (WARN_ON(!dispc->oldi_io_ctrl))
>> return;
>> - regmap_update_bits(dispc->oldi_io_ctrl, OLDI_DAT0_IO_CTRL,
>> - OLDI_PWRDN_TX, val);
>> - regmap_update_bits(dispc->oldi_io_ctrl, OLDI_DAT1_IO_CTRL,
>> - OLDI_PWRDN_TX, val);
>> - regmap_update_bits(dispc->oldi_io_ctrl, OLDI_DAT2_IO_CTRL,
>> - OLDI_PWRDN_TX, val);
>> - regmap_update_bits(dispc->oldi_io_ctrl, OLDI_DAT3_IO_CTRL,
>> - OLDI_PWRDN_TX, val);
>> - regmap_update_bits(dispc->oldi_io_ctrl, OLDI_CLK_IO_CTRL,
>> - OLDI_PWRDN_TX, val);
>> + if (dispc->feat->subrev == DISPC_AM65X) {
>
> Slight nitpick, but I think switch-case makes sense for the subrev. Even
> if there are just two options here, using switch makes the structure clearer.
Alright. I will make the edit.
>
>> + val = power ? 0 : AM65X_OLDI_PWRDN_TX;
>> +
>> + regmap_update_bits(dispc->oldi_io_ctrl, AM65X_OLDI_DAT0_IO_CTRL,
>> + AM65X_OLDI_PWRDN_TX, val);
>> + regmap_update_bits(dispc->oldi_io_ctrl, AM65X_OLDI_DAT1_IO_CTRL,
>> + AM65X_OLDI_PWRDN_TX, val);
>> + regmap_update_bits(dispc->oldi_io_ctrl, AM65X_OLDI_DAT2_IO_CTRL,
>> + AM65X_OLDI_PWRDN_TX, val);
>> + regmap_update_bits(dispc->oldi_io_ctrl, AM65X_OLDI_DAT3_IO_CTRL,
>> + AM65X_OLDI_PWRDN_TX, val);
>> + regmap_update_bits(dispc->oldi_io_ctrl, AM65X_OLDI_CLK_IO_CTRL,
>> + AM65X_OLDI_PWRDN_TX, val);
>> +
>> + } else if (dispc->feat->subrev == DISPC_AM625) {
>> + if (power) {
>> + switch (dispc->oldi_mode) {
>> + case OLDI_MODE_SINGLE_LINK:
>> + /* Power down OLDI TX 1 */
>> + val = AM625_OLDI1_PWRDN_TX;
>> + break;
>> +
>> + case OLDI_MODE_CLONE_SINGLE_LINK:
>> + case OLDI_MODE_DUAL_LINK:
>> + /* No Power down */
>> + val = 0;
>> + break;
>> +
>> + default:
>> + /* Power down both OLDI TXes and LVDS Bandgap */
>> + val = AM625_OLDI0_PWRDN_TX | AM625_OLDI1_PWRDN_TX |
>> + AM625_OLDI_PWRDN_BG;
>> + break;
>> + }
>> +
>> + } else {
>> + /* Power down both OLDI TXes and LVDS Bandgap */
>> + val = AM625_OLDI0_PWRDN_TX | AM625_OLDI1_PWRDN_TX |
>> + AM625_OLDI_PWRDN_BG;
>> + }
>> +
>> + regmap_update_bits(dispc->oldi_io_ctrl, AM625_OLDI_PD_CTRL,
>> + AM625_OLDI0_PWRDN_TX | AM625_OLDI1_PWRDN_TX |
>> + AM625_OLDI_PWRDN_BG, val);
>> + }
>> }
>> static void dispc_set_num_datalines(struct
Re: [PATCH v7 4/6] drm/tidss: Add support to configure OLDI mode for am625-dss
Hi Tomi,
On 03-Feb-23 20:42, Tomi Valkeinen wrote:
> On 25/01/2023 13:35, Aradhya Bhatia wrote:
>> The newer version of DSS (AM625-DSS) has 2 OLDI TXes at its disposal.
>> These can be configured to support the following modes:
>>
>> 1. OLDI_SINGLE_LINK_SINGLE_MODE
>> Single Output over OLDI 0.
>> +--+ +-+ +---+
>> | | | | | |
>> | CRTC +--->+ ENCODER +->| PANEL |
>> | | | | | |
>> +--+ +-+ +---+
>>
>> 2. OLDI_SINGLE_LINK_CLONE_MODE
>> Duplicate Output over OLDI 0 and 1.
>> +--+ +-+ +---+
>> | | | | | |
>> | CRTC +---+--->| ENCODER +->| PANEL |
>> | | | | | | |
>> +--+ | +-+ +---+
>> |
>> | +-+ +---+
>> | | | | |
>> +--->| ENCODER +->| PANEL |
>> | | | |
>> +-+ +---+
>>
>> 3. OLDI_DUAL_LINK_MODE
>> Combined Output over OLDI 0 and 1.
>> +--+ +-+ +---+
>> | | | +->| |
>> | CRTC +--->+ ENCODER | | PANEL |
>> | | | +->| |
>> +--+ +-+ +---+
>>
>> Following the above pathways for different modes, 2 encoder/panel-bridge
>> pipes get created for clone mode, and 1 pipe in cases of single link and
>> dual link mode.
>>
>> Add support for confguring the OLDI modes using OF and LVDS DRM helper
>> functions.
>>
>> Signed-off-by: Aradhya Bhatia
>> ---
>> drivers/gpu/drm/tidss/tidss_dispc.c | 24 ++-
>> drivers/gpu/drm/tidss/tidss_dispc.h | 12 ++
>> drivers/gpu/drm/tidss/tidss_drv.h | 3 +
>> drivers/gpu/drm/tidss/tidss_encoder.c | 4 +-
>> drivers/gpu/drm/tidss/tidss_encoder.h | 3 +-
>> drivers/gpu/drm/tidss/tidss_kms.c | 221 --
>> 6 files changed, 245 insertions(+), 22 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
>> b/drivers/gpu/drm/tidss/tidss_dispc.c
>> index b55ccbcaa67f..37a73e309330 100644
>> --- a/drivers/gpu/drm/tidss/tidss_dispc.c
>> +++ b/drivers/gpu/drm/tidss/tidss_dispc.c
>> @@ -88,6 +88,8 @@ const struct dispc_features dispc_k2g_feats = {
>> .subrev = DISPC_K2G,
>> + .has_oldi = false,
>> +
>> .common = "common",
>> .common_regs = tidss_k2g_common_regs,
>> @@ -166,6 +168,8 @@ const struct dispc_features dispc_am625_feats = {
>> .subrev = DISPC_AM625,
>> + .has_oldi = true,
>> +
>> .common = "common",
>> .common_regs = tidss_am65x_common_regs,
>> @@ -218,6 +222,8 @@ const struct dispc_features dispc_am65x_feats = {
>> .subrev = DISPC_AM65X,
>> + .has_oldi = true,
>> +
>> .common = "common",
>> .common_regs = tidss_am65x_common_regs,
>> @@ -309,6 +315,8 @@ const struct dispc_features dispc_j721e_feats = {
>> .subrev = DISPC_J721E,
>> + .has_oldi = false,
>> +
>> .common = "common_m",
>> .common_regs = tidss_j721e_common_regs,
>> @@ -361,6 +369,8 @@ struct dispc_device {
>> struct dss_vp_data vp_data[TIDSS_MAX_VPS];
>> + enum dispc_oldi_modes oldi_mode;
>> +
>> u32 *fourccs;
>> u32 num_fourccs;
>> @@ -1963,6 +1973,12 @@ const u32 *dispc_plane_formats(struct dispc_device
>> *dispc, unsigned int *len)
>> return dispc->fourccs;
>> }
>> +void dispc_set_oldi_mode(struct dispc_device *dispc,
>> + enum dispc_oldi_modes oldi_mode)
>> +{
>> + dispc->oldi_mode = oldi_mode;
>> +}
>> +
>> static s32 pixinc(int pixels, u8 ps)
>> {
>> if (pixels == 1)
>> @@ -2647,7 +2663,7 @@ int dispc_runtime_resume(struct dispc_device *dispc)
>> REG_GET(dispc, DSS_SYSSTATUS, 2, 2),
>> REG_GET(dispc, DSS_SYSSTATUS, 3, 3));
>> - if (dispc->feat->subrev == DISPC_AM65X)
>> + if (dispc->feat->has_oldi)
>> dev_dbg(dispc->dev, "OLDI RESETDONE %d,%d,%d\n",
>> REG_GET(dispc, DSS_SYSSTATUS, 5, 5),
>> REG_GET(dispc, DSS_SYSSTATUS, 6, 6),
>> @@ -2688,7 +2704,7 @@ static int dispc_iomap_resource(struct platform_device
>> *pdev, const char *name,
>> return 0;
>> }
>> -static int dispc_init_am65x_oldi_io_ctrl(struct device *dev,
>> +static int dispc_init_am6xx_oldi_io_ctrl(struct device *dev,
>> struct dispc_device *dispc)
>> {
>> dispc->oldi_io_ctrl =
>> @@ -2827,8 +2843,8 @@ int dispc_init(struct tidss_device *tidss)
>> dispc->vp_data[i].gamma_table = gamma_table;
>> }
>> - if (feat->subrev == DISPC_AM65X) {
>> - r = dispc_init_am65x_oldi_io_ctrl(dev, dispc);
>> + if (feat->has_oldi) {
>> + r = dispc_init_am6xx_oldi_io_ctrl(dev, dispc);
>> if (r)
>> return r;
>> }
>> diff --git
Re: [PATCH v7 1/6] drm/tidss: Remove Video Port to Output Port coupling
Hi Tomi,
Thanks for the review!
On 03-Feb-23 16:53, Tomi Valkeinen wrote:
> On 25/01/2023 13:35, Aradhya Bhatia wrote:
>> Make DSS Video Ports agnostic of output bus types.
>>
>> DSS controllers have had a 1-to-1 coupling between its VPs and its
>> output ports. This no longer stands true for the new AM625 DSS. This
>> coupling, hence, has been removed by renaming the 'vp_bus_type' to
>> 'output_port_bus_type' because the VPs are essentially agnostic of the
>> bus type and it is the output ports which have a bus type.
>>
>> The AM625 DSS has 2 VPs but requires 3 output ports to support its
>> Dual-Link OLDI video output coming from a single VP.
>
> Not a biggie, but this sentence is a bit odd here at the end. Shouldn't
> it be after the "...stands true for the new AM625 DSS."?
Yes! It should be. Will make the edit.
>
>> Signed-off-by: Aradhya Bhatia
>> ---
>> drivers/gpu/drm/tidss/tidss_dispc.c | 47 +
>> drivers/gpu/drm/tidss/tidss_dispc.h | 21 +++--
>> drivers/gpu/drm/tidss/tidss_drv.h | 5 +--
>> drivers/gpu/drm/tidss/tidss_irq.h | 2 +-
>> drivers/gpu/drm/tidss/tidss_kms.c | 12
>> 5 files changed, 48 insertions(+), 39 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
>> b/drivers/gpu/drm/tidss/tidss_dispc.c
>> index 165365b515e1..c1c4faccbddc 100644
>> --- a/drivers/gpu/drm/tidss/tidss_dispc.c
>> +++ b/drivers/gpu/drm/tidss/tidss_dispc.c
>> @@ -61,7 +61,7 @@ const struct dispc_features dispc_k2g_feats = {
>> .min_pclk_khz = 4375,
>> .max_pclk_khz = {
>> - [DISPC_VP_DPI] = 15,
>> + [DISPC_PORT_DPI] = 15,
>> },
>> /*
>> @@ -96,7 +96,6 @@ const struct dispc_features dispc_k2g_feats = {
>> .vp_name = { "vp1" },
>> .ovr_name = { "ovr1" },
>> .vpclk_name = { "vp1" },
>> - .vp_bus_type = { DISPC_VP_DPI },
>> .vp_feat = { .color = {
>> .has_ctm = true,
>> @@ -109,6 +108,9 @@ const struct dispc_features dispc_k2g_feats = {
>> .vid_name = { "vid1" },
>> .vid_lite = { false },
>> .vid_order = { 0 },
>> +
>> + .num_output_ports = 1,
>> + .output_port_bus_type = { DISPC_PORT_DPI },
>> };
>
> Just thinking out loud, as these will get more complex in the future,
> maybe we should finally group them with struct. E.g. we could define
> struct array for vps, like (just hacky example):
>
> struct {
> const char *name;
> const char *clkname;
> struct tidss_vp_feat feat;
> } vps[TIDSS_MAX_PORTS];
>
> and then use them as:
>
> .vps = {
> {
> .name = "kala",
> .clkname = "kissa",
> .feat.color.has_ctm = true,
> }, {
> .name = "kala2",
> .clkname = "kissa2",
> .feat.color.has_ctm = false,
> },
> },
>
> Perhaps something to try in the future.
>
Yes, agreed! Having that structure will tidy this up.
I will keep this under future work.
>> static const u16 tidss_am65x_common_regs[DISPC_COMMON_REG_TABLE_LEN] = {
>> @@ -140,8 +142,8 @@ static const u16
>> tidss_am65x_common_regs[DISPC_COMMON_REG_TABLE_LEN] = {
>> const struct dispc_features dispc_am65x_feats = {
>> .max_pclk_khz = {
>> - [DISPC_VP_DPI] = 165000,
>> - [DISPC_VP_OLDI] = 165000,
>> + [DISPC_PORT_DPI] = 165000,
>> + [DISPC_PORT_OLDI] = 165000,
>> },
>> .scaling = {
>> @@ -171,7 +173,6 @@ const struct dispc_features dispc_am65x_feats = {
>> .vp_name = { "vp1", "vp2" },
>> .ovr_name = { "ovr1", "ovr2" },
>> .vpclk_name = { "vp1", "vp2" },
>> - .vp_bus_type = { DISPC_VP_OLDI, DISPC_VP_DPI },
>> .vp_feat = { .color = {
>> .has_ctm = true,
>> @@ -185,6 +186,9 @@ const struct dispc_features dispc_am65x_feats = {
>> .vid_name = { "vid", "vidl1" },
>> .vid_lite = { false, true, },
>> .vid_order = { 1, 0 },
>> +
>> + .num_output_ports = 2,
>> + .output_port_bus_type = { DISPC_PORT_OLDI, DISPC_PORT_DPI },
>> };
>> static const u16 tidss_j721e_common_regs[DISPC_COMMON_REG_TABLE_LEN] = {
>> @@ -229,8 +233,8 @@ static const u16
>> tidss_j721e_common_regs[DISPC_COMMON_REG_TABLE_LEN] = {
>> const struct dispc_features dispc_j721e_feats = {
>> .max_pclk_khz = {
>> - [DISPC_VP_DPI] = 17,
>> - [DISPC_VP_INTERNAL] = 60,
>> + [DISPC_PORT_DPI] = 17,
>> + [DISPC_PORT_INTERNAL] = 60,
>> },
>> .scaling = {
>> @@ -260,9 +264,7 @@ const struct dispc_features dispc_j721e_feats = {
>> .vp_name = { "vp1", "vp2", "vp3", "vp4" },
>> .ovr_name = { "ovr1", "ovr2", "ovr3", "ovr4" },
>> .vpclk_name = { "vp1", "vp2", "vp3", "vp4" },
>> - /* Currently hard coded VP routing (see dispc_initial_config()) */
>> - .vp_bus_type = { DISPC_VP_INTERNAL, DISPC_VP_DPI,
>> - DISPC_VP_INTERNAL, DISPC_VP_DPI, },
>> +
>
> I think this line
[PATCH] drm/shmem-helper: Fix locking for drm_gem_shmem_get_pages_sgt()
Other functions touching shmem->sgt take the pages lock, so do that here
too. drm_gem_shmem_get_pages() & co take the same lock, so move to the
_locked() variants to avoid recursive locking.
Discovered while auditing locking to write the Rust abstractions.
Fixes: 2194a63a818d ("drm: Add library for shmem backed GEM objects")
Fixes: 4fa3d66f132b ("drm/shmem: Do dma_unmap_sg before purging pages")
Signed-off-by: Asahi Lina
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 54 --
1 file changed, 34 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index b602cd72a120..2c559b310cad 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -681,23 +681,7 @@ struct sg_table *drm_gem_shmem_get_sg_table(struct
drm_gem_shmem_object *shmem)
}
EXPORT_SYMBOL_GPL(drm_gem_shmem_get_sg_table);
-/**
- * drm_gem_shmem_get_pages_sgt - Pin pages, dma map them, and return a
- * scatter/gather table for a shmem GEM object.
- * @shmem: shmem GEM object
- *
- * This function returns a scatter/gather table suitable for driver usage. If
- * the sg table doesn't exist, the pages are pinned, dma-mapped, and a sg
- * table created.
- *
- * This is the main function for drivers to get at backing storage, and it
hides
- * and difference between dma-buf imported and natively allocated objects.
- * drm_gem_shmem_get_sg_table() should not be directly called by drivers.
- *
- * Returns:
- * A pointer to the scatter/gather table of pinned pages or errno on failure.
- */
-struct sg_table *drm_gem_shmem_get_pages_sgt(struct drm_gem_shmem_object
*shmem)
+static struct sg_table *drm_gem_shmem_get_pages_sgt_locked(struct
drm_gem_shmem_object *shmem)
{
struct drm_gem_object *obj = >base;
int ret;
@@ -708,7 +692,7 @@ struct sg_table *drm_gem_shmem_get_pages_sgt(struct
drm_gem_shmem_object *shmem)
WARN_ON(obj->import_attach);
- ret = drm_gem_shmem_get_pages(shmem);
+ ret = drm_gem_shmem_get_pages_locked(shmem);
if (ret)
return ERR_PTR(ret);
@@ -730,10 +714,40 @@ struct sg_table *drm_gem_shmem_get_pages_sgt(struct
drm_gem_shmem_object *shmem)
sg_free_table(sgt);
kfree(sgt);
err_put_pages:
- drm_gem_shmem_put_pages(shmem);
+ drm_gem_shmem_put_pages_locked(shmem);
return ERR_PTR(ret);
}
-EXPORT_SYMBOL_GPL(drm_gem_shmem_get_pages_sgt);
+
+/**
+ * drm_gem_shmem_get_pages_sgt - Pin pages, dma map them, and return a
+ * scatter/gather table for a shmem GEM object.
+ * @shmem: shmem GEM object
+ *
+ * This function returns a scatter/gather table suitable for driver usage. If
+ * the sg table doesn't exist, the pages are pinned, dma-mapped, and a sg
+ * table created.
+ *
+ * This is the main function for drivers to get at backing storage, and it
hides
+ * and difference between dma-buf imported and natively allocated objects.
+ * drm_gem_shmem_get_sg_table() should not be directly called by drivers.
+ *
+ * Returns:
+ * A pointer to the scatter/gather table of pinned pages or errno on failure.
+ */
+struct sg_table *drm_gem_shmem_get_pages_sgt(struct drm_gem_shmem_object
*shmem)
+{
+ int ret;
+ struct sg_table *sgt;
+
+ ret = mutex_lock_interruptible(>pages_lock);
+ if (ret)
+ return ERR_PTR(ret);
+ sgt = drm_gem_shmem_get_pages_sgt_locked(shmem);
+ mutex_unlock(>pages_lock);
+
+ return sgt;
+}
+EXPORT_SYMBOL(drm_gem_shmem_get_pages_sgt);
/**
* drm_gem_shmem_prime_import_sg_table - Produce a shmem GEM object from
--
2.35.1
[GIT PULL] fbdev fixes for v6.2-rc7
Hi Linus, please pull the latest fbdev fixes for 6.2-rc7, which - fix fbcon to prevent fonts bigger than 32x32 pixels to avoid overflows reported by syzbot, - switch omapfb to use kstrtobool(), and - switch some fbdev drivers to use the backlight helpers Thanks, Helge --- The following changes since commit b7bfaa761d760e72a969d116517eaa12e404c262: Linux 6.2-rc3 (2023-01-08 11:49:43 -0600) are available in the Git repository at: http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git tags/fbdev-for-6.2-rc7 for you to fetch changes up to 2b09d5d364986f724f17001ccfe4126b9b43a0be: fbcon: Check font dimension limits (2023-02-04 14:29:19 +0100) fbdev updates for kernel 6.2-rc7: - Check font size in fbcon, reported by UBSAN and syzbot - Use backlight helpers in various fbdev drivers Christophe JAILLET (1): fbdev: omapfb: Use kstrtobool() instead of strtobool() Randy Dunlap (1): fbdev: fbmon: fix function name in kernel-doc Samuel Thibault (1): fbcon: Check font dimension limits Stephen Kitt (8): fbdev: aty128fb: Use backlight helper fbdev: atyfb: Use backlight helper fbdev: radeon: Use backlight helper fbdev: mx3fb: Use backlight helper fbdev: nvidia: Use backlight helper fbdev: omapfb: panel-dsi-cm: Use backlight helper fbdev: riva: Use backlight helper fbdev: atmel_lcdfb: Rework backlight status updates drivers/video/fbdev/atmel_lcdfb.c | 22 +- drivers/video/fbdev/aty/aty128fb.c | 6 ++ drivers/video/fbdev/aty/atyfb_base.c | 8 +--- drivers/video/fbdev/aty/radeon_backlight.c | 6 +- drivers/video/fbdev/core/fbcon.c | 7 +-- drivers/video/fbdev/core/fbmon.c | 2 +- drivers/video/fbdev/mx3fb.c| 7 +-- drivers/video/fbdev/nvidia/nv_backlight.c | 8 +--- .../fbdev/omap2/omapfb/displays/panel-dsi-cm.c | 8 +--- .../video/fbdev/omap2/omapfb/dss/display-sysfs.c | 7 --- .../video/fbdev/omap2/omapfb/dss/manager-sysfs.c | 7 --- .../video/fbdev/omap2/omapfb/dss/overlay-sysfs.c | 3 ++- drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c| 3 ++- drivers/video/fbdev/riva/fbdev.c | 8 +--- 14 files changed, 27 insertions(+), 75 deletions(-)
