On Thu, Oct 24, 2019 at 01:28:28PM +0530, Jagan Teki wrote:

On Thu, Oct 17, 2019 at 3:22 PM Maxime Ripard [off-list ref] wrote:

quoted

On Wed, Oct 16, 2019 at 02:19:44PM +0530, Jagan Teki wrote:

quoted

On Wed, Oct 16, 2019 at 1:33 PM Maxime Ripard [off-list ref] wrote:

quoted

On Mon, Oct 14, 2019 at 05:37:50PM +0530, Jagan Teki wrote:

quoted

On Mon, Oct 7, 2019 at 4:27 PM Maxime Ripard [off-list ref] wrote:

quoted

On Sat, Oct 05, 2019 at 07:49:12PM +0530, Jagan Teki wrote:

quoted

Add MIPI DSI pipeline for Allwinner A64.

- dsi node, with A64 compatible since it doesn't support
  DSI_SCLK gating unlike A33
- dphy node, with A64 compatible with A33 fallback since
  DPHY on A64 and A33 is similar
- finally, attach the dsi_in to tcon0 for complete MIPI DSI

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Merlijn Wajer <redacted>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 38 +++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 69128a6dfc46..ad4170b8aee0 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi

@@ -382,6 +382,12 @@
                                      #address-cells = <1>;
                                      #size-cells = <0>;
                                      reg = <1>;
+
+                                     tcon0_out_dsi: endpoint@1 {
+                                             reg = <1>;
+                                             remote-endpoint = <&dsi_in_tcon0>;
+                                             allwinner,tcon-channel = <1>;
+                                     };
                              };
                      };
              };

@@ -1003,6 +1009,38 @@
                      status = "disabled";
              };

+             dsi: dsi@1ca0000 {
+                     compatible = "allwinner,sun50i-a64-mipi-dsi";
+                     reg = <0x01ca0000 0x1000>;
+                     interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
+                     clocks = <&ccu CLK_BUS_MIPI_DSI>;
+                     clock-names = "bus";

This won't validate with the bindings you have either here, since it
still expects bus and mod.

I guess in that cas, we can just drop clock-names, which will require
a bit of work on the driver side as well.

Okay.
mod clock is not required for a64, ie reason we have has_mod_clk quirk
patch. Adjust the clock-names: on dt-bindings would make sense here,
what do you think?

I'm confused, what are you suggesting?

Sorry for the confusion.

The mod clock is not required for A64 and we have a patch for handling
mod clock using has_mod_clk quirk(on the series), indeed the mod clock
is available in A31 and not needed for A64. So, to satisfy this
requirement the clock-names on dt-bindings can update to make mod
clock-name is optional and bus clock is required.

No, the bus clock name is not needed if there's only one clock.

Okay, is it because the same clock handle it on PHY side?

No, because there's only one clock and thus you don't need to
differentiate them.

quoted

quoted

I'm not exactly sure, this is correct but trying to understand if it
is possible or not? something like

   clocks:
      minItems: 1
      maxItems: 2
     items:
       - description: Bus Clock
       - description: Module Clock

That's correct.

quoted

   clock-names:
      minItems: 1
      maxItems: 2
     items:
       - const: bus
       - const: mod

Here, just keep the current clock-names definition, and make it
required only for SoCs that are not the A64

Okay, please have a look here I have pasted the diff for comments.

   clocks:
+    minItems: 2
     items:
       - description: Bus Clock
       - description: Module Clock

Didn't you tell me that you didn't need the module clock?

How do you handle the case were you just have the bus clock then?

Maxime

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel