Add dt-bindings documentation for Raydium RM67191 DSI panel.
Signed-off-by: Robert Chiras <[email protected]>
---
.../bindings/display/panel/raydium,rm67191.txt | 43 ++++++++++++++++++++++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt
diff --git a/Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt b/Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt
new file mode 100644
index 0000000..0952610
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt
@@ -0,0 +1,43 @@
+Raydium RM67171 OLED LCD panel with MIPI-DSI protocol
+
+Required properties:
+- compatible: "raydium,rm67191"
+- reg: virtual channel for MIPI-DSI protocol
+ must be <0>
+- dsi-lanes: number of DSI lanes to be used
+ must be <3> or <4>
+- port: input port node with endpoint definition as
+ defined in Documentation/devicetree/bindings/graph.txt;
+ the input port should be connected to a MIPI-DSI device
+ driver
+
+Optional properties:
+- reset-gpios: a GPIO spec for the RST_B GPIO pin
+- pinctrl-0 phandle to the pin settings for the reset pin
+- width-mm: physical panel width [mm]
+- height-mm: physical panel height [mm]
+- display-timings: timings for the connected panel according to [1]
+- video-mode: 0 - burst-mode
+ 1 - non-burst with sync event
+ 2 - non-burst with sync pulse
+
+[1]: Documentation/devicetree/bindings/display/panel/display-timing.txt
+
+Example:
+
+ panel@0 {
+ compatible = "raydium,rm67191";
+ reg = <0>;
+ pinctrl-0 = <&pinctrl_mipi_dsi_0_1_en>;
+ pinctrl-names = "default";
+ reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
+ dsi-lanes = <4>;
+ width-mm = <68>;
+ height-mm = <121>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&mipi_out>;
+ };
+ };
+ };
--
2.7.4
Hi Robert.
Thanks for the contribution.
On Tue, Jun 18, 2019 at 04:30:45PM +0300, Robert Chiras wrote:
> Add dt-bindings documentation for Raydium RM67191 DSI panel.
>
> Signed-off-by: Robert Chiras <[email protected]>
> ---
> .../bindings/display/panel/raydium,rm67191.txt | 43 ++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt
>
> diff --git a/Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt b/Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt
> new file mode 100644
> index 0000000..0952610
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt
> @@ -0,0 +1,43 @@
> +Raydium RM67171 OLED LCD panel with MIPI-DSI protocol
> +
> +Required properties:
> +- compatible: "raydium,rm67191"
> +- reg: virtual channel for MIPI-DSI protocol
> + must be <0>
> +- dsi-lanes: number of DSI lanes to be used
> + must be <3> or <4>
> +- port: input port node with endpoint definition as
> + defined in Documentation/devicetree/bindings/graph.txt;
> + the input port should be connected to a MIPI-DSI device
> + driver
> +
> +Optional properties:
> +- reset-gpios: a GPIO spec for the RST_B GPIO pin
> +- pinctrl-0 phandle to the pin settings for the reset pin
pinctrl is not included in bindings, they are implicit.
> +- width-mm: physical panel width [mm]
> +- height-mm: physical panel height [mm]
Please refer to panel-common.txt for the above.
> +- display-timings: timings for the connected panel according to [1]
> +- video-mode: 0 - burst-mode
> + 1 - non-burst with sync event
> + 2 - non-burst with sync pulse
> +
> +[1]: Documentation/devicetree/bindings/display/panel/display-timing.txt
> +
> +Example:
> +
> + panel@0 {
> + compatible = "raydium,rm67191";
> + reg = <0>;
> + pinctrl-0 = <&pinctrl_mipi_dsi_0_1_en>;
> + pinctrl-names = "default";
> + reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
> + dsi-lanes = <4>;
> + width-mm = <68>;
> + height-mm = <121>;
> +
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <&mipi_out>;
> + };
> + };
> + };
With the above fixed:
Signed-off-by: Sam Ravnborg <[email protected]>
Note: You need r-b from DT maintainer before we can apply it.
Sam
Hi Robert,
On Tue, Jun 18, 2019 at 10:33 AM Robert Chiras <[email protected]> wrote:
> +Optional properties:
> +- reset-gpios: a GPIO spec for the RST_B GPIO pin
> +- pinctrl-0 phandle to the pin settings for the reset pin
> +- width-mm: physical panel width [mm]
> +- height-mm: physical panel height [mm]
> +- display-timings: timings for the connected panel according to [1]
Still not convinced we need the 'display-timings' property, even as an
optional property. My understanding is that passing display timings in
the devicetree is not encouraged.
Last time you said you need to pass ''display-timings' to workaround
the problem of connecting this panel to mx8m DCSS or eLCDIF.
The panel timings come from the LCD manufacturer and it is agnostic to
what display controller interface it is connected to.
So I suggest making sure the timings passed in the driver are correct
as per the vendor datasheet. If they are correct and one specific
interface is not able to drive it, then probably it is a bug in this
specific display controller interface or in the SoC clock driver.
On Mi, 2019-06-19 at 10:21 -0300, Fabio Estevam wrote:
> Caution: EXT Email
>
> Hi Robert,
>
> On Tue, Jun 18, 2019 at 10:33 AM Robert Chiras <[email protected]
> > wrote:
>
> >
> > +Optional properties:
> > +- reset-gpios: a GPIO spec for the RST_B GPIO pin
> > +- pinctrl-0 phandle to the pin settings for the reset
> > pin
> > +- width-mm: physical panel width [mm]
> > +- height-mm: physical panel height [mm]
> > +- display-timings: timings for the connected panel according
> > to [1]
> Still not convinced we need the 'display-timings' property, even as
> an
> optional property. My understanding is that passing display timings
> in
> the devicetree is not encouraged.
>
> Last time you said you need to pass ''display-timings' to workaround
> the problem of connecting this panel to mx8m DCSS or eLCDIF.
>
> The panel timings come from the LCD manufacturer and it is agnostic
> to
> what display controller interface it is connected to.
>
> So I suggest making sure the timings passed in the driver are correct
> as per the vendor datasheet. If they are correct and one specific
> interface is not able to drive it, then probably it is a bug in this
> specific display controller interface or in the SoC clock driver.
I understand. I will remove the display-timings from dt and also from
driver. Currently, this panel works in this form with both LCDIF and
DCSS on our 8M SoC so, as you said, probably the issue we were seeing
in our tree was coming from elsewhere.