Re: [RFT PATCH v2 01/48] drm/panel: raydium-rm692e5: Stop tracking prepared
On Fri May 3, 2024 at 11:32 PM CEST, Douglas Anderson wrote:
> As talked about in commit d2aacaf07395 ("drm/panel: Check for already
> prepared/enabled in drm_panel"), we want to remove needless code from
> panel drivers that was storing and double-checking the
> prepared/enabled state. Even if someone was relying on the
> double-check before, that double-check is now in the core and not
> needed in individual drivers.
>
> Cc: Luca Weiss
> Cc: Konrad Dybcio
> Signed-off-by: Douglas Anderson
Seems to match with the changes I did for another (generated) panel
driver I upstreamed - see also:
https://github.com/msm8916-mainline/linux-mdss-dsi-panel-driver-generator/commit/74c104440dfd828aa94194fd279c0c505ab55854
Functionally also seems to be fine, I don't see any problems. Thanks!
Tested-by: Luca Weiss
Regards
Luca
> ---
>
> Changes in v2:
> - New
>
> drivers/gpu/drm/panel/panel-raydium-rm692e5.c | 10 --
> 1 file changed, 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-raydium-rm692e5.c
> b/drivers/gpu/drm/panel/panel-raydium-rm692e5.c
> index a613ba5b816c..21d97f6b8a2f 100644
> --- a/drivers/gpu/drm/panel/panel-raydium-rm692e5.c
> +++ b/drivers/gpu/drm/panel/panel-raydium-rm692e5.c
> @@ -23,7 +23,6 @@ struct rm692e5_panel {
> struct drm_dsc_config dsc;
> struct regulator_bulk_data supplies[3];
> struct gpio_desc *reset_gpio;
> - bool prepared;
> };
>
> static inline struct rm692e5_panel *to_rm692e5_panel(struct drm_panel *panel)
> @@ -171,9 +170,6 @@ static int rm692e5_prepare(struct drm_panel *panel)
> struct device *dev = >dsi->dev;
> int ret;
>
> - if (ctx->prepared)
> - return 0;
> -
> ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> if (ret < 0) {
> dev_err(dev, "Failed to enable regulators: %d\n", ret);
> @@ -213,8 +209,6 @@ static int rm692e5_prepare(struct drm_panel *panel)
>
> mipi_dsi_generic_write_seq(ctx->dsi, 0xfe, 0x00);
>
> - ctx->prepared = true;
> -
> return 0;
> }
>
> @@ -222,13 +216,9 @@ static int rm692e5_unprepare(struct drm_panel *panel)
> {
> struct rm692e5_panel *ctx = to_rm692e5_panel(panel);
>
> - if (!ctx->prepared)
> - return 0;
> -
> gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
>
> - ctx->prepared = false;
> return 0;
> }
>
Re: [PATCH] drm/msm/dpu: fix vblank IRQ handling for command panels
On Sun Apr 7, 2024 at 5:15 AM CEST, Dmitry Baryshkov wrote:
> On Sat, 30 Mar 2024 at 18:49, Marijn Suijten
> wrote:
> >
> > On 2024-03-30 05:52:29, Dmitry Baryshkov wrote:
> > > In case of CMD DSI panels, the vblank IRQ can be used outside of
> > > irq_enable/irq_disable pair. This results in the following kind of
> >
> > Can you clarify when exactly that is? Is it via ops.control_vblank_irq in
> > dpu_encoder_toggle_vblank_for_crtc()?
>
> Call trace:
> dpu_encoder_phys_cmd_control_vblank_irq+0x218/0x294
> dpu_encoder_toggle_vblank_for_crtc+0x160/0x194
> dpu_crtc_vblank+0xbc/0x228
> dpu_kms_enable_vblank+0x18/0x24
> vblank_ctrl_worker+0x34/0x6c
> process_one_work+0x218/0x620
> worker_thread+0x1ac/0x37c
> kthread+0x114/0x118
> ret_from_fork+0x10/0x20
>
> The vblank_ctrl_work happens when the framework attempts to trigger
> the vblank on the CRTC.
>
> >
> > > messages. Move assignment of IRQ indices to atomic_enable /
> > > atomic_disable callbacks.
> > >
> > > [dpu error]invalid IRQ=[134217727, 31]
> > > [drm:dpu_encoder_phys_cmd_control_vblank_irq] *ERROR* vblank irq err
> > > id:31 pp:0 ret:-22, enable true/0
> > > [drm:dpu_encoder_phys_cmd_control_vblank_irq] *ERROR* vblank irq err
> > > id:31 pp:0 ret:-22, enable false/0
> >
> > You are right that such messages are common, both at random but also
> > seemingly
> > around toggling the `ACTIVE` property on the CRTC:
> >
> > [ 45.878300] panel-samsung-souxp ae94000.dsi.0:
> > samsung_souxp00_disable
> > [ 45.909941] panel-samsung-souxp ae94000.dsi.0:
> > samsung_souxp00_unprepare
> > [ 46.093234] [drm:dpu_encoder_helper_wait_for_irq] *ERROR*
> > encoder is disabled id=31, callback=dpu_encoder_phys_cmd_ctl_start_irq,
> > IRQ=[134217727, 31]
> > [ 46.130421] panel-samsung-souxp ae94000.dsi.0:
> > samsung_souxp00_prepare
> > [ 46.340457] panel-samsung-souxp ae94000.dsi.0:
> > samsung_souxp00_enable
> > [ 65.520323] [dpu error]invalid IRQ=[134217727, 31]
> > irq_cb:dpu_encoder_phys_cmd_te_rd_ptr_irq
> > [ 65.520463] [drm:dpu_encoder_phys_cmd_control_vblank_irq]
> > *ERROR* vblank irq err id:31 pp:0 ret:-22, enable true/0
> > [ 65.630199] [drm:dpu_encoder_phys_cmd_control_vblank_irq]
> > *ERROR* vblank irq err id:31 pp:0 ret:-22, enable false/0
> > [ 166.576465] panel-samsung-souxp ae94000.dsi.0:
> > samsung_souxp00_disable
> > [ 166.609674] panel-samsung-souxp ae94000.dsi.0:
> > samsung_souxp00_unprepare
> > [ 166.781967] [drm:dpu_encoder_helper_wait_for_irq] *ERROR*
> > encoder is disabled id=31, callback=dpu_encoder_phys_cmd_ctl_start_irq,
> > IRQ=[134217727, 31]
> > [ 166.829805] panel-samsung-souxp ae94000.dsi.0:
> > samsung_souxp00_prepare
> > [ 167.040476] panel-samsung-souxp ae94000.dsi.0:
> > samsung_souxp00_enable
> > [ 337.449827] [dpu error]invalid IRQ=[134217727, 31]
> > irq_cb:dpu_encoder_phys_cmd_te_rd_ptr_irq
> > [ 337.450434] [drm:dpu_encoder_phys_cmd_control_vblank_irq]
> > *ERROR* vblank irq err id:31 pp:0 ret:-22, enable true/0
> > [ 337.569526] [drm:dpu_encoder_phys_cmd_control_vblank_irq]
> > *ERROR* vblank irq err id:31 pp:0 ret:-22, enable false/0
> > [ 354.980357] [dpu error]invalid IRQ=[134217727, 31]
> > irq_cb:dpu_encoder_phys_cmd_te_rd_ptr_irq
> > [ 354.980495] [drm:dpu_encoder_phys_cmd_control_vblank_irq]
> > *ERROR* vblank irq err id:31 pp:0 ret:-22, enable true/0
> > [ 355.090460] [drm:dpu_encoder_phys_cmd_control_vblank_irq]
> > *ERROR* vblank irq err id:31 pp:0 ret:-22, enable false/0
> >
> > Unfortunately with this patch, turning the CRTC off via ./modetest -M msm -a
> > -w 81:ACTIVE:0 immediately triggers a bunch of WARNs (note that the CRTC
> > turns
> > on immediately again when the command returns, that's probably the
> > framebuffer
> > console taking over again). Running it a few times in succession this may
> > or
> > may not happen, or reboot the phone (Xperia Griffin) entirely:
>
> I could not reproduce it here, on Pixel-3. I'd like to review vblank
> IRQs later. For now I think it is easier to revert d13f638c9b88
> ("drm/msm/dpu: drop dpu_encoder_phys_ops.atomic_mode_set"). I'll send
> a patch.
Hi,
Did anything happen regarding this, I'm not finding anything on the
lists?
I'm seeing these errors also on SC7280/QCM6490 Fairphone 5 phone with
kernel 6.9-rc6 (+ out of tree patches).
[ 77.073366] [dpu error]invalid IRQ=[134217727, 31]
irq_cb:dpu_encoder_phys_cmd_te_rd_ptr_irq
[ 77.073391] [drm:dpu_encoder_phys_cmd_control_vblank_irq] *ERROR* vblank irq
err id:31 pp:0 ret:-22, enable true/0
[ 79.214720] [drm:dpu_encoder_phys_cmd_control_vblank_irq] *ERROR* vblank irq
err id:31 pp:0 ret:-22, enable false/0
Regards
Luca
>
> >
> > [ 23.423930] panel-samsung-souxp ae94000.dsi.0:
> > samsung_souxp00_disable
> > [ 23.461013] [dpu error]invalid IRQ=[134217727, 31]
> >
[PATCH v2 3/3] arm64: dts: qcom: sm6350: Add DisplayPort controller
Add the node for the DisplayPort controller found on the SM6350 SoC.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/sm6350.dtsi | 88
1 file changed, 88 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6350.dtsi
b/arch/arm64/boot/dts/qcom/sm6350.dtsi
index 24bcec3366ef..d7cf4b5ceea6 100644
--- a/arch/arm64/boot/dts/qcom/sm6350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi
@@ -2033,6 +2033,14 @@ dpu_intf1_out: endpoint {
remote-endpoint =
<_dsi0_in>;
};
};
+
+ port@2 {
+ reg = <2>;
+
+ dpu_intf0_out: endpoint {
+ remote-endpoint =
<_dp_in>;
+ };
+ };
};
mdp_opp_table: opp-table {
@@ -2070,6 +2078,86 @@ opp-56000 {
};
};
+ mdss_dp: displayport-controller@ae9 {
+ compatible = "qcom,sm6350-dp", "qcom,sm8350-dp";
+ reg = <0 0xae9 0 0x200>,
+ <0 0xae90200 0 0x200>,
+ <0 0xae90400 0 0x600>,
+ <0 0xae91000 0 0x400>,
+ <0 0xae91400 0 0x400>;
+ interrupt-parent = <>;
+ interrupts = <12>;
+ clocks = < DISP_CC_MDSS_AHB_CLK>,
+< DISP_CC_MDSS_DP_AUX_CLK>,
+< DISP_CC_MDSS_DP_LINK_CLK>,
+<
DISP_CC_MDSS_DP_LINK_INTF_CLK>,
+< DISP_CC_MDSS_DP_PIXEL_CLK>;
+ clock-names = "core_iface",
+ "core_aux",
+ "ctrl_link",
+ "ctrl_link_iface",
+ "stream_pixel";
+
+ assigned-clocks = <
DISP_CC_MDSS_DP_LINK_CLK_SRC>,
+ <
DISP_CC_MDSS_DP_PIXEL_CLK_SRC>;
+ assigned-clock-parents = <_1_qmpphy
QMP_USB43DP_DP_LINK_CLK>,
+<_1_qmpphy
QMP_USB43DP_DP_VCO_DIV_CLK>;
+
+ phys = <_1_qmpphy QMP_USB43DP_DP_PHY>;
+ phy-names = "dp";
+
+ #sound-dai-cells = <0>;
+
+ operating-points-v2 = <_opp_table>;
+ power-domains = < SM6350_CX>;
+
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ mdss_dp_in: endpoint {
+ remote-endpoint =
<_intf0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mdss_dp_out: endpoint {
+ };
+ };
+ };
+
+ dp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-16000 {
+ opp-hz = /bits/ 64 <16000>;
+ required-opps =
<_opp_low_svs>;
+ };
+
+ opp-27000 {
+ opp-hz = /bits/ 64 <27000>;
+ r
[PATCH v2 2/3] dt-bindings: display: msm: sm6350-mdss: document DP controller subnode
Document the displayport controller subnode of the SM6350 MDSS. Signed-off-by: Luca Weiss --- .../devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml| 9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml index c9ba1fae8042..bba666bdffe5 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml @@ -53,6 +53,15 @@ patternProperties: compatible: const: qcom,sm6350-dpu + "^displayport-controller@[0-9a-f]+$": +type: object +additionalProperties: true + +properties: + compatible: +contains: + const: qcom,sm6350-dp + "^dsi@[0-9a-f]+$": type: object additionalProperties: true -- 2.44.0
[PATCH v2 1/3] dt-bindings: display: msm: dp-controller: document SM6350 compatible
Add the compatible string for the DisplayPort controller on SM6350 which is compatible with the one on SM8350. Acked-by: Rob Herring Signed-off-by: Luca Weiss --- Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml index ae53cbfb2193..97993feda193 100644 --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml @@ -29,6 +29,7 @@ properties: - qcom,sm8650-dp - items: - enum: + - qcom,sm6350-dp - qcom,sm8150-dp - qcom,sm8250-dp - qcom,sm8450-dp -- 2.44.0
[PATCH v2 0/3] DisplayPort support for SM6350/SM7225
Add the required changes to support DisplayPort (normally(?) available via the USB-C connector) on the SM6350/SM7225 SoC. This has been tested on a Fairphone 4 smartphone with additional changes not included in this series (mostly just wiring up TCPM and the SBU mux). Signed-off-by: Luca Weiss --- Changes in v2: - Fix typo in dp-controller patch subject - Use 'contains' for subnode in mdss schema - Pick up tags - Link to v1: https://lore.kernel.org/r/20240328-sm6350-dp-v1-0-215ca2b81...@fairphone.com --- Luca Weiss (3): dt-bindings: display: msm: dp-controller: document SM6350 compatible dt-bindings: display: msm: sm6350-mdss: document DP controller subnode arm64: dts: qcom: sm6350: Add DisplayPort controller .../bindings/display/msm/dp-controller.yaml| 1 + .../bindings/display/msm/qcom,sm6350-mdss.yaml | 9 +++ arch/arm64/boot/dts/qcom/sm6350.dtsi | 88 ++ 3 files changed, 98 insertions(+) --- base-commit: 871760455183dc66b3e185f8d3ed2184cc9fac25 change-id: 20240328-sm6350-dp-41238153b448 Best regards, -- Luca Weiss
Re: [PATCH 1/3] dt-bindings: display: msm: dp-controller: document SM8250 compatible
Stupid typo in subject, should of course be SM6350, not SM8250. On Thu Mar 28, 2024 at 10:42 AM CET, Luca Weiss wrote: > Add the compatible string for the DisplayPort controller on SM6350 which > is compatible with the one on SM8350. > > Signed-off-by: Luca Weiss > --- > Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > index ae53cbfb2193..97993feda193 100644 > --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > @@ -29,6 +29,7 @@ properties: >- qcom,sm8650-dp >- items: >- enum: > + - qcom,sm6350-dp >- qcom,sm8150-dp >- qcom,sm8250-dp >- qcom,sm8450-dp
[PATCH 3/3] arm64: dts: qcom: sm6350: Add DisplayPort controller
Add the node for the DisplayPort controller found on the SM6350 SoC.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/sm6350.dtsi | 88
1 file changed, 88 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6350.dtsi
b/arch/arm64/boot/dts/qcom/sm6350.dtsi
index 24bcec3366ef..d7cf4b5ceea6 100644
--- a/arch/arm64/boot/dts/qcom/sm6350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi
@@ -2033,6 +2033,14 @@ dpu_intf1_out: endpoint {
remote-endpoint =
<_dsi0_in>;
};
};
+
+ port@2 {
+ reg = <2>;
+
+ dpu_intf0_out: endpoint {
+ remote-endpoint =
<_dp_in>;
+ };
+ };
};
mdp_opp_table: opp-table {
@@ -2070,6 +2078,86 @@ opp-56000 {
};
};
+ mdss_dp: displayport-controller@ae9 {
+ compatible = "qcom,sm6350-dp", "qcom,sm8350-dp";
+ reg = <0 0xae9 0 0x200>,
+ <0 0xae90200 0 0x200>,
+ <0 0xae90400 0 0x600>,
+ <0 0xae91000 0 0x400>,
+ <0 0xae91400 0 0x400>;
+ interrupt-parent = <>;
+ interrupts = <12>;
+ clocks = < DISP_CC_MDSS_AHB_CLK>,
+< DISP_CC_MDSS_DP_AUX_CLK>,
+< DISP_CC_MDSS_DP_LINK_CLK>,
+<
DISP_CC_MDSS_DP_LINK_INTF_CLK>,
+< DISP_CC_MDSS_DP_PIXEL_CLK>;
+ clock-names = "core_iface",
+ "core_aux",
+ "ctrl_link",
+ "ctrl_link_iface",
+ "stream_pixel";
+
+ assigned-clocks = <
DISP_CC_MDSS_DP_LINK_CLK_SRC>,
+ <
DISP_CC_MDSS_DP_PIXEL_CLK_SRC>;
+ assigned-clock-parents = <_1_qmpphy
QMP_USB43DP_DP_LINK_CLK>,
+<_1_qmpphy
QMP_USB43DP_DP_VCO_DIV_CLK>;
+
+ phys = <_1_qmpphy QMP_USB43DP_DP_PHY>;
+ phy-names = "dp";
+
+ #sound-dai-cells = <0>;
+
+ operating-points-v2 = <_opp_table>;
+ power-domains = < SM6350_CX>;
+
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ mdss_dp_in: endpoint {
+ remote-endpoint =
<_intf0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mdss_dp_out: endpoint {
+ };
+ };
+ };
+
+ dp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-16000 {
+ opp-hz = /bits/ 64 <16000>;
+ required-opps =
<_opp_low_svs>;
+ };
+
+ opp-27000 {
+ opp-hz = /bits/ 64 <27000>;
+ required-opps =
<_opp_svs>;
+ };
+
+
[PATCH 2/3] dt-bindings: display: msm: sm6350-mdss: document DP controller subnode
Document the displayport controller subnode of the SM6350 MDSS. Signed-off-by: Luca Weiss --- .../devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml index c9ba1fae8042..d91b8eca6aba 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml @@ -53,6 +53,16 @@ patternProperties: compatible: const: qcom,sm6350-dpu + "^displayport-controller@[0-9a-f]+$": +type: object +additionalProperties: true + +properties: + compatible: +items: + - const: qcom,sm6350-dp + - const: qcom,sm8350-dp + "^dsi@[0-9a-f]+$": type: object additionalProperties: true -- 2.44.0
[PATCH 1/3] dt-bindings: display: msm: dp-controller: document SM8250 compatible
Add the compatible string for the DisplayPort controller on SM6350 which is compatible with the one on SM8350. Signed-off-by: Luca Weiss --- Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml index ae53cbfb2193..97993feda193 100644 --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml @@ -29,6 +29,7 @@ properties: - qcom,sm8650-dp - items: - enum: + - qcom,sm6350-dp - qcom,sm8150-dp - qcom,sm8250-dp - qcom,sm8450-dp -- 2.44.0
[PATCH 0/3] DisplayPort support for SM6350/SM7225
Add the required changes to support DisplayPort (normally(?) available via the USB-C connector) on the SM6350/SM7225 SoC. This has been tested on a Fairphone 4 smartphone with additional changes not included in this series (mostly just wiring up TCPM and the SBU mux). Signed-off-by: Luca Weiss --- Luca Weiss (3): dt-bindings: display: msm: dp-controller: document SM8250 compatible dt-bindings: display: msm: sm6350-mdss: document DP controller subnode arm64: dts: qcom: sm6350: Add DisplayPort controller .../bindings/display/msm/dp-controller.yaml| 1 + .../bindings/display/msm/qcom,sm6350-mdss.yaml | 10 +++ arch/arm64/boot/dts/qcom/sm6350.dtsi | 88 ++ 3 files changed, 99 insertions(+) --- base-commit: 871760455183dc66b3e185f8d3ed2184cc9fac25 change-id: 20240328-sm6350-dp-41238153b448 Best regards, -- Luca Weiss
[PATCH] drm/msm/adreno: Set highest_bank_bit for A619
The default highest_bank_bit of 15 didn't seem to cause issues so far
but downstream defines it to be 14. But similar to [0] leaving it on 14
(or 15 for that matter) causes some corruption issues with some
resolutions with DisplayPort, like 1920x1200.
So set it to 13 for now so that there's no screen corruption.
[0] commit 6a0dbcd20ef2 ("drm/msm/a6xx: set highest_bank_bit to 13 for a610")
Fixes: b7616b5c69e6 ("drm/msm/adreno: Add A619 support")
Signed-off-by: Luca Weiss
---
@Akhil: Dmitry & Abhinav said I should ping you specifically to take a
look if you have an idea why HBB=13 works but HBB=14 causes issues.
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 0674aca0f8a3..cf0b1de1c071 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1377,6 +1377,10 @@ static void a6xx_calc_ubwc_config(struct adreno_gpu *gpu)
if (adreno_is_a618(gpu))
gpu->ubwc_config.highest_bank_bit = 14;
+ if (adreno_is_a619(gpu))
+ /* TODO: Should be 14 but causes corruption at e.g. 1920x1200
on DP */
+ gpu->ubwc_config.highest_bank_bit = 13;
+
if (adreno_is_a619_holi(gpu))
gpu->ubwc_config.highest_bank_bit = 13;
---
base-commit: d5a436a7b5958caa6fc0dcda6c842f9d951be73b
change-id: 20240328-a619-hbb-a3b6bda9e4a7
Best regards,
--
Luca Weiss
Re: [PATCH] drm/bridge: Select DRM_KMS_HELPER for DRM_PANEL_BRIDGE
On Mon Mar 18, 2024 at 11:59 AM CET, Jani Nikula wrote:
> On Mon, 18 Mar 2024, Jani Nikula wrote:
> > On Mon, 18 Mar 2024, Neil Armstrong wrote:
> >> Hi,
> >>
> >> On Thu, 11 Jan 2024 13:38:04 +0100, Luca Weiss wrote:
> >>> Since the kconfig symbol of DRM_PANEL_BRIDGE is only adding
> >>> bridge/panel.o to drm_kms_helper object, we need to select
> >>> DRM_KMS_HELPER to make sure the file is actually getting built.
> >>>
> >>> Otherwise with certain defconfigs e.g. devm_drm_of_get_bridge will not
> >>> be properly available:
> >>>
> >>> [...]
> >>
> >> Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git
> >> (drm-misc-fixes)
> >>
> >> [1/1] drm/bridge: Select DRM_KMS_HELPER for DRM_PANEL_BRIDGE
> >>
> >> https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/e3f18b0dd1db242791afbc3bd173026163ce0ccc
> >
> > With my kernel config, e3f18b0dd1db ("drm/bridge: Select DRM_KMS_HELPER
> > for DRM_PANEL_BRIDGE") leads to:
> >
> > WARNING: unmet direct dependencies detected for DRM_KMS_HELPER
> > Depends on [m]: HAS_IOMEM [=y] && DRM [=m]
> > Selected by [y]:
> > - DRM_PANEL_BRIDGE [=y] && HAS_IOMEM [=y] && DRM_BRIDGE [=y]
> > Selected by [m]:
> > - DRM [=m] && HAS_IOMEM [=y] && (AGP [=y] || AGP [=y]=n) &&
> > !EMULATED_CMPXCHG && HAS_DMA [=y] && DRM_FBDEV_EMULATION [=y]
> > - DRM_MIPI_DBI [=m] && HAS_IOMEM [=y] && DRM [=m]
> > - DRM_KUNIT_TEST [=m] && HAS_IOMEM [=y] && DRM [=m] && KUNIT [=y] && MMU
> > [=y]
> > - DRM_RADEON [=m] && HAS_IOMEM [=y] && DRM [=m] && PCI [=y] && MMU [=y]
> > && (AGP [=y] || !AGP [=y])
> > - DRM_AMDGPU [=m] && HAS_IOMEM [=y] && DRM [=m] && PCI [=y] && MMU [=y]
> > && !UML
> > - DRM_NOUVEAU [=m] && HAS_IOMEM [=y] && DRM [=m] && PCI [=y] && MMU [=y]
> > - DRM_I915 [=m] && HAS_IOMEM [=y] && DRM [=m] && X86 [=y] && PCI [=y] &&
> > !PREEMPT_RT [=n]
> > - DRM_XE [=m] && HAS_IOMEM [=y] && DRM [=m] && PCI [=y] && MMU [=y] && (m
> > && MODULES [=y] || y && KUNIT [=y]=y) && 64BIT [=y]
> > - DRM_VKMS [=m] && HAS_IOMEM [=y] && DRM [=m] && MMU [=y]
> > - DRM_VMWGFX [=m] && HAS_IOMEM [=y] && DRM [=m] && PCI [=y] && MMU [=y]
> > && (X86 [=y] || ARM64)
> > - DRM_GMA500 [=m] && HAS_IOMEM [=y] && DRM [=m] && PCI [=y] && X86 [=y]
> > && MMU [=y]
> > - DRM_UDL [=m] && HAS_IOMEM [=y] && DRM [=m] && USB [=m] &&
> > USB_ARCH_HAS_HCD [=y] && MMU [=y]
> > - DRM_AST [=m] && HAS_IOMEM [=y] && DRM [=m] && PCI [=y] && MMU [=y]
> > - DRM_MGAG200 [=m] && HAS_IOMEM [=y] && DRM [=m] && PCI [=y] && MMU [=y]
> > - DRM_QXL [=m] && HAS_IOMEM [=y] && DRM [=m] && PCI [=y] && MMU [=y]
> > - DRM_VIRTIO_GPU [=m] && HAS_IOMEM [=y] && DRM [=m] && VIRTIO_MENU [=y]
> > && MMU [=y]
> > - DRM_BOCHS [=m] && HAS_IOMEM [=y] && DRM [=m] && PCI [=y] && MMU [=y]
> > - DRM_CIRRUS_QEMU [=m] && HAS_IOMEM [=y] && DRM [=m] && PCI [=y] && MMU
> > [=y]
> > - DRM_GM12U320 [=m] && HAS_IOMEM [=y] && DRM [=m] && USB [=m] && MMU [=y]
> > - DRM_PANEL_MIPI_DBI [=m] && HAS_IOMEM [=y] && DRM [=m] && SPI [=y]
> > - DRM_SIMPLEDRM [=m] && HAS_IOMEM [=y] && DRM [=m] && MMU [=y]
> > - TINYDRM_HX8357D [=m] && HAS_IOMEM [=y] && DRM [=m] && SPI [=y]
> > - TINYDRM_ILI9163 [=m] && HAS_IOMEM [=y] && DRM [=m] && SPI [=y]
> > - TINYDRM_ILI9225 [=m] && HAS_IOMEM [=y] && DRM [=m] && SPI [=y]
> > - TINYDRM_ILI9341 [=m] && HAS_IOMEM [=y] && DRM [=m] && SPI [=y]
> > - TINYDRM_ILI9486 [=m] && HAS_IOMEM [=y] && DRM [=m] && SPI [=y]
> > - TINYDRM_MI0283QT [=m] && HAS_IOMEM [=y] && DRM [=m] && SPI [=y]
> > - TINYDRM_REPAPER [=m] && HAS_IOMEM [=y] && DRM [=m] && SPI [=y]
> > - TINYDRM_ST7586 [=m] && HAS_IOMEM [=y] && DRM [=m] && SPI [=y]
> > - TINYDRM_ST7735R [=m] && HAS_IOMEM [=y] && DRM [=m] && SPI [=y]
> > - DRM_XEN_FRONTEND [=m] && HAS_IOMEM [=y] && XEN [=y] && DRM [=m]
> > - DRM_VBOXVIDEO [=m] && HAS_IOMEM [=y] && DRM [=m] && X86 [=y] && PCI [=y]
> > - DRM_GUD [=m] && HAS_IOMEM [=y] && DRM [=m] && USB [=m] && MMU [=y]
> > - DRM_SSD130X [=m] && HAS_IOMEM [=y] && DRM [=m] && MMU [=y]
> > - DRM_ANALOGIX_ANX78XX [=m] && HAS_IOMEM [=y] && DRM [=m] && DRM_BRIDGE
> > [=y]
>
> Please read Documentation/kbuild/kconfig-language.rst.
>
> Basically boolean DRM_PANEL_BRIDGE selecting tristate DRM_KMS_HELPER
> forces it to y while it should remain m.
Would you know the correct fix for this? I'm aware of the pattern
"select FOO || !FOO" but I guess it's also not applicable here?
In any case building DRM_PANEL_BRIDGE also needs to build
DRM_KMS_HELPER, otherwise the object files just don't get used.
Unfortunately I'm not versed well enough at all in Kconfig :/
>
> Please revert.
>
> BR,
> Jani.
Re: [PATCH] drm/bridge: Select DRM_KMS_HELPER for DRM_PANEL_BRIDGE
On Sun Mar 3, 2024 at 9:37 PM CET, Dmitry Baryshkov wrote:
> On Thu, 29 Feb 2024 at 11:27, Luca Weiss wrote:
> >
> > On Wed Jan 17, 2024 at 9:59 AM CET, Luca Weiss wrote:
> > > On Mon Jan 15, 2024 at 9:43 AM CET, Neil Armstrong wrote:
> > > > Hi Luca,
> > > >
> > > > On 11/01/2024 13:38, Luca Weiss wrote:
> > > > > Since the kconfig symbol of DRM_PANEL_BRIDGE is only adding
> > > > > bridge/panel.o to drm_kms_helper object, we need to select
> > > > > DRM_KMS_HELPER to make sure the file is actually getting built.
> > > > >
> > > > > Otherwise with certain defconfigs e.g. devm_drm_of_get_bridge will not
> > > > > be properly available:
> > > > >
> > > > >aarch64-linux-gnu-ld: drivers/phy/qualcomm/phy-qcom-qmp-combo.o:
> > > > > in function `qmp_combo_bridge_attach':
> > > > >drivers/phy/qualcomm/phy-qcom-qmp-combo.c:3204:(.text+0x8f4):
> > > > > undefined reference to `devm_drm_of_get_bridge'
> > > > >
> > > > > Signed-off-by: Luca Weiss
> > > > > ---
> > > > > I can see "depends on DRM_KMS_HELPER" was removed with commit
> > > > > 3c3384050d68 ("drm: Don't make DRM_PANEL_BRIDGE dependent on
> > > > > DRM_KMS_HELPERS")
>
> Could you please make sure that the usecase described in the mentioned
> commit message doesn't get broken by your change?
Hi Neil,
The problem fixed in that linked patch (3c3384050d68) is about fixing
undefined reference errors with specific .config setups - similar to
this patch.
Since we're only adding a 'select' and not removing anything I don't see
how it could cause new errors like that, and it does fix the one I'm
describing.
And also I checked again and I don't see any circular dependencies
(something that was also mentioned in the linked patch), so apart from
what I mentioned with that I'm not too familiar when 'select' should be
used and when 'depend' should be used, it's good from my perspective.
Regards
Luca
>
> > > > >
> > > > > I'm not too familiar with Kconfig but it feels more correct if
> > > > > PHY_QCOM_QMP_COMBO selects DRM_PANEL_BRIDGE that that's enough; and it
> > > > > doesn't also has to explicitly select DRM_KMS_HELPER because of how
> > > > > the
> > > > > objects are built in the Makefile.
> > > > >
> > > > > Alternatively solution to this patch could be adjusting this line in
> > > > > include/drm/drm_bridge.h:
> > > > >
> > > > >-#if defined(CONFIG_OF) && defined(CONFIG_DRM_PANEL_BRIDGE)
> > > > >+#if defined(CONFIG_OF) && defined(CONFIG_DRM_PANEL_BRIDGE) &&
> > > > > defined(CONFIG_DRM_KMS_HELPER)
> > > > > struct drm_bridge *devm_drm_of_get_bridge(struct device *dev,
> > > > > struct device_node *node,
> > > > > u32 port, u32 endpoint);
> > > > >
> > > > > .. and then selecting DRM_KMS_HELPER for PHY_QCOM_QMP_COMBO.
> > > > >
> > > > > But I think the solution in this patch is better. Let me know what you
> > > > > think.
> > > >
> > > > I think this is no more the case after on linux-next:
> > > > 35921910bbd0 phy: qcom: qmp-combo: switch to DRM_AUX_BRIDGE
> > > >
> > > > But could you still check ?
> > >
> > > On next-20240117 the error happens in the aux-bridge file instead then.
> > >
> > > aarch64-linux-gnu-ld: drivers/gpu/drm/bridge/aux-bridge.o: in function
> > > `drm_aux_bridge_probe':
> > > drivers/gpu/drm/bridge/aux-bridge.c:115:(.text+0xe0): undefined reference
> > > to `devm_drm_of_get_bridge'
> > >
> > > I'm attaching the defconfig with which I can reproduce this but it's
> > > really just DRM_KMS_HELPER=n and PHY_QCOM_QMP_COMBO=y I believe.
> >
> > Hi Neil,
> >
> > Ping on this patch
> >
> > Regards
> > Luca
> >
> > >
> > > Regards
> > > Luca
> > >
> > >
> > > >
> > > > Neil
> > > >
> > > > > ---
> > > > > drivers/gpu/drm/bridge/Kconfig | 1 +
> > > > > 1 file changed, 1 insertion(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/bridge/Kconfig
> > > > > b/drivers/gpu/drm/bridge/Kconfig
> > > > > index ac9ec5073619..ae782b427829 100644
> > > > > --- a/drivers/gpu/drm/bridge/Kconfig
> > > > > +++ b/drivers/gpu/drm/bridge/Kconfig
> > > > > @@ -8,6 +8,7 @@ config DRM_BRIDGE
> > > > > config DRM_PANEL_BRIDGE
> > > > > def_bool y
> > > > > depends on DRM_BRIDGE
> > > > > + select DRM_KMS_HELPER
> > > > > select DRM_PANEL
> > > > > help
> > > > > DRM bridge wrapper of DRM panels
> > > > >
> > > > > ---
> > > > > base-commit: b9c3a1fa6fb324e691a03cf124b79f4842e65d76
> > > > > change-id: 20240111-drm-panel-bridge-fixup-5c2977fb969f
> > > > >
> > > > > Best regards,
> >
Re: [PATCH] drm/bridge: Select DRM_KMS_HELPER for DRM_PANEL_BRIDGE
On Wed Jan 17, 2024 at 9:59 AM CET, Luca Weiss wrote:
> On Mon Jan 15, 2024 at 9:43 AM CET, Neil Armstrong wrote:
> > Hi Luca,
> >
> > On 11/01/2024 13:38, Luca Weiss wrote:
> > > Since the kconfig symbol of DRM_PANEL_BRIDGE is only adding
> > > bridge/panel.o to drm_kms_helper object, we need to select
> > > DRM_KMS_HELPER to make sure the file is actually getting built.
> > >
> > > Otherwise with certain defconfigs e.g. devm_drm_of_get_bridge will not
> > > be properly available:
> > >
> > >aarch64-linux-gnu-ld: drivers/phy/qualcomm/phy-qcom-qmp-combo.o: in
> > > function `qmp_combo_bridge_attach':
> > >drivers/phy/qualcomm/phy-qcom-qmp-combo.c:3204:(.text+0x8f4):
> > > undefined reference to `devm_drm_of_get_bridge'
> > >
> > > Signed-off-by: Luca Weiss
> > > ---
> > > I can see "depends on DRM_KMS_HELPER" was removed with commit
> > > 3c3384050d68 ("drm: Don't make DRM_PANEL_BRIDGE dependent on
> > > DRM_KMS_HELPERS")
> > >
> > > I'm not too familiar with Kconfig but it feels more correct if
> > > PHY_QCOM_QMP_COMBO selects DRM_PANEL_BRIDGE that that's enough; and it
> > > doesn't also has to explicitly select DRM_KMS_HELPER because of how the
> > > objects are built in the Makefile.
> > >
> > > Alternatively solution to this patch could be adjusting this line in
> > > include/drm/drm_bridge.h:
> > >
> > >-#if defined(CONFIG_OF) && defined(CONFIG_DRM_PANEL_BRIDGE)
> > >+#if defined(CONFIG_OF) && defined(CONFIG_DRM_PANEL_BRIDGE) &&
> > > defined(CONFIG_DRM_KMS_HELPER)
> > > struct drm_bridge *devm_drm_of_get_bridge(struct device *dev, struct
> > > device_node *node,
> > > u32 port, u32 endpoint);
> > >
> > > .. and then selecting DRM_KMS_HELPER for PHY_QCOM_QMP_COMBO.
> > >
> > > But I think the solution in this patch is better. Let me know what you
> > > think.
> >
> > I think this is no more the case after on linux-next:
> > 35921910bbd0 phy: qcom: qmp-combo: switch to DRM_AUX_BRIDGE
> >
> > But could you still check ?
>
> On next-20240117 the error happens in the aux-bridge file instead then.
>
> aarch64-linux-gnu-ld: drivers/gpu/drm/bridge/aux-bridge.o: in function
> `drm_aux_bridge_probe':
> drivers/gpu/drm/bridge/aux-bridge.c:115:(.text+0xe0): undefined reference to
> `devm_drm_of_get_bridge'
>
> I'm attaching the defconfig with which I can reproduce this but it's
> really just DRM_KMS_HELPER=n and PHY_QCOM_QMP_COMBO=y I believe.
Hi Neil,
Ping on this patch
Regards
Luca
>
> Regards
> Luca
>
>
> >
> > Neil
> >
> > > ---
> > > drivers/gpu/drm/bridge/Kconfig | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/Kconfig
> > > b/drivers/gpu/drm/bridge/Kconfig
> > > index ac9ec5073619..ae782b427829 100644
> > > --- a/drivers/gpu/drm/bridge/Kconfig
> > > +++ b/drivers/gpu/drm/bridge/Kconfig
> > > @@ -8,6 +8,7 @@ config DRM_BRIDGE
> > > config DRM_PANEL_BRIDGE
> > > def_bool y
> > > depends on DRM_BRIDGE
> > > + select DRM_KMS_HELPER
> > > select DRM_PANEL
> > > help
> > > DRM bridge wrapper of DRM panels
> > >
> > > ---
> > > base-commit: b9c3a1fa6fb324e691a03cf124b79f4842e65d76
> > > change-id: 20240111-drm-panel-bridge-fixup-5c2977fb969f
> > >
> > > Best regards,
Re: [PATCH RESEND 0/4] Ensure all backlight drivers zero the properties structure
On Dienstag, 20. Februar 2024 16:35:23 CET Daniel Thompson wrote: > [Sorry for the RESEND so soon... embarrassingly I got Lee's e-mail > address wrong the first time!] > > Luca Weiss recently shared a patch to zero the properties structure for > lm3630a... and shortly afterwards I realized I should probably scan for > a similar class of errors in other drivers. Thanks for fixing the other drivers! Was definitely a fun one to debug :) > > Results follow in the next four patches (they could all be one patch but > for the fact there are different Fixes: tags)! > > Daniel Thompson (4): > backlight: da9052: Fully initialize backlight_properties during probe > backlight: lm3639: Fully initialize backlight_properties during probe > backlight: lp8788: Fully initialize backlight_properties during probe > backlight: mp3309c: Fully initialize backlight_properties during probe > > drivers/video/backlight/da9052_bl.c | 1 + > drivers/video/backlight/lm3639_bl.c | 1 + > drivers/video/backlight/lp8788_bl.c | 1 + > drivers/video/backlight/mp3309c.c | 1 + > 4 files changed, 4 insertions(+) > > > base-commit: b401b621758e46812da61fa58a67c3fd8d91de0d > -- > 2.43.0 > >
Re: [PATCH 4/4] ARM: dts: qcom: msm8974-hammerhead: Hook up backlight
On Dienstag, 20. Februar 2024 15:12:10 CET Daniel Thompson wrote:
> On Tue, Feb 20, 2024 at 12:11:22AM +0100, Luca Weiss wrote:
> > Connect the panel with the backlight nodes so that the backlight can be
> > turned off when the display is blanked.
> >
> > Signed-off-by: Luca Weiss
>
> Reviewed-by: Daniel Thompson
>
>
> > ---
> > arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
> > b/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
> > index 4aaae8537a3f..8eaa5b162815 100644
> > --- a/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
> > +++ b/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
> > @@ -182,7 +182,7 @@ _i2c5 {
> > status = "okay";
> > clock-frequency = <355000>;
> >
> > - led-controller@38 {
> > + backlight: led-controller@38 {
>
> Again... a minor nit regarding existing problems but this node doesn't
> follow the generic naming recommendations:
> https://devicetree-specification.readthedocs.io/en/stable/devicetree-basics.html#generic-names-recommendation
"led-controller" is listed on that page, or do you mean something else?
>
>
> Daniel.
>
Re: [PATCH 3/4] backlight: lm3630a: Use backlight_get_brightness helper in update_status
On Dienstag, 20. Februar 2024 15:11:07 CET Daniel Thompson wrote: > On Tue, Feb 20, 2024 at 12:11:21AM +0100, Luca Weiss wrote: > > As per documentation "drivers are expected to use this function in their > > update_status() operation to get the brightness value.". > > > > With this we can also drop the manual backlight_is_blank() handling > > since backlight_get_brightness() is already handling this correctly. > > > > Signed-off-by: Luca Weiss > > Reviewed-by: Daniel Thompson > > However... > > > --- > > /* disable sleep */ > > @@ -201,9 +202,9 @@ static int lm3630a_bank_a_update_status(struct > > backlight_device *bl) > > goto out_i2c_err; > > usleep_range(1000, 2000); > > /* minimum brightness is 0x04 */ > > - ret = lm3630a_write(pchip, REG_BRT_A, bl->props.brightness); > > + ret = lm3630a_write(pchip, REG_BRT_A, brightness); > > ... then handling of the minimum brightness looks weird in this driver. > > The range of the backlight is 0..max_brightness. Sadly the drivers > are inconsistant regarding whether zero means off or just minimum, > however three certainly isn't supposed to mean off! In other words the > offsetting should be handled by driver rather than hoping userspace has > some magic LM3630A mode. I could also try and fix that.. 1. Treat 1..4 as 4, so have backlight on at that minimum level? Probably wouldn't be noticable that brightness 1=2=3=4. And the backlight will be on compared to off as it is now. 2. Decrease max_brightness by 4 values, so probably 0..251 and shift the values up in the driver so we get 4..255? Or would you have some other idea here? Regards Luca > > You didn't introduce this so this patch still has my R-b ... > > > Daniel. >
[PATCH 3/4] backlight: lm3630a: Use backlight_get_brightness helper in update_status
As per documentation "drivers are expected to use this function in their update_status() operation to get the brightness value.". With this we can also drop the manual backlight_is_blank() handling since backlight_get_brightness() is already handling this correctly. Signed-off-by: Luca Weiss --- drivers/video/backlight/lm3630a_bl.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/video/backlight/lm3630a_bl.c b/drivers/video/backlight/lm3630a_bl.c index 26ff4178cc16..e6c0916ec88b 100644 --- a/drivers/video/backlight/lm3630a_bl.c +++ b/drivers/video/backlight/lm3630a_bl.c @@ -189,10 +189,11 @@ static int lm3630a_bank_a_update_status(struct backlight_device *bl) int ret; struct lm3630a_chip *pchip = bl_get_data(bl); enum lm3630a_pwm_ctrl pwm_ctrl = pchip->pdata->pwm_ctrl; + int brightness = backlight_get_brightness(bl); /* pwm control */ if ((pwm_ctrl & LM3630A_PWM_BANK_A) != 0) - return lm3630a_pwm_ctrl(pchip, bl->props.brightness, + return lm3630a_pwm_ctrl(pchip, brightness, bl->props.max_brightness); /* disable sleep */ @@ -201,9 +202,9 @@ static int lm3630a_bank_a_update_status(struct backlight_device *bl) goto out_i2c_err; usleep_range(1000, 2000); /* minimum brightness is 0x04 */ - ret = lm3630a_write(pchip, REG_BRT_A, bl->props.brightness); + ret = lm3630a_write(pchip, REG_BRT_A, brightness); - if (backlight_is_blank(bl) || (backlight_get_brightness(bl) < 0x4)) + if (brightness < 0x4) /* turn the string off */ ret |= lm3630a_update(pchip, REG_CTRL, LM3630A_LEDA_ENABLE, 0); else @@ -263,10 +264,11 @@ static int lm3630a_bank_b_update_status(struct backlight_device *bl) int ret; struct lm3630a_chip *pchip = bl_get_data(bl); enum lm3630a_pwm_ctrl pwm_ctrl = pchip->pdata->pwm_ctrl; + int brightness = backlight_get_brightness(bl); /* pwm control */ if ((pwm_ctrl & LM3630A_PWM_BANK_B) != 0) - return lm3630a_pwm_ctrl(pchip, bl->props.brightness, + return lm3630a_pwm_ctrl(pchip, brightness, bl->props.max_brightness); /* disable sleep */ @@ -275,9 +277,9 @@ static int lm3630a_bank_b_update_status(struct backlight_device *bl) goto out_i2c_err; usleep_range(1000, 2000); /* minimum brightness is 0x04 */ - ret = lm3630a_write(pchip, REG_BRT_B, bl->props.brightness); + ret = lm3630a_write(pchip, REG_BRT_B, brightness); - if (backlight_is_blank(bl) || (backlight_get_brightness(bl) < 0x4)) + if (brightness < 0x4) /* turn the string off */ ret |= lm3630a_update(pchip, REG_CTRL, LM3630A_LEDB_ENABLE, 0); else -- 2.43.2
[PATCH 1/4] backlight: lm3630a: Initialize backlight_properties on init
The backlight_properties struct should be initialized to zero before
using, otherwise there will be some random values in the struct.
Fixes: 0c2a665a648e ("backlight: add Backlight driver for lm3630 chip")
Signed-off-by: Luca Weiss
---
drivers/video/backlight/lm3630a_bl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/backlight/lm3630a_bl.c
b/drivers/video/backlight/lm3630a_bl.c
index a3412c936ca2..8e275275b808 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -343,6 +343,7 @@ static int lm3630a_backlight_register(struct lm3630a_chip
*pchip)
struct backlight_properties props;
const char *label;
+ memset(, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_RAW;
if (pdata->leda_ctrl != LM3630A_LEDA_DISABLE) {
props.brightness = pdata->leda_init_brt;
--
2.43.2
[PATCH 0/4] Various fixes for the lm3630a backlight driver
On the MSM8974 Nexus 5 and OnePlus One phones (latter doesn't have display upstream) the display backlight was turning off whenever you would write a brightness to sysfs since a recent commit to the driver (kernel v6.5). backlight: lm3630a: Turn off both led strings when display is blank Turns out, backlight_is_blank() thought the display was blanked because the props variable is was checking was never actually initialized so it was just reading some value that was left before. The first commit in this series fixes this, and the others are some cleanups / fixes I noticed while working on this. As last commit, we can finally hook up the panel and backlight on the Nexus 5 so blanking the screen actually turns off the backlight. Signed-off-by: Luca Weiss --- Luca Weiss (4): backlight: lm3630a: Initialize backlight_properties on init backlight: lm3630a: Don't set bl->props.brightness in get_brightness backlight: lm3630a: Use backlight_get_brightness helper in update_status ARM: dts: qcom: msm8974-hammerhead: Hook up backlight .../qcom/qcom-msm8974-lge-nexus5-hammerhead.dts| 4 ++- drivers/video/backlight/lm3630a_bl.c | 29 ++ 2 files changed, 16 insertions(+), 17 deletions(-) --- base-commit: b401b621758e46812da61fa58a67c3fd8d91de0d change-id: 20240219-lm3630a-fixups-8a9359e5a8ce Best regards, -- Luca Weiss
[PATCH 4/4] ARM: dts: qcom: msm8974-hammerhead: Hook up backlight
Connect the panel with the backlight nodes so that the backlight can be
turned off when the display is blanked.
Signed-off-by: Luca Weiss
---
arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
b/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
index 4aaae8537a3f..8eaa5b162815 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
@@ -182,7 +182,7 @@ _i2c5 {
status = "okay";
clock-frequency = <355000>;
- led-controller@38 {
+ backlight: led-controller@38 {
compatible = "ti,lm3630a";
status = "okay";
reg = <0x38>;
@@ -272,6 +272,8 @@ panel: panel@0 {
reg = <0>;
compatible = "lg,acx467akm-7";
+ backlight = <>;
+
pinctrl-names = "default";
pinctrl-0 = <_pin>;
--
2.43.2
[PATCH 2/4] backlight: lm3630a: Don't set bl->props.brightness in get_brightness
There's no need to set bl->props.brightness, the get_brightness function
is just supposed to return the current brightness and not touch the
struct.
With that done we can also remove the 'goto out' and just return the
value.
Fixes: 0c2a665a648e ("backlight: add Backlight driver for lm3630 chip")
Signed-off-by: Luca Weiss
---
drivers/video/backlight/lm3630a_bl.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/video/backlight/lm3630a_bl.c
b/drivers/video/backlight/lm3630a_bl.c
index 8e275275b808..26ff4178cc16 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -233,7 +233,7 @@ static int lm3630a_bank_a_get_brightness(struct
backlight_device *bl)
if (rval < 0)
goto out_i2c_err;
brightness |= rval;
- goto out;
+ return brightness;
}
/* disable sleep */
@@ -244,11 +244,8 @@ static int lm3630a_bank_a_get_brightness(struct
backlight_device *bl)
rval = lm3630a_read(pchip, REG_BRT_A);
if (rval < 0)
goto out_i2c_err;
- brightness = rval;
+ return rval;
-out:
- bl->props.brightness = brightness;
- return bl->props.brightness;
out_i2c_err:
dev_err(pchip->dev, "i2c failed to access register\n");
return 0;
@@ -310,7 +307,7 @@ static int lm3630a_bank_b_get_brightness(struct
backlight_device *bl)
if (rval < 0)
goto out_i2c_err;
brightness |= rval;
- goto out;
+ return brightness;
}
/* disable sleep */
@@ -321,11 +318,8 @@ static int lm3630a_bank_b_get_brightness(struct
backlight_device *bl)
rval = lm3630a_read(pchip, REG_BRT_B);
if (rval < 0)
goto out_i2c_err;
- brightness = rval;
+ return rval;
-out:
- bl->props.brightness = brightness;
- return bl->props.brightness;
out_i2c_err:
dev_err(pchip->dev, "i2c failed to access register\n");
return 0;
--
2.43.2
[PATCH v3 3/4] arm64: dts: qcom: sm6350: Remove "disabled" state of GMU
The GMU won't probe without GPU being enabled, so we can remove the
disabled status so we don't have to explicitly enable the GMU in all the
devices that enable GPU.
Reviewed-by: Konrad Dybcio
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/sm6350.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm6350.dtsi
b/arch/arm64/boot/dts/qcom/sm6350.dtsi
index 43cffe8e1247..5a05f14669be 100644
--- a/arch/arm64/boot/dts/qcom/sm6350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi
@@ -1439,8 +1439,6 @@ gmu: gmu@3d6a000 {
operating-points-v2 = <_opp_table>;
- status = "disabled";
-
gmu_opp_table: opp-table {
compatible = "operating-points-v2";
--
2.43.2
[PATCH v3 4/4] arm64: dts: qcom: sm7225-fairphone-fp4: Enable display and GPU
Add the description for the display panel found on this phone.
Unfortunately the LCDB module on PM6150L isn't yet supported upstream so
we need to use a dummy regulator-fixed in the meantime.
And with this done we can also enable the GPU and set the zap shader
firmware path.
Reviewed-by: Konrad Dybcio
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/sm6350.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts | 53 +++
2 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm6350.dtsi
b/arch/arm64/boot/dts/qcom/sm6350.dtsi
index 5a05f14669be..c8099b10ddc4 100644
--- a/arch/arm64/boot/dts/qcom/sm6350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi
@@ -1328,7 +1328,7 @@ gpu: gpu@3d0 {
status = "disabled";
- zap-shader {
+ gpu_zap_shader: zap-shader {
memory-region = <_gpu_mem>;
};
diff --git a/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
b/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
index ade619805519..4e61da8078d1 100644
--- a/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
+++ b/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
@@ -68,6 +68,14 @@ key-volume-up {
};
};
+ /* Dummy regulator until PM6150L has LCDB VSP/VSN support */
+ lcdb_dummy: regulator-lcdb-dummy {
+ compatible = "regulator-fixed";
+ regulator-name = "lcdb_dummy";
+ regulator-min-microvolt = <550>;
+ regulator-max-microvolt = <550>;
+ };
+
reserved-memory {
/*
* The rmtfs memory region in downstream is 'dynamically
allocated'
@@ -373,6 +381,14 @@ _dma1 {
status = "okay";
};
+ {
+ status = "okay";
+};
+
+_zap_shader {
+ firmware-name = "qcom/sm7225/fairphone4/a615_zap.mbn";
+};
+
{
clock-frequency = <40>;
status = "okay";
@@ -404,6 +420,43 @@ {
status = "okay";
};
+ {
+ status = "okay";
+};
+
+_dsi0 {
+ vdda-supply = <_l22a>;
+ status = "okay";
+
+ panel@0 {
+ compatible = "djn,9a-3r063-1102b";
+ reg = <0>;
+
+ backlight = <_wled>;
+ reset-gpios = <_gpios 9 GPIO_ACTIVE_LOW>;
+
+ vdd1-supply = <_l1e>;
+ vsn-supply = <_dummy>;
+ vsp-supply = <_dummy>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <_dsi0_out>;
+ };
+ };
+ };
+};
+
+_dsi0_out {
+ data-lanes = <0 1 2 3>;
+ remote-endpoint = <_in>;
+};
+
+_dsi0_phy {
+ vdds-supply = <_l18a>;
+ status = "okay";
+};
+
{
firmware-name = "qcom/sm7225/fairphone4/modem.mdt";
status = "okay";
--
2.43.2
[PATCH v3 2/4] drm/panel: Add driver for DJN HX83112A LCD panel
Add support for the 2340x1080 LCD panel (DJN 9A-3R063-1102B) bundled
with a HX83112A driver IC, as found on the Fairphone 4 smartphone.
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/panel/Kconfig| 10 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-himax-hx83112a.c | 372 +++
3 files changed, 383 insertions(+)
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 8f3783742208..7e25a4609682 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -162,6 +162,16 @@ config DRM_PANEL_FEIYANG_FY07024DI26A30D
Say Y if you want to enable support for panels based on the
Feiyang FY07024DI26A30-D MIPI-DSI interface.
+config DRM_PANEL_HIMAX_HX83112A
+ tristate "Himax HX83112A-based DSI panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ select DRM_KMS_HELPER
+ help
+ Say Y here if you want to enable support for Himax HX83112A-based
+ display panels, such as the one found in the Fairphone 4 smartphone.
+
config DRM_PANEL_HIMAX_HX8394
tristate "HIMAX HX8394 MIPI-DSI LCD panels"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index d94a644d0a6c..f3e40f24d516 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_DRM_PANEL_EBBG_FT8719) += panel-ebbg-ft8719.o
obj-$(CONFIG_DRM_PANEL_ELIDA_KD35T133) += panel-elida-kd35t133.o
obj-$(CONFIG_DRM_PANEL_FEIXIN_K101_IM2BA02) += panel-feixin-k101-im2ba02.o
obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) +=
panel-feiyang-fy07024di26a30d.o
+obj-$(CONFIG_DRM_PANEL_HIMAX_HX83112A) += panel-himax-hx83112a.o
obj-$(CONFIG_DRM_PANEL_HIMAX_HX8394) += panel-himax-hx8394.o
obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9341) += panel-ilitek-ili9341.o
diff --git a/drivers/gpu/drm/panel/panel-himax-hx83112a.c
b/drivers/gpu/drm/panel/panel-himax-hx83112a.c
new file mode 100644
index ..466c27012abf
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-himax-hx83112a.c
@@ -0,0 +1,372 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Generated with linux-mdss-dsi-panel-driver-generator from vendor device
tree.
+ * Copyright (c) 2024 Luca Weiss
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+/* Manufacturer specific DSI commands */
+#define HX83112A_SETPOWER1 0xb1
+#define HX83112A_SETDISP 0xb2
+#define HX83112A_SETDRV0xb4
+#define HX83112A_SETEXTC 0xb9
+#define HX83112A_SETBANK 0xbd
+#define HX83112A_SETPTBA 0xbf
+#define HX83112A_SETDGCLUT 0xc1
+#define HX83112A_SETTCON 0xc7
+#define HX83112A_SETCLOCK 0xcb
+#define HX83112A_SETPANEL 0xcc
+#define HX83112A_SETPOWER2 0xd2
+#define HX83112A_SETGIP0 0xd3
+#define HX83112A_SETGIP1 0xd5
+#define HX83112A_SETGIP2 0xd6
+#define HX83112A_SETGIP3 0xd8
+#define HX83112A_SETTP10xe7
+#define HX83112A_UNKNOWN1 0xe9
+
+struct hx83112a_panel {
+ struct drm_panel panel;
+ struct mipi_dsi_device *dsi;
+ struct regulator_bulk_data supplies[3];
+ struct gpio_desc *reset_gpio;
+};
+
+static inline struct hx83112a_panel *to_hx83112a_panel(struct drm_panel *panel)
+{
+ return container_of(panel, struct hx83112a_panel, panel);
+}
+
+static void hx83112a_reset(struct hx83112a_panel *ctx)
+{
+ gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+ msleep(20);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+ msleep(20);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+ msleep(50);
+}
+
+static int hx83112a_on(struct hx83112a_panel *ctx)
+{
+ struct mipi_dsi_device *dsi = ctx->dsi;
+ struct device *dev = >dev;
+ int ret;
+
+ dsi->mode_flags |= MIPI_DSI_MODE_LPM;
+
+ mipi_dsi_dcs_write_seq(dsi, HX83112A_SETEXTC, 0x83, 0x11, 0x2a);
+ mipi_dsi_dcs_write_seq(dsi, HX83112A_SETPOWER1,
+ 0x08, 0x28, 0x28, 0x83, 0x83, 0x4c, 0x4f, 0x33);
+ mipi_dsi_dcs_write_seq(dsi, HX83112A_SETDISP,
+ 0x00, 0x02, 0x00, 0x90, 0x24, 0x00, 0x08, 0x19,
+ 0xea, 0x11, 0x11, 0x00, 0x11, 0xa3);
+ mipi_dsi_dcs_write_seq(dsi, HX83112A_SETDRV,
+ 0x58, 0x68, 0x58, 0x68, 0x0f, 0xef, 0x0b, 0xc0,
+ 0x0b, 0xc0, 0x0b, 0xc0, 0x00, 0xff, 0x00, 0xff,
+ 0x00, 0x00, 0x14, 0x15, 0x00, 0x29, 0x11, 0x07,
+ 0x12, 0x00, 0x29);
+ mipi_dsi_dcs_write_seq(dsi, HX83112A_SETBANK, 0x02);
+ mipi_dsi_dcs_write_seq(dsi, HX83112A_SETDRV,
+ 0x00, 0x
[PATCH v3 1/4] dt-bindings: display: panel: Add Himax HX83112A
Himax HX83112A is a display driver IC used to drive LCD DSI panels.
Describe it and the DJN 9A-3R063-1102B using it.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Luca Weiss
---
.../bindings/display/panel/himax,hx83112a.yaml | 74 ++
1 file changed, 74 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/panel/himax,hx83112a.yaml
b/Documentation/devicetree/bindings/display/panel/himax,hx83112a.yaml
new file mode 100644
index ..174661d13811
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/himax,hx83112a.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/himax,hx83112a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Himax HX83112A-based DSI display panels
+
+maintainers:
+ - Luca Weiss
+
+description:
+ The Himax HX83112A is a generic DSI Panel IC used to control
+ LCD panels.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+contains:
+ const: djn,9a-3r063-1102b
+
+ vdd1-supply:
+description: Digital voltage rail
+
+ vsn-supply:
+description: Positive source voltage rail
+
+ vsp-supply:
+description: Negative source voltage rail
+
+ reg: true
+ port: true
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - vdd1-supply
+ - vsn-supply
+ - vsp-supply
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "djn,9a-3r063-1102b";
+reg = <0>;
+
+backlight = <_wled>;
+reset-gpios = <_gpios 9 GPIO_ACTIVE_LOW>;
+
+vdd1-supply = <_l1e>;
+vsn-supply = <_lcdb_ncp>;
+vsp-supply = <_lcdb_ldo>;
+
+port {
+panel_in_0: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+};
+
+...
--
2.43.2
[PATCH v3 0/4] Add display support for Fairphone 4
Introduce the bindings and panel driver for the LCD panel with the model number 9A-3R063-1102B from DJN which is using the HX83112A driver IC. It is used on the Fairphone 4 smartphone. Then we can add the panel to the device dts and also enable the GPU. Signed-off-by: Luca Weiss --- Changes in v3: - Update compatible to djn,9a-3r063-1102b - Add defines for manufacturer-specific DSI commands - Pick up tags - Link to v2: https://lore.kernel.org/r/20240110-fp4-panel-v2-0-8ad11174f...@fairphone.com Changes in v2: - Driver: - Drop "bool prepared" from driver (Dmitry) - Use drm_connector_helper_get_modes_fixed (Dmitry) - Use dev_err_probe in error path (Dmitry) - Fix width/height variables (myself) - Dts: - Don't drop simple-framebuffer (Konrad) - Drop disablement of gmu in dtsi (Konrad) - Set zap shader path (myself) - Pick up tags - Link to v1: https://lore.kernel.org/r/20240105-fp4-panel-v1-0-1afbabc55...@fairphone.com --- Luca Weiss (4): dt-bindings: display: panel: Add Himax HX83112A drm/panel: Add driver for DJN HX83112A LCD panel arm64: dts: qcom: sm6350: Remove "disabled" state of GMU arm64: dts: qcom: sm7225-fairphone-fp4: Enable display and GPU .../bindings/display/panel/himax,hx83112a.yaml | 74 arch/arm64/boot/dts/qcom/sm6350.dtsi | 4 +- arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts | 53 +++ drivers/gpu/drm/panel/Kconfig | 10 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-himax-hx83112a.c | 372 + 6 files changed, 511 insertions(+), 3 deletions(-) --- base-commit: 91f11e5814cfbad83ee22fbcf96b0eb41302d889 change-id: 20240105-fp4-panel-50aba8536a0a Best regards, -- Luca Weiss
Re: [PATCH v2 2/4] drm/panel: Add driver for DJN HX83112A LCD panel
On Mon Jan 22, 2024 at 12:27 PM CET, Luca Weiss wrote: > On Fri Jan 12, 2024 at 11:26 AM CET, wrote: > > On 12/01/2024 11:23, Linus Walleij wrote: > > > On Fri, Jan 12, 2024 at 10:52 AM Luca Weiss > > > wrote: > > > > > >> Since there's zero indication Truly is involved in this panel in my > > >> documentation - much less the number 5P65 - I'm not going to add that. > > > > Ack > > > > > > > > OK then, I fold, thanks for looking into it. > > > Keep the Himax hx83112a file name and symbols. > > > > > >> So in short this panel is the model 9A-3R063-1102B from DJN, which uses > > >> a Himax HX83112A driver IC. > > > > > > So compatible = "djn,9a-3r063-1102b" since the setup sequences for > > > hx83112a are clearly for this one display? > > > > Yep let's settle on that! > Hi Neil and Linus, Any feedback about the below question? Regards Luca > It's clear to me to use "djn,9a-3r063-1102b" in the driver now but what > about dts? > > Currently here in v2 we have this: > compatible = "fairphone,fp4-hx83112a-djn", "himax,hx83112a"; > > Should this just become this? > compatible = "djn,9a-3r063-1102b"; > > Or e.g. this? > compatible = "djn,9a-3r063-1102b", "himax,hx83112a"; > > Or something else completely? Do we have some documentation / best > practises around this maybe? > > Regards > Luca > > > > > Thanks, > > Neil > > > > > > > > Yours, > > > Linus Walleij
Re: [RFT PATCH v2 4/4] drm/msm/dpu: enable writeback on SM6350
On Tue Dec 19, 2023 at 4:39 PM CET, Luca Weiss wrote:
> On Sun Dec 3, 2023 at 1:32 AM CET, Dmitry Baryshkov wrote:
> > Enable WB2 hardware block, enabling writeback support on this platform.
> >
> > Signed-off-by: Dmitry Baryshkov
>
> Hi Dmitry,
>
> I've tried this on sm7225-fairphone-fp4 but having trouble testing this.
>
> I guess I'm using some ID wrong with modetest, could you check and see
> what I do wrong?
>
> libdrm is on version 2.4.118 from Alpine Linux/postmarketOS, kernel is
> v6.7.0-rc6 plus a few patches for hardware enablement (like display).
>
> See log:
>
>
>
Hi Dmitry,
I've tested again now and made it work.
$ modetest -M msm -a -s 38@64:1024x768 -o test.d -P 45@64:1024x768
Then display the image with
$ magick display -size 1024x768 -depth 8 RGBA:test.d
As discussed on IRC it seems the byte order of R and B might be wrong,
so it looks like BGRA is the format we get the data in, not RGBA.
Anyways:
Tested-by: Luca Weiss
Regards
Luca
>
> Regards
> Luca
>
>
> > ---
> > .../drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h | 18 ++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h
> > b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h
> > index 62db84bd15f2..3c179a73c030 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h
> > @@ -27,6 +27,7 @@ static const struct dpu_mdp_cfg sm6350_mdp = {
> > [DPU_CLK_CTRL_DMA0] = { .reg_off = 0x2ac, .bit_off = 8 },
> > [DPU_CLK_CTRL_DMA1] = { .reg_off = 0x2b4, .bit_off = 8 },
> > [DPU_CLK_CTRL_DMA2] = { .reg_off = 0x2c4, .bit_off = 8 },
> > + [DPU_CLK_CTRL_WB2] = { .reg_off = 0x2bc, .bit_off = 16 },
> > [DPU_CLK_CTRL_REG_DMA] = { .reg_off = 0x2bc, .bit_off = 20 },
> > },
> > };
> > @@ -146,6 +147,21 @@ static const struct dpu_dsc_cfg sm6350_dsc[] = {
> > },
> > };
> >
> > +static const struct dpu_wb_cfg sm6350_wb[] = {
> > + {
> > + .name = "wb_2", .id = WB_2,
> > + .base = 0x65000, .len = 0x2c8,
> > + .features = WB_SM8250_MASK,
> > + .format_list = wb2_formats,
> > + .num_formats = ARRAY_SIZE(wb2_formats),
> > + .clk_ctrl = DPU_CLK_CTRL_WB2,
> > + .xin_id = 6,
> > + .vbif_idx = VBIF_RT,
> > + .maxlinewidth = 1920,
> > + .intr_wb_done = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 4),
> > + },
> > +};
> > +
> > static const struct dpu_intf_cfg sm6350_intf[] = {
> > {
> > .name = "intf_0", .id = INTF_0,
> > @@ -219,6 +235,8 @@ const struct dpu_mdss_cfg dpu_sm6350_cfg = {
> > .dsc = sm6350_dsc,
> > .pingpong_count = ARRAY_SIZE(sm6350_pp),
> > .pingpong = sm6350_pp,
> > + .wb_count = ARRAY_SIZE(sm6350_wb),
> > + .wb = sm6350_wb,
> > .intf_count = ARRAY_SIZE(sm6350_intf),
> > .intf = sm6350_intf,
> > .vbif_count = ARRAY_SIZE(sdm845_vbif),
Re: [PATCH v2 2/4] drm/panel: Add driver for DJN HX83112A LCD panel
On Fri Jan 12, 2024 at 11:26 AM CET, wrote: > On 12/01/2024 11:23, Linus Walleij wrote: > > On Fri, Jan 12, 2024 at 10:52 AM Luca Weiss > > wrote: > > > >> Since there's zero indication Truly is involved in this panel in my > >> documentation - much less the number 5P65 - I'm not going to add that. > > Ack > > > > > OK then, I fold, thanks for looking into it. > > Keep the Himax hx83112a file name and symbols. > > > >> So in short this panel is the model 9A-3R063-1102B from DJN, which uses > >> a Himax HX83112A driver IC. > > > > So compatible = "djn,9a-3r063-1102b" since the setup sequences for > > hx83112a are clearly for this one display? > > Yep let's settle on that! It's clear to me to use "djn,9a-3r063-1102b" in the driver now but what about dts? Currently here in v2 we have this: compatible = "fairphone,fp4-hx83112a-djn", "himax,hx83112a"; Should this just become this? compatible = "djn,9a-3r063-1102b"; Or e.g. this? compatible = "djn,9a-3r063-1102b", "himax,hx83112a"; Or something else completely? Do we have some documentation / best practises around this maybe? Regards Luca > > Thanks, > Neil > > > > > Yours, > > Linus Walleij
[PATCH v2 2/2] drm/msm/adreno: Add A305B support
Add support for the Adreno 305B GPU that is found in MSM8226(v2) SoC.
Previously this was mistakenly claimed to be supported but using wrong
a configuration.
In MSM8226v1 there's also a A305B but with chipid 0x03000510 which
should work with the same configuration but due to lack of hardware for
testing this is not added.
Reviewed-by: Konrad Dybcio
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 13 ++---
drivers/gpu/drm/msm/adreno/adreno_device.c | 15 +++
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 5 +
3 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index c86b377f6f0d..5273dc849838 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -134,6 +134,13 @@ static int a3xx_hw_init(struct msm_gpu *gpu)
/* Set up AOOO: */
gpu_write(gpu, REG_A3XX_VBIF_OUT_AXI_AOOO_EN, 0x003c);
gpu_write(gpu, REG_A3XX_VBIF_OUT_AXI_AOOO, 0x003c003c);
+ } else if (adreno_is_a305b(adreno_gpu)) {
+ gpu_write(gpu, REG_A3XX_VBIF_IN_RD_LIM_CONF0, 0x00181818);
+ gpu_write(gpu, REG_A3XX_VBIF_IN_WR_LIM_CONF0, 0x00181818);
+ gpu_write(gpu, REG_A3XX_VBIF_OUT_RD_LIM_CONF0, 0x0018);
+ gpu_write(gpu, REG_A3XX_VBIF_OUT_WR_LIM_CONF0, 0x0018);
+ gpu_write(gpu, REG_A3XX_VBIF_DDR_OUT_MAX_BURST, 0x0303);
+ gpu_write(gpu, REG_A3XX_VBIF_ROUND_ROBIN_QOS_ARB, 0x0003);
} else if (adreno_is_a306(adreno_gpu)) {
gpu_write(gpu, REG_A3XX_VBIF_ROUND_ROBIN_QOS_ARB, 0x0003);
gpu_write(gpu, REG_A3XX_VBIF_OUT_RD_LIM_CONF0, 0x000a);
@@ -230,7 +237,7 @@ static int a3xx_hw_init(struct msm_gpu *gpu)
gpu_write(gpu, REG_A3XX_UCHE_CACHE_MODE_CONTROL_REG, 0x0001);
/* Enable Clock gating: */
- if (adreno_is_a306(adreno_gpu))
+ if (adreno_is_a305b(adreno_gpu) || adreno_is_a306(adreno_gpu))
gpu_write(gpu, REG_A3XX_RBBM_CLOCK_CTL, 0x);
else if (adreno_is_a320(adreno_gpu))
gpu_write(gpu, REG_A3XX_RBBM_CLOCK_CTL, 0xbfff);
@@ -333,7 +340,7 @@ static int a3xx_hw_init(struct msm_gpu *gpu)
AXXX_CP_QUEUE_THRESHOLDS_CSQ_IB1_START(2) |
AXXX_CP_QUEUE_THRESHOLDS_CSQ_IB2_START(6) |
AXXX_CP_QUEUE_THRESHOLDS_CSQ_ST_START(14));
- } else if (adreno_is_a330(adreno_gpu)) {
+ } else if (adreno_is_a330(adreno_gpu) || adreno_is_a305b(adreno_gpu)) {
/* NOTE: this (value take from downstream android driver)
* includes some bits outside of the known bitfields. But
* A330 has this "MERCIU queue" thing too, which might
@@ -559,7 +566,7 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
goto fail;
/* if needed, allocate gmem: */
- if (adreno_is_a330(adreno_gpu)) {
+ if (adreno_is_a330(adreno_gpu) || adreno_is_a305b(adreno_gpu)) {
ret = adreno_gpu_ocmem_init(_gpu->base.pdev->dev,
adreno_gpu, _gpu->ocmem);
if (ret)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 2ce7d7b1690d..f2768e52ed12 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -55,10 +55,17 @@ static const struct adreno_info gpulist[] = {
.inactive_period = DRM_MSM_INACTIVE_PERIOD,
.init = a2xx_gpu_init,
}, {
- .chip_ids = ADRENO_CHIP_IDS(
- 0x03000512,
- 0x03000520
- ),
+ .chip_ids = ADRENO_CHIP_IDS(0x03000512),
+ .family = ADRENO_3XX,
+ .fw = {
+ [ADRENO_FW_PM4] = "a330_pm4.fw",
+ [ADRENO_FW_PFP] = "a330_pfp.fw",
+ },
+ .gmem = SZ_128K,
+ .inactive_period = DRM_MSM_INACTIVE_PERIOD,
+ .init = a3xx_gpu_init,
+ }, {
+ .chip_ids = ADRENO_CHIP_IDS(0x03000520),
.family = ADRENO_3XX,
.revn = 305,
.fw = {
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index bc14df96feb0..d3c41af706df 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -256,6 +256,11 @@ static inline bool adreno_is_a305(const struct adreno_gpu
*gpu)
return adreno_is_revn(gpu, 305);
}
+static inline bool adreno_is_a305b(const struct adreno_gpu *gpu)
+{
+ return gpu->info->chip_ids[0] == 0x03000512;
+}
+
static inline bool adreno_is_a306(co
[PATCH v2 1/2] dt-bindings: display/msm: gpu: Allow multiple digits for patchid
Some GPUs like the Adreno A305B has a patchid higher than 9, in this case 18. Make sure the regexes can account for that. Acked-by: Krzysztof Kozlowski Signed-off-by: Luca Weiss --- Documentation/devicetree/bindings/display/msm/gpu.yaml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml b/Documentation/devicetree/bindings/display/msm/gpu.yaml index b019db954793..40b5c6bd11f8 100644 --- a/Documentation/devicetree/bindings/display/msm/gpu.yaml +++ b/Documentation/devicetree/bindings/display/msm/gpu.yaml @@ -23,7 +23,7 @@ properties: The driver is parsing the compat string for Adreno to figure out the gpu-id and patch level. items: - - pattern: '^qcom,adreno-[3-7][0-9][0-9]\.[0-9]$' + - pattern: '^qcom,adreno-[3-7][0-9][0-9]\.[0-9]+$' - const: qcom,adreno - description: | The driver is parsing the compat string for Imageon to @@ -127,7 +127,7 @@ allOf: properties: compatible: contains: -pattern: '^qcom,adreno-[3-5][0-9][0-9]\.[0-9]$' +pattern: '^qcom,adreno-[3-5][0-9][0-9]\.[0-9]+$' then: properties: @@ -203,7 +203,7 @@ allOf: properties: compatible: contains: - pattern: '^qcom,adreno-[67][0-9][0-9]\.[0-9]$' + pattern: '^qcom,adreno-[67][0-9][0-9]\.[0-9]+$' then: # Starting with A6xx, the clocks are usually defined in the GMU node properties: -- 2.43.0
[PATCH v2 0/2] Add GPU support for MSM8226 (Adreno A305B)
Add the necessary bits to bring up the GPU on msm8226. Tested on apq8026-lg-lenok. Signed-off-by: Luca Weiss --- Changes in v2: - Drop applied patch - Use "if (a305b || a306)" for writing REG_A3XX_RBBM_CLOCK_CTL - Pick up tags - Link to v1: https://lore.kernel.org/r/20231130-msm8226-gpu-v1-0-6bb2f1b29...@z3ntu.xyz --- Luca Weiss (2): dt-bindings: display/msm: gpu: Allow multiple digits for patchid drm/msm/adreno: Add A305B support Documentation/devicetree/bindings/display/msm/gpu.yaml | 6 +++--- drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 13 ++--- drivers/gpu/drm/msm/adreno/adreno_device.c | 15 +++ drivers/gpu/drm/msm/adreno/adreno_gpu.h| 5 + 4 files changed, 29 insertions(+), 10 deletions(-) --- base-commit: bda7a2e04984237bc14ade7c9660f76fbc035686 change-id: 20231130-msm8226-gpu-c2ff8473a9ff Best regards, -- Luca Weiss
Re: [PATCH v2 2/4] drm/panel: Add driver for DJN HX83112A LCD panel
On Fri Jan 12, 2024 at 10:14 AM CET, Neil Armstrong wrote:
> On 12/01/2024 10:00, Luca Weiss wrote:
> > On Thu Jan 11, 2024 at 8:05 PM CET, Linus Walleij wrote:
> >> On Thu, Jan 11, 2024 at 4:28 PM Luca Weiss
> >> wrote:
> >>
> >>> In some internal documentation it says "LCD Driver IC" "HX83112A" and I
> >>> don't see any reference to Truly 5P65 anywhere.
> >>
> >> In the Android directory I pointed to I see this file:
> >> HX83112_Android_Driver/Truly_5p65_module_fw/UpdateFW.bat
> >>
> >> (Notice the 5p65 fw dir is *inside* the HX82112 dir)
> >>
> >> And in that file:
> >> adb push TRULY_5P65_1080_2160_HX83112A_D01C01.bin
> >> /system/etc/firmware/Himax_firmware.bin
> >>
> >> Clearly indicating that they are pushing a Truly 5P65 firmware into
> >> the Himax display firmware directory.
> >>
> >> To be fair, that is the driver for the touchscreen part of HX83112A,
> >> but ... Truly is a well known manufacturer of display controllers?
> >>
> >> But... given that you have a @fairphone.com mal address and
> >> a working relationship with them, can't you just ask?
> >>
> >>> On their website they have this sentence:
> >>
> >> All OEMs want to look like everything is their own product. It is
> >> business as usual.
> >
> > I can't tell you anything there that I don't know, sorry.
> >
> >>
> >> Further on the same note since I guess you have a datasheet)
> >> please bring in #defines for the commands (the first byte in the
> >> write sequences, for examples:
> >>
> >> + mipi_dsi_dcs_write_seq(dsi, 0xbd, 0x02);
> >> + mipi_dsi_dcs_write_seq(dsi, 0xd8,
> >> + 0xaa, 0xff, 0xff, 0xff, 0xff, 0xff, 0xaa,
> >> 0xff,
> >> + 0xff, 0xff, 0xff, 0xff);
> >> + mipi_dsi_dcs_write_seq(dsi, 0xbd, 0x03);
> >>
> >> Clearly 0xbd is HX83112_CMD_SETREGBANK?
> >> (This is easily spotted from the similar structure in the
> >> existing panel-himax-hx8394.c.) So please add #defines
> >> for all commands you know, especially if you have a datasheet
> >> because we reviewers don't have them and "it's just magic
> >> bytes" isn't very compelling. It adds a lot to understanding.
> >
> > Right, the register names seem to match more or less the ones from that
> > driver, plus some new ones and some differently named ones. Will send a
> > v3 with that.
> >
> >>
> >> I strongly suspect other Himax displays such as HX8394 to
> >> be using a Truly controller as well, hence the similarities.
> >>
> >> In a datasheet for their TFT800480-84-V1-E display controller
> >> Truly kept the init sequence name of void LCD_INIT_HX8290(void)
> >> for example.
> >
> > In that datasheet (assuming I'm looking at the same one?) it says
> > "Driver IC" "HX8290-A[...]" so there the display driver is manufactured
> > by Himax and not Truly to my understanding. Truly is assembling together
> > Driver + all the other parts that go into an LCD.
> >
> > For the panel used on Fairphone 4 that part is done by the company DJN.
>
> Looking at the discussion, this seems to confirm the Display+Touch IC is
> HX83112A,
> and Truly is the panel manufacturer and all assembled by DJN, so IMHO the
> initial driver is right.
>
> Perhaps the compatible should be djn,hx83112a-truly-5p65 to reflect that ?
Since there's zero indication Truly is involved in this panel in my
documentation - much less the number 5P65 - I'm not going to add that.
One other number I'm certain of is from DJN's side the model number of
this panel is 9A-3R063-1102B, which I assume is the specific combination
of components + frame and everything for Fairphone 4 device.
That one you can also find in this document (Ctrl-F for DJN)
https://www.fairphone.com/wp-content/uploads/2022/09/FP4_Information-for-repairers-and-recyclers.pdf
.. or on this picture:
https://guide-images.cdn.ifixit.com/igi/HgTquQPABg1mAMHD.huge
So something like djn,9a-3r063-1102b would also be somewhat valid I
guess?
So in short this panel is the model 9A-3R063-1102B from DJN, which uses
a Himax HX83112A driver IC.
And there's also AU Optronics listed as 玻璃厂家 ("glass manufacturer"?)
fwiw, though the display also uses Corning Gorilla Glass 5 so not sure
who's supplying what.
Regards
Luca
>
> Neil
>
> >
> > Regards
> > Luca
> >
> >>
> >> Yours,
> >> Linus Walleij
> >
Re: [PATCH v2 2/4] drm/panel: Add driver for DJN HX83112A LCD panel
On Thu Jan 11, 2024 at 8:05 PM CET, Linus Walleij wrote: > On Thu, Jan 11, 2024 at 4:28 PM Luca Weiss wrote: > > > In some internal documentation it says "LCD Driver IC" "HX83112A" and I > > don't see any reference to Truly 5P65 anywhere. > > In the Android directory I pointed to I see this file: > HX83112_Android_Driver/Truly_5p65_module_fw/UpdateFW.bat > > (Notice the 5p65 fw dir is *inside* the HX82112 dir) > > And in that file: > adb push TRULY_5P65_1080_2160_HX83112A_D01C01.bin > /system/etc/firmware/Himax_firmware.bin > > Clearly indicating that they are pushing a Truly 5P65 firmware into > the Himax display firmware directory. > > To be fair, that is the driver for the touchscreen part of HX83112A, > but ... Truly is a well known manufacturer of display controllers? > > But... given that you have a @fairphone.com mal address and > a working relationship with them, can't you just ask? > > > On their website they have this sentence: > > All OEMs want to look like everything is their own product. It is > business as usual. I can't tell you anything there that I don't know, sorry. > > Further on the same note since I guess you have a datasheet) > please bring in #defines for the commands (the first byte in the > write sequences, for examples: > > + mipi_dsi_dcs_write_seq(dsi, 0xbd, 0x02); > + mipi_dsi_dcs_write_seq(dsi, 0xd8, > + 0xaa, 0xff, 0xff, 0xff, 0xff, 0xff, 0xaa, 0xff, > + 0xff, 0xff, 0xff, 0xff); > + mipi_dsi_dcs_write_seq(dsi, 0xbd, 0x03); > > Clearly 0xbd is HX83112_CMD_SETREGBANK? > (This is easily spotted from the similar structure in the > existing panel-himax-hx8394.c.) So please add #defines > for all commands you know, especially if you have a datasheet > because we reviewers don't have them and "it's just magic > bytes" isn't very compelling. It adds a lot to understanding. Right, the register names seem to match more or less the ones from that driver, plus some new ones and some differently named ones. Will send a v3 with that. > > I strongly suspect other Himax displays such as HX8394 to > be using a Truly controller as well, hence the similarities. > > In a datasheet for their TFT800480-84-V1-E display controller > Truly kept the init sequence name of void LCD_INIT_HX8290(void) > for example. In that datasheet (assuming I'm looking at the same one?) it says "Driver IC" "HX8290-A[...]" so there the display driver is manufactured by Himax and not Truly to my understanding. Truly is assembling together Driver + all the other parts that go into an LCD. For the panel used on Fairphone 4 that part is done by the company DJN. Regards Luca > > Yours, > Linus Walleij
Re: [PATCH v2 2/4] drm/panel: Add driver for DJN HX83112A LCD panel
On Thu Jan 11, 2024 at 3:57 PM CET, Linus Walleij wrote: > On Wed, Jan 10, 2024 at 4:14 PM Luca Weiss wrote: > > > Add support for the 2340x1080 LCD DJN panel bundled with a HX83112A > > driver IC, as found on the Fairphone 4 smartphone. > > > > Signed-off-by: Luca Weiss > > This makes it sound like the Himax HX83112A is the driver IC. > > This does not seem to be the case: > https://github.com/HimaxSoftware/HX83112_Android_Driver > > The driver IC seems to be a truly 5p65. Hi Linus, In some internal documentation it says "LCD Driver IC" "HX83112A" and I don't see any reference to Truly 5P65 anywhere. On their website they have this sentence: Himax offers display drivers for mobile handset displays that combine source driver, gate driver, timing controller, frame buffer, and DC to DC circuits into a single chip in various display technologies, such as TFT-LCD, LTPS, In-Cell Touch and AMOLED. https://www.himax.com.tw/products/display-drivers/mobile-handset-applications/ While I'm not super well versed in panel driver ICs, this sounds like it should be the one to take the name from? Regards Luca > > If this is right, could you rename the driver file to truly-5p65.c > and all symbols containing hx83112 to truly_5965 or something > that indicate the driver IC instead of the panel? > > My main concern is that the next display using the same IC > need to find the right file to patch. > > Yours, > Linus Walleij
[PATCH] drm/bridge: Select DRM_KMS_HELPER for DRM_PANEL_BRIDGE
Since the kconfig symbol of DRM_PANEL_BRIDGE is only adding
bridge/panel.o to drm_kms_helper object, we need to select
DRM_KMS_HELPER to make sure the file is actually getting built.
Otherwise with certain defconfigs e.g. devm_drm_of_get_bridge will not
be properly available:
aarch64-linux-gnu-ld: drivers/phy/qualcomm/phy-qcom-qmp-combo.o: in function
`qmp_combo_bridge_attach':
drivers/phy/qualcomm/phy-qcom-qmp-combo.c:3204:(.text+0x8f4): undefined
reference to `devm_drm_of_get_bridge'
Signed-off-by: Luca Weiss
---
I can see "depends on DRM_KMS_HELPER" was removed with commit
3c3384050d68 ("drm: Don't make DRM_PANEL_BRIDGE dependent on DRM_KMS_HELPERS")
I'm not too familiar with Kconfig but it feels more correct if
PHY_QCOM_QMP_COMBO selects DRM_PANEL_BRIDGE that that's enough; and it
doesn't also has to explicitly select DRM_KMS_HELPER because of how the
objects are built in the Makefile.
Alternatively solution to this patch could be adjusting this line in
include/drm/drm_bridge.h:
-#if defined(CONFIG_OF) && defined(CONFIG_DRM_PANEL_BRIDGE)
+#if defined(CONFIG_OF) && defined(CONFIG_DRM_PANEL_BRIDGE) &&
defined(CONFIG_DRM_KMS_HELPER)
struct drm_bridge *devm_drm_of_get_bridge(struct device *dev, struct
device_node *node,
u32 port, u32 endpoint);
.. and then selecting DRM_KMS_HELPER for PHY_QCOM_QMP_COMBO.
But I think the solution in this patch is better. Let me know what you
think.
---
drivers/gpu/drm/bridge/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index ac9ec5073619..ae782b427829 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -8,6 +8,7 @@ config DRM_BRIDGE
config DRM_PANEL_BRIDGE
def_bool y
depends on DRM_BRIDGE
+ select DRM_KMS_HELPER
select DRM_PANEL
help
DRM bridge wrapper of DRM panels
---
base-commit: b9c3a1fa6fb324e691a03cf124b79f4842e65d76
change-id: 20240111-drm-panel-bridge-fixup-5c2977fb969f
Best regards,
--
Luca Weiss
[PATCH v2 4/4] arm64: dts: qcom: sm7225-fairphone-fp4: Enable display and GPU
Add the description for the display panel found on this phone.
Unfortunately the LCDB module on PM6150L isn't yet supported upstream so
we need to use a dummy regulator-fixed in the meantime.
And with this done we can also enable the GPU and set the zap shader
firmware path.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/sm6350.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts | 53 +++
2 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm6350.dtsi
b/arch/arm64/boot/dts/qcom/sm6350.dtsi
index 29008e155d62..b9f4b6be7da9 100644
--- a/arch/arm64/boot/dts/qcom/sm6350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi
@@ -1338,7 +1338,7 @@ gpu: gpu@3d0 {
status = "disabled";
- zap-shader {
+ gpu_zap_shader: zap-shader {
memory-region = <_gpu_mem>;
};
diff --git a/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
b/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
index ade619805519..9a7d0448fb68 100644
--- a/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
+++ b/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
@@ -68,6 +68,14 @@ key-volume-up {
};
};
+ /* Dummy regulator until PM6150L has LCDB VSP/VSN support */
+ lcdb_dummy: regulator-lcdb-dummy {
+ compatible = "regulator-fixed";
+ regulator-name = "lcdb_dummy";
+ regulator-min-microvolt = <550>;
+ regulator-max-microvolt = <550>;
+ };
+
reserved-memory {
/*
* The rmtfs memory region in downstream is 'dynamically
allocated'
@@ -373,6 +381,14 @@ _dma1 {
status = "okay";
};
+ {
+ status = "okay";
+};
+
+_zap_shader {
+ firmware-name = "qcom/sm7225/fairphone4/a615_zap.mbn";
+};
+
{
clock-frequency = <40>;
status = "okay";
@@ -404,6 +420,43 @@ {
status = "okay";
};
+ {
+ status = "okay";
+};
+
+_dsi0 {
+ vdda-supply = <_l22a>;
+ status = "okay";
+
+ panel@0 {
+ compatible = "fairphone,fp4-hx83112a-djn", "himax,hx83112a";
+ reg = <0>;
+
+ backlight = <_wled>;
+ reset-gpios = <_gpios 9 GPIO_ACTIVE_LOW>;
+
+ vdd1-supply = <_l1e>;
+ vsn-supply = <_dummy>;
+ vsp-supply = <_dummy>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <_dsi0_out>;
+ };
+ };
+ };
+};
+
+_dsi0_out {
+ data-lanes = <0 1 2 3>;
+ remote-endpoint = <_in>;
+};
+
+_dsi0_phy {
+ vdds-supply = <_l18a>;
+ status = "okay";
+};
+
{
firmware-name = "qcom/sm7225/fairphone4/modem.mdt";
status = "okay";
--
2.43.0
[PATCH v2 1/4] dt-bindings: display: panel: Add Himax HX83112A
Himax HX83112A is a display driver IC used to drive LCD DSI panels.
Describe it.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Luca Weiss
---
.../bindings/display/panel/himax,hx83112a.yaml | 75 ++
1 file changed, 75 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/panel/himax,hx83112a.yaml
b/Documentation/devicetree/bindings/display/panel/himax,hx83112a.yaml
new file mode 100644
index ..22f58f1da9fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/himax,hx83112a.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/himax,hx83112a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Himax HX83112A-based DSI display panels
+
+maintainers:
+ - Luca Weiss
+
+description:
+ The Himax HX83112A is a generic DSI Panel IC used to control
+ LCD panels.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+items:
+ - const: fairphone,fp4-hx83112a-djn
+ - const: himax,hx83112a
+
+ vdd1-supply:
+description: Digital voltage rail
+
+ vsn-supply:
+description: Positive source voltage rail
+
+ vsp-supply:
+description: Negative source voltage rail
+
+ reg: true
+ port: true
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - vdd1-supply
+ - vsn-supply
+ - vsp-supply
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "fairphone,fp4-hx83112a-djn", "himax,hx83112a";
+reg = <0>;
+
+backlight = <_wled>;
+reset-gpios = <_gpios 9 GPIO_ACTIVE_LOW>;
+
+vdd1-supply = <_l1e>;
+vsn-supply = <_lcdb_ncp>;
+vsp-supply = <_lcdb_ldo>;
+
+port {
+panel_in_0: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+};
+
+...
--
2.43.0
[PATCH v2 2/4] drm/panel: Add driver for DJN HX83112A LCD panel
Add support for the 2340x1080 LCD DJN panel bundled with a HX83112A
driver IC, as found on the Fairphone 4 smartphone.
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/panel/Kconfig| 10 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-himax-hx83112a.c | 352 +++
3 files changed, 363 insertions(+)
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 99e14dc212ec..3379b13df4b8 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -162,6 +162,16 @@ config DRM_PANEL_FEIYANG_FY07024DI26A30D
Say Y if you want to enable support for panels based on the
Feiyang FY07024DI26A30-D MIPI-DSI interface.
+config DRM_PANEL_HIMAX_HX83112A
+ tristate "Himax HX83112A-based DSI panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ select DRM_KMS_HELPER
+ help
+ Say Y here if you want to enable support for Himax HX83112A-based
+ display panels, such as the one found in the Fairphone 4 smartphone.
+
config DRM_PANEL_HIMAX_HX8394
tristate "HIMAX HX8394 MIPI-DSI LCD panels"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index d10c3de51c6d..c2fc4c8c8340 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_DRM_PANEL_EBBG_FT8719) += panel-ebbg-ft8719.o
obj-$(CONFIG_DRM_PANEL_ELIDA_KD35T133) += panel-elida-kd35t133.o
obj-$(CONFIG_DRM_PANEL_FEIXIN_K101_IM2BA02) += panel-feixin-k101-im2ba02.o
obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) +=
panel-feiyang-fy07024di26a30d.o
+obj-$(CONFIG_DRM_PANEL_HIMAX_HX83112A) += panel-himax-hx83112a.o
obj-$(CONFIG_DRM_PANEL_HIMAX_HX8394) += panel-himax-hx8394.o
obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9341) += panel-ilitek-ili9341.o
diff --git a/drivers/gpu/drm/panel/panel-himax-hx83112a.c
b/drivers/gpu/drm/panel/panel-himax-hx83112a.c
new file mode 100644
index ..6075fd8e
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-himax-hx83112a.c
@@ -0,0 +1,352 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Generated with linux-mdss-dsi-panel-driver-generator from vendor device
tree.
+ * Copyright (c) 2024 Luca Weiss
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+struct hx83112a_panel {
+ struct drm_panel panel;
+ struct mipi_dsi_device *dsi;
+ struct regulator_bulk_data supplies[3];
+ struct gpio_desc *reset_gpio;
+};
+
+static inline struct hx83112a_panel *to_hx83112a_panel(struct drm_panel *panel)
+{
+ return container_of(panel, struct hx83112a_panel, panel);
+}
+
+static void hx83112a_reset(struct hx83112a_panel *ctx)
+{
+ gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+ msleep(20);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+ msleep(20);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+ msleep(50);
+}
+
+static int hx83112a_on(struct hx83112a_panel *ctx)
+{
+ struct mipi_dsi_device *dsi = ctx->dsi;
+ struct device *dev = >dev;
+ int ret;
+
+ dsi->mode_flags |= MIPI_DSI_MODE_LPM;
+
+ mipi_dsi_dcs_write_seq(dsi, 0xb9, 0x83, 0x11, 0x2a);
+ mipi_dsi_dcs_write_seq(dsi, 0xb1,
+ 0x08, 0x28, 0x28, 0x83, 0x83, 0x4c, 0x4f, 0x33);
+ mipi_dsi_dcs_write_seq(dsi, 0xb2,
+ 0x00, 0x02, 0x00, 0x90, 0x24, 0x00, 0x08, 0x19,
+ 0xea, 0x11, 0x11, 0x00, 0x11, 0xa3);
+ mipi_dsi_dcs_write_seq(dsi, 0xb4,
+ 0x58, 0x68, 0x58, 0x68, 0x0f, 0xef, 0x0b, 0xc0,
+ 0x0b, 0xc0, 0x0b, 0xc0, 0x00, 0xff, 0x00, 0xff,
+ 0x00, 0x00, 0x14, 0x15, 0x00, 0x29, 0x11, 0x07,
+ 0x12, 0x00, 0x29);
+ mipi_dsi_dcs_write_seq(dsi, 0xbd, 0x02);
+ mipi_dsi_dcs_write_seq(dsi, 0xb4,
+ 0x00, 0x12, 0x12, 0x11, 0x88, 0x12, 0x12, 0x00,
+ 0x53);
+ mipi_dsi_dcs_write_seq(dsi, 0xbd, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0xbd, 0x03);
+ mipi_dsi_dcs_write_seq(dsi, 0xc1,
+ 0xff, 0xfe, 0xfb, 0xf8, 0xf4, 0xf1, 0xed, 0xe6,
+ 0xe2, 0xde, 0xdb, 0xd6, 0xd3, 0xcf, 0xca, 0xc6,
+ 0xc2, 0xbe, 0xb9, 0xb0, 0xa7, 0x9e, 0x96, 0x8d,
+ 0x84, 0x7c, 0x74, 0x6b, 0x62, 0x5a, 0x51, 0x49,
+ 0x41, 0x39, 0x31, 0x29, 0x21, 0x19, 0x12, 0x0a,
+ 0x06, 0x05, 0x02, 0x01, 0x00, 0x00, 0xc9, 0xb3,
+ 0x08, 0x0e, 0xf2, 0xe1, 0x59, 0xf4, 0x22, 0xa
[PATCH v2 3/4] arm64: dts: qcom: sm6350: Remove "disabled" state of GMU
The GMU won't probe without GPU being enabled, so we can remove the
disabled status so we don't have to explicitly enable the GMU in all the
devices that enable GPU.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/sm6350.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm6350.dtsi
b/arch/arm64/boot/dts/qcom/sm6350.dtsi
index 8fd6f4d03490..29008e155d62 100644
--- a/arch/arm64/boot/dts/qcom/sm6350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi
@@ -1449,8 +1449,6 @@ gmu: gmu@3d6a000 {
operating-points-v2 = <_opp_table>;
- status = "disabled";
-
gmu_opp_table: opp-table {
compatible = "operating-points-v2";
--
2.43.0
[PATCH v2 0/4] Add display support for Fairphone 4
Introduce the bindings and panel driver for the DJN LCD panel using HX83112A driver IC. Then we can add the panel to the device dts and also enable the GPU. Signed-off-by: Luca Weiss --- Changes in v2: - Driver: - Drop "bool prepared" from driver (Dmitry) - Use drm_connector_helper_get_modes_fixed (Dmitry) - Use dev_err_probe in error path (Dmitry) - Fix width/height variables (myself) - Dts: - Don't drop simple-framebuffer (Konrad) - Drop disablement of gmu in dtsi (Konrad) - Set zap shader path (myself) - Pick up tags - Link to v1: https://lore.kernel.org/r/20240105-fp4-panel-v1-0-1afbabc55...@fairphone.com --- Luca Weiss (4): dt-bindings: display: panel: Add Himax HX83112A drm/panel: Add driver for DJN HX83112A LCD panel arm64: dts: qcom: sm6350: Remove "disabled" state of GMU arm64: dts: qcom: sm7225-fairphone-fp4: Enable display and GPU .../bindings/display/panel/himax,hx83112a.yaml | 75 + arch/arm64/boot/dts/qcom/sm6350.dtsi | 4 +- arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts | 53 drivers/gpu/drm/panel/Kconfig | 10 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-himax-hx83112a.c | 352 + 6 files changed, 492 insertions(+), 3 deletions(-) --- base-commit: c03393f04b540b66d267a402fcc9ac2d3733b9e3 change-id: 20240105-fp4-panel-50aba8536a0a Best regards, -- Luca Weiss
Re: [PATCH 3/3] arm64: dts: qcom: sm7225-fairphone-fp4: Enable display and GPU
On Wed Jan 10, 2024 at 12:23 PM CET, Maxime Ripard wrote: > On Wed, Jan 10, 2024 at 12:00:23PM +0100, Luca Weiss wrote: > > On Wed Jan 10, 2024 at 11:58 AM CET, Konrad Dybcio wrote: > > > > > > > > > On 1/5/24 15:29, Luca Weiss wrote: > > > > Add the description for the display panel found on this phone and remove > > > > the simple-framebuffer that was in place until now > > > > > > Why? They should be able to coexist with a smooth-ish handoff > > > > Does that work upstream? I'm aware that downstream can do this but > > thought this was still missing upstream. > > It depends what you call smooth-ish I guess, but KMS handles the > handover just fine. You're likely to get a flicker during the transition > though. Right, seems to work. Also visually looks okay. fairphone-fp4:~$ dmesg | grep "frame buffer device" [0.250511] Console: switching to colour frame buffer device 135x146 [0.284146] simple-framebuffer a000.framebuffer: [drm] fb0: simpledrmdrmfb frame buffer device [2.576712] Console: switching to colour frame buffer device 135x146 [2.604907] msm_dpu ae01000.display-controller: [drm] fb0: msmdrmfb frame buffer device I thought before that having two outputs like this would cause two different framebuffers/display devices to appear, but yeah as I said seems okay. Will change in v2. Regards Luca > > Either way, the DT isn't the right place to choose, you should enable > both, and the distro will choose its policy through configuration. > > Maxime
Re: [PATCH 3/3] arm64: dts: qcom: sm7225-fairphone-fp4: Enable display and GPU
On Wed Jan 10, 2024 at 11:58 AM CET, Konrad Dybcio wrote:
>
>
> On 1/5/24 15:29, Luca Weiss wrote:
> > Add the description for the display panel found on this phone and remove
> > the simple-framebuffer that was in place until now
>
> Why? They should be able to coexist with a smooth-ish handoff
Does that work upstream? I'm aware that downstream can do this but
thought this was still missing upstream.
Didn't check what happens when you have both enabled.
>
> [...]
>
> >
> > + {
> > + status = "okay";
>
> Please kick the disablement from the SoC dtsi instead, it won't
> probe without the GPU being enabled
Ack, will include a patch in v2 for that.
>
> Konrad
[PATCH 2/3] drm/panel: Add driver for DJN HX83112A LCD panel
Add support for the 2340x1080 LCD DJN panel bundled with a HX83112A
driver IC, as found on the Fairphone 4 smartphone.
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/panel/Kconfig| 9 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-himax-hx83112a.c | 372 +++
3 files changed, 382 insertions(+)
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 99e14dc212ec..e98d329826f2 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -162,6 +162,15 @@ config DRM_PANEL_FEIYANG_FY07024DI26A30D
Say Y if you want to enable support for panels based on the
Feiyang FY07024DI26A30-D MIPI-DSI interface.
+config DRM_PANEL_HIMAX_HX83112A
+ tristate "Himax HX83112A-based DSI panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for Himax HX83112A-based
+ display panels, such as the one found in the Fairphone 4 smartphone.
+
config DRM_PANEL_HIMAX_HX8394
tristate "HIMAX HX8394 MIPI-DSI LCD panels"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index d10c3de51c6d..c2fc4c8c8340 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_DRM_PANEL_EBBG_FT8719) += panel-ebbg-ft8719.o
obj-$(CONFIG_DRM_PANEL_ELIDA_KD35T133) += panel-elida-kd35t133.o
obj-$(CONFIG_DRM_PANEL_FEIXIN_K101_IM2BA02) += panel-feixin-k101-im2ba02.o
obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) +=
panel-feiyang-fy07024di26a30d.o
+obj-$(CONFIG_DRM_PANEL_HIMAX_HX83112A) += panel-himax-hx83112a.o
obj-$(CONFIG_DRM_PANEL_HIMAX_HX8394) += panel-himax-hx8394.o
obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9341) += panel-ilitek-ili9341.o
diff --git a/drivers/gpu/drm/panel/panel-himax-hx83112a.c
b/drivers/gpu/drm/panel/panel-himax-hx83112a.c
new file mode 100644
index ..ce86aad11bf5
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-himax-hx83112a.c
@@ -0,0 +1,372 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Generated with linux-mdss-dsi-panel-driver-generator from vendor device
tree.
+ * Copyright (c) 2024 Luca Weiss
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+struct hx83112a_panel {
+ struct drm_panel panel;
+ struct mipi_dsi_device *dsi;
+ struct regulator_bulk_data supplies[3];
+ struct gpio_desc *reset_gpio;
+ bool prepared;
+};
+
+static inline struct hx83112a_panel *to_hx83112a_panel(struct drm_panel *panel)
+{
+ return container_of(panel, struct hx83112a_panel, panel);
+}
+
+static void hx83112a_reset(struct hx83112a_panel *ctx)
+{
+ gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+ msleep(20);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+ msleep(20);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+ msleep(50);
+}
+
+static int hx83112a_on(struct hx83112a_panel *ctx)
+{
+ struct mipi_dsi_device *dsi = ctx->dsi;
+ struct device *dev = >dev;
+ int ret;
+
+ dsi->mode_flags |= MIPI_DSI_MODE_LPM;
+
+ mipi_dsi_dcs_write_seq(dsi, 0xb9, 0x83, 0x11, 0x2a);
+ mipi_dsi_dcs_write_seq(dsi, 0xb1,
+ 0x08, 0x28, 0x28, 0x83, 0x83, 0x4c, 0x4f, 0x33);
+ mipi_dsi_dcs_write_seq(dsi, 0xb2,
+ 0x00, 0x02, 0x00, 0x90, 0x24, 0x00, 0x08, 0x19,
+ 0xea, 0x11, 0x11, 0x00, 0x11, 0xa3);
+ mipi_dsi_dcs_write_seq(dsi, 0xb4,
+ 0x58, 0x68, 0x58, 0x68, 0x0f, 0xef, 0x0b, 0xc0,
+ 0x0b, 0xc0, 0x0b, 0xc0, 0x00, 0xff, 0x00, 0xff,
+ 0x00, 0x00, 0x14, 0x15, 0x00, 0x29, 0x11, 0x07,
+ 0x12, 0x00, 0x29);
+ mipi_dsi_dcs_write_seq(dsi, 0xbd, 0x02);
+ mipi_dsi_dcs_write_seq(dsi, 0xb4,
+ 0x00, 0x12, 0x12, 0x11, 0x88, 0x12, 0x12, 0x00,
+ 0x53);
+ mipi_dsi_dcs_write_seq(dsi, 0xbd, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0xbd, 0x03);
+ mipi_dsi_dcs_write_seq(dsi, 0xc1,
+ 0xff, 0xfe, 0xfb, 0xf8, 0xf4, 0xf1, 0xed, 0xe6,
+ 0xe2, 0xde, 0xdb, 0xd6, 0xd3, 0xcf, 0xca, 0xc6,
+ 0xc2, 0xbe, 0xb9, 0xb0, 0xa7, 0x9e, 0x96, 0x8d,
+ 0x84, 0x7c, 0x74, 0x6b, 0x62, 0x5a, 0x51, 0x49,
+ 0x41, 0x39, 0x31, 0x29, 0x21, 0x19, 0x12, 0x0a,
+ 0x06, 0x05, 0x02, 0x01, 0x00, 0x00, 0xc9, 0xb3,
+ 0x08, 0x0e, 0xf2, 0xe1, 0x59, 0xf4, 0x22, 0xad,
+ 0x4
[PATCH 3/3] arm64: dts: qcom: sm7225-fairphone-fp4: Enable display and GPU
Add the description for the display panel found on this phone and remove
the simple-framebuffer that was in place until now. Unfortunately the
LCDB module on PM6150L isn't yet supported upstream so we need to use a
dummy regulator-fixed in the meantime.
And with this done we can also enable the GPU.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts | 62 +++
1 file changed, 53 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
b/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
index ade619805519..8eb376f2db46 100644
--- a/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
+++ b/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
@@ -45,15 +45,6 @@ chosen {
ranges;
stdout-path = "serial0:115200n8";
-
- framebuffer0: framebuffer@a00 {
- compatible = "simple-framebuffer";
- reg = <0 0xa000 0 (2340 * 1080 * 4)>;
- width = <1080>;
- height = <2340>;
- stride = <(1080 * 4)>;
- format = "a8r8g8b8";
- };
};
gpio-keys {
@@ -68,6 +59,14 @@ key-volume-up {
};
};
+ /* Dummy regulator until PM6150L has LCDB VSP/VSN support */
+ lcdb_dummy: regulator-lcdb-dummy {
+ compatible = "regulator-fixed";
+ regulator-name = "lcdb_dummy";
+ regulator-min-microvolt = <550>;
+ regulator-max-microvolt = <550>;
+ };
+
reserved-memory {
/*
* The rmtfs memory region in downstream is 'dynamically
allocated'
@@ -365,6 +364,10 @@ {
status = "okay";
};
+ {
+ status = "okay";
+};
+
_dma0 {
status = "okay";
};
@@ -373,6 +376,10 @@ _dma1 {
status = "okay";
};
+ {
+ status = "okay";
+};
+
{
clock-frequency = <40>;
status = "okay";
@@ -404,6 +411,43 @@ {
status = "okay";
};
+ {
+ status = "okay";
+};
+
+_dsi0 {
+ vdda-supply = <_l22a>;
+ status = "okay";
+
+ panel@0 {
+ compatible = "fairphone,fp4-hx83112a-djn", "himax,hx83112a";
+ reg = <0>;
+
+ backlight = <_wled>;
+ reset-gpios = <_gpios 9 GPIO_ACTIVE_LOW>;
+
+ vdd1-supply = <_l1e>;
+ vsn-supply = <_dummy>;
+ vsp-supply = <_dummy>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <_dsi0_out>;
+ };
+ };
+ };
+};
+
+_dsi0_out {
+ data-lanes = <0 1 2 3>;
+ remote-endpoint = <_in>;
+};
+
+_dsi0_phy {
+ vdds-supply = <_l18a>;
+ status = "okay";
+};
+
{
firmware-name = "qcom/sm7225/fairphone4/modem.mdt";
status = "okay";
--
2.43.0
[PATCH 1/3] dt-bindings: display: panel: Add Himax HX83112A
Himax HX83112A is a display driver IC used to drive LCD DSI panels.
Describe it.
Signed-off-by: Luca Weiss
---
.../bindings/display/panel/himax,hx83112a.yaml | 75 ++
1 file changed, 75 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/panel/himax,hx83112a.yaml
b/Documentation/devicetree/bindings/display/panel/himax,hx83112a.yaml
new file mode 100644
index ..22f58f1da9fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/himax,hx83112a.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/himax,hx83112a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Himax HX83112A-based DSI display panels
+
+maintainers:
+ - Luca Weiss
+
+description:
+ The Himax HX83112A is a generic DSI Panel IC used to control
+ LCD panels.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+items:
+ - const: fairphone,fp4-hx83112a-djn
+ - const: himax,hx83112a
+
+ vdd1-supply:
+description: Digital voltage rail
+
+ vsn-supply:
+description: Positive source voltage rail
+
+ vsp-supply:
+description: Negative source voltage rail
+
+ reg: true
+ port: true
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - vdd1-supply
+ - vsn-supply
+ - vsp-supply
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "fairphone,fp4-hx83112a-djn", "himax,hx83112a";
+reg = <0>;
+
+backlight = <_wled>;
+reset-gpios = <_gpios 9 GPIO_ACTIVE_LOW>;
+
+vdd1-supply = <_l1e>;
+vsn-supply = <_lcdb_ncp>;
+vsp-supply = <_lcdb_ldo>;
+
+port {
+panel_in_0: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+};
+
+...
--
2.43.0
[PATCH 0/3] Add display support for Fairphone 4
Introduce the bindings and panel driver for the DJN LCD panel using HX83112A driver IC. Then we can add the panel to the device dts and also enable the GPU. Signed-off-by: Luca Weiss --- Luca Weiss (3): dt-bindings: display: panel: Add Himax HX83112A drm/panel: Add driver for DJN HX83112A LCD panel arm64: dts: qcom: sm7225-fairphone-fp4: Enable display and GPU .../bindings/display/panel/himax,hx83112a.yaml | 75 + arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts | 62 +++- drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-himax-hx83112a.c | 372 + 5 files changed, 510 insertions(+), 9 deletions(-) --- base-commit: e9ad8e6186dbc420e26d2ffbb05cdce33fbf041d change-id: 20240105-fp4-panel-50aba8536a0a Best regards, -- Luca Weiss
Re: [PATCH] drm/panel/raydium-rm692e5: select CONFIG_DRM_DISPLAY_DP_HELPER
On Mon Oct 23, 2023 at 3:25 PM CEST, Neil Armstrong wrote:
> Hi,
>
> On 23/10/2023 13:55, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > As with several other panel drivers, this fails to link without the DP
> > helper library:
> >
> > ld: drivers/gpu/drm/panel/panel-raydium-rm692e5.o: in function
> > `rm692e5_prepare':
> > panel-raydium-rm692e5.c:(.text+0x11f4): undefined reference to
> > `drm_dsc_pps_payload_pack'
> >
> > Select the same symbols that the others already use.
> >
> > Fixes: 988d0ff29ecf7 ("drm/panel: Add driver for BOE RM692E5 AMOLED panel")
> > Signed-off-by: Arnd Bergmann
> > ---
> > drivers/gpu/drm/panel/Kconfig | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> > index 99e14dc212ecb..a4ac4b4fe 100644
> > --- a/drivers/gpu/drm/panel/Kconfig
> > +++ b/drivers/gpu/drm/panel/Kconfig
> > @@ -530,6 +530,8 @@ config DRM_PANEL_RAYDIUM_RM692E5
> > depends on OF
> > depends on DRM_MIPI_DSI
> > depends on BACKLIGHT_CLASS_DEVICE
> > + select DRM_DISPLAY_DP_HELPER
> > + select DRM_DISPLAY_HELPER
> > help
> > Say Y here if you want to enable support for Raydium RM692E5-based
> > display panels, such as the one found in the Fairphone 5 smartphone.
>
> Will apply once drm-misc-next-fixes is synced with the last drm-misc-next PR
> for v6.7.
Hi Neil,
I think this patch is still pending, I don't see it in linux-next.
It was also reported by a buildbot today
https://lore.kernel.org/lkml/202312281138.phn1js8s-...@intel.com/
Regards
Luca
>
> Neil
Re: [PATCH 2/3] drm/msm/adreno: Add A305B support
On Donnerstag, 30. November 2023 21:35:19 CET Luca Weiss wrote:
> Add support for the Adreno 305B GPU that is found in MSM8226(v2) SoC.
> Previously this was mistakenly claimed to be supported but using wrong
> a configuration.
>
> In MSM8226v1 there's also a A305B but with chipid 0x03000510 which
> should work with the same configuration but due to lack of hardware for
> testing this is not added.
>
> Signed-off-by: Luca Weiss
Hi all,
Any chance this can be picked up for v6.8? The dts patch has already been
picked up :)
Regards
Luca
> ---
> drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 15 ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 15 +++
> drivers/gpu/drm/msm/adreno/adreno_gpu.h| 5 +
> 3 files changed, 28 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c index c86b377f6f0d..5fc29801c4c7
> 100644
> --- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> @@ -134,6 +134,13 @@ static int a3xx_hw_init(struct msm_gpu *gpu)
> /* Set up AOOO: */
> gpu_write(gpu, REG_A3XX_VBIF_OUT_AXI_AOOO_EN, 0x003c);
> gpu_write(gpu, REG_A3XX_VBIF_OUT_AXI_AOOO, 0x003c003c);
> + } else if (adreno_is_a305b(adreno_gpu)) {
> + gpu_write(gpu, REG_A3XX_VBIF_IN_RD_LIM_CONF0, 0x00181818);
> + gpu_write(gpu, REG_A3XX_VBIF_IN_WR_LIM_CONF0, 0x00181818);
> + gpu_write(gpu, REG_A3XX_VBIF_OUT_RD_LIM_CONF0,
0x0018);
> + gpu_write(gpu, REG_A3XX_VBIF_OUT_WR_LIM_CONF0,
0x0018);
> + gpu_write(gpu, REG_A3XX_VBIF_DDR_OUT_MAX_BURST,
0x0303);
> + gpu_write(gpu, REG_A3XX_VBIF_ROUND_ROBIN_QOS_ARB, 0x0003);
> } else if (adreno_is_a306(adreno_gpu)) {
> gpu_write(gpu, REG_A3XX_VBIF_ROUND_ROBIN_QOS_ARB, 0x0003);
> gpu_write(gpu, REG_A3XX_VBIF_OUT_RD_LIM_CONF0,
0x000a);
> @@ -230,7 +237,9 @@ static int a3xx_hw_init(struct msm_gpu *gpu)
> gpu_write(gpu, REG_A3XX_UCHE_CACHE_MODE_CONTROL_REG, 0x0001);
>
> /* Enable Clock gating: */
> - if (adreno_is_a306(adreno_gpu))
> + if (adreno_is_a305b(adreno_gpu))
> + gpu_write(gpu, REG_A3XX_RBBM_CLOCK_CTL, 0x);
> + else if (adreno_is_a306(adreno_gpu))
> gpu_write(gpu, REG_A3XX_RBBM_CLOCK_CTL, 0x);
> else if (adreno_is_a320(adreno_gpu))
> gpu_write(gpu, REG_A3XX_RBBM_CLOCK_CTL, 0xbfff);
> @@ -333,7 +342,7 @@ static int a3xx_hw_init(struct msm_gpu *gpu)
>
AXXX_CP_QUEUE_THRESHOLDS_CSQ_IB1_START(2) |
>
AXXX_CP_QUEUE_THRESHOLDS_CSQ_IB2_START(6) |
>
AXXX_CP_QUEUE_THRESHOLDS_CSQ_ST_START(14));
> - } else if (adreno_is_a330(adreno_gpu)) {
> + } else if (adreno_is_a330(adreno_gpu) ||
adreno_is_a305b(adreno_gpu)) {
> /* NOTE: this (value take from downstream android driver)
>* includes some bits outside of the known bitfields. But
>* A330 has this "MERCIU queue" thing too, which might
> @@ -559,7 +568,7 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
> goto fail;
>
> /* if needed, allocate gmem: */
> - if (adreno_is_a330(adreno_gpu)) {
> + if (adreno_is_a330(adreno_gpu) || adreno_is_a305b(adreno_gpu)) {
> ret = adreno_gpu_ocmem_init(_gpu->base.pdev->dev,
> adreno_gpu, _gpu-
>ocmem);
> if (ret)
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> b/drivers/gpu/drm/msm/adreno/adreno_device.c index
> f62ab5257e66..7028d5449956 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> @@ -55,10 +55,17 @@ static const struct adreno_info gpulist[] = {
> .inactive_period = DRM_MSM_INACTIVE_PERIOD,
> .init = a2xx_gpu_init,
> }, {
> - .chip_ids = ADRENO_CHIP_IDS(
> - 0x03000512,
> - 0x03000520
> - ),
> + .chip_ids = ADRENO_CHIP_IDS(0x03000512),
> + .family = ADRENO_3XX,
> + .fw = {
> + [ADRENO_FW_PM4] = "a330_pm4.fw",
> + [ADRENO_FW_PFP] = "a330_pfp.fw",
> + },
> + .gmem = SZ_128K,
> + .inactive_period = DRM_MSM_INACTIVE_PERIOD,
> + .init = a3xx_gpu_init,
> + }, {
> + .chip_ids = ADRENO_CHIP_IDS(0x03000520),
> .family = ADRENO_3XX,
>
Re: [RFT PATCH v2 4/4] drm/msm/dpu: enable writeback on SM6350
On Sun Dec 3, 2023 at 1:32 AM CET, Dmitry Baryshkov wrote: > Enable WB2 hardware block, enabling writeback support on this platform. > > Signed-off-by: Dmitry Baryshkov Hi Dmitry, I've tried this on sm7225-fairphone-fp4 but having trouble testing this. I guess I'm using some ID wrong with modetest, could you check and see what I do wrong? libdrm is on version 2.4.118 from Alpine Linux/postmarketOS, kernel is v6.7.0-rc6 plus a few patches for hardware enablement (like display). See log: fairphone-fp4:~$ sudo modetest -ac trying to open device 'i915'...failed trying to open device 'amdgpu'...failed trying to open device 'radeon'...failed trying to open device 'nouveau'...failed trying to open device 'vmwgfx'...failed trying to open device 'omapdrm'...failed trying to open device 'exynos'...failed trying to open device 'tilcdc'...failed trying to open device 'msm'...done Connectors: id encoder status namesize (mm) modes encoders 32 31 connected DSI-1 65x115 1 31 modes: index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot #0 1080x2340 60.00 1080 1108 1116 1124 2340 2367 2372 2377 160304 flags: ; type: preferred, driver props: 1 EDID: flags: immutable blob blobs: value: 2 DPMS: flags: enum enums: On=0 Standby=1 Suspend=2 Off=3 value: 0 5 link-status: flags: enum enums: Good=0 Bad=1 value: 0 6 non-desktop: flags: immutable range values: 0 1 value: 0 4 TILE: flags: immutable blob blobs: value: 20 CRTC_ID: flags: object value: 63 38 0 unknown Writeback-1 0x0 0 33 props: 2 DPMS: flags: enum enums: On=0 Standby=1 Suspend=2 Off=3 value: 0 5 link-status: flags: enum enums: Good=0 Bad=1 value: 0 6 non-desktop: flags: immutable range values: 0 1 value: 0 4 TILE: flags: immutable blob blobs: value: 20 CRTC_ID: flags: object value: 0 36 WRITEBACK_OUT_FENCE_PTR: flags: range values: 0 18446744073709551615 value: 0 34 WRITEBACK_FB_ID: flags: object value: 0 35 WRITEBACK_PIXEL_FORMATS: flags: immutable blob blobs: value: 52473136424731365247323441523234 52413234414232345852323452583234 58423234415231355241313558523135 52583135415231325241313252583132 58523132424731364247323441423234 42413234425832345842323441423135 42413135584231354258313541423132 424131324258313258423132 fairphone-fp4:~$ sudo cat /sys/kernel/debug/dri/0/state plane[39]: plane-0 crtc=crtc-0 fb=66 allocated by = phoc refcount=2 format=XR24 little-endian (0x34325258) modifier=0x501 size=1080x2340 layers: size[0]=1080x2340 pitch[0]=4352 offset[0]=0 obj[0]: name=0 refcount=3 start=00101fec size=10485760 imported=no crtc-pos=1080x2340+0+0 src-pos=1080.00x2340.00+0.00+0.00 rotation=1 normalized-zpos=0 color-encoding=ITU-R BT.601 YCbCr color-range=YCbCr limited range stage=1 sspp[0]=sspp_0 multirect_mode[0]=none multirect_index[0]=solo src[0]=1080x2340+0+0 dst[0]=1080x2340+0+0 plane[45]: plane-1 crtc=(null) fb=0 crtc-pos=0x0+0+0 src-pos=0.00x0.00+0.00+0.00 rotation=1 normalized-zpos=0 color-encoding=ITU-R BT.601 YCbCr color-range=YCbCr limited range stage=0 sspp[0]=sspp_8 multirect_mode[0]=none multirect_index[0]=solo src[0]=0x0+0+0 dst[0]=0x0+0+0 plane[51]: plane-2 crtc=(null) fb=0 crtc-pos=0x0+0+0 src-pos=0.00x0.00+0.00+0.00 rotation=1 normalized-zpos=0 color-encoding=ITU-R BT.601 YCbCr color-range=YCbCr limited range
[PATCH 2/3] drm/msm/adreno: Add A305B support
Add support for the Adreno 305B GPU that is found in MSM8226(v2) SoC.
Previously this was mistakenly claimed to be supported but using wrong
a configuration.
In MSM8226v1 there's also a A305B but with chipid 0x03000510 which
should work with the same configuration but due to lack of hardware for
testing this is not added.
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 15 ---
drivers/gpu/drm/msm/adreno/adreno_device.c | 15 +++
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 5 +
3 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index c86b377f6f0d..5fc29801c4c7 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -134,6 +134,13 @@ static int a3xx_hw_init(struct msm_gpu *gpu)
/* Set up AOOO: */
gpu_write(gpu, REG_A3XX_VBIF_OUT_AXI_AOOO_EN, 0x003c);
gpu_write(gpu, REG_A3XX_VBIF_OUT_AXI_AOOO, 0x003c003c);
+ } else if (adreno_is_a305b(adreno_gpu)) {
+ gpu_write(gpu, REG_A3XX_VBIF_IN_RD_LIM_CONF0, 0x00181818);
+ gpu_write(gpu, REG_A3XX_VBIF_IN_WR_LIM_CONF0, 0x00181818);
+ gpu_write(gpu, REG_A3XX_VBIF_OUT_RD_LIM_CONF0, 0x0018);
+ gpu_write(gpu, REG_A3XX_VBIF_OUT_WR_LIM_CONF0, 0x0018);
+ gpu_write(gpu, REG_A3XX_VBIF_DDR_OUT_MAX_BURST, 0x0303);
+ gpu_write(gpu, REG_A3XX_VBIF_ROUND_ROBIN_QOS_ARB, 0x0003);
} else if (adreno_is_a306(adreno_gpu)) {
gpu_write(gpu, REG_A3XX_VBIF_ROUND_ROBIN_QOS_ARB, 0x0003);
gpu_write(gpu, REG_A3XX_VBIF_OUT_RD_LIM_CONF0, 0x000a);
@@ -230,7 +237,9 @@ static int a3xx_hw_init(struct msm_gpu *gpu)
gpu_write(gpu, REG_A3XX_UCHE_CACHE_MODE_CONTROL_REG, 0x0001);
/* Enable Clock gating: */
- if (adreno_is_a306(adreno_gpu))
+ if (adreno_is_a305b(adreno_gpu))
+ gpu_write(gpu, REG_A3XX_RBBM_CLOCK_CTL, 0x);
+ else if (adreno_is_a306(adreno_gpu))
gpu_write(gpu, REG_A3XX_RBBM_CLOCK_CTL, 0x);
else if (adreno_is_a320(adreno_gpu))
gpu_write(gpu, REG_A3XX_RBBM_CLOCK_CTL, 0xbfff);
@@ -333,7 +342,7 @@ static int a3xx_hw_init(struct msm_gpu *gpu)
AXXX_CP_QUEUE_THRESHOLDS_CSQ_IB1_START(2) |
AXXX_CP_QUEUE_THRESHOLDS_CSQ_IB2_START(6) |
AXXX_CP_QUEUE_THRESHOLDS_CSQ_ST_START(14));
- } else if (adreno_is_a330(adreno_gpu)) {
+ } else if (adreno_is_a330(adreno_gpu) || adreno_is_a305b(adreno_gpu)) {
/* NOTE: this (value take from downstream android driver)
* includes some bits outside of the known bitfields. But
* A330 has this "MERCIU queue" thing too, which might
@@ -559,7 +568,7 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
goto fail;
/* if needed, allocate gmem: */
- if (adreno_is_a330(adreno_gpu)) {
+ if (adreno_is_a330(adreno_gpu) || adreno_is_a305b(adreno_gpu)) {
ret = adreno_gpu_ocmem_init(_gpu->base.pdev->dev,
adreno_gpu, _gpu->ocmem);
if (ret)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index f62ab5257e66..7028d5449956 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -55,10 +55,17 @@ static const struct adreno_info gpulist[] = {
.inactive_period = DRM_MSM_INACTIVE_PERIOD,
.init = a2xx_gpu_init,
}, {
- .chip_ids = ADRENO_CHIP_IDS(
- 0x03000512,
- 0x03000520
- ),
+ .chip_ids = ADRENO_CHIP_IDS(0x03000512),
+ .family = ADRENO_3XX,
+ .fw = {
+ [ADRENO_FW_PM4] = "a330_pm4.fw",
+ [ADRENO_FW_PFP] = "a330_pfp.fw",
+ },
+ .gmem = SZ_128K,
+ .inactive_period = DRM_MSM_INACTIVE_PERIOD,
+ .init = a3xx_gpu_init,
+ }, {
+ .chip_ids = ADRENO_CHIP_IDS(0x03000520),
.family = ADRENO_3XX,
.revn = 305,
.fw = {
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index 80b3f6312116..c654f21499bb 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -247,6 +247,11 @@ static inline bool adreno_is_a305(const struct adreno_gpu
*gpu)
return adreno_is_revn(gpu, 305);
}
+static inline bool adreno_is_a305b(const struct adreno_gpu *gpu)
+{
+ return gpu->info->chip_i
[PATCH 1/3] dt-bindings: display/msm: gpu: Allow multiple digits for patchid
Some GPUs like the Adreno A305B has a patchid higher than 9, in this case 18. Make sure the regexes can account for that. Signed-off-by: Luca Weiss --- Documentation/devicetree/bindings/display/msm/gpu.yaml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml b/Documentation/devicetree/bindings/display/msm/gpu.yaml index b019db954793..40b5c6bd11f8 100644 --- a/Documentation/devicetree/bindings/display/msm/gpu.yaml +++ b/Documentation/devicetree/bindings/display/msm/gpu.yaml @@ -23,7 +23,7 @@ properties: The driver is parsing the compat string for Adreno to figure out the gpu-id and patch level. items: - - pattern: '^qcom,adreno-[3-7][0-9][0-9]\.[0-9]$' + - pattern: '^qcom,adreno-[3-7][0-9][0-9]\.[0-9]+$' - const: qcom,adreno - description: | The driver is parsing the compat string for Imageon to @@ -127,7 +127,7 @@ allOf: properties: compatible: contains: -pattern: '^qcom,adreno-[3-5][0-9][0-9]\.[0-9]$' +pattern: '^qcom,adreno-[3-5][0-9][0-9]\.[0-9]+$' then: properties: @@ -203,7 +203,7 @@ allOf: properties: compatible: contains: - pattern: '^qcom,adreno-[67][0-9][0-9]\.[0-9]$' + pattern: '^qcom,adreno-[67][0-9][0-9]\.[0-9]+$' then: # Starting with A6xx, the clocks are usually defined in the GMU node properties: -- 2.43.0
[PATCH 0/3] Add GPU support for MSM8226 (Adreno A305B)
Add the necessary bits to bring up the GPU on msm8226. Tested on apq8026-lg-lenok. Signed-off-by: Luca Weiss --- Luca Weiss (3): dt-bindings: display/msm: gpu: Allow multiple digits for patchid drm/msm/adreno: Add A305B support ARM: dts: qcom: msm8226: Add GPU .../devicetree/bindings/display/msm/gpu.yaml | 6 ++-- arch/arm/boot/dts/qcom/qcom-msm8226.dtsi | 40 ++ drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 15 ++-- drivers/gpu/drm/msm/adreno/adreno_device.c | 15 +--- drivers/gpu/drm/msm/adreno/adreno_gpu.h| 5 +++ 5 files changed, 71 insertions(+), 10 deletions(-) --- base-commit: 32bbbdc6dbe6ca65a3e3e2ed2ca3c562793e7797 change-id: 20231130-msm8226-gpu-c2ff8473a9ff Best regards, -- Luca Weiss
[PATCH 3/3] ARM: dts: qcom: msm8226: Add GPU
The msm8226 SoC contains an Adreno 305B. Add a node to configure it.
Signed-off-by: Luca Weiss
---
arch/arm/boot/dts/qcom/qcom-msm8226.dtsi | 40
1 file changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8226.dtsi
b/arch/arm/boot/dts/qcom/qcom-msm8226.dtsi
index 5cd03ea7b084..9b43766df8f8 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8226.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8226.dtsi
@@ -1006,6 +1006,46 @@ mdss_dsi0_phy: phy@fd922a00 {
"ref";
};
};
+
+ gpu: adreno@fdb0 {
+ compatible = "qcom,adreno-305.18", "qcom,adreno";
+ reg = <0xfdb0 0x1>;
+ reg-names = "kgsl_3d0_reg_memory";
+
+ interrupts = ;
+ interrupt-names = "kgsl_3d0_irq";
+
+ clocks = < OXILI_GFX3D_CLK>,
+< OXILICX_AHB_CLK>,
+< OXILICX_AXI_CLK>;
+ clock-names = "core", "iface", "mem_iface";
+
+ sram = <_sram>;
+ power-domains = < OXILICX_GDSC>;
+ operating-points-v2 = <_opp_table>;
+
+ status = "disabled";
+
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-45000 {
+ opp-hz = /bits/ 64 <45000>;
+ };
+
+ opp-32000 {
+ opp-hz = /bits/ 64 <32000>;
+ };
+
+ opp-2 {
+ opp-hz = /bits/ 64 <2>;
+ };
+
+ opp-1900 {
+ opp-hz = /bits/ 64 <1900>;
+ };
+ };
+ };
};
thermal-zones {
--
2.43.0
Re: [RFC PATCH 1/3] drm/msm/dpu: add support for MSM8953
On Freitag, 6. Oktober 2023 15:38:51 CEST Dmitry Baryshkov wrote: > On 29/09/2023 23:52, Luca Weiss wrote: > > On Samstag, 23. September 2023 23:49:10 CEST Dmitry Baryshkov wrote: > >> Experimental support for MSM8953, which has MDP5 v1.16. It looks like > >> trimmed down version of MSM8996. Less SSPP, LM and PP blocks. No DSC, > >> etc. > > > > Hi Dmitry, > > > > As written on IRC, on sdm632-fairphone-fp3 with this DPU patches the > > screen is initializing and displaying stuff :) But there's some errors, > > which presumably are the reason that the screen is only updating a few > > times per second. > > > > [ 22.774205] [drm:dpu_kms_hw_init:1164] dpu hardware revision:0x1010 > > [ 23.099806] [drm:_dpu_encoder_phys_cmd_wait_for_ctl_start:657] [dpu > > error]enc31 intf1 ctl start interrupt wait failed [ 23.099821] > > [drm:dpu_kms_wait_for_commit_done:495] [dpu error]wait for commit done > > returned -22 > > > > These messages appear about 13 times per second but as I mentioned, the > > screen *is* updating (slowly) there. > > For my understanding, does it work with the MDP5 driver? Not perfectly, but it does work. What I mean is that the panel is running at 30Hz (shown e.g. with kmscube) instead of the 60Hz it should run at. One of the comments I got is that mdp5 is essentially unmaintained so I should try DPU ;) Also I can ask someone with a video-mode panel to test, maybe it works better there. At least good to have more data points? Regards Luca > > > Also you for sure forgot to add "qcom,msm8953-mdp5" to the > > msm_mdp5_dpu_migration list, without this DPU is never even considered for > > 8953.
Re: [RFC PATCH 1/3] drm/msm/dpu: add support for MSM8953
On Samstag, 23. September 2023 23:49:10 CEST Dmitry Baryshkov wrote:
> Experimental support for MSM8953, which has MDP5 v1.16. It looks like
> trimmed down version of MSM8996. Less SSPP, LM and PP blocks. No DSC,
> etc.
>
Hi Dmitry,
As written on IRC, on sdm632-fairphone-fp3 with this DPU patches the screen is
initializing and displaying stuff :) But there's some errors, which presumably
are the reason that the screen is only updating a few times per second.
[ 22.774205] [drm:dpu_kms_hw_init:1164] dpu hardware revision:0x1010
[ 23.099806] [drm:_dpu_encoder_phys_cmd_wait_for_ctl_start:657] [dpu
error]enc31 intf1 ctl start interrupt wait failed
[ 23.099821] [drm:dpu_kms_wait_for_commit_done:495] [dpu error]wait for
commit done returned -22
These messages appear about 13 times per second but as I mentioned, the screen
*is* updating (slowly) there.
Also you for sure forgot to add "qcom,msm8953-mdp5" to the
msm_mdp5_dpu_migration list, without this DPU is never even considered for
8953.
Regards
Luca
> Signed-off-by: Dmitry Baryshkov
> ---
> .../msm/disp/dpu1/catalog/dpu_1_16_msm8953.h | 221 ++
> .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 12 +
> .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 1 +
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 +
> 4 files changed, 235 insertions(+)
> create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_1_16_msm8953.h
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_1_16_msm8953.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_1_16_msm8953.h new file mode
> 100644
> index ..6944bfa4568a
> --- /dev/null
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_1_16_msm8953.h
> @@ -0,0 +1,221 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (c) 2023, Linaro Limited
> + */
> +
> +#ifndef _DPU_1_16_MSM8953_H
> +#define _DPU_1_16_MSM8953_H
> +
> +static const struct dpu_caps msm8953_dpu_caps = {
> + .max_mixer_width = DEFAULT_DPU_LINE_WIDTH,
> + .max_mixer_blendstages = 0x4,
> + .max_linewidth = DEFAULT_DPU_LINE_WIDTH,
> + .pixel_ram_size = 40 * 1024,
> + .max_hdeci_exp = MAX_HORZ_DECIMATION,
> + .max_vdeci_exp = MAX_VERT_DECIMATION,
> +};
> +
> +static const struct dpu_mdp_cfg msm8953_mdp[] = {
> + {
> + .name = "top_0",
> + .base = 0x0, .len = 0x454,
> + .features = BIT(DPU_MDP_VSYNC_SEL),
> + .clk_ctrls = {
> + [DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0
> },
> + [DPU_CLK_CTRL_RGB0] = { .reg_off = 0x2ac, .bit_off = 4
> },
> + [DPU_CLK_CTRL_RGB1] = { .reg_off = 0x2b4, .bit_off = 4
> },
> + [DPU_CLK_CTRL_DMA0] = { .reg_off = 0x2ac, .bit_off = 8
> },
> + [DPU_CLK_CTRL_CURSOR0] = { .reg_off = 0x3a8, .bit_off =
> 16 },
> + },
> + },
> +};
> +
> +static const struct dpu_ctl_cfg msm8953_ctl[] = {
> + {
> + .name = "ctl_0", .id = CTL_0,
> + .base = 0x1000, .len = 0x64,
> + .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
> + }, {
> + .name = "ctl_1", .id = CTL_1,
> + .base = 0x1200, .len = 0x64,
> + .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 10),
> + }, {
> + .name = "ctl_2", .id = CTL_2,
> + .base = 0x1400, .len = 0x64,
> + .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 11),
> + },
> +};
> +
> +static const struct dpu_sspp_cfg msm8953_sspp[] = {
> + {
> + .name = "sspp_0", .id = SSPP_VIG0,
> + .base = 0x4000, .len = 0x150,
> + .features = VIG_MSM8953_MASK,
> + .sblk = _vig_sblk_qseed2,
> + .xin_id = 0,
> + .type = SSPP_TYPE_VIG,
> + .clk_ctrl = DPU_CLK_CTRL_VIG0,
> + }, {
> + .name = "sspp_4", .id = SSPP_RGB0,
> + .base = 0x14000, .len = 0x150,
> + .features = RGB_MSM8953_MASK,
> + .sblk = _rgb_sblk,
> + .xin_id = 1,
> + .type = SSPP_TYPE_RGB,
> + .clk_ctrl = DPU_CLK_CTRL_RGB0,
> + }, {
> + .name = "sspp_5", .id = SSPP_RGB1,
> + .base = 0x16000, .len = 0x150,
> + .features = RGB_MSM8953_MASK,
> + .sblk = _rgb_sblk,
> + .xin_id = 5,
> + .type = SSPP_TYPE_RGB,
> + .clk_ctrl = DPU_CLK_CTRL_RGB1,
> + }, {
> + .name = "sspp_8", .id = SSPP_DMA0,
> + .base = 0x24000, .len = 0x150,
> + .features = DMA_MSM8953_MASK | BIT(DPU_SSPP_CURSOR),
> + .sblk = _dma_sblk,
> + .xin_id = 2,
> + .type = SSPP_TYPE_DMA,
> + .clk_ctrl = DPU_CLK_CTRL_DMA0,
> + },
> +};
> +
> +static const struct dpu_lm_cfg msm8953_lm[] = {
> + {
> + .name = "lm_0", .id = LM_0,
> + .base = 0x44000, .len = 0x320,
> +
Re: [Freedreno] [PATCH v3 6/7] drm/msm/dsi: Add phy configuration for MSM8226
On Mittwoch, 7. Juni 2023 21:46:31 CEST Jeykumar Sankaran wrote:
> On 6/1/2023 10:00 AM, Luca Weiss wrote:
> > MSM8226 uses a modified PLL lock sequence compared to MSM8974, which is
> > based on the function dsi_pll_enable_seq_m in the msm-3.10 kernel.
> >
> > Worth noting that the msm-3.10 downstream kernel also will try other
> > sequences in case this one doesn't work, but during testing it has shown
> >
> > that the _m sequence succeeds first time also:
> >.pll_enable_seqs[0] = dsi_pll_enable_seq_m,
> >.pll_enable_seqs[1] = dsi_pll_enable_seq_m,
> >.pll_enable_seqs[2] = dsi_pll_enable_seq_d,
> >.pll_enable_seqs[3] = dsi_pll_enable_seq_d,
> >.pll_enable_seqs[4] = dsi_pll_enable_seq_f1,
> >.pll_enable_seqs[5] = dsi_pll_enable_seq_c,
> >.pll_enable_seqs[6] = dsi_pll_enable_seq_e,
> >
> > We may need to expand this in the future.
> >
> > Signed-off-by: Luca Weiss
> > ---
> >
> > drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 +
> > drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 3 +-
> > drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 97
> > ++ 3 files changed, 101 insertions(+), 1
> > deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
> > b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c index bb09cbe8ff86..9d5795c58a98
> > 100644
> > --- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
> > +++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
> > @@ -541,6 +541,8 @@ static const struct of_device_id dsi_phy_dt_match[] =
> > {
> >
> > .data = _phy_28nm_hpm_famb_cfgs },
> >
> > { .compatible = "qcom,dsi-phy-28nm-lp",
> >
> > .data = _phy_28nm_lp_cfgs },
> >
> > + { .compatible = "qcom,dsi-phy-28nm-8226",
> > + .data = _phy_28nm_8226_cfgs },
> >
> > #endif
> > #ifdef CONFIG_DRM_MSM_DSI_20NM_PHY
> >
> > { .compatible = "qcom,dsi-phy-20nm",
> >
> > diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
> > b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h index 7137a17ae523..8b640d174785
> > 100644
> > --- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
> > +++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
> > @@ -46,8 +46,9 @@ struct msm_dsi_phy_cfg {
> >
> > extern const struct msm_dsi_phy_cfg dsi_phy_28nm_hpm_cfgs;
> > extern const struct msm_dsi_phy_cfg dsi_phy_28nm_hpm_famb_cfgs;
> > extern const struct msm_dsi_phy_cfg dsi_phy_28nm_lp_cfgs;
> >
> > -extern const struct msm_dsi_phy_cfg dsi_phy_20nm_cfgs;
> > +extern const struct msm_dsi_phy_cfg dsi_phy_28nm_8226_cfgs;
> >
> > extern const struct msm_dsi_phy_cfg dsi_phy_28nm_8960_cfgs;
> >
> > +extern const struct msm_dsi_phy_cfg dsi_phy_20nm_cfgs;
> >
> > extern const struct msm_dsi_phy_cfg dsi_phy_14nm_cfgs;
> > extern const struct msm_dsi_phy_cfg dsi_phy_14nm_660_cfgs;
> > extern const struct msm_dsi_phy_cfg dsi_phy_14nm_2290_cfgs;
> >
> > diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
> > b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c index
> > 4c1bf55c5f38..ceec7bb87bf1 100644
> > --- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
> > +++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
> > @@ -37,6 +37,7 @@
> >
> > /* v2.0.0 28nm LP implementation */
> > #define DSI_PHY_28NM_QUIRK_PHY_LP BIT(0)
> >
> > +#define DSI_PHY_28NM_QUIRK_PHY_8226BIT(1)
> >
> > #define LPFR_LUT_SIZE 10
> > struct lpfr_cfg {
> >
> > @@ -377,6 +378,74 @@ static int dsi_pll_28nm_vco_prepare_hpm(struct clk_hw
> > *hw)>
> > return ret;
> >
> > }
> >
> > +static int dsi_pll_28nm_vco_prepare_8226(struct clk_hw *hw)
> > +{
> > + struct dsi_pll_28nm *pll_28nm = to_pll_28nm(hw);
> > + struct device *dev = _28nm->phy->pdev->dev;
> > + void __iomem *base = pll_28nm->phy->pll_base;
> > + u32 max_reads = 5, timeout_us = 100;
> > + bool locked;
> > + u32 val;
> > + int i;
> > +
> > + DBG("id=%d", pll_28nm->phy->id);
> > +
> > + pll_28nm_software_reset(pll_28nm);
> > +
> > + /*
> > +* PLL power up sequence.
> > +* Add necessary delays recommended by hardware.
> > +*/
> > + dsi_phy_write(base + REG_DSI_28nm_PHY_PLL_CAL_CFG1, 0x34);
> > +
> > + val = DSI_28nm_PHY_PLL_GLB_CFG_PLL_PWRDN_B;
> > + dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 200);
> >
[PATCH v3 7/7] ARM: dts: qcom: msm8226: Add mdss nodes
Add the nodes that describe the mdss so that display can work on
MSM8226.
Signed-off-by: Luca Weiss
---
arch/arm/boot/dts/qcom-msm8226.dtsi | 127
1 file changed, 127 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8226.dtsi
b/arch/arm/boot/dts/qcom-msm8226.dtsi
index 42acb9ddb8cc..9f53747d2990 100644
--- a/arch/arm/boot/dts/qcom-msm8226.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8226.dtsi
@@ -636,6 +636,133 @@ smd-edge {
label = "lpass";
};
};
+
+ mdss: display-subsystem@fd90 {
+ compatible = "qcom,mdss";
+ reg = <0xfd90 0x100>, <0xfd924000 0x1000>;
+ reg-names = "mdss_phys", "vbif_phys";
+
+ power-domains = < MDSS_GDSC>;
+
+ clocks = < MDSS_AHB_CLK>,
+< MDSS_AXI_CLK>,
+< MDSS_VSYNC_CLK>;
+ clock-names = "iface",
+ "bus",
+ "vsync";
+
+ interrupts = ;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ status = "disabled";
+
+ mdss_mdp: display-controller@fd90 {
+ compatible = "qcom,msm8226-mdp5", "qcom,mdp5";
+ reg = <0xfd900100 0x22000>;
+ reg-names = "mdp_phys";
+
+ interrupt-parent = <>;
+ interrupts = <0>;
+
+ clocks = < MDSS_AHB_CLK>,
+< MDSS_AXI_CLK>,
+< MDSS_MDP_CLK>,
+< MDSS_VSYNC_CLK>;
+ clock-names = "iface",
+ "bus",
+ "core",
+ "vsync";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mdss_mdp_intf1_out: endpoint {
+ remote-endpoint =
<_dsi0_in>;
+ };
+ };
+ };
+ };
+
+ mdss_dsi0: dsi@fd922800 {
+ compatible = "qcom,msm8226-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
+ reg = <0xfd922800 0x1f8>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <>;
+ interrupts = <4>;
+
+ assigned-clocks = < BYTE0_CLK_SRC>,
+ < PCLK0_CLK_SRC>;
+ assigned-clock-parents = <_dsi0_phy 0>,
+<_dsi0_phy 1>;
+
+ clocks = < MDSS_MDP_CLK>,
+< MDSS_AHB_CLK>,
+< MDSS_AXI_CLK>,
+< MDSS_BYTE0_CLK>,
+< MDSS_PCLK0_CLK>,
+< MDSS_ESC0_CLK>,
+< MMSS_MISC_AHB_CLK>;
+ clock-names = "mdp_core",
+ "iface",
+ "bus",
+ "byte",
+ "pixel",
+ "core",
+ "core_mmss";
+
+ phys = <_dsi0_phy>;
+
+ #address-cells = <1>;
+
[PATCH v3 0/7] Display support for MSM8226
This series adds the required configs for MDP5 and DSI blocks that are needed for MDSS on MSM8226. Finally we can add the new nodes into the dts. Tested on apq8026-lg-lenok and msm8926-htc-memul. Signed-off-by: Luca Weiss --- Changes in v3: - Adjust mdss labels to new style (Stephan) - Link to v2: https://lore.kernel.org/r/20230308-msm8226-mdp-v2-0-e005b769e...@z3ntu.xyz Changes in v2: - In dsi-phy-28nm.yaml fix the order of the compatibles 1/7 (Conor) - Remove leftover debugging comments from 6/7 (Konrad) - Rewrap some clock-names lines and move status property last in 7/7 (Konrad) - Pick up tags - Link to v1: https://lore.kernel.org/r/20230308-msm8226-mdp-v1-0-679f335d3...@z3ntu.xyz --- Luca Weiss (7): dt-bindings: msm: dsi-phy-28nm: Document msm8226 compatible dt-bindings: display/msm: dsi-controller-main: Add msm8226 compatible dt-bindings: display/msm: qcom,mdp5: Add msm8226 compatible drm/msm/mdp5: Add MDP5 configuration for MSM8226 drm/msm/dsi: Add configuration for MSM8226 drm/msm/dsi: Add phy configuration for MSM8226 ARM: dts: qcom: msm8226: Add mdss nodes .../bindings/display/msm/dsi-controller-main.yaml | 2 + .../bindings/display/msm/dsi-phy-28nm.yaml | 3 +- .../devicetree/bindings/display/msm/qcom,mdp5.yaml | 1 + .../devicetree/bindings/display/msm/qcom,mdss.yaml | 1 + arch/arm/boot/dts/qcom-msm8226.dtsi| 127 + drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 82 + drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 + drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 + drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 + drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 3 +- drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 97 11 files changed, 319 insertions(+), 2 deletions(-) --- base-commit: 1b3183710d69a48baf728cc1bee9f1fb3cfeb507 change-id: 20230308-msm8226-mdp-6431e8d672a0 Best regards, -- Luca Weiss
[PATCH v3 1/7] dt-bindings: msm: dsi-phy-28nm: Document msm8226 compatible
The MSM8226 SoC uses a slightly different 28nm dsi phy. Add a new compatible for it. And while we're at it, in the dsi-phy-28nm.yaml move the 8960 compatible to its correct place so its sorted alphabetically. Acked-by: Conor Dooley Signed-off-by: Luca Weiss --- Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml | 3 ++- Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml| 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml index cf4a338c4661..62fb3e484eb2 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml @@ -15,10 +15,11 @@ allOf: properties: compatible: enum: + - qcom,dsi-phy-28nm-8226 + - qcom,dsi-phy-28nm-8960 - qcom,dsi-phy-28nm-hpm - qcom,dsi-phy-28nm-hpm-fam-b - qcom,dsi-phy-28nm-lp - - qcom,dsi-phy-28nm-8960 reg: items: diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml index b0100105e428..db9f07c6142d 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml @@ -125,6 +125,7 @@ patternProperties: - qcom,dsi-phy-14nm-660 - qcom,dsi-phy-14nm-8953 - qcom,dsi-phy-20nm + - qcom,dsi-phy-28nm-8226 - qcom,dsi-phy-28nm-hpm - qcom,dsi-phy-28nm-lp - qcom,hdmi-phy-8084 -- 2.40.1
[PATCH v3 4/7] drm/msm/mdp5: Add MDP5 configuration for MSM8226
Add the required config for the v1.1 MDP5 found on MSM8226.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 82
1 file changed, 82 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
index 2eec2d78f32a..694d54341337 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
@@ -103,6 +103,87 @@ static const struct mdp5_cfg_hw msm8x74v1_config = {
.max_clk = 2,
};
+static const struct mdp5_cfg_hw msm8x26_config = {
+ .name = "msm8x26",
+ .mdp = {
+ .count = 1,
+ .caps = MDP_CAP_SMP |
+ 0,
+ },
+ .smp = {
+ .mmb_count = 7,
+ .mmb_size = 4096,
+ .clients = {
+ [SSPP_VIG0] = 1,
+ [SSPP_DMA0] = 4,
+ [SSPP_RGB0] = 7,
+ },
+ },
+ .ctl = {
+ .count = 2,
+ .base = { 0x00500, 0x00600 },
+ .flush_hw_mask = 0x0003,
+ },
+ .pipe_vig = {
+ .count = 1,
+ .base = { 0x01100 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SCALE |
+ MDP_PIPE_CAP_CSC |
+ 0,
+ },
+ .pipe_rgb = {
+ .count = 1,
+ .base = { 0x01d00 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SCALE |
+ 0,
+ },
+ .pipe_dma = {
+ .count = 1,
+ .base = { 0x02900 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ 0,
+ },
+ .lm = {
+ .count = 2,
+ .base = { 0x03100, 0x03d00 },
+ .instances = {
+ { .id = 0, .pp = 0, .dspp = 0,
+ .caps = MDP_LM_CAP_DISPLAY, },
+ { .id = 1, .pp = -1, .dspp = -1,
+ .caps = MDP_LM_CAP_WB },
+},
+ .nb_stages = 2,
+ .max_width = 2048,
+ .max_height = 0x,
+ },
+ .dspp = {
+ .count = 1,
+ .base = { 0x04500 },
+ },
+ .pp = {
+ .count = 1,
+ .base = { 0x21a00 },
+ },
+ .intf = {
+ .base = { 0x0, 0x21200 },
+ .connect = {
+ [0] = INTF_DISABLED,
+ [1] = INTF_DSI,
+ },
+ },
+ .perf = {
+ .ab_inefficiency = 100,
+ .ib_inefficiency = 200,
+ .clk_inefficiency = 125
+ },
+ .max_clk = 2,
+};
+
static const struct mdp5_cfg_hw msm8x74v2_config = {
.name = "msm8x74",
.mdp = {
@@ -1236,6 +1317,7 @@ static const struct mdp5_cfg_hw sdm660_config = {
static const struct mdp5_cfg_handler cfg_handlers_v1[] = {
{ .revision = 0, .config = { .hw = _config } },
+ { .revision = 1, .config = { .hw = _config } },
{ .revision = 2, .config = { .hw = _config } },
{ .revision = 3, .config = { .hw = _config } },
{ .revision = 6, .config = { .hw = _config } },
--
2.40.1
[PATCH v3 6/7] drm/msm/dsi: Add phy configuration for MSM8226
MSM8226 uses a modified PLL lock sequence compared to MSM8974, which is
based on the function dsi_pll_enable_seq_m in the msm-3.10 kernel.
Worth noting that the msm-3.10 downstream kernel also will try other
sequences in case this one doesn't work, but during testing it has shown
that the _m sequence succeeds first time also:
.pll_enable_seqs[0] = dsi_pll_enable_seq_m,
.pll_enable_seqs[1] = dsi_pll_enable_seq_m,
.pll_enable_seqs[2] = dsi_pll_enable_seq_d,
.pll_enable_seqs[3] = dsi_pll_enable_seq_d,
.pll_enable_seqs[4] = dsi_pll_enable_seq_f1,
.pll_enable_seqs[5] = dsi_pll_enable_seq_c,
.pll_enable_seqs[6] = dsi_pll_enable_seq_e,
We may need to expand this in the future.
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 +
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 3 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 97 ++
3 files changed, 101 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index bb09cbe8ff86..9d5795c58a98 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -541,6 +541,8 @@ static const struct of_device_id dsi_phy_dt_match[] = {
.data = _phy_28nm_hpm_famb_cfgs },
{ .compatible = "qcom,dsi-phy-28nm-lp",
.data = _phy_28nm_lp_cfgs },
+ { .compatible = "qcom,dsi-phy-28nm-8226",
+ .data = _phy_28nm_8226_cfgs },
#endif
#ifdef CONFIG_DRM_MSM_DSI_20NM_PHY
{ .compatible = "qcom,dsi-phy-20nm",
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index 7137a17ae523..8b640d174785 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -46,8 +46,9 @@ struct msm_dsi_phy_cfg {
extern const struct msm_dsi_phy_cfg dsi_phy_28nm_hpm_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_28nm_hpm_famb_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_28nm_lp_cfgs;
-extern const struct msm_dsi_phy_cfg dsi_phy_20nm_cfgs;
+extern const struct msm_dsi_phy_cfg dsi_phy_28nm_8226_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_28nm_8960_cfgs;
+extern const struct msm_dsi_phy_cfg dsi_phy_20nm_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_14nm_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_14nm_660_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_14nm_2290_cfgs;
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
index 4c1bf55c5f38..ceec7bb87bf1 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
@@ -37,6 +37,7 @@
/* v2.0.0 28nm LP implementation */
#define DSI_PHY_28NM_QUIRK_PHY_LP BIT(0)
+#define DSI_PHY_28NM_QUIRK_PHY_8226BIT(1)
#define LPFR_LUT_SIZE 10
struct lpfr_cfg {
@@ -377,6 +378,74 @@ static int dsi_pll_28nm_vco_prepare_hpm(struct clk_hw *hw)
return ret;
}
+static int dsi_pll_28nm_vco_prepare_8226(struct clk_hw *hw)
+{
+ struct dsi_pll_28nm *pll_28nm = to_pll_28nm(hw);
+ struct device *dev = _28nm->phy->pdev->dev;
+ void __iomem *base = pll_28nm->phy->pll_base;
+ u32 max_reads = 5, timeout_us = 100;
+ bool locked;
+ u32 val;
+ int i;
+
+ DBG("id=%d", pll_28nm->phy->id);
+
+ pll_28nm_software_reset(pll_28nm);
+
+ /*
+* PLL power up sequence.
+* Add necessary delays recommended by hardware.
+*/
+ dsi_phy_write(base + REG_DSI_28nm_PHY_PLL_CAL_CFG1, 0x34);
+
+ val = DSI_28nm_PHY_PLL_GLB_CFG_PLL_PWRDN_B;
+ dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 200);
+
+ val |= DSI_28nm_PHY_PLL_GLB_CFG_PLL_PWRGEN_PWRDN_B;
+ dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 200);
+
+ val |= DSI_28nm_PHY_PLL_GLB_CFG_PLL_LDO_PWRDN_B;
+ val |= DSI_28nm_PHY_PLL_GLB_CFG_PLL_ENABLE;
+ dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 600);
+
+ for (i = 0; i < 7; i++) {
+ /* DSI Uniphy lock detect setting */
+ dsi_phy_write(base + REG_DSI_28nm_PHY_PLL_LKDET_CFG2, 0x0d);
+ dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_LKDET_CFG2,
+ 0x0c, 100);
+ dsi_phy_write(base + REG_DSI_28nm_PHY_PLL_LKDET_CFG2, 0x0d);
+
+ /* poll for PLL ready status */
+ locked = pll_28nm_poll_for_ready(pll_28nm,
+ max_reads, timeout_us);
+ if (locked)
+ break;
+
+ pll_28nm_software_reset(pll_28nm);
+
+ /*
+* PLL power up sequence.
+* Add necessary delays recommended by hardware.
+*/
+ dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_PWRGEN_CFG,
0x00, 5
[PATCH v3 5/7] drm/msm/dsi: Add configuration for MSM8226
Add the config for the v1.0.2 DSI found on MSM8226. We can reuse
existing bits from other revisions that are identical for v1.0.2.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Konrad Dybcio
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 ++
drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 29ccd755cc2e..8a5fb6df7210 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -245,6 +245,8 @@ static const struct msm_dsi_cfg_handler dsi_cfg_handlers[]
= {
_dsi_cfg, _dsi_v2_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_0,
_apq8084_dsi_cfg, _dsi_6g_host_ops},
+ {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_0_2,
+ _apq8084_dsi_cfg, _dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_1,
_apq8084_dsi_cfg, _dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_1_1,
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
index 91bdaf50bb1a..43f0dd74edb6 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
@@ -11,6 +11,7 @@
#define MSM_DSI_VER_MAJOR_V2 0x02
#define MSM_DSI_VER_MAJOR_6G 0x03
#define MSM_DSI_6G_VER_MINOR_V1_0 0x1000
+#define MSM_DSI_6G_VER_MINOR_V1_0_20x1002
#define MSM_DSI_6G_VER_MINOR_V1_1 0x1001
#define MSM_DSI_6G_VER_MINOR_V1_1_10x10010001
#define MSM_DSI_6G_VER_MINOR_V1_2 0x1002
--
2.40.1
[PATCH v3 2/7] dt-bindings: display/msm: dsi-controller-main: Add msm8226 compatible
Add the compatible for the DSI found on MSM8226. Acked-by: Conor Dooley Signed-off-by: Luca Weiss --- Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml index 130e16d025bc..660e0f496826 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -15,6 +15,7 @@ properties: - items: - enum: - qcom,apq8064-dsi-ctrl + - qcom,msm8226-dsi-ctrl - qcom,msm8916-dsi-ctrl - qcom,msm8953-dsi-ctrl - qcom,msm8974-dsi-ctrl @@ -256,6 +257,7 @@ allOf: compatible: contains: enum: + - qcom,msm8226-dsi-ctrl - qcom,msm8974-dsi-ctrl then: properties: -- 2.40.1
[PATCH v3 3/7] dt-bindings: display/msm: qcom,mdp5: Add msm8226 compatible
Add the compatible for the MDP5 found on MSM8226. Acked-by: Conor Dooley Signed-off-by: Luca Weiss --- Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml b/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml index a763cf8da122..2fe032d0e8f8 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml @@ -22,6 +22,7 @@ properties: - items: - enum: - qcom,apq8084-mdp5 + - qcom,msm8226-mdp5 - qcom,msm8916-mdp5 - qcom,msm8917-mdp5 - qcom,msm8953-mdp5 -- 2.40.1
[PATCH v2 7/7] ARM: dts: qcom: msm8226: Add mdss nodes
Add the nodes that describe the mdss so that display can work on
MSM8226.
Signed-off-by: Luca Weiss
---
arch/arm/boot/dts/qcom-msm8226.dtsi | 127
1 file changed, 127 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8226.dtsi
b/arch/arm/boot/dts/qcom-msm8226.dtsi
index 42acb9ddb8cc..c794f5ece1d1 100644
--- a/arch/arm/boot/dts/qcom-msm8226.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8226.dtsi
@@ -636,6 +636,133 @@ smd-edge {
label = "lpass";
};
};
+
+ mdss: display-subsystem@fd90 {
+ compatible = "qcom,mdss";
+ reg = <0xfd90 0x100>, <0xfd924000 0x1000>;
+ reg-names = "mdss_phys", "vbif_phys";
+
+ power-domains = < MDSS_GDSC>;
+
+ clocks = < MDSS_AHB_CLK>,
+< MDSS_AXI_CLK>,
+< MDSS_VSYNC_CLK>;
+ clock-names = "iface",
+ "bus",
+ "vsync";
+
+ interrupts = ;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ status = "disabled";
+
+ mdp: display-controller@fd90 {
+ compatible = "qcom,msm8226-mdp5", "qcom,mdp5";
+ reg = <0xfd900100 0x22000>;
+ reg-names = "mdp_phys";
+
+ interrupt-parent = <>;
+ interrupts = <0>;
+
+ clocks = < MDSS_AHB_CLK>,
+< MDSS_AXI_CLK>,
+< MDSS_MDP_CLK>,
+< MDSS_VSYNC_CLK>;
+ clock-names = "iface",
+ "bus",
+ "core",
+ "vsync";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mdp5_intf1_out: endpoint {
+ remote-endpoint =
<_in>;
+ };
+ };
+ };
+ };
+
+ dsi0: dsi@fd922800 {
+ compatible = "qcom,msm8226-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
+ reg = <0xfd922800 0x1f8>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <>;
+ interrupts = <4>;
+
+ assigned-clocks = < BYTE0_CLK_SRC>,
+ < PCLK0_CLK_SRC>;
+ assigned-clock-parents = <_phy0 0>,
+<_phy0 1>;
+
+ clocks = < MDSS_MDP_CLK>,
+< MDSS_AHB_CLK>,
+< MDSS_AXI_CLK>,
+< MDSS_BYTE0_CLK>,
+< MDSS_PCLK0_CLK>,
+< MDSS_ESC0_CLK>,
+< MMSS_MISC_AHB_CLK>;
+ clock-names = "mdp_core",
+ "iface",
+ "bus",
+ "byte",
+ "pixel",
+ "core",
+ "core_mmss";
+
+ phys = <_phy0>;
+
+ #address-cells = <1>;
+
[PATCH v2 5/7] drm/msm/dsi: Add configuration for MSM8226
Add the config for the v1.0.2 DSI found on MSM8226. We can reuse
existing bits from other revisions that are identical for v1.0.2.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Konrad Dybcio
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 ++
drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 29ccd755cc2e..8a5fb6df7210 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -245,6 +245,8 @@ static const struct msm_dsi_cfg_handler dsi_cfg_handlers[]
= {
_dsi_cfg, _dsi_v2_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_0,
_apq8084_dsi_cfg, _dsi_6g_host_ops},
+ {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_0_2,
+ _apq8084_dsi_cfg, _dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_1,
_apq8084_dsi_cfg, _dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_1_1,
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
index 91bdaf50bb1a..43f0dd74edb6 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
@@ -11,6 +11,7 @@
#define MSM_DSI_VER_MAJOR_V2 0x02
#define MSM_DSI_VER_MAJOR_6G 0x03
#define MSM_DSI_6G_VER_MINOR_V1_0 0x1000
+#define MSM_DSI_6G_VER_MINOR_V1_0_20x1002
#define MSM_DSI_6G_VER_MINOR_V1_1 0x1001
#define MSM_DSI_6G_VER_MINOR_V1_1_10x10010001
#define MSM_DSI_6G_VER_MINOR_V1_2 0x1002
--
2.40.1
[PATCH v2 4/7] drm/msm/mdp5: Add MDP5 configuration for MSM8226
Add the required config for the v1.1 MDP5 found on MSM8226.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 82
1 file changed, 82 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
index 2eec2d78f32a..694d54341337 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
@@ -103,6 +103,87 @@ static const struct mdp5_cfg_hw msm8x74v1_config = {
.max_clk = 2,
};
+static const struct mdp5_cfg_hw msm8x26_config = {
+ .name = "msm8x26",
+ .mdp = {
+ .count = 1,
+ .caps = MDP_CAP_SMP |
+ 0,
+ },
+ .smp = {
+ .mmb_count = 7,
+ .mmb_size = 4096,
+ .clients = {
+ [SSPP_VIG0] = 1,
+ [SSPP_DMA0] = 4,
+ [SSPP_RGB0] = 7,
+ },
+ },
+ .ctl = {
+ .count = 2,
+ .base = { 0x00500, 0x00600 },
+ .flush_hw_mask = 0x0003,
+ },
+ .pipe_vig = {
+ .count = 1,
+ .base = { 0x01100 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SCALE |
+ MDP_PIPE_CAP_CSC |
+ 0,
+ },
+ .pipe_rgb = {
+ .count = 1,
+ .base = { 0x01d00 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SCALE |
+ 0,
+ },
+ .pipe_dma = {
+ .count = 1,
+ .base = { 0x02900 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ 0,
+ },
+ .lm = {
+ .count = 2,
+ .base = { 0x03100, 0x03d00 },
+ .instances = {
+ { .id = 0, .pp = 0, .dspp = 0,
+ .caps = MDP_LM_CAP_DISPLAY, },
+ { .id = 1, .pp = -1, .dspp = -1,
+ .caps = MDP_LM_CAP_WB },
+},
+ .nb_stages = 2,
+ .max_width = 2048,
+ .max_height = 0x,
+ },
+ .dspp = {
+ .count = 1,
+ .base = { 0x04500 },
+ },
+ .pp = {
+ .count = 1,
+ .base = { 0x21a00 },
+ },
+ .intf = {
+ .base = { 0x0, 0x21200 },
+ .connect = {
+ [0] = INTF_DISABLED,
+ [1] = INTF_DSI,
+ },
+ },
+ .perf = {
+ .ab_inefficiency = 100,
+ .ib_inefficiency = 200,
+ .clk_inefficiency = 125
+ },
+ .max_clk = 2,
+};
+
static const struct mdp5_cfg_hw msm8x74v2_config = {
.name = "msm8x74",
.mdp = {
@@ -1236,6 +1317,7 @@ static const struct mdp5_cfg_hw sdm660_config = {
static const struct mdp5_cfg_handler cfg_handlers_v1[] = {
{ .revision = 0, .config = { .hw = _config } },
+ { .revision = 1, .config = { .hw = _config } },
{ .revision = 2, .config = { .hw = _config } },
{ .revision = 3, .config = { .hw = _config } },
{ .revision = 6, .config = { .hw = _config } },
--
2.40.1
[PATCH v2 2/7] dt-bindings: display/msm: dsi-controller-main: Add msm8226 compatible
Add the compatible for the DSI found on MSM8226. Acked-by: Conor Dooley Signed-off-by: Luca Weiss --- Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml index 130e16d025bc..660e0f496826 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -15,6 +15,7 @@ properties: - items: - enum: - qcom,apq8064-dsi-ctrl + - qcom,msm8226-dsi-ctrl - qcom,msm8916-dsi-ctrl - qcom,msm8953-dsi-ctrl - qcom,msm8974-dsi-ctrl @@ -256,6 +257,7 @@ allOf: compatible: contains: enum: + - qcom,msm8226-dsi-ctrl - qcom,msm8974-dsi-ctrl then: properties: -- 2.40.1
[PATCH v2 3/7] dt-bindings: display/msm: qcom,mdp5: Add msm8226 compatible
Add the compatible for the MDP5 found on MSM8226. Acked-by: Conor Dooley Signed-off-by: Luca Weiss --- Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml b/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml index a763cf8da122..2fe032d0e8f8 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml @@ -22,6 +22,7 @@ properties: - items: - enum: - qcom,apq8084-mdp5 + - qcom,msm8226-mdp5 - qcom,msm8916-mdp5 - qcom,msm8917-mdp5 - qcom,msm8953-mdp5 -- 2.40.1
[PATCH v2 6/7] drm/msm/dsi: Add phy configuration for MSM8226
MSM8226 uses a modified PLL lock sequence compared to MSM8974, which is
based on the function dsi_pll_enable_seq_m in the msm-3.10 kernel.
Worth noting that the msm-3.10 downstream kernel also will try other
sequences in case this one doesn't work, but during testing it has shown
that the _m sequence succeeds first time also:
.pll_enable_seqs[0] = dsi_pll_enable_seq_m,
.pll_enable_seqs[1] = dsi_pll_enable_seq_m,
.pll_enable_seqs[2] = dsi_pll_enable_seq_d,
.pll_enable_seqs[3] = dsi_pll_enable_seq_d,
.pll_enable_seqs[4] = dsi_pll_enable_seq_f1,
.pll_enable_seqs[5] = dsi_pll_enable_seq_c,
.pll_enable_seqs[6] = dsi_pll_enable_seq_e,
We may need to expand this in the future.
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 +
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 3 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 97 ++
3 files changed, 101 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index bb09cbe8ff86..9d5795c58a98 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -541,6 +541,8 @@ static const struct of_device_id dsi_phy_dt_match[] = {
.data = _phy_28nm_hpm_famb_cfgs },
{ .compatible = "qcom,dsi-phy-28nm-lp",
.data = _phy_28nm_lp_cfgs },
+ { .compatible = "qcom,dsi-phy-28nm-8226",
+ .data = _phy_28nm_8226_cfgs },
#endif
#ifdef CONFIG_DRM_MSM_DSI_20NM_PHY
{ .compatible = "qcom,dsi-phy-20nm",
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index 7137a17ae523..8b640d174785 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -46,8 +46,9 @@ struct msm_dsi_phy_cfg {
extern const struct msm_dsi_phy_cfg dsi_phy_28nm_hpm_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_28nm_hpm_famb_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_28nm_lp_cfgs;
-extern const struct msm_dsi_phy_cfg dsi_phy_20nm_cfgs;
+extern const struct msm_dsi_phy_cfg dsi_phy_28nm_8226_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_28nm_8960_cfgs;
+extern const struct msm_dsi_phy_cfg dsi_phy_20nm_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_14nm_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_14nm_660_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_14nm_2290_cfgs;
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
index 4c1bf55c5f38..ceec7bb87bf1 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
@@ -37,6 +37,7 @@
/* v2.0.0 28nm LP implementation */
#define DSI_PHY_28NM_QUIRK_PHY_LP BIT(0)
+#define DSI_PHY_28NM_QUIRK_PHY_8226BIT(1)
#define LPFR_LUT_SIZE 10
struct lpfr_cfg {
@@ -377,6 +378,74 @@ static int dsi_pll_28nm_vco_prepare_hpm(struct clk_hw *hw)
return ret;
}
+static int dsi_pll_28nm_vco_prepare_8226(struct clk_hw *hw)
+{
+ struct dsi_pll_28nm *pll_28nm = to_pll_28nm(hw);
+ struct device *dev = _28nm->phy->pdev->dev;
+ void __iomem *base = pll_28nm->phy->pll_base;
+ u32 max_reads = 5, timeout_us = 100;
+ bool locked;
+ u32 val;
+ int i;
+
+ DBG("id=%d", pll_28nm->phy->id);
+
+ pll_28nm_software_reset(pll_28nm);
+
+ /*
+* PLL power up sequence.
+* Add necessary delays recommended by hardware.
+*/
+ dsi_phy_write(base + REG_DSI_28nm_PHY_PLL_CAL_CFG1, 0x34);
+
+ val = DSI_28nm_PHY_PLL_GLB_CFG_PLL_PWRDN_B;
+ dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 200);
+
+ val |= DSI_28nm_PHY_PLL_GLB_CFG_PLL_PWRGEN_PWRDN_B;
+ dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 200);
+
+ val |= DSI_28nm_PHY_PLL_GLB_CFG_PLL_LDO_PWRDN_B;
+ val |= DSI_28nm_PHY_PLL_GLB_CFG_PLL_ENABLE;
+ dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 600);
+
+ for (i = 0; i < 7; i++) {
+ /* DSI Uniphy lock detect setting */
+ dsi_phy_write(base + REG_DSI_28nm_PHY_PLL_LKDET_CFG2, 0x0d);
+ dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_LKDET_CFG2,
+ 0x0c, 100);
+ dsi_phy_write(base + REG_DSI_28nm_PHY_PLL_LKDET_CFG2, 0x0d);
+
+ /* poll for PLL ready status */
+ locked = pll_28nm_poll_for_ready(pll_28nm,
+ max_reads, timeout_us);
+ if (locked)
+ break;
+
+ pll_28nm_software_reset(pll_28nm);
+
+ /*
+* PLL power up sequence.
+* Add necessary delays recommended by hardware.
+*/
+ dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_PWRGEN_CFG,
0x00, 5
[PATCH v2 0/7] Display support for MSM8226
This series adds the required configs for MDP5 and DSI blocks that are needed for MDSS on MSM8226. Finally we can add the new nodes into the dts. Tested on apq8026-lg-lenok and msm8926-htc-memul. Signed-off-by: Luca Weiss --- Changes in v2: - In dsi-phy-28nm.yaml fix the order of the compatibles 1/7 (Conor) - Remove leftover debugging comments from 6/7 (Konrad) - Rewrap some clock-names lines and move status property last in 7/7 (Konrad) - Pick up tags - Link to v1: https://lore.kernel.org/r/20230308-msm8226-mdp-v1-0-679f335d3...@z3ntu.xyz --- Luca Weiss (7): dt-bindings: msm: dsi-phy-28nm: Document msm8226 compatible dt-bindings: display/msm: dsi-controller-main: Add msm8226 compatible dt-bindings: display/msm: qcom,mdp5: Add msm8226 compatible drm/msm/mdp5: Add MDP5 configuration for MSM8226 drm/msm/dsi: Add configuration for MSM8226 drm/msm/dsi: Add phy configuration for MSM8226 ARM: dts: qcom: msm8226: Add mdss nodes .../bindings/display/msm/dsi-controller-main.yaml | 2 + .../bindings/display/msm/dsi-phy-28nm.yaml | 3 +- .../devicetree/bindings/display/msm/qcom,mdp5.yaml | 1 + .../devicetree/bindings/display/msm/qcom,mdss.yaml | 1 + arch/arm/boot/dts/qcom-msm8226.dtsi| 127 + drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 82 + drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 + drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 + drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 + drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 3 +- drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 97 11 files changed, 319 insertions(+), 2 deletions(-) --- base-commit: e5c87df1b3ab5220362ec48f907cc62ba8928b01 change-id: 20230308-msm8226-mdp-6431e8d672a0 Best regards, -- Luca Weiss
[PATCH v2 1/7] dt-bindings: msm: dsi-phy-28nm: Document msm8226 compatible
The MSM8226 SoC uses a slightly different 28nm dsi phy. Add a new compatible for it. And while we're at it, in the dsi-phy-28nm.yaml move the 8960 compatible to its correct place so its sorted alphabetically. Acked-by: Conor Dooley Signed-off-by: Luca Weiss --- Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml | 3 ++- Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml| 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml index cf4a338c4661..62fb3e484eb2 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml @@ -15,10 +15,11 @@ allOf: properties: compatible: enum: + - qcom,dsi-phy-28nm-8226 + - qcom,dsi-phy-28nm-8960 - qcom,dsi-phy-28nm-hpm - qcom,dsi-phy-28nm-hpm-fam-b - qcom,dsi-phy-28nm-lp - - qcom,dsi-phy-28nm-8960 reg: items: diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml index b0100105e428..db9f07c6142d 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml @@ -125,6 +125,7 @@ patternProperties: - qcom,dsi-phy-14nm-660 - qcom,dsi-phy-14nm-8953 - qcom,dsi-phy-20nm + - qcom,dsi-phy-28nm-8226 - qcom,dsi-phy-28nm-hpm - qcom,dsi-phy-28nm-lp - qcom,hdmi-phy-8084 -- 2.40.1
[PATCH 1/7] dt-bindings: msm: dsi-phy-28nm: Document msm8226 compatible
The MSM8226 SoC uses a slightly different 28nm dsi phy. Add a new compatible for it. Signed-off-by: Luca Weiss --- Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml | 1 + Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml| 1 + 2 files changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml index cf4a338c4661..bd70c3873ca9 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml @@ -18,6 +18,7 @@ properties: - qcom,dsi-phy-28nm-hpm - qcom,dsi-phy-28nm-hpm-fam-b - qcom,dsi-phy-28nm-lp + - qcom,dsi-phy-28nm-8226 - qcom,dsi-phy-28nm-8960 reg: diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml index b0100105e428..db9f07c6142d 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml @@ -125,6 +125,7 @@ patternProperties: - qcom,dsi-phy-14nm-660 - qcom,dsi-phy-14nm-8953 - qcom,dsi-phy-20nm + - qcom,dsi-phy-28nm-8226 - qcom,dsi-phy-28nm-hpm - qcom,dsi-phy-28nm-lp - qcom,hdmi-phy-8084 -- 2.40.1
[PATCH 5/7] drm/msm/dsi: Add configuration for MSM8226
Add the config for the v1.0.2 DSI found on MSM8226. We can reuse
existing bits from other revisions that are identical for v1.0.2.
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 ++
drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 29ccd755cc2e..8a5fb6df7210 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -245,6 +245,8 @@ static const struct msm_dsi_cfg_handler dsi_cfg_handlers[]
= {
_dsi_cfg, _dsi_v2_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_0,
_apq8084_dsi_cfg, _dsi_6g_host_ops},
+ {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_0_2,
+ _apq8084_dsi_cfg, _dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_1,
_apq8084_dsi_cfg, _dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_1_1,
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
index 91bdaf50bb1a..43f0dd74edb6 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
@@ -11,6 +11,7 @@
#define MSM_DSI_VER_MAJOR_V2 0x02
#define MSM_DSI_VER_MAJOR_6G 0x03
#define MSM_DSI_6G_VER_MINOR_V1_0 0x1000
+#define MSM_DSI_6G_VER_MINOR_V1_0_20x1002
#define MSM_DSI_6G_VER_MINOR_V1_1 0x1001
#define MSM_DSI_6G_VER_MINOR_V1_1_10x10010001
#define MSM_DSI_6G_VER_MINOR_V1_2 0x1002
--
2.40.1
[PATCH 2/7] dt-bindings: display/msm: dsi-controller-main: Add msm8226 compatible
Add the compatible for the DSI found on MSM8226. Signed-off-by: Luca Weiss --- Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml index 130e16d025bc..660e0f496826 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -15,6 +15,7 @@ properties: - items: - enum: - qcom,apq8064-dsi-ctrl + - qcom,msm8226-dsi-ctrl - qcom,msm8916-dsi-ctrl - qcom,msm8953-dsi-ctrl - qcom,msm8974-dsi-ctrl @@ -256,6 +257,7 @@ allOf: compatible: contains: enum: + - qcom,msm8226-dsi-ctrl - qcom,msm8974-dsi-ctrl then: properties: -- 2.40.1
[PATCH 0/7] Display support for MSM8226
This series adds the required configs for MDP5 and DSI blocks that are needed for MDSS on MSM8226. Finally we can add the new nodes into the dts. Tested on apq8026-lg-lenok and msm8926-htc-memul. Signed-off-by: Luca Weiss --- Luca Weiss (7): dt-bindings: msm: dsi-phy-28nm: Document msm8226 compatible dt-bindings: display/msm: dsi-controller-main: Add msm8226 compatible dt-bindings: display/msm: qcom,mdp5: Add msm8226 compatible drm/msm/mdp5: Add MDP5 configuration for MSM8226 drm/msm/dsi: Add configuration for MSM8226 drm/msm/dsi: Add phy configuration for MSM8226 ARM: dts: qcom: msm8226: Add mdss nodes .../bindings/display/msm/dsi-controller-main.yaml | 2 + .../bindings/display/msm/dsi-phy-28nm.yaml | 1 + .../devicetree/bindings/display/msm/qcom,mdp5.yaml | 1 + .../devicetree/bindings/display/msm/qcom,mdss.yaml | 1 + arch/arm/boot/dts/qcom-msm8226.dtsi| 118 + drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 82 ++ drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 + drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 + drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 + drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 3 +- drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 97 + 11 files changed, 309 insertions(+), 1 deletion(-) --- base-commit: e5c87df1b3ab5220362ec48f907cc62ba8928b01 change-id: 20230308-msm8226-mdp-6431e8d672a0 Best regards, -- Luca Weiss
[PATCH 7/7] ARM: dts: qcom: msm8226: Add mdss nodes
Add the nodes that describe the mdss so that display can work on
MSM8226.
Signed-off-by: Luca Weiss
---
arch/arm/boot/dts/qcom-msm8226.dtsi | 118
1 file changed, 118 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8226.dtsi
b/arch/arm/boot/dts/qcom-msm8226.dtsi
index 42acb9ddb8cc..182d6405032f 100644
--- a/arch/arm/boot/dts/qcom-msm8226.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8226.dtsi
@@ -636,6 +636,124 @@ smd-edge {
label = "lpass";
};
};
+
+ mdss: display-subsystem@fd90 {
+ compatible = "qcom,mdss";
+ reg = <0xfd90 0x100>, <0xfd924000 0x1000>;
+ reg-names = "mdss_phys", "vbif_phys";
+
+ power-domains = < MDSS_GDSC>;
+
+ clocks = < MDSS_AHB_CLK>,
+< MDSS_AXI_CLK>,
+< MDSS_VSYNC_CLK>;
+ clock-names = "iface", "bus", "vsync";
+
+ interrupts = ;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ status = "disabled";
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ mdp: display-controller@fd90 {
+ compatible = "qcom,msm8226-mdp5", "qcom,mdp5";
+ reg = <0xfd900100 0x22000>;
+ reg-names = "mdp_phys";
+
+ interrupt-parent = <>;
+ interrupts = <0>;
+
+ clocks = < MDSS_AHB_CLK>,
+< MDSS_AXI_CLK>,
+< MDSS_MDP_CLK>,
+< MDSS_VSYNC_CLK>;
+ clock-names = "iface", "bus", "core", "vsync";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mdp5_intf1_out: endpoint {
+ remote-endpoint =
<_in>;
+ };
+ };
+ };
+ };
+
+ dsi0: dsi@fd922800 {
+ compatible = "qcom,msm8226-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
+ reg = <0xfd922800 0x1f8>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <>;
+ interrupts = <4>;
+
+ assigned-clocks = < BYTE0_CLK_SRC>, <
PCLK0_CLK_SRC>;
+ assigned-clock-parents = <_phy0 0>,
<_phy0 1>;
+
+ clocks = < MDSS_MDP_CLK>,
+< MDSS_AHB_CLK>,
+< MDSS_AXI_CLK>,
+< MDSS_BYTE0_CLK>,
+< MDSS_PCLK0_CLK>,
+< MDSS_ESC0_CLK>,
+< MMSS_MISC_AHB_CLK>;
+ clock-names = "mdp_core",
+ "iface",
+ "bus",
+ "byte",
+ "pixel",
+ "core",
+ "core_mmss";
+
+ phys = <_phy0>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+
[PATCH 6/7] drm/msm/dsi: Add phy configuration for MSM8226
MSM8226 uses a modified PLL lock sequence compared to MSM8974, which is
based on the function dsi_pll_enable_seq_m in the msm-3.10 kernel.
Worth noting that the msm-3.10 downstream kernel also will try other
sequences in case this one doesn't work, but during testing it has shown
that the _m sequence succeeds first time also:
.pll_enable_seqs[0] = dsi_pll_enable_seq_m,
.pll_enable_seqs[1] = dsi_pll_enable_seq_m,
.pll_enable_seqs[2] = dsi_pll_enable_seq_d,
.pll_enable_seqs[3] = dsi_pll_enable_seq_d,
.pll_enable_seqs[4] = dsi_pll_enable_seq_f1,
.pll_enable_seqs[5] = dsi_pll_enable_seq_c,
.pll_enable_seqs[6] = dsi_pll_enable_seq_e,
We may need to expand this in the future.
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 +
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 3 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 97 ++
3 files changed, 101 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index bb09cbe8ff86..9d5795c58a98 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -541,6 +541,8 @@ static const struct of_device_id dsi_phy_dt_match[] = {
.data = _phy_28nm_hpm_famb_cfgs },
{ .compatible = "qcom,dsi-phy-28nm-lp",
.data = _phy_28nm_lp_cfgs },
+ { .compatible = "qcom,dsi-phy-28nm-8226",
+ .data = _phy_28nm_8226_cfgs },
#endif
#ifdef CONFIG_DRM_MSM_DSI_20NM_PHY
{ .compatible = "qcom,dsi-phy-20nm",
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index 7137a17ae523..8b640d174785 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -46,8 +46,9 @@ struct msm_dsi_phy_cfg {
extern const struct msm_dsi_phy_cfg dsi_phy_28nm_hpm_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_28nm_hpm_famb_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_28nm_lp_cfgs;
-extern const struct msm_dsi_phy_cfg dsi_phy_20nm_cfgs;
+extern const struct msm_dsi_phy_cfg dsi_phy_28nm_8226_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_28nm_8960_cfgs;
+extern const struct msm_dsi_phy_cfg dsi_phy_20nm_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_14nm_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_14nm_660_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_14nm_2290_cfgs;
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
index 4c1bf55c5f38..f71308387566 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
@@ -37,6 +37,7 @@
/* v2.0.0 28nm LP implementation */
#define DSI_PHY_28NM_QUIRK_PHY_LP BIT(0)
+#define DSI_PHY_28NM_QUIRK_PHY_8226BIT(1)
#define LPFR_LUT_SIZE 10
struct lpfr_cfg {
@@ -377,6 +378,74 @@ static int dsi_pll_28nm_vco_prepare_hpm(struct clk_hw *hw)
return ret;
}
+static int dsi_pll_28nm_vco_prepare_8226(struct clk_hw *hw)
+{
+ struct dsi_pll_28nm *pll_28nm = to_pll_28nm(hw);
+ struct device *dev = _28nm->phy->pdev->dev;
+ void __iomem *base = pll_28nm->phy->pll_base;
+ u32 max_reads = 5, timeout_us = 100;
+ bool locked;
+ u32 val;
+ int i;
+
+ DBG("id=%d", pll_28nm->phy->id);
+
+ pll_28nm_software_reset(pll_28nm);
+
+ /*
+* PLL power up sequence.
+* Add necessary delays recommended by hardware.
+*/
+ dsi_phy_write(base + REG_DSI_28nm_PHY_PLL_CAL_CFG1, 0x34);
+
+ val = DSI_28nm_PHY_PLL_GLB_CFG_PLL_PWRDN_B; // 1
+ dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 200);
+
+ val |= DSI_28nm_PHY_PLL_GLB_CFG_PLL_PWRGEN_PWRDN_B; // 4
+ dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 200);
+
+ val |= DSI_28nm_PHY_PLL_GLB_CFG_PLL_LDO_PWRDN_B; // 2
+ val |= DSI_28nm_PHY_PLL_GLB_CFG_PLL_ENABLE; // 8
+ dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 600);
+
+ for (i = 0; i < 7; i++) {
+ /* DSI Uniphy lock detect setting */
+ dsi_phy_write(base + REG_DSI_28nm_PHY_PLL_LKDET_CFG2, 0x0d);
+ dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_LKDET_CFG2,
+ 0x0c, 100);
+ dsi_phy_write(base + REG_DSI_28nm_PHY_PLL_LKDET_CFG2, 0x0d);
+
+ /* poll for PLL ready status */
+ locked = pll_28nm_poll_for_ready(pll_28nm,
+ max_reads, timeout_us);
+ if (locked)
+ break;
+
+ pll_28nm_software_reset(pll_28nm);
+
+ /*
+* PLL power up sequence.
+* Add necessary delays recommended by hardware.
+*/
+ dsi_phy_write_udelay(base + RE
[PATCH 4/7] drm/msm/mdp5: Add MDP5 configuration for MSM8226
Add the required config for the v1.1 MDP5 found on MSM8226.
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 82
1 file changed, 82 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
index 2eec2d78f32a..694d54341337 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
@@ -103,6 +103,87 @@ static const struct mdp5_cfg_hw msm8x74v1_config = {
.max_clk = 2,
};
+static const struct mdp5_cfg_hw msm8x26_config = {
+ .name = "msm8x26",
+ .mdp = {
+ .count = 1,
+ .caps = MDP_CAP_SMP |
+ 0,
+ },
+ .smp = {
+ .mmb_count = 7,
+ .mmb_size = 4096,
+ .clients = {
+ [SSPP_VIG0] = 1,
+ [SSPP_DMA0] = 4,
+ [SSPP_RGB0] = 7,
+ },
+ },
+ .ctl = {
+ .count = 2,
+ .base = { 0x00500, 0x00600 },
+ .flush_hw_mask = 0x0003,
+ },
+ .pipe_vig = {
+ .count = 1,
+ .base = { 0x01100 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SCALE |
+ MDP_PIPE_CAP_CSC |
+ 0,
+ },
+ .pipe_rgb = {
+ .count = 1,
+ .base = { 0x01d00 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SCALE |
+ 0,
+ },
+ .pipe_dma = {
+ .count = 1,
+ .base = { 0x02900 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ 0,
+ },
+ .lm = {
+ .count = 2,
+ .base = { 0x03100, 0x03d00 },
+ .instances = {
+ { .id = 0, .pp = 0, .dspp = 0,
+ .caps = MDP_LM_CAP_DISPLAY, },
+ { .id = 1, .pp = -1, .dspp = -1,
+ .caps = MDP_LM_CAP_WB },
+},
+ .nb_stages = 2,
+ .max_width = 2048,
+ .max_height = 0x,
+ },
+ .dspp = {
+ .count = 1,
+ .base = { 0x04500 },
+ },
+ .pp = {
+ .count = 1,
+ .base = { 0x21a00 },
+ },
+ .intf = {
+ .base = { 0x0, 0x21200 },
+ .connect = {
+ [0] = INTF_DISABLED,
+ [1] = INTF_DSI,
+ },
+ },
+ .perf = {
+ .ab_inefficiency = 100,
+ .ib_inefficiency = 200,
+ .clk_inefficiency = 125
+ },
+ .max_clk = 2,
+};
+
static const struct mdp5_cfg_hw msm8x74v2_config = {
.name = "msm8x74",
.mdp = {
@@ -1236,6 +1317,7 @@ static const struct mdp5_cfg_hw sdm660_config = {
static const struct mdp5_cfg_handler cfg_handlers_v1[] = {
{ .revision = 0, .config = { .hw = _config } },
+ { .revision = 1, .config = { .hw = _config } },
{ .revision = 2, .config = { .hw = _config } },
{ .revision = 3, .config = { .hw = _config } },
{ .revision = 6, .config = { .hw = _config } },
--
2.40.1
[PATCH 3/7] dt-bindings: display/msm: qcom,mdp5: Add msm8226 compatible
Add the compatible for the MDP5 found on MSM8226. Signed-off-by: Luca Weiss --- Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml b/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml index a763cf8da122..2fe032d0e8f8 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml @@ -22,6 +22,7 @@ properties: - items: - enum: - qcom,apq8084-mdp5 + - qcom,msm8226-mdp5 - qcom,msm8916-mdp5 - qcom,msm8917-mdp5 - qcom,msm8953-mdp5 -- 2.40.1
Re: [PATCH 7/8] arm64: dts: qcom: sm8450: remove invalid reg-names from ufs node
Hi Eric,
On Fri Mar 24, 2023 at 7:52 AM CET, Eric Biggers wrote:
> Hi Neil,
>
> On Thu, Mar 23, 2023 at 02:10:44PM +0100, Neil Armstrong wrote:
> > Hi,
> >
> > On 23/03/2023 11:49, Krzysztof Kozlowski wrote:
> > > On 23/03/2023 11:25, Neil Armstrong wrote:
> > > > Fixes the following DT bindings check error:
> > > > ufshc@1d84000: Unevaluated properties are not allowed ('reg-names' was
> > > > unexpected)
> > > >
> > > > Signed-off-by: Neil Armstrong
> > > > ---
> > > > arch/arm64/boot/dts/qcom/sm8450.dtsi | 1 -
> > > > 1 file changed, 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi
> > > > b/arch/arm64/boot/dts/qcom/sm8450.dtsi
> > > > index ef9bae2e6acc..8ecc48c7c5ef 100644
> > > > --- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
> > > > +++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
> > > > @@ -3996,7 +3996,6 @@ ufs_mem_hc: ufshc@1d84000 {
> > > > "jedec,ufs-2.0";
> > > > reg = <0 0x01d84000 0 0x3000>,
> > > > <0 0x01d88000 0 0x8000>;
> > > > - reg-names = "std", "ice";
> > >
> > > This is also part of:
> > > https://lore.kernel.org/linux-arm-msm/20230308155838.1094920-8-abel.v...@linaro.org/#Z31arch:arm64:boot:dts:qcom:sm8450.dtsi
> > > but I actually wonder whether you just missed some binding patch?
> >
> > I'm aware of Abel's RFC patchset to support shared ICE, but this is a
> > cleanup of the current DT,
> > and the current bindings schema doesn't document reg-names.
> >
>
> The ufs-qcom driver accesses the "ice" registers by name, so the reg-names
> can't
> be removed from the device tree. A few months ago there was a patch to fix
> the
> device tree schema for qcom,ufs to include the reg-names. It looks like that
> patch got missed, though:
> https://lore.kernel.org/r/20221209-dt-binding-ufs-v2-2-dc7a04699...@fairphone.com
Are you implying that I should resend the patch or something? Not sure
who to bug about applying this patch.
Regards
Luca
>
> - Eric
[PATCH] backlight: qcom-wled: Add PMI8950 compatible
PMI8950 contains WLED of version 4. Add support for it to the driver.
Signed-off-by: Luca Weiss
---
While adding dt-bindings and dts in a previous series I forgot to add the
compatible to the driver. Fix that now.
---
drivers/video/backlight/qcom-wled.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/backlight/qcom-wled.c
b/drivers/video/backlight/qcom-wled.c
index 527210e85795..5f504883aca5 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -1731,6 +1731,7 @@ static int wled_remove(struct platform_device *pdev)
static const struct of_device_id wled_match_table[] = {
{ .compatible = "qcom,pm8941-wled", .data = (void *)3 },
+ { .compatible = "qcom,pmi8950-wled", .data = (void *)4 },
{ .compatible = "qcom,pmi8994-wled", .data = (void *)4 },
{ .compatible = "qcom,pmi8998-wled", .data = (void *)4 },
{ .compatible = "qcom,pm660l-wled", .data = (void *)4 },
---
base-commit: 1b929c02afd37871d5afb9d498426f83432e71c2
change-id: 20221226-msm8953-6-2-wled-5f966bfa4db3
Best regards,
--
Luca Weiss
[PATCH v3 1/2] dt-bindings: backlight: qcom-wled: Add PMI8950 compatible
Document the compatible for the wled block found in PMI8950. Signed-off-by: Luca Weiss --- Changes since v2: * New patch Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml index 4c15693f7a01..5ac8605a53b1 100644 --- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml +++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml @@ -19,6 +19,7 @@ properties: compatible: enum: - qcom,pm8941-wled + - qcom,pmi8950-wled - qcom,pmi8994-wled - qcom,pmi8998-wled - qcom,pm660l-wled -- 2.38.1
Re: [PATCH v1 1/4] drm/msm/mdp5: stop overriding drvdata
Hi Dmitry,
On Montag, 20. Juni 2022 23:30:51 CEST Dmitry Baryshkov wrote:
> The rest of the code expects that master's device drvdata is the
> struct msm_drm_private instance. Do not override the mdp5's drvdata.
>
> Fixes: 6874f48bb8b0 ("drm/msm: make mdp5/dpu devices master components")
> Signed-off-by: Dmitry Baryshkov
In search of a fix for a problem on msm8974/msm8226 crashing during shutdown
I tried applying this patch.
On top of 6.0-rc6 with some of my patches incl. adding display support to
msm8226 which generally works fine without this patch, plus only this patch on
top.
Unfortunately it seems display isn't probing anymore and I'm getting a null
pointer dereference in dmesg as seen below.
Hope that's helpful so you can fix that ;)
Regards
Luca
[2.616083] platform fd922800.dsi: Fixing up cyclic dependency with
fd900100.mdp
[2.636031] msm_mdp fd900100.mdp: No interconnect support may cause display
underflows!
[2.638435] [drm] using 32m VRAM carveout
[2.646026] msm_mdp fd900100.mdp: [drm:msm_drm_bind [msm]] VRAM:
1c10->1e10
[2.647055] msm_mdp fd900100.mdp: bound fd922800.dsi (ops dsi_ops [msm])
[2.654642] 8<--- cut here ---
[2.662750] Unable to handle kernel NULL pointer dereference at virtual
address 04d8
[2.664358] [04d8] *pgd=
[2.672610] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[2.676106] Modules linked in: msm gpu_sched qnoc_msm8974 icc_smd_rpm
[2.681403] CPU: 0 PID: 108 Comm: kworker/u2:5 Not tainted
6.0.0-rc6-00034-g3b2cf6d374af #217
[2.687746] Hardware name: Generic DT based system
[2.696242] Workqueue: events_unbound deferred_probe_work_func
[2.700931] PC is at mdp5_runtime_resume+0x30/0x168 [msm]
[2.706747] LR is at mdp5_runtime_resume+0x30/0x168 [msm]
[2.712217] pc : []lr : []psr: 6013
[2.717598] sp : d0a49a48 ip : bf0c0370 fp : c196d094
[2.723671] r10: c036a9dc r9 : c2bfabc0 r8 :
[2.728880] r7 : c3079c94 r6 : c196d010 r5 : c08fab08 r4 :
[2.734092] r3 : c2bfabc0 r2 : r1 : r0 : 0002
[2.740691] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[2.747204] Control: 10c5387d Table: 1307006a DAC: 0051
[2.754403] Register r0 information: non-paged memory
[2.760129] Register r1 information: NULL pointer
[2.765163] Register r2 information: NULL pointer
[2.769850] Register r3 information: slab task_struct start c2bfabc0 pointer
offset 0
[2.774550] Register r4 information: NULL pointer
[2.782350] Register r5 information: non-slab/vmalloc memory
[2.787041] Register r6 information: slab kmalloc-1k start c196d000 pointer
offset 16 size 1024
[2.792781] Register r7 information: slab kmalloc-1k start c3079c00 pointer
offset 148 size 1024
[2.801201] Register r8 information: NULL pointer
[2.810216] Register r9 information: slab task_struct start c2bfabc0 pointer
offset 0
[2.814827] Register r10 information: non-slab/vmalloc memory
[2.822631] Register r11 information: slab kmalloc-1k start c196d000 pointer
offset 148 size 1024
[2.828371] Register r12 information: 242-page vmalloc region starting at
0xbf025000 allocated at load_module+0x9a4/0x1f44
[2.837233] Process kworker/u2:5 (pid: 108, stack limit = 0x(ptrval))
[2.848155] Stack: (0xd0a49a48 to 0xd0a4a000)
[2.854665] 9a40: c3079c10 c08fab08 c196d010 c08fd82c
c3079c10 c08fab08
[2.859020] 9a60: c196d010 0004 d0a49a9c c2bfabc0 c036a9dc c08fd9a8
c3079c10 c08fab08
[2.867179] 9a80: c196d010 c08fd0f8 c3079c10 0bebc200
ffadf800
[2.875339] 9aa0: 8807ce68 a6e11243 d0940100 6013 0004 c3079c94
c307e840 c3079c10
[2.883499] 9ac0: c3079c10 0001 c152654c c08fd484 c306b040 c3079c00
c11d4314 bf044ab8
[2.891658] 9ae0: c3079c10 d0a49b34 c3207900 0018 c3080400 c3080400
c0dd2950
[2.899818] 9b00: d0a49b14 a6e11243 3f0c81c2 c0dd29d0 c1179a84 bf0c0710
c3219ec0 d0a49b34
[2.907977] 9b20: 0004 c0492c60 c0dd2d18 d0a49b48 c117985c
c307ea34 c3080400
[2.916137] 9b40: c3079c10 cbf5b000 a6e11243 0001 c307e840
c3080400
[2.924297] 9b60: c3079c10 cbf5b000 c307e840 0001 c152654c bf071b38
1e10
[2.932457] 9b80: a6e11243 0001 c307fc08 0001 c307fc08
c3079dc0 a113
[2.940617] 9ba0: c152654c a6e11243 c152654c c3202300 c3202300 c3207900
c1526568 c32078c0
[2.948776] 9bc0: 0018 0001 c152654c c08e6a70 0001 c3202300
c3207900
[2.956935] 9be0: c3202300 c1526560 bf0b81d4 c0e9531c
c1805800 c08e6d3c
[2.965096] 9c00: c307ec40 c307fc08 c307fc08 c1526570 bf096abc
c307fc00 c3203340
[2.973256] 9c20: c307fc08 c08e61a4 c0ea4380 d0a49c30 00ff 00ff
[2.981415] 9c40: 0001 a6e11243 c307fc08
c15264f4 c08eed68
[
Re: [PATCH] i2c: qcom-geni: Fix GPI DMA buffer sync-back
Hi Robin,
On Sun Aug 7, 2022 at 4:04 PM CEST, Robin Reckmann wrote:
> Fix i2c transfers using GPI DMA mode for all message types that do not set
> the I2C_M_DMA_SAFE flag (e.g. SMBus "read byte").
>
> In this case a bounce buffer is returned by i2c_get_dma_safe_msg_buf(),
> and it has to synced back to the message after the transfer is done.
>
> Add missing assignment of dma buffer in geni_i2c_gpi().
>
> Set xferred in i2c_put_dma_safe_msg_buf() to true in case of no error to
> ensure the sync-back of this dma buffer to the message.
>
> Signed-off-by: Robin Reckmann
This makes I2C with GPI DMA work on sm6350/sm7725 fairphone-fp4!
Thanks for fixing this!
Tested-by: Luca Weiss
Regards
Luca
> ---
> drivers/i2c/busses/i2c-qcom-geni.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-qcom-geni.c
> b/drivers/i2c/busses/i2c-qcom-geni.c
> index 6ac402ea58fb..d3541e94794e 100644
> --- a/drivers/i2c/busses/i2c-qcom-geni.c
> +++ b/drivers/i2c/busses/i2c-qcom-geni.c
> @@ -484,12 +484,12 @@ static void geni_i2c_gpi_unmap(struct geni_i2c_dev
> *gi2c, struct i2c_msg *msg,
> {
> if (tx_buf) {
> dma_unmap_single(gi2c->se.dev->parent, tx_addr, msg->len,
> DMA_TO_DEVICE);
> - i2c_put_dma_safe_msg_buf(tx_buf, msg, false);
> + i2c_put_dma_safe_msg_buf(tx_buf, msg, !gi2c->err);
> }
>
> if (rx_buf) {
> dma_unmap_single(gi2c->se.dev->parent, rx_addr, msg->len,
> DMA_FROM_DEVICE);
> - i2c_put_dma_safe_msg_buf(rx_buf, msg, false);
> + i2c_put_dma_safe_msg_buf(rx_buf, msg, !gi2c->err);
> }
> }
>
> @@ -553,6 +553,7 @@ static int geni_i2c_gpi(struct geni_i2c_dev *gi2c, struct
> i2c_msg *msg,
> desc->callback_param = gi2c;
>
> dmaengine_submit(desc);
> + *buf = dma_buf;
> *dma_addr_p = addr;
>
> return 0;
> --
> 2.25.1
Re: [PATCH v3 2/4] drm/msm/adreno: Add A619 support
Hi all,
any comment on this patch series? Would be great to get this into 5.20
Regards
Luca
On Samstag, 28. Mai 2022 18:03:49 CEST Konrad Dybcio wrote:
> Add support for the Adreno 619 GPU, as found in Snapdragon 690 (SM6350),
> 480 (SM4350) and 750G (SM7225).
>
> Signed-off-by: Konrad Dybcio
> ---
> Changes since v2:
> - Fix some values in a619_build_bw_table (I think I miscopied things last
> time around..)
> - Add a comment about icache/dcache allocation for future porters
> - Resolve Dmitry's comment about BUG_ON (check patch 1/4)
>
> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 13 +++-
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 70 +-
> drivers/gpu/drm/msm/adreno/a6xx_hfi.c | 65 +++-
> drivers/gpu/drm/msm/adreno/adreno_device.c | 14 +
> drivers/gpu/drm/msm/adreno/adreno_gpu.h| 13 +++-
> 5 files changed, 169 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c index b1c876c339d0..0a7c3514e51b
> 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> @@ -527,6 +527,8 @@ static void a6xx_gmu_rpmh_init(struct a6xx_gmu *gmu)
> pdc_in_aop = true;
> else if (adreno_is_a618(adreno_gpu) ||
adreno_is_a640_family(adreno_gpu))
> pdc_address_offset = 0x30090;
> + else if (adreno_is_a619(adreno_gpu))
> + pdc_address_offset = 0x300a0;
> else
> pdc_address_offset = 0x30080;
>
> @@ -601,7 +603,8 @@ static void a6xx_gmu_rpmh_init(struct a6xx_gmu *gmu)
>
> pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS3_CMD0_MSGID + 4, 0x10108);
> pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS3_CMD0_ADDR + 4, 0x3);
> - if (adreno_is_a618(adreno_gpu) ||
adreno_is_a650_family(adreno_gpu))
> + if (adreno_is_a618(adreno_gpu) || adreno_is_a619(adreno_gpu) ||
> + adreno_is_a650_family(adreno_gpu))
> pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS3_CMD0_DATA + 4,
0x2);
> else
> pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS3_CMD0_DATA + 4,
0x3);
> @@ -1537,6 +1540,12 @@ int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct
> device_node *node) SZ_16M - SZ_16K, 0x04000, "icache");
> if (ret)
> goto err_memory;
> + /*
> + * NOTE: when porting legacy ("pre-650-family") GPUs you may be
tempted to
> add a condition + * to allocate icache/dcache here, as per downstream
code
> flow, but it may not actually be + * necessary. If you omit this step
and
> you don't get random pagefaults, you are likely + * good to go without
> this!
> + */
> } else if (adreno_is_a640_family(adreno_gpu)) {
> ret = a6xx_gmu_memory_alloc(gmu, >icache,
> SZ_256K - SZ_16K, 0x04000, "icache");
> @@ -1547,7 +1556,7 @@ int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct
> device_node *node) SZ_256K - SZ_16K, 0x44000, "dcache");
> if (ret)
> goto err_memory;
> - } else {
> + } else if (adreno_is_a630(adreno_gpu) ||
> adreno_is_a615_family(adreno_gpu)) { /* HFI v1, has sptprac */
> gmu->legacy = true;
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c index ccc4fcf7a630..331cd2f6b9e3
> 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -252,6 +252,74 @@ static void a6xx_submit(struct msm_gpu *gpu, struct
> msm_gem_submit *submit) a6xx_flush(gpu, ring);
> }
>
> +/* For a615 family (a615, a616, a618 and a619) */
> +const struct adreno_reglist a615_hwcg[] = {
> + {REG_A6XX_RBBM_CLOCK_CNTL_SP0, 0x0222},
> + {REG_A6XX_RBBM_CLOCK_CNTL2_SP0, 0x0220},
> + {REG_A6XX_RBBM_CLOCK_DELAY_SP0, 0x0080},
> + {REG_A6XX_RBBM_CLOCK_HYST_SP0, 0xF3CF},
> + {REG_A6XX_RBBM_CLOCK_CNTL_TP0, 0x0222},
> + {REG_A6XX_RBBM_CLOCK_CNTL_TP1, 0x0222},
> + {REG_A6XX_RBBM_CLOCK_CNTL2_TP0, 0x},
> + {REG_A6XX_RBBM_CLOCK_CNTL2_TP1, 0x},
> + {REG_A6XX_RBBM_CLOCK_CNTL3_TP0, 0x},
> + {REG_A6XX_RBBM_CLOCK_CNTL3_TP1, 0x},
> + {REG_A6XX_RBBM_CLOCK_CNTL4_TP0, 0x0002},
> + {REG_A6XX_RBBM_CLOCK_CNTL4_TP1, 0x0002},
> + {REG_A6XX_RBBM_CLOCK_HYST_TP0, 0x},
> + {REG_A6XX_RBBM_CLOCK_HYST_TP1, 0x},
> + {REG_A6XX_RBBM_CLOCK_HYST2_TP0, 0x},
> + {REG_A6XX_RBBM_CLOCK_HYST2_TP1, 0x},
> + {REG_A6XX_RBBM_CLOCK_HYST3_TP0, 0x},
> + {REG_A6XX_RBBM_CLOCK_HYST3_TP1, 0x},
> + {REG_A6XX_RBBM_CLOCK_HYST4_TP0, 0x0007},
> + {REG_A6XX_RBBM_CLOCK_HYST4_TP1, 0x0007},
> + {REG_A6XX_RBBM_CLOCK_DELAY_TP0, 0x},
> + {REG_A6XX_RBBM_CLOCK_DELAY_TP1, 0x},
> + {REG_A6XX_RBBM_CLOCK_DELAY2_TP0, 0x},
> + {REG_A6XX_RBBM_CLOCK_DELAY2_TP1, 0x},
> +
Re: [PATCH 2/5] drm/msm/mdss: enable optional core clock for MDP5 MDSS
Hi Dmitry,
On Mittwoch, 15. Juni 2022 15:59:32 CEST Dmitry Baryshkov wrote:
> Enable (optional) core (MDP_CLK) clock that allows accessing HW_REV
> registers during the platform init.
>
I believe you also need to update Documentation/devicetree/bindings/display/
msm/mdp5.txt with the new clock.
Regards
Luca
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/msm/msm_mdss.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
> index b41848bfff91..f7b4628986b8 100644
> --- a/drivers/gpu/drm/msm/msm_mdss.c
> +++ b/drivers/gpu/drm/msm/msm_mdss.c
> @@ -288,7 +288,7 @@ static int msm_mdss_reset(struct device *dev)
> /*
> * MDP5 MDSS uses at most three specified clocks.
> */
> -#define MDP5_MDSS_NUM_CLOCKS 3
> +#define MDP5_MDSS_NUM_CLOCKS 4
> static int mdp5_mdss_parse_clock(struct platform_device *pdev, struct
> clk_bulk_data **clocks) {
> struct clk_bulk_data *bulk;
> @@ -305,6 +305,7 @@ static int mdp5_mdss_parse_clock(struct platform_device
> *pdev, struct clk_bulk_d bulk[num_clocks++].id = "iface";
> bulk[num_clocks++].id = "bus";
> bulk[num_clocks++].id = "vsync";
> + bulk[num_clocks++].id = "core"; /* for hw_rev access */
>
> ret = devm_clk_bulk_get_optional(>dev, num_clocks, bulk);
> if (ret)
[PATCH v2 3/4] drm/msm/mdp5: Add perf data for MDP v1.16
From: Vladimir Lypak
Add the perf data for the mdp found in msm8953.
Signed-off-by: Vladimir Lypak
Signed-off-by: Luca Weiss
Reviewed-by: Dmitry Baryshkov
---
Changes from v1:
- pick up R-b tag
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
index 1bf9ff5dbabc..b17f868ffca8 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
@@ -837,6 +837,11 @@ static const struct mdp5_cfg_hw msm8x53_config = {
[2] = INTF_DSI,
},
},
+ .perf = {
+ .ab_inefficiency = 100,
+ .ib_inefficiency = 200,
+ .clk_inefficiency = 105
+ },
.max_clk = 4,
};
--
2.36.1
[PATCH v2 0/4] MDSS support for MSM8953
This series adds the APPS IOMMU and the MDSS block for display that is found on msm8953 SoCs. Luca Weiss (1): dt-bindings: qcom-iommu: Add Qualcomm MSM8953 compatible Vladimir Lypak (3): arm64: dts: qcom: msm8953: add APPS IOMMU drm/msm/mdp5: Add perf data for MDP v1.16 arm64: dts: qcom: msm8953: add MDSS .../devicetree/bindings/iommu/qcom,iommu.txt | 1 + arch/arm64/boot/dts/qcom/msm8953.dtsi | 244 ++ drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 5 + 3 files changed, 250 insertions(+) -- 2.36.1
[PATCH 1/2] drm/msm/mdp5: Add perf data for MDP v1.16
From: Vladimir Lypak
Add the perf data for the mdp found in msm8953.
Signed-off-by: Vladimir Lypak
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
index 1bf9ff5dbabc..b17f868ffca8 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
@@ -837,6 +837,11 @@ static const struct mdp5_cfg_hw msm8x53_config = {
[2] = INTF_DSI,
},
},
+ .perf = {
+ .ab_inefficiency = 100,
+ .ib_inefficiency = 200,
+ .clk_inefficiency = 105
+ },
.max_clk = 4,
};
--
2.36.1
[PATCH] drm/msm/dsi: Use single function for reset
From: Vladimir Lypak
There is currently two function for performing reset: dsi_sw_reset and
dsi_sw_reset_restore. Only difference betwean those is that latter one
assumes that DSI controller is enabled. In contrary former one assumes
that controller is disabled and executed during power-on. However this
assumtion is not true mobile devices which have boot splash set up by
boot-loader.
This patch removes dsi_sw_reset_restore and makes dsi_sw_reset disable
DSI controller during reset sequence if it's enabled.
Signed-off-by: Vladimir Lypak
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 48 +-
1 file changed, 21 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index a95d5df52653..bab2634ebd11 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1080,12 +1080,32 @@ static void dsi_timing_setup(struct msm_dsi_host
*msm_host, bool is_bonded_dsi)
static void dsi_sw_reset(struct msm_dsi_host *msm_host)
{
+ u32 ctrl;
+
+ ctrl = dsi_read(msm_host, REG_DSI_CTRL);
+
+ if (ctrl & DSI_CTRL_ENABLE) {
+ dsi_write(msm_host, REG_DSI_CTRL, ctrl & ~DSI_CTRL_ENABLE);
+ /*
+* dsi controller need to be disabled before
+* clocks turned on
+*/
+ wmb();
+ }
+
dsi_write(msm_host, REG_DSI_CLK_CTRL, DSI_CLK_CTRL_ENABLE_CLKS);
wmb(); /* clocks need to be enabled before reset */
+ /* dsi controller can only be reset while clocks are running */
dsi_write(msm_host, REG_DSI_RESET, 1);
msleep(DSI_RESET_TOGGLE_DELAY_MS); /* make sure reset happen */
dsi_write(msm_host, REG_DSI_RESET, 0);
+ wmb(); /* controller out of reset */
+
+ if (ctrl & DSI_CTRL_ENABLE) {
+ dsi_write(msm_host, REG_DSI_CTRL, ctrl);
+ wmb(); /* make sure dsi controller enabled again */
+ }
}
static void dsi_op_mode_config(struct msm_dsi_host *msm_host,
@@ -1478,32 +1498,6 @@ static int dsi_cmds2buf_tx(struct msm_dsi_host *msm_host,
return len;
}
-static void dsi_sw_reset_restore(struct msm_dsi_host *msm_host)
-{
- u32 data0, data1;
-
- data0 = dsi_read(msm_host, REG_DSI_CTRL);
- data1 = data0;
- data1 &= ~DSI_CTRL_ENABLE;
- dsi_write(msm_host, REG_DSI_CTRL, data1);
- /*
-* dsi controller need to be disabled before
-* clocks turned on
-*/
- wmb();
-
- dsi_write(msm_host, REG_DSI_CLK_CTRL, DSI_CLK_CTRL_ENABLE_CLKS);
- wmb(); /* make sure clocks enabled */
-
- /* dsi controller can only be reset while clocks are running */
- dsi_write(msm_host, REG_DSI_RESET, 1);
- msleep(DSI_RESET_TOGGLE_DELAY_MS); /* make sure reset happen */
- dsi_write(msm_host, REG_DSI_RESET, 0);
- wmb(); /* controller out of reset */
- dsi_write(msm_host, REG_DSI_CTRL, data0);
- wmb(); /* make sure dsi controller enabled again */
-}
-
static void dsi_hpd_worker(struct work_struct *work)
{
struct msm_dsi_host *msm_host =
@@ -1520,7 +1514,7 @@ static void dsi_err_worker(struct work_struct *work)
pr_err_ratelimited("%s: status=%x\n", __func__, status);
if (status & DSI_ERR_STATE_MDP_FIFO_UNDERFLOW)
- dsi_sw_reset_restore(msm_host);
+ dsi_sw_reset(msm_host);
/* It is safe to clear here because error irq is disabled. */
msm_host->err_work_state = 0;
--
2.36.1
[PATCH] drm/msm: Fix null pointer dereferences without iommu
Check if 'aspace' is set before using it as it will stay null without
IOMMU, such as on msm8974.
Fixes: bc2112583a0b ("drm/msm/gpu: Track global faults per address-space")
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 5 -
drivers/gpu/drm/msm/msm_gpu.c | 3 ++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 9efc84929be0..1219f71629a5 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -272,7 +272,10 @@ int adreno_get_param(struct msm_gpu *gpu, struct
msm_file_private *ctx,
*value = 0;
return 0;
case MSM_PARAM_FAULTS:
- *value = gpu->global_faults + ctx->aspace->faults;
+ if (ctx->aspace)
+ *value = gpu->global_faults + ctx->aspace->faults;
+ else
+ *value = gpu->global_faults;
return 0;
case MSM_PARAM_SUSPENDS:
*value = gpu->suspend_count;
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index faf0c242874e..58eb3e1662cb 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -371,7 +371,8 @@ static void recover_worker(struct kthread_work *work)
/* Increment the fault counts */
submit->queue->faults++;
- submit->aspace->faults++;
+ if (submit->aspace)
+ submit->aspace->faults++;
task = get_pid_task(submit->pid, PIDTYPE_PID);
if (task) {
--
2.36.0
Re: [PATCH] drm: add missing dependency to DRM_PANEL_EDP
Hi, any feedback on this patch? On Sonntag, 23. Jänner 2022 21:43:23 CET Luca Weiss wrote: > With CONFIG_DRM_PANEL_EDP=y and CONFIG_DRM_KMS_HELPER=m the compilation > fails: > > drivers/gpu/drm/panel/panel-edp.c:843: undefined reference to > `drm_panel_dp_aux_backlight' > > Add a dependency on DRM_KMS_HELPER to fix this. > > Signed-off-by: Luca Weiss > --- > I briefly tried "select DRM_KMS_HELPER" but that causes a circular > dependency. > If someone has a better idea how to solve this, feel free correct me. > > drivers/gpu/drm/panel/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig > index 434c2861bb40..fda97837ecb3 100644 > --- a/drivers/gpu/drm/panel/Kconfig > +++ b/drivers/gpu/drm/panel/Kconfig > @@ -102,6 +102,7 @@ config DRM_PANEL_SIMPLE > config DRM_PANEL_EDP > tristate "support for simple Embedded DisplayPort panels" > depends on OF > + depends on DRM_KMS_HELPER > depends on BACKLIGHT_CLASS_DEVICE > depends on PM > select VIDEOMODE_HELPERS
Re: [PATCH] drm: add missing dependency to DRM_PANEL_EDP
On Sonntag, 23. Jänner 2022 21:43:23 CET Luca Weiss wrote:
> With CONFIG_DRM_PANEL_EDP=y and CONFIG_DRM_KMS_HELPER=m the compilation
> fails:
>
> drivers/gpu/drm/panel/panel-edp.c:843: undefined reference to
> `drm_panel_dp_aux_backlight'
>
> Add a dependency on DRM_KMS_HELPER to fix this.
>
Forgot to add, this is the closest "Fixes" I can find, before that commit with
arm32 qcom_defconfig both beforementioned options were builtin
Fixes: 9d6366e743f3 ("drm: fb_helper: improve CONFIG_FB dependency")
> Signed-off-by: Luca Weiss
> ---
> I briefly tried "select DRM_KMS_HELPER" but that causes a circular
> dependency.
> If someone has a better idea how to solve this, feel free correct me.
>
> drivers/gpu/drm/panel/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 434c2861bb40..fda97837ecb3 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -102,6 +102,7 @@ config DRM_PANEL_SIMPLE
> config DRM_PANEL_EDP
> tristate "support for simple Embedded DisplayPort panels"
> depends on OF
> + depends on DRM_KMS_HELPER
> depends on BACKLIGHT_CLASS_DEVICE
> depends on PM
> select VIDEOMODE_HELPERS
[PATCH] drm: add missing dependency to DRM_PANEL_EDP
With CONFIG_DRM_PANEL_EDP=y and CONFIG_DRM_KMS_HELPER=m the compilation fails: drivers/gpu/drm/panel/panel-edp.c:843: undefined reference to `drm_panel_dp_aux_backlight' Add a dependency on DRM_KMS_HELPER to fix this. Signed-off-by: Luca Weiss --- I briefly tried "select DRM_KMS_HELPER" but that causes a circular dependency. If someone has a better idea how to solve this, feel free correct me. drivers/gpu/drm/panel/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index 434c2861bb40..fda97837ecb3 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -102,6 +102,7 @@ config DRM_PANEL_SIMPLE config DRM_PANEL_EDP tristate "support for simple Embedded DisplayPort panels" depends on OF + depends on DRM_KMS_HELPER depends on BACKLIGHT_CLASS_DEVICE depends on PM select VIDEOMODE_HELPERS -- 2.34.1
[PATCH 2/4] backlight: qcom-wled: Add PM6150L compatible
PM6150L contains WLED of version 5. Add support ofr it to the driver.
Signed-off-by: Luca Weiss
---
drivers/video/backlight/qcom-wled.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/backlight/qcom-wled.c
b/drivers/video/backlight/qcom-wled.c
index 306bcc6ccb92..527210e85795 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -1734,6 +1734,7 @@ static const struct of_device_id wled_match_table[] = {
{ .compatible = "qcom,pmi8994-wled", .data = (void *)4 },
{ .compatible = "qcom,pmi8998-wled", .data = (void *)4 },
{ .compatible = "qcom,pm660l-wled", .data = (void *)4 },
+ { .compatible = "qcom,pm6150l-wled", .data = (void *)5 },
{ .compatible = "qcom,pm8150l-wled", .data = (void *)5 },
{}
};
--
2.34.1
[PATCH 1/4] dt-bindings: backlight: qcom-wled: Add PM6150L compatible
Document the compatible for the wled block found in PM6150L. Signed-off-by: Luca Weiss --- Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml index d839e75d9788..1c24b333c6e2 100644 --- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml +++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml @@ -22,6 +22,7 @@ properties: - qcom,pmi8994-wled - qcom,pmi8998-wled - qcom,pm660l-wled + - qcom,pm6150l-wled - qcom,pm8150l-wled reg: -- 2.34.1
