RE: [PATCH] drm: of: Fix linking when CONFIG_OF is not set
Hi Laurent,
> From: Laurent Pinchart
> Sent: 19 December 2019 10:37
> To: dri-devel@lists.freedesktop.org
> Cc: Fabrizio Castro ; Daniel Vetter
> ; Dave Airlie
> Subject: [PATCH] drm: of: Fix linking when CONFIG_OF is not set
>
> The new helper drm_of_lvds_get_dual_link_pixel_order() introduced in
> commit 6529007522de has a fallback stub when CONFIG_OF is not set, but
> the stub is declared in drm_of.h without a static inline. This causes
> multiple definitions of the function to be linked when the CONFIG_OF
> option isn't set. Fix it by making the stub static inline.
>
> Fixes: 6529007522de ("drm: of: Add drm_of_lvds_get_dual_link_pixel_order")
> Reported-by: kbuild test robot
> Signed-off-by: Laurent Pinchart
Thank you for fixing this, I came to the same conclusion, therefore
Reviewed-by: Fabrizio Castro
> ---
> This fixes a link error in drm-next. Daniel, Dave, would you like to
> apply the patch directly ?
>
> include/drm/drm_of.h | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
> index 8ec7ca6d2369..b9b093add92e 100644
> --- a/include/drm/drm_of.h
> +++ b/include/drm/drm_of.h
> @@ -92,8 +92,9 @@ static inline int drm_of_find_panel_or_bridge(const struct
> device_node *np,
> return -EINVAL;
> }
>
> -int drm_of_lvds_get_dual_link_pixel_order(const struct device_node *port1,
> - const struct device_node *port2)
> +static inline int
> +drm_of_lvds_get_dual_link_pixel_order(const struct device_node *port1,
> + const struct device_node *port2)
> {
> return -EINVAL;
> }
> --
> Regards,
>
> Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v4 00/13] Add LCD panel support to iwg20d
Hi Neil,
> From: Neil Armstrong
> Sent: 18 December 2019 11:53
> Subject: Re: [PATCH v4 00/13] Add LCD panel support to iwg20d
>
> Hi,
>
> On 13/11/2019 16:51, Fabrizio Castro wrote:
> > The iW-RainboW-G20D-Qseven RZ/G1M,G1N Qseven Development Platform
> > comes with a 7" capacitive display kit from Emerging Display
> > Technologies Corporation (EDT). This series adds all that's
> > necessary for supporting it.
> >
> > Thanks,
> > Fab
> >
> > v3->v4:
> > * Reworked according to Laurent's and Jacopo's comments
> > v2->v3:
> > * Split the dt-schema patch in two patches as per Rob's comment
> > * Made fixes to the dt-schema according to Rob's comment
> > * Made fixes to the lvds-codec driver according to Jacopo's comments
> > * Added two new patches:
> > * drm: Define DRM_MODE_CONNECTOR_PARALLEL
> > * drm/panel: panel-simple: Add connector type for etm0700g0dh6
> > v1->v2:
> > * Convert dt-bindings to dt-schema
> >
> > Fabrizio Castro (13):
> > dt-bindings: display: bridge: Convert lvds-transmitter binding to
> > json-schema
> > dt-bindings: display: bridge: lvds-transmitter: Document
> > powerdown-gpios
> > dt-bindings: display: bridge: lvds-transmitter: Absorb ti,ds90c185.txt
> > dt-bindings: display: bridge: lvds-transmitter: Document
> > "ti,sn75lvds83"
> > drm/bridge: Repurpose lvds-encoder.c
> > drm/bridge: lvds-codec: Add "lvds-decoder" support
> > drm/bridge: lvds-codec: Simplify panel DT node localisation
> > dt-bindings: display: bridge: Repurpose lvds-encoder
> > dt-bindings: display: bridge: lvds-codec: Document ti,ds90cf384a
> > ARM: dts: iwg20d-q7-common: Add LCD support
> > ARM: shmobile_defconfig: Enable support for panels from EDT
> > [HACK] drm/bridge: lvds-codec: Enforce device specific compatible
> > strings
> > [HACK] dt-bindings: display: bridge: lvds-codec: Absorb
> > thine,thc63lvdm83d.txt
> >
> > .../bindings/display/bridge/lvds-codec.yaml| 131 +++
> > .../bindings/display/bridge/lvds-transmitter.txt | 66
> > .../bindings/display/bridge/thine,thc63lvdm83d.txt | 50 --
> > .../bindings/display/bridge/ti,ds90c185.txt| 55 ---
> > arch/arm/boot/dts/iwg20d-q7-common.dtsi| 85 ++
> > arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi | 1 -
> > arch/arm/configs/shmobile_defconfig| 3 +
> > drivers/gpu/drm/bridge/Kconfig | 8 +-
> > drivers/gpu/drm/bridge/Makefile| 2 +-
> > .../drm/bridge/{lvds-encoder.c => lvds-codec.c}| 179
> > +
> > 10 files changed, 333 insertions(+), 247 deletions(-)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> > delete mode 100644
> > Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
> > delete mode 100644
> > Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt
> > delete mode 100644
> > Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt
> > rename drivers/gpu/drm/bridge/{lvds-encoder.c => lvds-codec.c} (25%)
> >
>
> Applying patches 1->9 and 13 to drm-misc-next with correct SoB.
>
> Also applied change on patch 8 while applying.
>
> And checked the diff is the same as laurent's PR.
Thank you.
Fab
>
> Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v4 06/13] drm/bridge: lvds-codec: Add "lvds-decoder" support
> From: linux-renesas-soc-ow...@vger.kernel.org
> On Behalf Of Laurent Pinchart
> Sent: 17 December 2019 23:09
> Subject: Re: [PATCH v4 06/13] drm/bridge: lvds-codec: Add "lvds-decoder"
> support
>
> On Tue, Dec 17, 2019 at 10:06:14PM +, Fabrizio Castro wrote:
> > On 17 December 2019 13:54, Laurent Pinchart wrote:
> > > On Tue, Dec 17, 2019 at 01:38:51PM +0100, Geert Uytterhoeven wrote:
> > >> On Tue, Dec 17, 2019 at 1:31 PM Fabrizio Castro wrote:
> > >>> On 17 December 2019 12:21, Geert Uytterhoeven wrote:
> > >>>> On Tue, Dec 17, 2019 at 12:03 PM Fabrizio Castro wrote:
> > >>>>> On 13 December 2019 17:11, Laurent Pinchart wrote:
> > >>>>>> On Wed, Nov 13, 2019 at 03:51:25PM +, Fabrizio Castro wrote:
> > >>>>>>> Add support for transparent LVDS decoders by adding a new
> > >>>>>>> compatible string ("lvds-decoder") to the driver.
> > >>>>>>> This patch also adds member connector_type to struct lvds_codec,
> > >>>>>>> and that's because LVDS decoders have a different connector type
> > >>>>>>> from LVDS encoders. We fill this new member up with the data
> > >>>>>>> matching the compatible string.
> > >>>>>>>
> > >>>>>>> Signed-off-by: Fabrizio Castro
> > >>>>>>>
> > >>>>>>> --- a/drivers/gpu/drm/bridge/lvds-codec.c
> > >>>>>>> +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> > >>>>>>>
> > >>>>>>> @@ -65,6 +67,7 @@ static int lvds_codec_probe(struct
> > >>>>>>> platform_device *pdev)
> > >>>>>>> if (!lvds_codec)
> > >>>>>>> return -ENOMEM;
> > >>>>>>>
> > >>>>>>> + lvds_codec->connector_type =
> > >>>>>>> (u32)of_device_get_match_data(>dev);
> > >>>>>>
> > >>>>>> I'm now getting a compilation failure here:
> > >>>>>>
> > >>>>>> drivers/gpu/drm/bridge/lvds-codec.c: In function ‘lvds_codec_probe’:
> > >>>>>> drivers/gpu/drm/bridge/lvds-codec.c:68:31: error: cast from pointer
> > >>>>>> to integer of different size [-Werror=pointer-to-int-
> cast]
> > >>>>>> lvds_codec->connector_type =
> > >>>>>> (u32)of_device_get_match_data(>dev);
> > >>>>>>^
> > >>>>>>
> > >>>>>> The fix should be simple:
> > >>>>>>
> > >>>>>> lvds_codec->connector_type =
> > >>>>>> (uintptr_t)of_device_get_match_data(dev);
> > >>>>>>
> > >>>>>> I'm bothered by the fact that I've compiled this before without any
> > >>>>>> issue, so this really puzzles me. Do you get the same warning ?
> > >>>>>
> > >>>>> The warning appears when compiling for arm64, understandably so.
> > >>>>> We must have compiled this for arm only the first time around.
> > >>>>>
> > >>>>> I think the right way to solve this is to either cast to
> > >>>>> (u32)(uintptr_t) or (u32)(unsigned long).
> > >>>>
> > >>>> Just casting to uintptr_t should be sufficient.
> > >>>
> > >>> It should be sufficient for the compiler, but I have seen examples
> > >>> where people
> > >>> preferred to be explicit, like in:
> > >>> drivers/mailbox/mtk-cmdq-mailbox.c
> > >>> drivers/leds/leds-pm8058.c
> > >>>
> > >>> Since the kernel is increasing its tightness with respect to warnings,
> > >>> I personally prefer
> > >>> (u32)(uintptr_t), even though not strictly necessary, but I am fine
> > >>> with (uintptr_t) if you
> > >>> don't like (u32)(uintptr_t).
> > >>
> > >> It depends. I try to have as few casts as possible ("casts are evil").
> > >>
> > >> While adding the extra (u32) cast makes it clearer that the intended
> > >> result is a u32 (for now), it will cause silent truncation on 64-bit if
> > >> connector_type is ever enlarged to unsigned long, and larger values are
> > >> used.
> > >>
> > >> In this particular case this is unlikely, though, as unsigned long would
> > >> still be 32-bit on 32-bit platforms, so the larger values cannot be
> > >> used.
> > >
> > > I also try to add as few casts as possible, so (uintptr_t) would be my
> > > preference.
> > >
> > > Fabrizio, could you submit a new version of this patch with the problem
> > > fixed (and with the casts you decide to use, but using uintptr_t instead
> > > of unsigned long in any case) ?
> >
> > Will send a new version tomorrow with (uintptr_t)
>
> Done as v4.1 :-)
Thank you!
Fab
>
> --
> Regards,
>
> Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 2/6] drm: rcar-du: lvds: Improve identification of panels
Dual-LVDS panels are mistakenly identified as bridges, this
commit replaces the current logic with a call to
drm_of_find_panel_or_bridge to sort that out.
Signed-off-by: Fabrizio Castro
Reviewed-by: Laurent Pinchart
---
v5->v6:
* No change
v4->v5:
* Addressed comments from Laurent's review
v3->v4:
* New patch extracted from patch:
"drm: rcar-du: lvds: Add dual-LVDS panels support"
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 75 +
1 file changed, 10 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 87a5e8e..da71107 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -712,79 +713,23 @@ static int rcar_lvds_parse_dt_companion(struct rcar_lvds
*lvds)
static int rcar_lvds_parse_dt(struct rcar_lvds *lvds)
{
- struct device_node *local_output = NULL;
- struct device_node *remote_input = NULL;
- struct device_node *remote = NULL;
- struct device_node *node;
- bool is_bridge = false;
- int ret = 0;
-
- local_output = of_graph_get_endpoint_by_regs(lvds->dev->of_node, 1, 0);
- if (!local_output) {
- dev_dbg(lvds->dev, "unconnected port@1\n");
- ret = -ENODEV;
- goto done;
- }
-
- /*
-* Locate the connected entity and infer its type from the number of
-* endpoints.
-*/
- remote = of_graph_get_remote_port_parent(local_output);
- if (!remote) {
- dev_dbg(lvds->dev, "unconnected endpoint %pOF\n", local_output);
- ret = -ENODEV;
- goto done;
- }
+ int ret;
- if (!of_device_is_available(remote)) {
- dev_dbg(lvds->dev, "connected entity %pOF is disabled\n",
- remote);
- ret = -ENODEV;
+ ret = drm_of_find_panel_or_bridge(lvds->dev->of_node, 1, 0,
+ >panel, >next_bridge);
+ if (ret)
goto done;
- }
- remote_input = of_graph_get_remote_endpoint(local_output);
-
- for_each_endpoint_of_node(remote, node) {
- if (node != remote_input) {
- /*
-* We've found one endpoint other than the input, this
-* must be a bridge.
-*/
- is_bridge = true;
- of_node_put(node);
- break;
- }
- }
-
- if (is_bridge) {
- lvds->next_bridge = of_drm_find_bridge(remote);
- if (!lvds->next_bridge) {
- ret = -EPROBE_DEFER;
- goto done;
- }
-
- if (lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK)
- lvds->dual_link = lvds->next_bridge->timings
- ? lvds->next_bridge->timings->dual_link
- : false;
- } else {
- lvds->panel = of_drm_find_panel(remote);
- if (IS_ERR(lvds->panel)) {
- ret = PTR_ERR(lvds->panel);
- goto done;
- }
- }
+ if ((lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK) &&
+ lvds->next_bridge)
+ lvds->dual_link = lvds->next_bridge->timings
+ ? lvds->next_bridge->timings->dual_link
+ : false;
if (lvds->dual_link)
ret = rcar_lvds_parse_dt_companion(lvds);
done:
- of_node_put(local_output);
- of_node_put(remote_input);
- of_node_put(remote);
-
/*
* On D3/E3 the LVDS encoder provides a clock to the DU, which can be
* used for the DPAD output even when the LVDS output is not connected.
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v4 06/13] drm/bridge: lvds-codec: Add "lvds-decoder" support
Hi guys,
> From: Laurent Pinchart
> Sent: 17 December 2019 13:54
> Subject: Re: [PATCH v4 06/13] drm/bridge: lvds-codec: Add "lvds-decoder"
> support
>
> Hello,
>
> On Tue, Dec 17, 2019 at 01:38:51PM +0100, Geert Uytterhoeven wrote:
> > On Tue, Dec 17, 2019 at 1:31 PM Fabrizio Castro wrote:
> > > On 17 December 2019 12:21, Geert Uytterhoeven wrote:
> > >> On Tue, Dec 17, 2019 at 12:03 PM Fabrizio Castro wrote:
> > >>> On 13 December 2019 17:11, Laurent Pinchart wrote:
> > >>>> On Wed, Nov 13, 2019 at 03:51:25PM +, Fabrizio Castro wrote:
> > >>>>> Add support for transparent LVDS decoders by adding a new
> > >>>>> compatible string ("lvds-decoder") to the driver.
> > >>>>> This patch also adds member connector_type to struct lvds_codec,
> > >>>>> and that's because LVDS decoders have a different connector type
> > >>>>> from LVDS encoders. We fill this new member up with the data
> > >>>>> matching the compatible string.
> > >>>>>
> > >>>>> Signed-off-by: Fabrizio Castro
> > >>>>>
> > >>>>> --- a/drivers/gpu/drm/bridge/lvds-codec.c
> > >>>>> +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> > >>>>>
> > >>>>> @@ -65,6 +67,7 @@ static int lvds_codec_probe(struct platform_device
> > >>>>> *pdev)
> > >>>>> if (!lvds_codec)
> > >>>>> return -ENOMEM;
> > >>>>>
> > >>>>> + lvds_codec->connector_type =
> > >>>>> (u32)of_device_get_match_data(>dev);
> > >>>>
> > >>>> I'm now getting a compilation failure here:
> > >>>>
> > >>>> drivers/gpu/drm/bridge/lvds-codec.c: In function ‘lvds_codec_probe’:
> > >>>> drivers/gpu/drm/bridge/lvds-codec.c:68:31: error: cast from pointer to
> > >>>> integer of different size [-Werror=pointer-to-int-cast]
> > >>>> lvds_codec->connector_type =
> > >>>> (u32)of_device_get_match_data(>dev);
> > >>>>^
> > >>>>
> > >>>> The fix should be simple:
> > >>>>
> > >>>> lvds_codec->connector_type =
> > >>>> (uintptr_t)of_device_get_match_data(dev);
> > >>>>
> > >>>> I'm bothered by the fact that I've compiled this before without any
> > >>>> issue, so this really puzzles me. Do you get the same warning ?
> > >>>
> > >>> The warning appears when compiling for arm64, understandably so.
> > >>> We must have compiled this for arm only the first time around.
> > >>>
> > >>> I think the right way to solve this is to either cast to
> > >>> (u32)(uintptr_t) or (u32)(unsigned long).
> > >>
> > >> Just casting to uintptr_t should be sufficient.
> > >
> > > It should be sufficient for the compiler, but I have seen examples where
> > > people
> > > preferred to be explicit, like in:
> > > drivers/mailbox/mtk-cmdq-mailbox.c
> > > drivers/leds/leds-pm8058.c
> > >
> > > Since the kernel is increasing its tightness with respect to warnings, I
> > > personally prefer
> > > (u32)(uintptr_t), even though not strictly necessary, but I am fine with
> > > (uintptr_t) if you
> > > don't like (u32)(uintptr_t).
> >
> > It depends. I try to have as few casts as possible ("casts are evil").
> >
> > While adding the extra (u32) cast makes it clearer that the intended
> > result is a u32 (for now), it will cause silent truncation on 64-bit if
> > connector_type is ever enlarged to unsigned long, and larger values are
> > used.
> >
> > In this particular case this is unlikely, though, as unsigned long would
> > still be 32-bit on 32-bit platforms, so the larger values cannot be
> > used.
>
> I also try to add as few casts as possible, so (uintptr_t) would be my
> preference.
>
> Fabrizio, could you submit a new version of this patch with the problem
> fixed (and with the casts you decide to use, but using uintptr_t instead
> of unsigned long in any case) ?
Will send a new version tomorrow with (uintptr_t)
Thanks,
Fab
>
> --
> Regards,
>
> Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 0/6] Add dual-LVDS panel support to EK874
Dear All, this series adds support for dual-LVDS panel IDK-2121WR from Advantech: https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.htm V6 reworks patch "drm: rcar-du: lvds: Allow for even and odd pixels swap", and rebases the series on top of patch: https://patchwork.kernel.org/patch/11295991/ Thanks, Fab Fabrizio Castro (6): drm: of: Add drm_of_lvds_get_dual_link_pixel_order drm: rcar-du: lvds: Improve identification of panels drm: rcar-du: lvds: Get dual link configuration from DT drm: rcar-du: lvds: Allow for even and odd pixels swap dt-bindings: display: Add idk-2121wr binding arm64: dts: renesas: Add EK874 board with idk-2121wr display support .../display/panel/advantech,idk-2121wr.yaml| 128 +++ arch/arm64/boot/dts/renesas/Makefile | 3 +- .../boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts | 116 + drivers/gpu/drm/drm_of.c | 116 + drivers/gpu/drm/rcar-du/rcar_lvds.c| 180 - include/drm/drm_of.h | 20 +++ 6 files changed, 483 insertions(+), 80 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml create mode 100644 arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 5/6] dt-bindings: display: Add idk-2121wr binding
Add binding for the idk-2121wr LVDS panel from Advantech.
Some panel-specific documentation can be found here:
https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.htm
Signed-off-by: Fabrizio Castro
Reviewed-by: Laurent Pinchart
---
v5->v6:
* No change
v4->v5:
* No change
v3->v4:
* Absorbed patch "dt-bindings: display: Add bindings for LVDS
bus-timings"
* Big restructuring after Rob's and Laurent's comments
v2->v3:
* New patch
---
.../display/panel/advantech,idk-2121wr.yaml| 128 +
1 file changed, 128 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
new file mode 100644
index 000..24cd38b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
@@ -0,0 +1,128 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/advantech,idk-2121wr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Advantech IDK-2121WR 21.5" Full-HD dual-LVDS panel
+
+maintainers:
+ - Fabrizio Castro
+ - Thierry Reding
+
+description: |
+ The IDK-2121WR from Advantech is a Full-HD dual-LVDS panel.
+ A dual-LVDS interface is a dual-link connection with even pixels traveling
+ on one link, and with odd pixels traveling on the other link.
+
+ The panel expects odd pixels on the first port, and even pixels on the
+ second port, therefore the ports must be marked accordingly (with either
+ dual-lvds-odd-pixels or dual-lvds-even-pixels).
+
+properties:
+ compatible:
+items:
+ - const: advantech,idk-2121wr
+ - {} # panel-lvds, but not listed here to avoid false select
+
+ width-mm:
+const: 476
+
+ height-mm:
+const: 268
+
+ data-mapping:
+const: vesa-24
+
+ ports:
+type: object
+properties:
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+ port@0:
+type: object
+description: The sink for odd pixels.
+properties:
+ reg:
+const: 0
+
+ dual-lvds-odd-pixels: true
+
+required:
+ - reg
+ - dual-lvds-odd-pixels
+
+ port@1:
+type: object
+description: The sink for even pixels.
+properties:
+ reg:
+const: 1
+
+ dual-lvds-even-pixels: true
+
+required:
+ - reg
+ - dual-lvds-even-pixels
+
+ panel-timing: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - width-mm
+ - height-mm
+ - data-mapping
+ - panel-timing
+ - ports
+
+examples:
+ - |+
+panel-lvds {
+ compatible = "advantech,idk-2121wr", "panel-lvds";
+
+ width-mm = <476>;
+ height-mm = <268>;
+
+ data-mapping = "vesa-24";
+
+ panel-timing {
+clock-frequency = <14850>;
+hactive = <1920>;
+vactive = <1080>;
+hsync-len = <44>;
+hfront-porch = <88>;
+hback-porch = <148>;
+vfront-porch = <4>;
+vback-porch = <36>;
+vsync-len = <5>;
+ };
+
+ ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+ reg = <0>;
+ dual-lvds-odd-pixels;
+ panel_in0: endpoint {
+remote-endpoint = <_out>;
+ };
+};
+
+port@1 {
+ reg = <1>;
+ dual-lvds-even-pixels;
+ panel_in1: endpoint {
+remote-endpoint = <_out>;
+ };
+};
+ };
+};
+
+...
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v5 4/6] drm: rcar-du: lvds: Allow for even and odd pixels swap
Hi Laurent,
Thank you for your feedback!
> From: Laurent Pinchart
> Sent: 16 December 2019 21:35
> Subject: Re: [PATCH v5 4/6] drm: rcar-du: lvds: Allow for even and odd pixels
> swap
>
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Mon, Dec 16, 2019 at 08:12:32PM +, Fabrizio Castro wrote:
> > DT properties dual-lvds-even-pixels and dual-lvds-odd-pixels
> > can be used to work out if the driver needs to swap even
> > and odd pixels around.
> >
> > This patch makes use of the return value from function
> > drm_of_lvds_get_dual_link_pixel_order to determine if we
> > need to swap odd and even pixels around for things to work
> > properly.
> >
> > Signed-off-by: Fabrizio Castro
> >
> > ---
> > v4->v5:
> > * Addressed comments from Laurent's review
> >
> > v3->v4:
> > * New patch extracted from patch:
> > "drm: rcar-du: lvds: Add dual-LVDS panels support"
> > ---
> > drivers/gpu/drm/rcar-du/rcar_lvds.c | 67
> > +
> > 1 file changed, 53 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > index 3eb208e..c6a38c3 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > @@ -37,6 +37,12 @@ enum rcar_lvds_mode {
> > RCAR_LVDS_MODE_VESA = 4,
> > };
> >
> > +enum rcar_lvds_link_type {
> > + RCAR_LVDS_SINGLE_LINK = 0,
> > + RCAR_LVDS_DUAL_LINK_EVEN_ODD_PIXELS = 1,
> > + RCAR_LVDS_DUAL_LINK_ODD_EVEN_PIXELS = 2,
> > +};
> > +
> > #define RCAR_LVDS_QUIRK_LANES BIT(0) /* LVDS lanes 1 and 3
> > inverted */
> > #define RCAR_LVDS_QUIRK_GEN3_LVEN BIT(1) /* LVEN bit needs to be set on
> > R8A77970/R8A7799x */
> > #define RCAR_LVDS_QUIRK_PWDBIT(2) /* PWD bit available
> > (all of Gen3 but E3) */
> > @@ -67,7 +73,7 @@ struct rcar_lvds {
> > } clocks;
> >
> > struct drm_bridge *companion;
> > - bool dual_link;
> > + enum rcar_lvds_link_type dual_link;
>
> Do you think we should rename this to link_type (and test for
> lvds->link_type != RCAR_LVDS_SINGLE_LINK) instead of lvds->dual_link) ?
> Apart from that,
I'll send v6 to address that. I will also rebase on top of:
https://patchwork.kernel.org/patch/11295991/
and will use that as a dependency for v6
Cheers,
Fab
>
> Reviewed-by: Laurent Pinchart
>
> > };
> >
> > #define bridge_to_rcar_lvds(b) \
> > @@ -484,12 +490,31 @@ static void rcar_lvds_atomic_enable(struct drm_bridge
> > *bridge,
> > rcar_lvds_write(lvds, LVDCHCR, lvdhcr);
> >
> > if (lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK) {
> > - /*
> > -* Configure vertical stripe based on the mode of operation of
> > -* the connected device.
> > -*/
> > - rcar_lvds_write(lvds, LVDSTRIPE,
> > - lvds->dual_link ? LVDSTRIPE_ST_ON : 0);
> > + u32 lvdstripe = 0;
> > +
> > + if (lvds->dual_link) {
> > + /*
> > +* By default we generate even pixels from the primary
> > +* encoder and odd pixels from the companion encoder.
> > +* Swap pixels around if the sink requires odd pixels
> > +* from the primary encoder and even pixels from the
> > +* companion encoder.
> > +*/
> > + bool swap_pixels = lvds->dual_link ==
> > + RCAR_LVDS_DUAL_LINK_ODD_EVEN_PIXELS;
> > +
> > + /*
> > +* Configure vertical stripe since we are dealing with
> > +* an LVDS dual-link connection.
> > +*
> > +* ST_SWAP is reserved for the companion encoder, only
> > +* set it in the primary encoder.
> > +*/
> > + lvdstripe = LVDSTRIPE_ST_ON
> > + | (lvds->companion && swap_pixels ?
> > +LVDSTRIPE_ST_SWAP : 0);
> > + }
> > + rcar_lvds_write(lvds, LVDSTRIPE, lvdstripe);
> > }
> >
> > /*
> > @@ -716,15 +741,26 @@ static int rcar_lvds_parse_dt_companion(struct
> > rcar_lvds *lvds)
> > of_node_put(port0);
> > of_node_put(po
RE: [PATCH v3] drm: rcar-du: lvds: Get mode from state
Hi Laurent,
Thank you for your patch!
> From: Laurent Pinchart
> Sent: 16 December 2019 22:31
> Subject: [PATCH v3] drm: rcar-du: lvds: Get mode from state
>
> The R-Car LVDS encoder driver implements the bridge .mode_set()
> operation for the sole purpose of storing the mode in the LVDS private
> data, to be used later when enabling the encoder.
>
> Switch to the bridge .atomic_enable() and .atomic_disable() operations
> in order to access the global atomic state, and get the mode from the
> state instead. Remove both the unneeded .mode_set() operation and the
> display_mode and mode fields storing state data from the rcar_lvds
> private structure.
>
> As a side effect we get the CRTC from the state, replace the CRTC
> pointer retrieved through the bridge's encoder that shouldn't be used by
> atomic drivers.
>
> While at it, clarify a few error messages in rcar_lvds_get_lvds_mode()
> and turn them into warnings as they are not fatal.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Fabrizio Castro
And I have tested this on the EK874, therefore
Tested-by: Fabrizio Castro
> ---
> Changes since v2:
>
> - Turn a few dev_err() into dev_warn()
> - Split rcar_lvds_atomic_enable() to avoid setting the companion's
> bridge encoder pointer manually
> - Call .atomic_disable() on the companion
>
> Changes since v1:
>
> - Call .atomic_enable() on the companion
> - Set companion->encoder in .attach()
> ---
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 140 +++-
> 1 file changed, 74 insertions(+), 66 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> index 8c6c172bbf2e..284f10d0307f 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -65,9 +65,6 @@ struct rcar_lvds {
> struct clk *dotclkin[2];/* External DU clocks */
> } clocks;
>
> - struct drm_display_mode display_mode;
> - enum rcar_lvds_mode mode;
> -
> struct drm_bridge *companion;
> bool dual_link;
> };
> @@ -402,10 +399,53 @@ EXPORT_SYMBOL_GPL(rcar_lvds_clk_disable);
> * Bridge
> */
>
> -static void rcar_lvds_enable(struct drm_bridge *bridge)
> +static enum rcar_lvds_mode rcar_lvds_get_lvds_mode(struct rcar_lvds *lvds,
> + const struct drm_connector *connector)
> +{
> + const struct drm_display_info *info;
> + enum rcar_lvds_mode mode;
> +
> + /*
> + * There is no API yet to retrieve LVDS mode from a bridge, only panels
> + * are supported.
> + */
> + if (!lvds->panel)
> + return RCAR_LVDS_MODE_JEIDA;
> +
> + info = >display_info;
> + if (!info->num_bus_formats || !info->bus_formats) {
> + dev_warn(lvds->dev,
> + "no LVDS bus format reported, using JEIDA\n");
> + return RCAR_LVDS_MODE_JEIDA;
> + }
> +
> + switch (info->bus_formats[0]) {
> + case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
> + case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA:
> + mode = RCAR_LVDS_MODE_JEIDA;
> + break;
> + case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG:
> + mode = RCAR_LVDS_MODE_VESA;
> + break;
> + default:
> + dev_warn(lvds->dev,
> + "unsupported LVDS bus format 0x%04x, using JEIDA\n",
> + info->bus_formats[0]);
> + return RCAR_LVDS_MODE_JEIDA;
> + }
> +
> + if (info->bus_flags & DRM_BUS_FLAG_DATA_LSB_TO_MSB)
> + mode |= RCAR_LVDS_MODE_MIRROR;
> +
> + return mode;
> +}
> +
> +static void __rcar_lvds_atomic_enable(struct drm_bridge *bridge,
> + struct drm_atomic_state *state,
> + struct drm_crtc *crtc,
> + struct drm_connector *connector)
> {
> struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);
> - const struct drm_display_mode *mode = >display_mode;
> u32 lvdhcr;
> u32 lvdcr0;
> int ret;
> @@ -416,7 +456,8 @@ static void rcar_lvds_enable(struct drm_bridge *bridge)
>
> /* Enable the companion LVDS encoder in dual-link mode. */
> if (lvds->dual_link && lvds->companion)
> - lvds->companion->funcs->enable(lvds->companion);
> + __rcar_lvds_atomic_enable(lvds->companion, state, crtc,
> + connector);
>
> /*
>* Hardcode the channels and control signals routing for now.
>
[PATCH v6 3/6] drm: rcar-du: lvds: Get dual link configuration from DT
For dual-LVDS configurations, it is now possible to mark the
DT port nodes for the sink with boolean properties (like
dual-lvds-even-pixels and dual-lvds-odd-pixels) to let drivers
know the encoders need to be configured in dual-LVDS mode.
Rework the implementation of rcar_lvds_parse_dt_companion
to make use of the DT markers while keeping backward
compatibility.
Signed-off-by: Fabrizio Castro
Reviewed-by: Laurent Pinchart
---
v5->v6:
* No change
v4->v5:
* Addressed comments from Laurent's review
v3->v4:
* New patch extracted from patch:
"drm: rcar-du: lvds: Add dual-LVDS panels support"
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 54 +++--
1 file changed, 46 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index da71107..fdbd36b 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -678,7 +678,10 @@ static int rcar_lvds_parse_dt_companion(struct rcar_lvds
*lvds)
{
const struct of_device_id *match;
struct device_node *companion;
+ struct device_node *port0, *port1;
+ struct rcar_lvds *companion_lvds;
struct device *dev = lvds->dev;
+ int dual_link;
int ret = 0;
/* Locate the companion LVDS encoder for dual-link operation, if any. */
@@ -697,13 +700,54 @@ static int rcar_lvds_parse_dt_companion(struct rcar_lvds
*lvds)
goto done;
}
+ /*
+* We need to work out if the sink is expecting us to function in
+* dual-link mode. We do this by looking at the DT port nodes we are
+* connected to, if they are marked as expecting even pixels and
+* odd pixels than we need to enable vertical stripe output.
+*/
+ port0 = of_graph_get_port_by_id(dev->of_node, 1);
+ port1 = of_graph_get_port_by_id(companion, 1);
+ dual_link = drm_of_lvds_get_dual_link_pixel_order(port0, port1);
+ of_node_put(port0);
+ of_node_put(port1);
+
+ if (dual_link >= DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS)
+ lvds->dual_link = true;
+ else if (lvds->next_bridge && lvds->next_bridge->timings)
+ /*
+* Early dual-link bridge specific implementations populate the
+* timings field of drm_bridge, read the dual_link flag off the
+* bridge directly for backward compatibility.
+*/
+ lvds->dual_link = lvds->next_bridge->timings->dual_link;
+
+ if (!lvds->dual_link) {
+ dev_dbg(dev, "Single-link configuration detected\n");
+ goto done;
+ }
+
lvds->companion = of_drm_find_bridge(companion);
if (!lvds->companion) {
ret = -EPROBE_DEFER;
goto done;
}
- dev_dbg(dev, "Found companion encoder %pOF\n", companion);
+ dev_dbg(dev,
+ "Dual-link configuration detected (companion encoder %pOF)\n",
+ companion);
+
+ /*
+* FIXME: We should not be messing with the companion encoder private
+* data from the primary encoder, we should rather let the companion
+* encoder work things out on its own. However, the companion encoder
+* doesn't hold a reference to the primary encoder, and
+* drm_of_lvds_get_dual_link_pixel_order needs to be given references
+* to the output ports of both encoders, therefore leave it like this
+* for the time being.
+*/
+ companion_lvds = bridge_to_rcar_lvds(lvds->companion);
+ companion_lvds->dual_link = true;
done:
of_node_put(companion);
@@ -720,13 +764,7 @@ static int rcar_lvds_parse_dt(struct rcar_lvds *lvds)
if (ret)
goto done;
- if ((lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK) &&
- lvds->next_bridge)
- lvds->dual_link = lvds->next_bridge->timings
- ? lvds->next_bridge->timings->dual_link
- : false;
-
- if (lvds->dual_link)
+ if (lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK)
ret = rcar_lvds_parse_dt_companion(lvds);
done:
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 6/6] arm64: dts: renesas: Add EK874 board with idk-2121wr display support
The EK874 is advertised as compatible with panel IDK-2121WR from
Advantech, however the panel isn't sold alongside the board.
A new dts, adding everything that's required to get the panel to
to work with the EK874, is the most convenient way to support the
EK874 when it's connected to the IDK-2121WR.
Signed-off-by: Fabrizio Castro
Acked-by: Laurent Pinchart
---
Hi Geert,
I think it is now safe for you to have a look at this patch.
Thanks,
Fab
v5->v6:
* No change
v4->v5:
* No change
v3->v4:
* No change
v2->v3:
* Removed renesas,swap-data property
* Added dual-lvds-odd-pixels and dual-lvds-even-pixels properties
v1->v2:
* Added comment for lvds-connector-en-gpio
* Renamed _panel_in to panel_in0
* Renamed _panel_in to panel_in1
---
arch/arm64/boot/dts/renesas/Makefile | 3 +-
.../boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts | 116 +
2 files changed, 118 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts
diff --git a/arch/arm64/boot/dts/renesas/Makefile
b/arch/arm64/boot/dts/renesas/Makefile
index d4cc332..ab2c799 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -3,7 +3,8 @@ dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m.dtb
dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m-ex.dtb
dtb-$(CONFIG_ARCH_R8A774B1) += r8a774b1-hihope-rzg2n.dtb
dtb-$(CONFIG_ARCH_R8A774B1) += r8a774b1-hihope-rzg2n-ex.dtb
-dtb-$(CONFIG_ARCH_R8A774C0) += r8a774c0-cat874.dtb r8a774c0-ek874.dtb
+dtb-$(CONFIG_ARCH_R8A774C0) += r8a774c0-cat874.dtb r8a774c0-ek874.dtb \
+ r8a774c0-ek874-idk-2121wr.dtb
dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-salvator-x.dtb r8a7795-h3ulcb.dtb
dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-h3ulcb-kf.dtb
dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-salvator-xs.dtb
diff --git a/arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts
b/arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts
new file mode 100644
index 000..a7b27d0
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts
@@ -0,0 +1,116 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the Silicon Linux RZ/G2E evaluation kit (EK874),
+ * connected to an Advantech IDK-2121WR 21.5" LVDS panel
+ *
+ * Copyright (C) 2019 Renesas Electronics Corp.
+ */
+
+#include "r8a774c0-ek874.dts"
+
+/ {
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = < 0 5>;
+
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <6>;
+
+ power-supply = <_12p0v>;
+ enable-gpios = < 12 GPIO_ACTIVE_HIGH>;
+ };
+
+ panel-lvds {
+ compatible = "advantech,idk-2121wr", "panel-lvds";
+
+ width-mm = <476>;
+ height-mm = <268>;
+
+ data-mapping = "vesa-24";
+
+ panel-timing {
+ clock-frequency = <14850>;
+ hactive = <1920>;
+ vactive = <1080>;
+ hsync-len = <44>;
+ hfront-porch = <88>;
+ hback-porch = <148>;
+ vfront-porch = <4>;
+ vback-porch = <36>;
+ vsync-len = <5>;
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dual-lvds-odd-pixels;
+ panel_in0: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dual-lvds-even-pixels;
+ panel_in1: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+ };
+};
+
+ {
+ /*
+* When GP0_17 is low LVDS[01] are connected to the LVDS connector
+* When GP0_17 is high LVDS[01] are connected to the LT8918L
+*/
+ lvds-connector-en-gpio{
+ gpio-hog;
+ gpios = <17 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "lvds-connector-en-gpio";
+ };
+};
+
+ {
+ ports {
+ port@1 {
+ lvds0_out: endpoint {
+ remote-endpoint = <_in0>;
+ };
+ };
+ }
RE: [PATCH v4 06/13] drm/bridge: lvds-codec: Add "lvds-decoder" support
Hi Geert,
Thank you for your feedback!
> From: linux-renesas-soc-ow...@vger.kernel.org
> On Behalf Of Geert Uytterhoeven
> Sent: 17 December 2019 12:21
> Subject: Re: [PATCH v4 06/13] drm/bridge: lvds-codec: Add "lvds-decoder"
> support
>
> Hi Fabrizio,
>
> On Tue, Dec 17, 2019 at 12:03 PM Fabrizio Castro
> wrote:
> > > From: Laurent Pinchart
> > > Sent: 13 December 2019 17:11
> > > Subject: Re: [PATCH v4 06/13] drm/bridge: lvds-codec: Add "lvds-decoder"
> > > support
> > >
> > > On Wed, Nov 13, 2019 at 03:51:25PM +, Fabrizio Castro wrote:
> > > > Add support for transparent LVDS decoders by adding a new
> > > > compatible string ("lvds-decoder") to the driver.
> > > > This patch also adds member connector_type to struct lvds_codec,
> > > > and that's because LVDS decoders have a different connector type
> > > > from LVDS encoders. We fill this new member up with the data
> > > > matching the compatible string.
> > > >
> > > > Signed-off-by: Fabrizio Castro
> > > >
> > > > ---
> > > > v3->v4:
> > > > * New patch
> > > > ---
> > > > drivers/gpu/drm/bridge/lvds-codec.c | 19 ---
> > > > 1 file changed, 16 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
> > > > b/drivers/gpu/drm/bridge/lvds-codec.c
> > > > index b5801a2..c32e125 100644
> > > > --- a/drivers/gpu/drm/bridge/lvds-codec.c
> > > > +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> > > > @@ -7,6 +7,7 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > > #include
> > > > #include
> > > >
> > > > @@ -17,6 +18,7 @@ struct lvds_codec {
> > > > struct drm_bridge bridge;
> > > > struct drm_bridge *panel_bridge;
> > > > struct gpio_desc *powerdown_gpio;
> > > > + u32 connector_type;
> > > > };
> > > >
> > > > static int lvds_codec_attach(struct drm_bridge *bridge)
> > > > @@ -65,6 +67,7 @@ static int lvds_codec_probe(struct platform_device
> > > > *pdev)
> > > > if (!lvds_codec)
> > > > return -ENOMEM;
> > > >
> > > > + lvds_codec->connector_type =
> > > > (u32)of_device_get_match_data(>dev);
> > >
> > > I'm now getting a compilation failure here:
> > >
> > > drivers/gpu/drm/bridge/lvds-codec.c: In function ‘lvds_codec_probe’:
> > > drivers/gpu/drm/bridge/lvds-codec.c:68:31: error: cast from pointer to
> > > integer of different size [-Werror=pointer-to-int-cast]
> > > lvds_codec->connector_type = (u32)of_device_get_match_data(>dev);
> > >^
> > >
> > > The fix should be simple:
> > >
> > > lvds_codec->connector_type =
> > > (uintptr_t)of_device_get_match_data(dev);
> > >
> > > I'm bothered by the fact that I've compiled this before without any
> > > issue, so this really puzzles me. Do you get the same warning ?
> >
> > The warning appears when compiling for arm64, understandably so.
> > We must have compiled this for arm only the first time around.
> >
> > I think the right way to solve this is to either cast to (u32)(uintptr_t)
> > or (u32)(unsigned long).
>
> Just casting to uintptr_t should be sufficient.
It should be sufficient for the compiler, but I have seen examples where people
preferred to be explicit, like in:
drivers/mailbox/mtk-cmdq-mailbox.c
drivers/leds/leds-pm8058.c
Since the kernel is increasing its tightness with respect to warnings, I
personally prefer
(u32)(uintptr_t), even though not strictly necessary, but I am fine with
(uintptr_t) if you
don't like (u32)(uintptr_t).
Cheers,
Fab
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 1/6] drm: of: Add drm_of_lvds_get_dual_link_pixel_order
An LVDS dual-link connection is made of two links, with even
pixels transitting on one link, and odd pixels on the other
link. The device tree can be used to fully describe dual-link
LVDS connections between encoders and bridges/panels.
The sink of an LVDS dual-link connection is made of two ports,
the corresponding OF graph port nodes can be marked
with either dual-lvds-even-pixels or dual-lvds-odd-pixels,
and that fully describes an LVDS dual-link connection,
including pixel order.
drm_of_lvds_get_dual_link_pixel_order is a new helper
added by this patch, given the source port nodes it
returns DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS if the source
port nodes belong to an LVDS dual-link connection, with even
pixels expected to be generated from the first port, and odd
pixels expected to be generated from the second port.
If the new helper returns DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS,
odd pixels are expected to be generated from the first port,
and even pixels from the other port.
Signed-off-by: Fabrizio Castro
Reviewed-by: Laurent Pinchart
---
v5->v6:
* No change
v4->v5:
* Addressed comments from Laurent's review
v3->v4:
* New patch extracted from patch:
"drm: rcar-du: lvds: Add dual-LVDS panels support"
---
drivers/gpu/drm/drm_of.c | 116 +++
include/drm/drm_of.h | 20
2 files changed, 136 insertions(+)
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 0ca5880..b50b44e 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -274,3 +274,119 @@ int drm_of_find_panel_or_bridge(const struct device_node
*np,
return ret;
}
EXPORT_SYMBOL_GPL(drm_of_find_panel_or_bridge);
+
+enum drm_of_lvds_pixels {
+ DRM_OF_LVDS_EVEN = BIT(0),
+ DRM_OF_LVDS_ODD = BIT(1),
+};
+
+static int drm_of_lvds_get_port_pixels_type(struct device_node *port_node)
+{
+ bool even_pixels =
+ of_property_read_bool(port_node, "dual-lvds-even-pixels");
+ bool odd_pixels =
+ of_property_read_bool(port_node, "dual-lvds-odd-pixels");
+
+ return (even_pixels ? DRM_OF_LVDS_EVEN : 0) |
+ (odd_pixels ? DRM_OF_LVDS_ODD : 0);
+}
+
+static int drm_of_lvds_get_remote_pixels_type(
+ const struct device_node *port_node)
+{
+ struct device_node *endpoint = NULL;
+ int pixels_type = -EPIPE;
+
+ for_each_child_of_node(port_node, endpoint) {
+ struct device_node *remote_port;
+ int current_pt;
+
+ if (!of_node_name_eq(endpoint, "endpoint"))
+ continue;
+
+ remote_port = of_graph_get_remote_port(endpoint);
+ if (!remote_port) {
+ of_node_put(remote_port);
+ return -EPIPE;
+ }
+
+ current_pt = drm_of_lvds_get_port_pixels_type(remote_port);
+ of_node_put(remote_port);
+ if (pixels_type < 0)
+ pixels_type = current_pt;
+
+ /*
+* Sanity check, ensure that all remote endpoints have the same
+* pixel type. We may lift this restriction later if we need to
+* support multiple sinks with different dual-link
+* configurations by passing the endpoints explicitly to
+* drm_of_lvds_get_dual_link_pixel_order().
+*/
+ if (!current_pt || pixels_type != current_pt) {
+ of_node_put(remote_port);
+ return -EINVAL;
+ }
+ }
+
+ return pixels_type;
+}
+
+/**
+ * drm_of_lvds_get_dual_link_pixel_order - Get LVDS dual-link pixel order
+ * @port1: First DT port node of the Dual-link LVDS source
+ * @port2: Second DT port node of the Dual-link LVDS source
+ *
+ * An LVDS dual-link connection is made of two links, with even pixels
+ * transitting on one link, and odd pixels on the other link. This function
+ * returns, for two ports of an LVDS dual-link source, which port shall
transmit
+ * the even and odd pixels, based on the requirements of the connected sink.
+ *
+ * The pixel order is determined from the dual-lvds-even-pixels and
+ * dual-lvds-odd-pixels properties in the sink's DT port nodes. If those
+ * properties are not present, or if their usage is not valid, this function
+ * returns -EINVAL.
+ *
+ * If either port is not connected, this function returns -EPIPE.
+ *
+ * @port1 and @port2 are typically DT sibling nodes, but may have different
+ * parents when, for instance, two separate LVDS encoders carry the even and
odd
+ * pixels.
+ *
+ * Return:
+ * * DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS - @port1 carries even pixels and @port2
+ * carries odd pixels
+ * * DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS - @port1 carries odd pixels and @port2
+ * carries even pixels
+ * * -EINVAL - @port1 and @port2 are not c
RE: [PATCH v4 06/13] drm/bridge: lvds-codec: Add "lvds-decoder" support
Hi Laurent,
Thank you for your feedback!
> From: Laurent Pinchart
> Sent: 13 December 2019 17:11
> Subject: Re: [PATCH v4 06/13] drm/bridge: lvds-codec: Add "lvds-decoder"
> support
>
> Hi Fabrizio,
>
> On Wed, Nov 13, 2019 at 03:51:25PM +, Fabrizio Castro wrote:
> > Add support for transparent LVDS decoders by adding a new
> > compatible string ("lvds-decoder") to the driver.
> > This patch also adds member connector_type to struct lvds_codec,
> > and that's because LVDS decoders have a different connector type
> > from LVDS encoders. We fill this new member up with the data
> > matching the compatible string.
> >
> > Signed-off-by: Fabrizio Castro
> >
> > ---
> > v3->v4:
> > * New patch
> > ---
> > drivers/gpu/drm/bridge/lvds-codec.c | 19 ---
> > 1 file changed, 16 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
> > b/drivers/gpu/drm/bridge/lvds-codec.c
> > index b5801a2..c32e125 100644
> > --- a/drivers/gpu/drm/bridge/lvds-codec.c
> > +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> > @@ -7,6 +7,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -17,6 +18,7 @@ struct lvds_codec {
> > struct drm_bridge bridge;
> > struct drm_bridge *panel_bridge;
> > struct gpio_desc *powerdown_gpio;
> > + u32 connector_type;
> > };
> >
> > static int lvds_codec_attach(struct drm_bridge *bridge)
> > @@ -65,6 +67,7 @@ static int lvds_codec_probe(struct platform_device *pdev)
> > if (!lvds_codec)
> > return -ENOMEM;
> >
> > + lvds_codec->connector_type = (u32)of_device_get_match_data(>dev);
>
> I'm now getting a compilation failure here:
>
> drivers/gpu/drm/bridge/lvds-codec.c: In function ‘lvds_codec_probe’:
> drivers/gpu/drm/bridge/lvds-codec.c:68:31: error: cast from pointer to
> integer of different size [-Werror=pointer-to-int-cast]
> lvds_codec->connector_type = (u32)of_device_get_match_data(>dev);
>^
>
> The fix should be simple:
>
> lvds_codec->connector_type = (uintptr_t)of_device_get_match_data(dev);
>
> I'm bothered by the fact that I've compiled this before without any
> issue, so this really puzzles me. Do you get the same warning ?
The warning appears when compiling for arm64, understandably so.
We must have compiled this for arm only the first time around.
I think the right way to solve this is to either cast to (u32)(uintptr_t) or
(u32)(unsigned long).
What's your preference?
Thanks,
Fab
>
> > lvds_codec->powerdown_gpio = devm_gpiod_get_optional(dev, "powerdown",
> > GPIOD_OUT_HIGH);
> > if (IS_ERR(lvds_codec->powerdown_gpio)) {
> > @@ -105,7 +108,7 @@ static int lvds_codec_probe(struct platform_device
> > *pdev)
> >
> > lvds_codec->panel_bridge =
> > devm_drm_panel_bridge_add_typed(dev, panel,
> > - DRM_MODE_CONNECTOR_LVDS);
> > + lvds_codec->connector_type);
> > if (IS_ERR(lvds_codec->panel_bridge))
> > return PTR_ERR(lvds_codec->panel_bridge);
> >
> > @@ -133,8 +136,18 @@ static int lvds_codec_remove(struct platform_device
> > *pdev)
> > }
> >
> > static const struct of_device_id lvds_codec_match[] = {
> > - { .compatible = "lvds-encoder" },
> > - { .compatible = "thine,thc63lvdm83d" },
> > + {
> > + .compatible = "lvds-decoder",
> > + .data = (void *)DRM_MODE_CONNECTOR_DPI,
> > + },
> > + {
> > + .compatible = "lvds-encoder",
> > + .data = (void *)DRM_MODE_CONNECTOR_LVDS,
> > + },
> > + {
> > + .compatible = "thine,thc63lvdm83d",
> > + .data = (void *)DRM_MODE_CONNECTOR_LVDS,
> > + },
> > {},
> > };
> > MODULE_DEVICE_TABLE(of, lvds_codec_match);
>
> --
> Regards,
>
> Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 4/6] drm: rcar-du: lvds: Allow for even and odd pixels swap
DT properties dual-lvds-even-pixels and dual-lvds-odd-pixels
can be used to work out if the driver needs to swap even
and odd pixels around.
This patch makes use of the return value from function
drm_of_lvds_get_dual_link_pixel_order to determine if we
need to swap odd and even pixels around for things to work
properly.
The dual_link boolean field from struct rcar_lvds is not
sufficient to describe the type of LVDS link anymore, since
we now have information related to pixel order, therefore
rename it to link_type and repurpose its usage to fit the
new requirements.
Signed-off-by: Fabrizio Castro
Reviewed-by: Laurent Pinchart
---
v5->v6:
* Renamed dual_link to link_type and reworked its usage
v4->v5:
* Addressed comments from Laurent's review
v3->v4:
* New patch extracted from patch:
"drm: rcar-du: lvds: Add dual-LVDS panels support"
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 77 -
1 file changed, 58 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index fdbd36b..8ffa4fb 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -37,6 +37,12 @@ enum rcar_lvds_mode {
RCAR_LVDS_MODE_VESA = 4,
};
+enum rcar_lvds_link_type {
+ RCAR_LVDS_SINGLE_LINK = 0,
+ RCAR_LVDS_DUAL_LINK_EVEN_ODD_PIXELS = 1,
+ RCAR_LVDS_DUAL_LINK_ODD_EVEN_PIXELS = 2,
+};
+
#define RCAR_LVDS_QUIRK_LANES BIT(0) /* LVDS lanes 1 and 3 inverted
*/
#define RCAR_LVDS_QUIRK_GEN3_LVEN BIT(1) /* LVEN bit needs to be set on
R8A77970/R8A7799x */
#define RCAR_LVDS_QUIRK_PWDBIT(2) /* PWD bit available (all of
Gen3 but E3) */
@@ -67,7 +73,7 @@ struct rcar_lvds {
} clocks;
struct drm_bridge *companion;
- bool dual_link;
+ enum rcar_lvds_link_type link_type;
};
#define bridge_to_rcar_lvds(b) \
@@ -456,7 +462,7 @@ static void __rcar_lvds_atomic_enable(struct drm_bridge
*bridge,
return;
/* Enable the companion LVDS encoder in dual-link mode. */
- if (lvds->dual_link && lvds->companion)
+ if (lvds->link_type != RCAR_LVDS_SINGLE_LINK && lvds->companion)
__rcar_lvds_atomic_enable(lvds->companion, state, crtc,
connector);
@@ -482,19 +488,38 @@ static void __rcar_lvds_atomic_enable(struct drm_bridge
*bridge,
rcar_lvds_write(lvds, LVDCHCR, lvdhcr);
if (lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK) {
- /*
-* Configure vertical stripe based on the mode of operation of
-* the connected device.
-*/
- rcar_lvds_write(lvds, LVDSTRIPE,
- lvds->dual_link ? LVDSTRIPE_ST_ON : 0);
+ u32 lvdstripe = 0;
+
+ if (lvds->link_type != RCAR_LVDS_SINGLE_LINK) {
+ /*
+* By default we generate even pixels from the primary
+* encoder and odd pixels from the companion encoder.
+* Swap pixels around if the sink requires odd pixels
+* from the primary encoder and even pixels from the
+* companion encoder.
+*/
+ bool swap_pixels = lvds->link_type ==
+ RCAR_LVDS_DUAL_LINK_ODD_EVEN_PIXELS;
+
+ /*
+* Configure vertical stripe since we are dealing with
+* an LVDS dual-link connection.
+*
+* ST_SWAP is reserved for the companion encoder, only
+* set it in the primary encoder.
+*/
+ lvdstripe = LVDSTRIPE_ST_ON
+ | (lvds->companion && swap_pixels ?
+LVDSTRIPE_ST_SWAP : 0);
+ }
+ rcar_lvds_write(lvds, LVDSTRIPE, lvdstripe);
}
/*
* PLL clock configuration on all instances but the companion in
* dual-link mode.
*/
- if (!lvds->dual_link || lvds->companion) {
+ if (lvds->link_type == RCAR_LVDS_SINGLE_LINK || lvds->companion) {
const struct drm_crtc_state *crtc_state =
drm_atomic_get_new_crtc_state(state, crtc);
const struct drm_display_mode *mode =
@@ -592,7 +617,7 @@ static void rcar_lvds_atomic_disable(struct drm_bridge
*bridge,
rcar_lvds_write(lvds, LVDPLLCR, 0);
/* Disable the companion LVDS encoder in dual-link mode. */
- if (lvds->dual_link && lvds->companion)
+ if (lvds->link_type != RCAR_LVDS_SINGLE_LINK && lvds->companion)
lvds
[PATCH v5 2/6] drm: rcar-du: lvds: Improve identification of panels
Dual-LVDS panels are mistakenly identified as bridges, this
commit replaces the current logic with a call to
drm_of_find_panel_or_bridge to sort that out.
Signed-off-by: Fabrizio Castro
---
v4->v5:
* Addressed comments from Laurent's review
v3->v4:
* New patch extracted from patch:
"drm: rcar-du: lvds: Add dual-LVDS panels support"
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 75 +
1 file changed, 10 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index b03b7cd..4d038bd 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -716,79 +717,23 @@ static int rcar_lvds_parse_dt_companion(struct rcar_lvds
*lvds)
static int rcar_lvds_parse_dt(struct rcar_lvds *lvds)
{
- struct device_node *local_output = NULL;
- struct device_node *remote_input = NULL;
- struct device_node *remote = NULL;
- struct device_node *node;
- bool is_bridge = false;
- int ret = 0;
-
- local_output = of_graph_get_endpoint_by_regs(lvds->dev->of_node, 1, 0);
- if (!local_output) {
- dev_dbg(lvds->dev, "unconnected port@1\n");
- ret = -ENODEV;
- goto done;
- }
-
- /*
-* Locate the connected entity and infer its type from the number of
-* endpoints.
-*/
- remote = of_graph_get_remote_port_parent(local_output);
- if (!remote) {
- dev_dbg(lvds->dev, "unconnected endpoint %pOF\n", local_output);
- ret = -ENODEV;
- goto done;
- }
+ int ret;
- if (!of_device_is_available(remote)) {
- dev_dbg(lvds->dev, "connected entity %pOF is disabled\n",
- remote);
- ret = -ENODEV;
+ ret = drm_of_find_panel_or_bridge(lvds->dev->of_node, 1, 0,
+ >panel, >next_bridge);
+ if (ret)
goto done;
- }
- remote_input = of_graph_get_remote_endpoint(local_output);
-
- for_each_endpoint_of_node(remote, node) {
- if (node != remote_input) {
- /*
-* We've found one endpoint other than the input, this
-* must be a bridge.
-*/
- is_bridge = true;
- of_node_put(node);
- break;
- }
- }
-
- if (is_bridge) {
- lvds->next_bridge = of_drm_find_bridge(remote);
- if (!lvds->next_bridge) {
- ret = -EPROBE_DEFER;
- goto done;
- }
-
- if (lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK)
- lvds->dual_link = lvds->next_bridge->timings
- ? lvds->next_bridge->timings->dual_link
- : false;
- } else {
- lvds->panel = of_drm_find_panel(remote);
- if (IS_ERR(lvds->panel)) {
- ret = PTR_ERR(lvds->panel);
- goto done;
- }
- }
+ if ((lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK) &&
+ lvds->next_bridge)
+ lvds->dual_link = lvds->next_bridge->timings
+ ? lvds->next_bridge->timings->dual_link
+ : false;
if (lvds->dual_link)
ret = rcar_lvds_parse_dt_companion(lvds);
done:
- of_node_put(local_output);
- of_node_put(remote_input);
- of_node_put(remote);
-
/*
* On D3/E3 the LVDS encoder provides a clock to the DU, which can be
* used for the DPAD output even when the LVDS output is not connected.
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 0/6] Add dual-LVDS panel support to EK874
Dear All, this series adds support for dual-LVDS panel IDK-2121WR from Advantech: https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.htm V5 incorporates the comments from Laurent on v4, including rebasing the series on top of patch: https://patchwork.kernel.org/patch/11290969/ As a result, patch "drm: rcar-du: lvds: Fix mode for companion encoder" has been dropped. Thanks, Fab Fabrizio Castro (6): drm: of: Add drm_of_lvds_get_dual_link_pixel_order drm: rcar-du: lvds: Improve identification of panels drm: rcar-du: lvds: Get dual link configuration from DT drm: rcar-du: lvds: Allow for even and odd pixels swap dt-bindings: display: Add idk-2121wr binding arm64: dts: renesas: Add EK874 board with idk-2121wr display support .../display/panel/advantech,idk-2121wr.yaml| 128 +++ arch/arm64/boot/dts/renesas/Makefile | 3 +- .../boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts | 116 ++ drivers/gpu/drm/drm_of.c | 116 ++ drivers/gpu/drm/rcar-du/rcar_lvds.c| 172 - include/drm/drm_of.h | 20 +++ 6 files changed, 479 insertions(+), 76 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml create mode 100644 arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 5/6] dt-bindings: display: Add idk-2121wr binding
Add binding for the idk-2121wr LVDS panel from Advantech.
Some panel-specific documentation can be found here:
https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.htm
Signed-off-by: Fabrizio Castro
Reviewed-by: Laurent Pinchart
---
v4->v5:
* No change
v3->v4:
* Absorbed patch "dt-bindings: display: Add bindings for LVDS
bus-timings"
* Big restructuring after Rob's and Laurent's comments
v2->v3:
* new patch
---
.../display/panel/advantech,idk-2121wr.yaml| 128 +
1 file changed, 128 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
new file mode 100644
index 000..24cd38b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
@@ -0,0 +1,128 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/advantech,idk-2121wr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Advantech IDK-2121WR 21.5" Full-HD dual-LVDS panel
+
+maintainers:
+ - Fabrizio Castro
+ - Thierry Reding
+
+description: |
+ The IDK-2121WR from Advantech is a Full-HD dual-LVDS panel.
+ A dual-LVDS interface is a dual-link connection with even pixels traveling
+ on one link, and with odd pixels traveling on the other link.
+
+ The panel expects odd pixels on the first port, and even pixels on the
+ second port, therefore the ports must be marked accordingly (with either
+ dual-lvds-odd-pixels or dual-lvds-even-pixels).
+
+properties:
+ compatible:
+items:
+ - const: advantech,idk-2121wr
+ - {} # panel-lvds, but not listed here to avoid false select
+
+ width-mm:
+const: 476
+
+ height-mm:
+const: 268
+
+ data-mapping:
+const: vesa-24
+
+ ports:
+type: object
+properties:
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+ port@0:
+type: object
+description: The sink for odd pixels.
+properties:
+ reg:
+const: 0
+
+ dual-lvds-odd-pixels: true
+
+required:
+ - reg
+ - dual-lvds-odd-pixels
+
+ port@1:
+type: object
+description: The sink for even pixels.
+properties:
+ reg:
+const: 1
+
+ dual-lvds-even-pixels: true
+
+required:
+ - reg
+ - dual-lvds-even-pixels
+
+ panel-timing: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - width-mm
+ - height-mm
+ - data-mapping
+ - panel-timing
+ - ports
+
+examples:
+ - |+
+panel-lvds {
+ compatible = "advantech,idk-2121wr", "panel-lvds";
+
+ width-mm = <476>;
+ height-mm = <268>;
+
+ data-mapping = "vesa-24";
+
+ panel-timing {
+clock-frequency = <14850>;
+hactive = <1920>;
+vactive = <1080>;
+hsync-len = <44>;
+hfront-porch = <88>;
+hback-porch = <148>;
+vfront-porch = <4>;
+vback-porch = <36>;
+vsync-len = <5>;
+ };
+
+ ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+ reg = <0>;
+ dual-lvds-odd-pixels;
+ panel_in0: endpoint {
+remote-endpoint = <_out>;
+ };
+};
+
+port@1 {
+ reg = <1>;
+ dual-lvds-even-pixels;
+ panel_in1: endpoint {
+remote-endpoint = <_out>;
+ };
+};
+ };
+};
+
+...
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 1/6] drm: of: Add drm_of_lvds_get_dual_link_pixel_order
An LVDS dual-link connection is made of two links, with even
pixels transitting on one link, and odd pixels on the other
link. The device tree can be used to fully describe dual-link
LVDS connections between encoders and bridges/panels.
The sink of an LVDS dual-link connection is made of two ports,
the corresponding OF graph port nodes can be marked
with either dual-lvds-even-pixels or dual-lvds-odd-pixels,
and that fully describes an LVDS dual-link connection,
including pixel order.
drm_of_lvds_get_dual_link_pixel_order is a new helper
added by this patch, given the source port nodes it
returns DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS if the source
port nodes belong to an LVDS dual-link connection, with even
pixels expected to be generated from the first port, and odd
pixels expected to be generated from the second port.
If the new helper returns DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS,
odd pixels are expected to be generated from the first port,
and even pixels from the other port.
Signed-off-by: Fabrizio Castro
Reviewed-by: Laurent Pinchart
---
v4->v5:
* Addressed comments from Laurent's review
v3->v4:
* New patch extracted from patch:
"drm: rcar-du: lvds: Add dual-LVDS panels support"
---
drivers/gpu/drm/drm_of.c | 116 +++
include/drm/drm_of.h | 20
2 files changed, 136 insertions(+)
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 0ca5880..b50b44e 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -274,3 +274,119 @@ int drm_of_find_panel_or_bridge(const struct device_node
*np,
return ret;
}
EXPORT_SYMBOL_GPL(drm_of_find_panel_or_bridge);
+
+enum drm_of_lvds_pixels {
+ DRM_OF_LVDS_EVEN = BIT(0),
+ DRM_OF_LVDS_ODD = BIT(1),
+};
+
+static int drm_of_lvds_get_port_pixels_type(struct device_node *port_node)
+{
+ bool even_pixels =
+ of_property_read_bool(port_node, "dual-lvds-even-pixels");
+ bool odd_pixels =
+ of_property_read_bool(port_node, "dual-lvds-odd-pixels");
+
+ return (even_pixels ? DRM_OF_LVDS_EVEN : 0) |
+ (odd_pixels ? DRM_OF_LVDS_ODD : 0);
+}
+
+static int drm_of_lvds_get_remote_pixels_type(
+ const struct device_node *port_node)
+{
+ struct device_node *endpoint = NULL;
+ int pixels_type = -EPIPE;
+
+ for_each_child_of_node(port_node, endpoint) {
+ struct device_node *remote_port;
+ int current_pt;
+
+ if (!of_node_name_eq(endpoint, "endpoint"))
+ continue;
+
+ remote_port = of_graph_get_remote_port(endpoint);
+ if (!remote_port) {
+ of_node_put(remote_port);
+ return -EPIPE;
+ }
+
+ current_pt = drm_of_lvds_get_port_pixels_type(remote_port);
+ of_node_put(remote_port);
+ if (pixels_type < 0)
+ pixels_type = current_pt;
+
+ /*
+* Sanity check, ensure that all remote endpoints have the same
+* pixel type. We may lift this restriction later if we need to
+* support multiple sinks with different dual-link
+* configurations by passing the endpoints explicitly to
+* drm_of_lvds_get_dual_link_pixel_order().
+*/
+ if (!current_pt || pixels_type != current_pt) {
+ of_node_put(remote_port);
+ return -EINVAL;
+ }
+ }
+
+ return pixels_type;
+}
+
+/**
+ * drm_of_lvds_get_dual_link_pixel_order - Get LVDS dual-link pixel order
+ * @port1: First DT port node of the Dual-link LVDS source
+ * @port2: Second DT port node of the Dual-link LVDS source
+ *
+ * An LVDS dual-link connection is made of two links, with even pixels
+ * transitting on one link, and odd pixels on the other link. This function
+ * returns, for two ports of an LVDS dual-link source, which port shall
transmit
+ * the even and odd pixels, based on the requirements of the connected sink.
+ *
+ * The pixel order is determined from the dual-lvds-even-pixels and
+ * dual-lvds-odd-pixels properties in the sink's DT port nodes. If those
+ * properties are not present, or if their usage is not valid, this function
+ * returns -EINVAL.
+ *
+ * If either port is not connected, this function returns -EPIPE.
+ *
+ * @port1 and @port2 are typically DT sibling nodes, but may have different
+ * parents when, for instance, two separate LVDS encoders carry the even and
odd
+ * pixels.
+ *
+ * Return:
+ * * DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS - @port1 carries even pixels and @port2
+ * carries odd pixels
+ * * DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS - @port1 carries odd pixels and @port2
+ * carries even pixels
+ * * -EINVAL - @port1 and @port2 are not connected to a dual-link LVDS
[PATCH v5 3/6] drm: rcar-du: lvds: Get dual link configuration from DT
For dual-LVDS configurations, it is now possible to mark the
DT port nodes for the sink with boolean properties (like
dual-lvds-even-pixels and dual-lvds-odd-pixels) to let drivers
know the encoders need to be configured in dual-LVDS mode.
Rework the implementation of rcar_lvds_parse_dt_companion
to make use of the DT markers while keeping backward
compatibility.
Signed-off-by: Fabrizio Castro
Reviewed-by: Laurent Pinchart
---
v4->v5:
* Addressed comments from Laurent's review
v3->v4:
* New patch extracted from patch:
"drm: rcar-du: lvds: Add dual-LVDS panels support"
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 54 +++--
1 file changed, 46 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 4d038bd..3eb208e 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -682,7 +682,10 @@ static int rcar_lvds_parse_dt_companion(struct rcar_lvds
*lvds)
{
const struct of_device_id *match;
struct device_node *companion;
+ struct device_node *port0, *port1;
+ struct rcar_lvds *companion_lvds;
struct device *dev = lvds->dev;
+ int dual_link;
int ret = 0;
/* Locate the companion LVDS encoder for dual-link operation, if any. */
@@ -701,13 +704,54 @@ static int rcar_lvds_parse_dt_companion(struct rcar_lvds
*lvds)
goto done;
}
+ /*
+* We need to work out if the sink is expecting us to function in
+* dual-link mode. We do this by looking at the DT port nodes we are
+* connected to, if they are marked as expecting even pixels and
+* odd pixels than we need to enable vertical stripe output.
+*/
+ port0 = of_graph_get_port_by_id(dev->of_node, 1);
+ port1 = of_graph_get_port_by_id(companion, 1);
+ dual_link = drm_of_lvds_get_dual_link_pixel_order(port0, port1);
+ of_node_put(port0);
+ of_node_put(port1);
+
+ if (dual_link >= DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS)
+ lvds->dual_link = true;
+ else if (lvds->next_bridge && lvds->next_bridge->timings)
+ /*
+* Early dual-link bridge specific implementations populate the
+* timings field of drm_bridge, read the dual_link flag off the
+* bridge directly for backward compatibility.
+*/
+ lvds->dual_link = lvds->next_bridge->timings->dual_link;
+
+ if (!lvds->dual_link) {
+ dev_dbg(dev, "Single-link configuration detected\n");
+ goto done;
+ }
+
lvds->companion = of_drm_find_bridge(companion);
if (!lvds->companion) {
ret = -EPROBE_DEFER;
goto done;
}
- dev_dbg(dev, "Found companion encoder %pOF\n", companion);
+ dev_dbg(dev,
+ "Dual-link configuration detected (companion encoder %pOF)\n",
+ companion);
+
+ /*
+* FIXME: We should not be messing with the companion encoder private
+* data from the primary encoder, we should rather let the companion
+* encoder work things out on its own. However, the companion encoder
+* doesn't hold a reference to the primary encoder, and
+* drm_of_lvds_get_dual_link_pixel_order needs to be given references
+* to the output ports of both encoders, therefore leave it like this
+* for the time being.
+*/
+ companion_lvds = bridge_to_rcar_lvds(lvds->companion);
+ companion_lvds->dual_link = true;
done:
of_node_put(companion);
@@ -724,13 +768,7 @@ static int rcar_lvds_parse_dt(struct rcar_lvds *lvds)
if (ret)
goto done;
- if ((lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK) &&
- lvds->next_bridge)
- lvds->dual_link = lvds->next_bridge->timings
- ? lvds->next_bridge->timings->dual_link
- : false;
-
- if (lvds->dual_link)
+ if (lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK)
ret = rcar_lvds_parse_dt_companion(lvds);
done:
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v4 5/7] drm: rcar-du: lvds: Fix mode for companion encoder
Hi Laurent,
Thank you for your feedback!
> From: devicetree-ow...@vger.kernel.org On
> Behalf Of Laurent Pinchart
> Sent: 13 December 2019 21:42
> Subject: Re: [PATCH v4 5/7] drm: rcar-du: lvds: Fix mode for companion encoder
>
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Fri, Dec 06, 2019 at 04:32:52PM +, Fabrizio Castro wrote:
> > Primary and companion encoders need to set the same mode for
> > things to work properly.
> >
> > rcar_lvds_mode_set gets called into for the primary encoder only,
> > therefore initialize the companion encoder mode while sorting
> > the primary encoder mode out.
> >
> > Fixes: fa440d870358 ("drm: rcar-du: lvds: Add support for dual-link mode")
> > Signed-off-by: Fabrizio Castro
>
> Would you mind rebasing this on top of "drm: rcar-du: lvds: Get mode
> from state" ?
It looks like dropping this patch and rebasing on top of your v2 for
"drm: rcar-du: lvds: Get mode from state" does the trick now.
Will put a dependency to your patch in v5.
Cheers,
Fab
>
> > ---
> > v3->v4:
> > * New patch extracted from patch:
> > "drm: rcar-du: lvds: Add dual-LVDS panels support"
> > ---
> > drivers/gpu/drm/rcar-du/rcar_lvds.c | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > index cb2147c..eed5611 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > @@ -614,6 +614,18 @@ static void rcar_lvds_mode_set(struct drm_bridge
> > *bridge,
> > lvds->display_mode = *adjusted_mode;
> >
> > rcar_lvds_get_lvds_mode(lvds);
> > + if (lvds->companion) {
> > + struct rcar_lvds *companion_lvds = bridge_to_rcar_lvds(
> > + lvds->companion);
> > +
> > + /*
> > +* FIXME: We should not be messing with the companion encoder
> > +* private data from the primary encoder, but since
> > +* rcar_lvds_mode_set gets called into for the primary encoder
> > +* only, we don't have much of a choice for now.
> > +*/
> > + companion_lvds->mode = lvds->mode;
> > + }
> > }
> >
> > static int rcar_lvds_attach(struct drm_bridge *bridge)
>
> --
> Regards,
>
> Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 4/6] drm: rcar-du: lvds: Allow for even and odd pixels swap
DT properties dual-lvds-even-pixels and dual-lvds-odd-pixels
can be used to work out if the driver needs to swap even
and odd pixels around.
This patch makes use of the return value from function
drm_of_lvds_get_dual_link_pixel_order to determine if we
need to swap odd and even pixels around for things to work
properly.
Signed-off-by: Fabrizio Castro
---
v4->v5:
* Addressed comments from Laurent's review
v3->v4:
* New patch extracted from patch:
"drm: rcar-du: lvds: Add dual-LVDS panels support"
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 67 +
1 file changed, 53 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 3eb208e..c6a38c3 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -37,6 +37,12 @@ enum rcar_lvds_mode {
RCAR_LVDS_MODE_VESA = 4,
};
+enum rcar_lvds_link_type {
+ RCAR_LVDS_SINGLE_LINK = 0,
+ RCAR_LVDS_DUAL_LINK_EVEN_ODD_PIXELS = 1,
+ RCAR_LVDS_DUAL_LINK_ODD_EVEN_PIXELS = 2,
+};
+
#define RCAR_LVDS_QUIRK_LANES BIT(0) /* LVDS lanes 1 and 3 inverted
*/
#define RCAR_LVDS_QUIRK_GEN3_LVEN BIT(1) /* LVEN bit needs to be set on
R8A77970/R8A7799x */
#define RCAR_LVDS_QUIRK_PWDBIT(2) /* PWD bit available (all of
Gen3 but E3) */
@@ -67,7 +73,7 @@ struct rcar_lvds {
} clocks;
struct drm_bridge *companion;
- bool dual_link;
+ enum rcar_lvds_link_type dual_link;
};
#define bridge_to_rcar_lvds(b) \
@@ -484,12 +490,31 @@ static void rcar_lvds_atomic_enable(struct drm_bridge
*bridge,
rcar_lvds_write(lvds, LVDCHCR, lvdhcr);
if (lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK) {
- /*
-* Configure vertical stripe based on the mode of operation of
-* the connected device.
-*/
- rcar_lvds_write(lvds, LVDSTRIPE,
- lvds->dual_link ? LVDSTRIPE_ST_ON : 0);
+ u32 lvdstripe = 0;
+
+ if (lvds->dual_link) {
+ /*
+* By default we generate even pixels from the primary
+* encoder and odd pixels from the companion encoder.
+* Swap pixels around if the sink requires odd pixels
+* from the primary encoder and even pixels from the
+* companion encoder.
+*/
+ bool swap_pixels = lvds->dual_link ==
+ RCAR_LVDS_DUAL_LINK_ODD_EVEN_PIXELS;
+
+ /*
+* Configure vertical stripe since we are dealing with
+* an LVDS dual-link connection.
+*
+* ST_SWAP is reserved for the companion encoder, only
+* set it in the primary encoder.
+*/
+ lvdstripe = LVDSTRIPE_ST_ON
+ | (lvds->companion && swap_pixels ?
+LVDSTRIPE_ST_SWAP : 0);
+ }
+ rcar_lvds_write(lvds, LVDSTRIPE, lvdstripe);
}
/*
@@ -716,15 +741,26 @@ static int rcar_lvds_parse_dt_companion(struct rcar_lvds
*lvds)
of_node_put(port0);
of_node_put(port1);
- if (dual_link >= DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS)
- lvds->dual_link = true;
- else if (lvds->next_bridge && lvds->next_bridge->timings)
+ switch (dual_link) {
+ case DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS:
+ lvds->dual_link = RCAR_LVDS_DUAL_LINK_ODD_EVEN_PIXELS;
+ break;
+ case DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS:
+ lvds->dual_link = RCAR_LVDS_DUAL_LINK_EVEN_ODD_PIXELS;
+ break;
+ default:
/*
* Early dual-link bridge specific implementations populate the
-* timings field of drm_bridge, read the dual_link flag off the
-* bridge directly for backward compatibility.
+* timings field of drm_bridge. If the flag is set, we assume
+* that we are expected to generate even pixels from the primary
+* encoder, and odd pixels from the companion encoder.
*/
- lvds->dual_link = lvds->next_bridge->timings->dual_link;
+ if (lvds->next_bridge && lvds->next_bridge->timings &&
+ lvds->next_bridge->timings->dual_link)
+ lvds->dual_link = RCAR_LVDS_DUAL_LINK_EVEN_ODD_PIXELS;
+ else
+ lvds->dual_link = RCAR_LVDS_SINGLE_LINK;
+ }
if (!lvds->dual_link) {
[PATCH v5 6/6] arm64: dts: renesas: Add EK874 board with idk-2121wr display support
The EK874 is advertised as compatible with panel IDK-2121WR from
Advantech, however the panel isn't sold alongside the board.
A new dts, adding everything that's required to get the panel to
to work with the EK874, is the most convenient way to support the
EK874 when it's connected to the IDK-2121WR.
Signed-off-by: Fabrizio Castro
Acked-by: Laurent Pinchart
---
Hi Geert,
I think it is now safe for you to have a look at this patch.
Thanks,
Fab
v4->v5:
* no change
v3->v4:
* no change
v2->v3:
* removed renesas,swap-data property
* added dual-lvds-odd-pixels and dual-lvds-even-pixels properties
v1->v2:
* Added comment for lvds-connector-en-gpio
* Renamed _panel_in to panel_in0
* Renamed _panel_in to panel_in1
---
arch/arm64/boot/dts/renesas/Makefile | 3 +-
.../boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts | 116 +
2 files changed, 118 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts
diff --git a/arch/arm64/boot/dts/renesas/Makefile
b/arch/arm64/boot/dts/renesas/Makefile
index d4cc332..ab2c799 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -3,7 +3,8 @@ dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m.dtb
dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m-ex.dtb
dtb-$(CONFIG_ARCH_R8A774B1) += r8a774b1-hihope-rzg2n.dtb
dtb-$(CONFIG_ARCH_R8A774B1) += r8a774b1-hihope-rzg2n-ex.dtb
-dtb-$(CONFIG_ARCH_R8A774C0) += r8a774c0-cat874.dtb r8a774c0-ek874.dtb
+dtb-$(CONFIG_ARCH_R8A774C0) += r8a774c0-cat874.dtb r8a774c0-ek874.dtb \
+ r8a774c0-ek874-idk-2121wr.dtb
dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-salvator-x.dtb r8a7795-h3ulcb.dtb
dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-h3ulcb-kf.dtb
dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-salvator-xs.dtb
diff --git a/arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts
b/arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts
new file mode 100644
index 000..a7b27d0
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts
@@ -0,0 +1,116 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the Silicon Linux RZ/G2E evaluation kit (EK874),
+ * connected to an Advantech IDK-2121WR 21.5" LVDS panel
+ *
+ * Copyright (C) 2019 Renesas Electronics Corp.
+ */
+
+#include "r8a774c0-ek874.dts"
+
+/ {
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = < 0 5>;
+
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <6>;
+
+ power-supply = <_12p0v>;
+ enable-gpios = < 12 GPIO_ACTIVE_HIGH>;
+ };
+
+ panel-lvds {
+ compatible = "advantech,idk-2121wr", "panel-lvds";
+
+ width-mm = <476>;
+ height-mm = <268>;
+
+ data-mapping = "vesa-24";
+
+ panel-timing {
+ clock-frequency = <14850>;
+ hactive = <1920>;
+ vactive = <1080>;
+ hsync-len = <44>;
+ hfront-porch = <88>;
+ hback-porch = <148>;
+ vfront-porch = <4>;
+ vback-porch = <36>;
+ vsync-len = <5>;
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dual-lvds-odd-pixels;
+ panel_in0: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dual-lvds-even-pixels;
+ panel_in1: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+ };
+};
+
+ {
+ /*
+* When GP0_17 is low LVDS[01] are connected to the LVDS connector
+* When GP0_17 is high LVDS[01] are connected to the LT8918L
+*/
+ lvds-connector-en-gpio{
+ gpio-hog;
+ gpios = <17 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "lvds-connector-en-gpio";
+ };
+};
+
+ {
+ ports {
+ port@1 {
+ lvds0_out: endpoint {
+ remote-endpoint = <_in0>;
+ };
+ };
+ };
+
RE: [PATCH v2] drm: rcar-du: lvds: Get mode from state
Hi Laurent,
Thank you for your patch!
> From: linux-renesas-soc-ow...@vger.kernel.org
> On Behalf Of Laurent Pinchart
> Sent: 13 December 2019 18:28
> Subject: [PATCH v2] drm: rcar-du: lvds: Get mode from state
>
> The R-Car LVDS encoder driver implements the bridge .mode_set()
> operation for the sole purpose of storing the mode in the LVDS private
> data, to be used later when enabling the encoder.
>
> Switch to the bridge .atomic_enable() and .atomic_disable() operations
> in order to access the global atomic state, and get the mode from the
> state instead. Remove both the unneeded .mode_set() operation and the
> display_mode and mode fields storing state data from the rcar_lvds
> private structure.
>
> As a side effect we get the CRTC from the state, replace the CRTC
> pointer retrieved through the bridge's encoder that shouldn't be used by
> atomic drivers.
>
> Signed-off-by: Laurent Pinchart
> ---
> Changes since v1:
>
> - Call .atomic_enable() on the companion
> - Set companion->encoder in .attach()
>
> The patch has been tested on the Draak board with the HDMI output in
> LVDS dual-link mode, and on the Salvator-XS board with the HDMI, VGA and
> LVDS outputs in single-link mode.
>
> ---
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 158 +++-
> 1 file changed, 85 insertions(+), 73 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> index 8c6c172bbf2e..c550bfd59e71 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -65,9 +65,6 @@ struct rcar_lvds {
> struct clk *dotclkin[2];/* External DU clocks */
> } clocks;
>
> - struct drm_display_mode display_mode;
> - enum rcar_lvds_mode mode;
> -
> struct drm_bridge *companion;
> bool dual_link;
> };
> @@ -402,10 +399,51 @@ EXPORT_SYMBOL_GPL(rcar_lvds_clk_disable);
> * Bridge
> */
>
> -static void rcar_lvds_enable(struct drm_bridge *bridge)
> +static enum rcar_lvds_mode rcar_lvds_get_lvds_mode(struct rcar_lvds *lvds,
> + const struct drm_connector *connector)
> +{
> + const struct drm_display_info *info;
> + enum rcar_lvds_mode mode;
> +
> + /*
> + * There is no API yet to retrieve LVDS mode from a bridge, only panels
> + * are supported.
> + */
> + if (!lvds->panel)
> + return RCAR_LVDS_MODE_JEIDA;
> +
> + info = >display_info;
> + if (!info->num_bus_formats || !info->bus_formats) {
> + dev_err(lvds->dev, "no LVDS bus format reported\n");
dev_warn perhaps?
Also, how about:
s/no LVDS bus format reported/no LVDS bus format reported, using JEIDA/
or something along those lines?
> + return RCAR_LVDS_MODE_JEIDA;
> + }
> +
> + switch (info->bus_formats[0]) {
> + case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
Shall we take the below into account here?
https://lwn.net/Articles/794944/
> + case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA:
> + mode = RCAR_LVDS_MODE_JEIDA;
> + break;
> + case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG:
> + mode = RCAR_LVDS_MODE_VESA;
> + break;
> + default:
> + dev_err(lvds->dev, "unsupported LVDS bus format 0x%04x\n",
> + info->bus_formats[0]);
dev_warn perhaps?
Also, how about:
s/unsupported LVDS bus format 0x%04x/unsupported LVDS bus format 0x%04x, using
JEIDA/
or something along those lines?
> + return RCAR_LVDS_MODE_JEIDA;
> + }
> +
> + if (info->bus_flags & DRM_BUS_FLAG_DATA_LSB_TO_MSB)
> + mode |= RCAR_LVDS_MODE_MIRROR;
> +
> + return mode;
> +}
> +
> +static void rcar_lvds_atomic_enable(struct drm_bridge *bridge,
> + struct drm_atomic_state *state)
> {
> struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);
> - const struct drm_display_mode *mode = >display_mode;
> + struct drm_connector *connector;
> + struct drm_crtc *crtc;
> u32 lvdhcr;
> u32 lvdcr0;
> int ret;
> @@ -414,9 +452,14 @@ static void rcar_lvds_enable(struct drm_bridge *bridge)
> if (ret < 0)
> return;
>
> + /* Retrieve the connector and CRTC through the atomic state. */
> + connector = drm_atomic_get_new_connector_for_encoder(state,
> + bridge->encoder);
> + crtc = drm_atomic_get_new_connector_state(state, connector)->crtc;
> +
> /* Enable the companion LVDS encoder in dual-link mode. */
> if (lvds->dual_link && lvds->companion)
> - lvds->companion->funcs->enable(lvds->companion);
> + lvds->companion->funcs->atomic_enable(lvds->companion, state);
>
> /*
>* Hardcode the channels and control signals routing for now.
> @@ -452,18 +495,20 @@ static void rcar_lvds_enable(struct drm_bridge *bridge)
>* PLL clock configuration on all
RE: [PATCH v4 2/7] drm: rcar-du: lvds: Improve identification of panels
Hi Laurent,
Thank you for your feedback!
> From: Laurent Pinchart
> Sent: 13 December 2019 21:22
> Subject: Re: [PATCH v4 2/7] drm: rcar-du: lvds: Improve identification of
> panels
>
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Fri, Dec 06, 2019 at 04:32:49PM +, Fabrizio Castro wrote:
> > Dual-LVDS panels are mistakenly identified as bridges, this
> > commit replaces the current logic with a call to
> > drm_of_find_panel_or_bridge to sort that out.
> >
> > Signed-off-by: Fabrizio Castro
> >
> > ---
> > v3->v4:
> > * New patch extracted from patch:
> > "drm: rcar-du: lvds: Add dual-LVDS panels support"
> > ---
> > drivers/gpu/drm/rcar-du/rcar_lvds.c | 45
> > +
> > 1 file changed, 10 insertions(+), 35 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > index 8c6c172..3cb0a83 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > @@ -21,6 +21,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -705,10 +706,7 @@ static int rcar_lvds_parse_dt_companion(struct
> > rcar_lvds *lvds)
> > static int rcar_lvds_parse_dt(struct rcar_lvds *lvds)
> > {
> > struct device_node *local_output = NULL;
> > - struct device_node *remote_input = NULL;
> > struct device_node *remote = NULL;
> > - struct device_node *node;
> > - bool is_bridge = false;
> > int ret = 0;
> >
> > local_output = of_graph_get_endpoint_by_regs(lvds->dev->of_node, 1, 0);
> > @@ -736,45 +734,22 @@ static int rcar_lvds_parse_dt(struct rcar_lvds *lvds)
> > goto done;
> > }
>
> I think you can remove the calls above this too.
> drm_of_find_panel_or_bridge() calls of_graph_get_remote_node(), which in
> turn calls of_graph_get_endpoint_by_regs(),
> of_graph_get_remote_port_parent() and checks the status of the remote
> with of_device_is_available().
Will take those out in v5
Thanks,
Fab
>
> >
> > - remote_input = of_graph_get_remote_endpoint(local_output);
> > -
> > - for_each_endpoint_of_node(remote, node) {
> > - if (node != remote_input) {
> > - /*
> > -* We've found one endpoint other than the input, this
> > -* must be a bridge.
> > -*/
> > - is_bridge = true;
> > - of_node_put(node);
> > - break;
> > - }
> > - }
> > -
> > - if (is_bridge) {
> > - lvds->next_bridge = of_drm_find_bridge(remote);
> > - if (!lvds->next_bridge) {
> > - ret = -EPROBE_DEFER;
> > - goto done;
> > - }
> > + ret = drm_of_find_panel_or_bridge(lvds->dev->of_node, 1, 0,
> > + >panel, >next_bridge);
> > + if (ret)
> > + goto done;
> >
> > - if (lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK)
> > - lvds->dual_link = lvds->next_bridge->timings
> > - ? lvds->next_bridge->timings->dual_link
> > - : false;
> > - } else {
> > - lvds->panel = of_drm_find_panel(remote);
> > - if (IS_ERR(lvds->panel)) {
> > - ret = PTR_ERR(lvds->panel);
> > - goto done;
> > - }
> > - }
> > + if ((lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK) &&
> > + lvds->next_bridge)
> > + lvds->dual_link = lvds->next_bridge->timings
> > + ? lvds->next_bridge->timings->dual_link
> > + : false;
> >
> > if (lvds->dual_link)
> > ret = rcar_lvds_parse_dt_companion(lvds);
> >
> > done:
> > of_node_put(local_output);
> > - of_node_put(remote_input);
> > of_node_put(remote);
> >
> > /*
>
> --
> Regards,
>
> Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v4 1/7] drm: of: Add drm_of_lvds_get_dual_link_pixel_order
Hi Laurent,
Thank you for your feedback!
> From: linux-renesas-soc-ow...@vger.kernel.org
> On Behalf Of Laurent Pinchart
> Sent: 13 December 2019 21:06
> Subject: Re: [PATCH v4 1/7] drm: of: Add drm_of_lvds_get_dual_link_pixel_order
>
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Fri, Dec 06, 2019 at 04:32:48PM +, Fabrizio Castro wrote:
> > An LVDS dual-link connection is made of two links, with even
> > pixels transitting on one link, and odd pixels on the other
> > link. The device tree can be used to fully describe dual-link
> > LVDS connections between encoders and bridges/panels.
> > The sink of an LVDS dual-link connection is made of two ports,
> > the corresponding OF graph port nodes can be marked
> > with either dual-lvds-even-pixels or dual-lvds-odd-pixels,
> > and that fully describes an LVDS dual-link connection,
> > including pixel order.
> >
> > drm_of_lvds_get_dual_link_pixel_order is a new helper
> > added by this patch, given the source port nodes it
> > returns DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS if the source
> > port nodes belong to an LVDS dual-link connection, with even
> > pixels expected to be generated from the first port, and odd
> > pixels expected to be generated from the second port.
> > If the new helper returns DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS,
> > odd pixels are expected to be generated from the first port,
> > and even pixels from the other port.
> >
> > Signed-off-by: Fabrizio Castro
> >
> > ---
> > v3->v4:
> > * The patch had title "drm: Add bus timings helper" in v3
> > * The code has now been moved to drm_of, and has been fully
> > restructured, thanks to Laurent and Daniel for the comments
> >
> > v2->v3:
> > * new patch
> > ---
> > drivers/gpu/drm/drm_of.c | 104
> > +++
> > include/drm/drm_of.h | 20 +
> > 2 files changed, 124 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> > index 0ca5880..c2e9ab7 100644
> > --- a/drivers/gpu/drm/drm_of.c
> > +++ b/drivers/gpu/drm/drm_of.c
> > @@ -274,3 +274,107 @@ int drm_of_find_panel_or_bridge(const struct
> > device_node *np,
> > return ret;
> > }
> > EXPORT_SYMBOL_GPL(drm_of_find_panel_or_bridge);
> > +
> > +enum drm_of_lvds_pixels {
> > + DRM_OF_LVDS_EVEN = BIT(0),
> > + DRM_OF_LVDS_ODD = BIT(1),
> > +};
> > +
> > +static int drm_of_lvds_get_port_pixels_type(struct device_node *port_node)
> > +{
> > + bool even_pixels =
> > + of_property_read_bool(port_node, "dual-lvds-even-pixels");
> > + bool odd_pixels =
> > + of_property_read_bool(port_node, "dual-lvds-odd-pixels");
> > +
> > + return (even_pixels ? DRM_OF_LVDS_EVEN : 0) |
> > + (odd_pixels ? DRM_OF_LVDS_ODD : 0);
> > +}
> > +
> > +static int drm_of_lvds_get_remote_pixels_type(
> > + const struct device_node *port_node)
> > +{
> > + struct device_node *endpoint = NULL;
> > + int pixels_type = -EPIPE;
> > +
> > + for_each_child_of_node(port_node, endpoint) {
> > + struct device_node *remote_port;
> > + int current_pt;
> > +
> > + if (!of_node_name_eq(endpoint, "endpoint"))
> > + continue;
> > +
> > + remote_port = of_graph_get_remote_port(endpoint);
> > + if (!remote_port)
>
> You need an of_node_put(endpoint) in the code paths that exit from the
> loop.
Right, thank you for spotting this!
>
> > + return -EPIPE;
> > +
> > + current_pt = drm_of_lvds_get_port_pixels_type(remote_port);
> > + of_node_put(remote_port);
> > + if (!pixels_type)
> > + pixels_type = current_pt;
>
> This will never happen as pixels_type is initialized to -EPIPE.
> Replacing the condition with if (pixels_type < 0) should fix it.
I agree
>
> > + if (!current_pt || pixels_type != current_pt)
> > + return -EINVAL;
>
> I would add a comment to explain this. If I understand the code
> correcty, something along the lines of
>
> /*
>* Sanity check, ensure that all remote endpoints have the same
>* pixel type. We may lift this restriction later if we need to
>* support multiple sinks with different dual-link
>* configurations by passing the endpoi
RE: [PATCH v4 4/7] drm: rcar-du: lvds: Allow for even and odd pixels swap
Hi Laurent,
Thank you for your feedback!
> From: devicetree-ow...@vger.kernel.org On
> Behalf Of Laurent Pinchart
> Sent: 13 December 2019 21:41
> Subject: Re: [PATCH v4 4/7] drm: rcar-du: lvds: Allow for even and odd pixels
> swap
>
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Fri, Dec 06, 2019 at 04:32:51PM +, Fabrizio Castro wrote:
> > DT properties dual-lvds-even-pixels and dual-lvds-odd-pixels
> > can be used to work out if the driver needs to swap even
> > and odd pixels around.
> >
> > This patch makes use of the return value from function
> > drm_of_lvds_get_dual_link_pixel_order to determine if we
> > need to swap odd and even pixels around for things to work
> > properly.
> >
> > Signed-off-by: Fabrizio Castro
> >
> > ---
> > v3->v4:
> > * New patch extracted from patch:
> > "drm: rcar-du: lvds: Add dual-LVDS panels support"
> > ---
> > drivers/gpu/drm/rcar-du/rcar_lvds.c | 46
> > +
> > 1 file changed, 37 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > index 6c1f171..cb2147c 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > @@ -71,6 +71,7 @@ struct rcar_lvds {
> >
> > struct drm_bridge *companion;
> > bool dual_link;
> > + bool stripe_swap_data;
>
> Should we merge those two fields in an int dual_link that would be set
> to DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS,
> DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS or a negative value (or maybe we the
> value of enum drm_lvds_dual_link_pixels could be modified so that 0
> could mean single link) ?
I see your point, and I think there is a third option, using definitions local
to the
RCAR LVDS driver (via an enum?).
The reason for thinking about a third option is that option 1 could be a bit
error prone,
as negative values usually have special meaning. I like option 2, I find it
neat, but if
I did that then we would need to agree again on names, definitions, interfaces,
etc.,
as the meaning of things will change slightly. Also, we will probably be fine
with the
helper and definitions we already agreed on.
I think option 3 will offer a little bit of decoupling between the helper and
the driver,
and should have a limited effect on previous uses of dual_link.
I'll make option 3 related changes in v5, if you don't like them then I think
we should
try option 2.
>
> > };
> >
> > #define bridge_to_rcar_lvds(b) \
> > @@ -441,12 +442,20 @@ static void rcar_lvds_enable(struct drm_bridge
> > *bridge)
> > rcar_lvds_write(lvds, LVDCHCR, lvdhcr);
> >
> > if (lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK) {
> > - /*
> > -* Configure vertical stripe based on the mode of operation of
> > -* the connected device.
> > -*/
> > - rcar_lvds_write(lvds, LVDSTRIPE,
> > - lvds->dual_link ? LVDSTRIPE_ST_ON : 0);
> > + u32 lvdstripe = 0;
> > +
> > + if (lvds->dual_link)
> > + /*
> > +* Configure vertical stripe based on the mode of
> > +* operation of the connected device.
> > +*
> > +* ST_SWAP from LVD1STRIPE is reserved, do not set
> > +* in the companion LVDS
>
> Maybe "ST_SWAP is reserved for the companion encoder, only set it in the
> primary encoder." ?
sure
>
> > +*/
> > + lvdstripe = LVDSTRIPE_ST_ON |
> > + (lvds->companion && lvds->stripe_swap_data ?
> > +LVDSTRIPE_ST_SWAP : 0);
>
> To match the coding style of the rest of the driver,
ok
>
> lvdstripe = LVDSTRIPE_ST_ON
> | (lvds->companion && lvds->stripe_swap_data ?
>LVDSTRIPE_ST_SWAP : 0);
>
> Even though not strictly required, could you surround this statement
> with { } as it spans quite a few lines with the comment ?
Will rework this slightly anyway to make room for option 3.
>
> > + rcar_lvds_write(lvds, LVDSTRIPE, lvdstripe);
> > }
> >
> > /*
> > @@ -702,17 +711,33 @@ static int rcar_lvds_parse_dt_companion(struct
> > rcar_lvds *lvds)
> > dual_link = drm_of_lvds_get_dual_link_pixel_order(p0, p1);
> > of_
RE: [PATCH v4 3/7] drm: rcar-du: lvds: Get dual link configuration from DT
Hi Laurent,
Thank you for your feedback!
> From: Laurent Pinchart
> Sent: 13 December 2019 21:30
> Subject: Re: [PATCH v4 3/7] drm: rcar-du: lvds: Get dual link configuration
> from DT
>
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Fri, Dec 06, 2019 at 04:32:50PM +, Fabrizio Castro wrote:
> > For dual-LVDS configurations, it is now possible to mark the
> > DT port nodes for the sink with boolean properties (like
> > dual-lvds-even-pixels and dual-lvds-odd-pixels) to let drivers
> > know the encoders need to be configured in dual-LVDS mode.
> >
> > Rework the implementation of rcar_lvds_parse_dt_companion
> > to make use of the DT markers while keeping backward
> > compatibility.
> >
> > Signed-off-by: Fabrizio Castro
> >
> > ---
> > v3->v4:
> > * New patch extracted from patch:
> > "drm: rcar-du: lvds: Add dual-LVDS panels support"
> > ---
> > drivers/gpu/drm/rcar-du/rcar_lvds.c | 56
> > +++--
> > 1 file changed, 47 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > index 3cb0a83..6c1f171 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > @@ -669,8 +669,10 @@ EXPORT_SYMBOL_GPL(rcar_lvds_dual_link);
> > static int rcar_lvds_parse_dt_companion(struct rcar_lvds *lvds)
> > {
> > const struct of_device_id *match;
> > - struct device_node *companion;
> > + struct device_node *companion, *p0, *p1;
>
> Could you rename p0 and p1 to port0 and port1, and spit them to a
> separate line of variable declaration ?
sure
>
> > + struct rcar_lvds *companion_lvds;
> > struct device *dev = lvds->dev;
> > + int dual_link;
> > int ret = 0;
> >
> > /* Locate the companion LVDS encoder for dual-link operation, if any. */
> > @@ -689,13 +691,55 @@ static int rcar_lvds_parse_dt_companion(struct
> > rcar_lvds *lvds)
> > goto done;
> > }
> >
> > + /*
> > +* We need to work out if the sink is expecting us to function in
> > +* dual-link mode. We do this by looking at the DT port nodes we are
> > +* connected to, if they are marked as expecting even pixels and
> > +* odd pixels than we need to enable vertical stripe output.
> > +*/
> > + p0 = of_graph_get_port_by_id(dev->of_node, 1);
> > + p1 = of_graph_get_port_by_id(companion, 1);
> > + dual_link = drm_of_lvds_get_dual_link_pixel_order(p0, p1);
> > + of_node_put(p0);
> > + of_node_put(p1);
> > + if (dual_link >= DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS) {
> > + lvds->dual_link = true;
> > + } else if (lvds->next_bridge && lvds->next_bridge->timings) {
> > + /*
> > +* Early dual-link bridge specific implementations populate the
> > +* timings field of drm_bridge, read the dual_link flag off the
> > +* bridge directly for backward compatibility.
> > +*/
> > + lvds->dual_link = lvds->next_bridge->timings->dual_link;
> > + }
> > +
> > + if (!lvds->dual_link) {
> > + dev_dbg(dev, "Single-link configuration detected\n");
> > + goto done;
> > + }
> > +
> > lvds->companion = of_drm_find_bridge(companion);
> > if (!lvds->companion) {
> > ret = -EPROBE_DEFER;
> > goto done;
> > }
> >
> > - dev_dbg(dev, "Found companion encoder %pOF\n", companion);
> > + dev_dbg(dev,
> > + "Dual-link configuration detected (companion encoder %pOF)\n",
> > + companion);
> > +
> > + companion_lvds = bridge_to_rcar_lvds(lvds->companion);
>
> Could you move this line after the FIXME comment ?
Will do
Thanks,
Fab
>
> With these small issues fixed,
>
> Reviewed-by: Laurent Pinchart
>
> > +
> > + /*
> > +* FIXME: We should not be messing with the companion encoder private
> > +* data from the primary encoder, we should rather let the companion
> > +* encoder work things out on its own. However, the companion encoder
> > +* doesn't hold a reference to the primary encoder, and
> > +* drm_of_lvds_get_dual_link_pixel_order needs to be given references
> > +* to the output ports of both encoders, therefore leave it like this
> > +* for the time being.
> &
RE: [PATCH v3 4/8] drm: rcar-du: lvds: Add dual-LVDS panels support
Hi Laurent,
> From: linux-renesas-soc-ow...@vger.kernel.org
> On Behalf Of Laurent Pinchart
> Sent: 07 November 2019 19:51
> Subject: Re: [PATCH v3 4/8] drm: rcar-du: lvds: Add dual-LVDS panels support
>
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Wed, Aug 28, 2019 at 07:36:38PM +0100, Fabrizio Castro wrote:
> > The driver doesn't support dual-link LVDS displays, and the way
> > it identifies bridges won't allow for dual-LVDS displays to be
> > connected. Also, it's not possible to swap even and odd pixels
> > around in case the wiring isn't taking advantage of the default
> > hardware configuration. Further more, the "mode" of the companion
> > encoder should be same as the mode of the primary encoder.
> >
> > Rework the driver to improve all of the above, so that it can
> > support dual-LVDS displays.
>
> That's lots of changes in one patch, could it be split to ease review ?
> Also, should the commit message be reworded to explain what the patch
> does, instead of enumerating issues ? When there's a single issue being
> addressed in a patch it's usually fine, but there the change is larger,
> without an explanation of how you intend to fix the issues I can't tell
> if the code really matches your intent.
Sorry for the pain, I'll split this patch into smaller patches.
>
> > Signed-off-by: Fabrizio Castro
> >
> > ---
> > v2->v3:
> > * reworked to take advantange of the new dt-bindings
> > * squashed in the patche for fixing the companion's mode
> >
> > Laurent,
> >
> > unfortunately the best way to get the companion encoder to use
> > the same mode as the primary encoder is setting the mode directly
> > without calling into rcar_lvds_mode_set for the companion encoder,
> > as the below test fails for the companion encoder in
> > rcar_lvds_get_lvds_mode:
> > if (!info->num_bus_formats || !info->bus_formats)
>
> Would "[PATCH] drm: rcar-du: lvds: Get mode from state" help here ?
> Maybe you could review that patch, I could then include it in my -next
> branch, your work would be simplified, and everybody would be happy ?
> :-)
I gave that a try, it doesn't work for me, even after fixing the NULL
pointer. Perhaps we could finalize this series first and then we could figure
that patch out next?
>
> > Anyhow, setting the mode for the companion encoder doesn't seem
> > to be mandary according to the experiments I have been running,
> > but the HW User's Manual doesn't really say much about this,
> > therefore I think the safest option is still to set the mode for
> > the companion encoder.
>
> I agree it should be done.
>
> > ---
> > drivers/gpu/drm/rcar-du/rcar_lvds.c | 110
> > +---
> > 1 file changed, 65 insertions(+), 45 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > index 3fe0b86..dfec5e7 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > @@ -20,6 +20,8 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > #include
> > #include
> >
> > @@ -69,6 +71,7 @@ struct rcar_lvds {
> >
> > struct drm_bridge *companion;
> > bool dual_link;
> > + bool stripe_swap_data;
> > };
> >
> > #define bridge_to_rcar_lvds(b) \
> > @@ -439,12 +442,20 @@ static void rcar_lvds_enable(struct drm_bridge
> > *bridge)
> > rcar_lvds_write(lvds, LVDCHCR, lvdhcr);
> >
> > if (lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK) {
> > - /*
> > -* Configure vertical stripe based on the mode of operation of
> > -* the connected device.
> > -*/
> > - rcar_lvds_write(lvds, LVDSTRIPE,
> > - lvds->dual_link ? LVDSTRIPE_ST_ON : 0);
> > + u32 lvdstripe = 0;
> > +
> > + if (lvds->dual_link)
> > + /*
> > +* Configure vertical stripe based on the mode of
> > +* operation of the connected device.
> > +*
> > +* ST_SWAP from LVD1STRIPE is reserved, do not set
> > +* in the companion LVDS
> > +*/
> > + lvdstripe = LVDSTRIPE_ST_ON |
> > + (lvds->companion && lvds->stripe_swap_data ?
> > +LVDSTRIPE_ST_SWAP
[PATCH v4 3/7] drm: rcar-du: lvds: Get dual link configuration from DT
For dual-LVDS configurations, it is now possible to mark the
DT port nodes for the sink with boolean properties (like
dual-lvds-even-pixels and dual-lvds-odd-pixels) to let drivers
know the encoders need to be configured in dual-LVDS mode.
Rework the implementation of rcar_lvds_parse_dt_companion
to make use of the DT markers while keeping backward
compatibility.
Signed-off-by: Fabrizio Castro
---
v3->v4:
* New patch extracted from patch:
"drm: rcar-du: lvds: Add dual-LVDS panels support"
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 56 +++--
1 file changed, 47 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 3cb0a83..6c1f171 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -669,8 +669,10 @@ EXPORT_SYMBOL_GPL(rcar_lvds_dual_link);
static int rcar_lvds_parse_dt_companion(struct rcar_lvds *lvds)
{
const struct of_device_id *match;
- struct device_node *companion;
+ struct device_node *companion, *p0, *p1;
+ struct rcar_lvds *companion_lvds;
struct device *dev = lvds->dev;
+ int dual_link;
int ret = 0;
/* Locate the companion LVDS encoder for dual-link operation, if any. */
@@ -689,13 +691,55 @@ static int rcar_lvds_parse_dt_companion(struct rcar_lvds
*lvds)
goto done;
}
+ /*
+* We need to work out if the sink is expecting us to function in
+* dual-link mode. We do this by looking at the DT port nodes we are
+* connected to, if they are marked as expecting even pixels and
+* odd pixels than we need to enable vertical stripe output.
+*/
+ p0 = of_graph_get_port_by_id(dev->of_node, 1);
+ p1 = of_graph_get_port_by_id(companion, 1);
+ dual_link = drm_of_lvds_get_dual_link_pixel_order(p0, p1);
+ of_node_put(p0);
+ of_node_put(p1);
+ if (dual_link >= DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS) {
+ lvds->dual_link = true;
+ } else if (lvds->next_bridge && lvds->next_bridge->timings) {
+ /*
+* Early dual-link bridge specific implementations populate the
+* timings field of drm_bridge, read the dual_link flag off the
+* bridge directly for backward compatibility.
+*/
+ lvds->dual_link = lvds->next_bridge->timings->dual_link;
+ }
+
+ if (!lvds->dual_link) {
+ dev_dbg(dev, "Single-link configuration detected\n");
+ goto done;
+ }
+
lvds->companion = of_drm_find_bridge(companion);
if (!lvds->companion) {
ret = -EPROBE_DEFER;
goto done;
}
- dev_dbg(dev, "Found companion encoder %pOF\n", companion);
+ dev_dbg(dev,
+ "Dual-link configuration detected (companion encoder %pOF)\n",
+ companion);
+
+ companion_lvds = bridge_to_rcar_lvds(lvds->companion);
+
+ /*
+* FIXME: We should not be messing with the companion encoder private
+* data from the primary encoder, we should rather let the companion
+* encoder work things out on its own. However, the companion encoder
+* doesn't hold a reference to the primary encoder, and
+* drm_of_lvds_get_dual_link_pixel_order needs to be given references
+* to the output ports of both encoders, therefore leave it like this
+* for the time being.
+*/
+ companion_lvds->dual_link = true;
done:
of_node_put(companion);
@@ -739,13 +783,7 @@ static int rcar_lvds_parse_dt(struct rcar_lvds *lvds)
if (ret)
goto done;
- if ((lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK) &&
- lvds->next_bridge)
- lvds->dual_link = lvds->next_bridge->timings
- ? lvds->next_bridge->timings->dual_link
- : false;
-
- if (lvds->dual_link)
+ if (lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK)
ret = rcar_lvds_parse_dt_companion(lvds);
done:
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/7] drm: of: Add drm_of_lvds_get_dual_link_pixel_order
An LVDS dual-link connection is made of two links, with even
pixels transitting on one link, and odd pixels on the other
link. The device tree can be used to fully describe dual-link
LVDS connections between encoders and bridges/panels.
The sink of an LVDS dual-link connection is made of two ports,
the corresponding OF graph port nodes can be marked
with either dual-lvds-even-pixels or dual-lvds-odd-pixels,
and that fully describes an LVDS dual-link connection,
including pixel order.
drm_of_lvds_get_dual_link_pixel_order is a new helper
added by this patch, given the source port nodes it
returns DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS if the source
port nodes belong to an LVDS dual-link connection, with even
pixels expected to be generated from the first port, and odd
pixels expected to be generated from the second port.
If the new helper returns DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS,
odd pixels are expected to be generated from the first port,
and even pixels from the other port.
Signed-off-by: Fabrizio Castro
---
v3->v4:
* The patch had title "drm: Add bus timings helper" in v3
* The code has now been moved to drm_of, and has been fully
restructured, thanks to Laurent and Daniel for the comments
v2->v3:
* new patch
---
drivers/gpu/drm/drm_of.c | 104 +++
include/drm/drm_of.h | 20 +
2 files changed, 124 insertions(+)
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 0ca5880..c2e9ab7 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -274,3 +274,107 @@ int drm_of_find_panel_or_bridge(const struct device_node
*np,
return ret;
}
EXPORT_SYMBOL_GPL(drm_of_find_panel_or_bridge);
+
+enum drm_of_lvds_pixels {
+ DRM_OF_LVDS_EVEN = BIT(0),
+ DRM_OF_LVDS_ODD = BIT(1),
+};
+
+static int drm_of_lvds_get_port_pixels_type(struct device_node *port_node)
+{
+ bool even_pixels =
+ of_property_read_bool(port_node, "dual-lvds-even-pixels");
+ bool odd_pixels =
+ of_property_read_bool(port_node, "dual-lvds-odd-pixels");
+
+ return (even_pixels ? DRM_OF_LVDS_EVEN : 0) |
+ (odd_pixels ? DRM_OF_LVDS_ODD : 0);
+}
+
+static int drm_of_lvds_get_remote_pixels_type(
+ const struct device_node *port_node)
+{
+ struct device_node *endpoint = NULL;
+ int pixels_type = -EPIPE;
+
+ for_each_child_of_node(port_node, endpoint) {
+ struct device_node *remote_port;
+ int current_pt;
+
+ if (!of_node_name_eq(endpoint, "endpoint"))
+ continue;
+
+ remote_port = of_graph_get_remote_port(endpoint);
+ if (!remote_port)
+ return -EPIPE;
+
+ current_pt = drm_of_lvds_get_port_pixels_type(remote_port);
+ of_node_put(remote_port);
+ if (!pixels_type)
+ pixels_type = current_pt;
+ if (!current_pt || pixels_type != current_pt)
+ return -EINVAL;
+ }
+
+ return pixels_type;
+}
+
+/**
+ * drm_of_lvds_get_dual_link_pixel_order - Get LVDS dual-link pixel order
+ * @port1: First DT port node of the Dual-link LVDS source
+ * @port2: Second DT port node of the Dual-link LVDS source
+ *
+ * An LVDS dual-link connection is made of two links, with even pixels
+ * transitting on one link, and odd pixels on the other link. This function
+ * returns, for two ports of an LVDS dual-link source, which port shall
transmit
+ * the even and odd pixels, based on the requirements of the connected sink.
+ *
+ * The pixel order is determined from the dual-lvds-even-pixels and
+ * dual-lvds-odd-pixels properties in the sink's DT port nodes. If those
+ * properties are not present, or if their usage is not valid, this function
+ * returns -EINVAL.
+ *
+ * If either port is not connected, this function returns -EPIPE.
+ *
+ * @port1 and @port2 are typically DT sibling nodes, but may have different
+ * parents when, for instance, two separate LVDS encoders carry the even and
odd
+ * pixels.
+ *
+ * Return:
+ * * DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS - @port1 carries even pixels and @port2
+ * carries odd pixels
+ * * DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS - @port1 carries odd pixels and @port1
+ * carries even pixels
+ * * -EINVAL - @port1 and @port2 are not connected to a dual-link LVDS sink, or
+ * the sink configuration is invalid
+ * * -EPIPE - when @port1 or port2 are not connected
+ */
+int drm_of_lvds_get_dual_link_pixel_order(const struct device_node *port1,
+ const struct device_node *port2)
+{
+ int remote_p1_pt, remote_p2_pt;
+
+ if (!port1 || !port2)
+ return -EINVAL;
+
+ remote_p1_pt = drm_of_lvds_get_remote_pixels_type(port1);
+ if (remote_p1_pt < 0)
+ return remote_p1_pt;
+
+
[PATCH v4 2/7] drm: rcar-du: lvds: Improve identification of panels
Dual-LVDS panels are mistakenly identified as bridges, this
commit replaces the current logic with a call to
drm_of_find_panel_or_bridge to sort that out.
Signed-off-by: Fabrizio Castro
---
v3->v4:
* New patch extracted from patch:
"drm: rcar-du: lvds: Add dual-LVDS panels support"
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 45 +
1 file changed, 10 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 8c6c172..3cb0a83 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -705,10 +706,7 @@ static int rcar_lvds_parse_dt_companion(struct rcar_lvds
*lvds)
static int rcar_lvds_parse_dt(struct rcar_lvds *lvds)
{
struct device_node *local_output = NULL;
- struct device_node *remote_input = NULL;
struct device_node *remote = NULL;
- struct device_node *node;
- bool is_bridge = false;
int ret = 0;
local_output = of_graph_get_endpoint_by_regs(lvds->dev->of_node, 1, 0);
@@ -736,45 +734,22 @@ static int rcar_lvds_parse_dt(struct rcar_lvds *lvds)
goto done;
}
- remote_input = of_graph_get_remote_endpoint(local_output);
-
- for_each_endpoint_of_node(remote, node) {
- if (node != remote_input) {
- /*
-* We've found one endpoint other than the input, this
-* must be a bridge.
-*/
- is_bridge = true;
- of_node_put(node);
- break;
- }
- }
-
- if (is_bridge) {
- lvds->next_bridge = of_drm_find_bridge(remote);
- if (!lvds->next_bridge) {
- ret = -EPROBE_DEFER;
- goto done;
- }
+ ret = drm_of_find_panel_or_bridge(lvds->dev->of_node, 1, 0,
+ >panel, >next_bridge);
+ if (ret)
+ goto done;
- if (lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK)
- lvds->dual_link = lvds->next_bridge->timings
- ? lvds->next_bridge->timings->dual_link
- : false;
- } else {
- lvds->panel = of_drm_find_panel(remote);
- if (IS_ERR(lvds->panel)) {
- ret = PTR_ERR(lvds->panel);
- goto done;
- }
- }
+ if ((lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK) &&
+ lvds->next_bridge)
+ lvds->dual_link = lvds->next_bridge->timings
+ ? lvds->next_bridge->timings->dual_link
+ : false;
if (lvds->dual_link)
ret = rcar_lvds_parse_dt_companion(lvds);
done:
of_node_put(local_output);
- of_node_put(remote_input);
of_node_put(remote);
/*
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/7] drm: rcar-du: lvds: Allow for even and odd pixels swap
DT properties dual-lvds-even-pixels and dual-lvds-odd-pixels
can be used to work out if the driver needs to swap even
and odd pixels around.
This patch makes use of the return value from function
drm_of_lvds_get_dual_link_pixel_order to determine if we
need to swap odd and even pixels around for things to work
properly.
Signed-off-by: Fabrizio Castro
---
v3->v4:
* New patch extracted from patch:
"drm: rcar-du: lvds: Add dual-LVDS panels support"
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 46 +
1 file changed, 37 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 6c1f171..cb2147c 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -71,6 +71,7 @@ struct rcar_lvds {
struct drm_bridge *companion;
bool dual_link;
+ bool stripe_swap_data;
};
#define bridge_to_rcar_lvds(b) \
@@ -441,12 +442,20 @@ static void rcar_lvds_enable(struct drm_bridge *bridge)
rcar_lvds_write(lvds, LVDCHCR, lvdhcr);
if (lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK) {
- /*
-* Configure vertical stripe based on the mode of operation of
-* the connected device.
-*/
- rcar_lvds_write(lvds, LVDSTRIPE,
- lvds->dual_link ? LVDSTRIPE_ST_ON : 0);
+ u32 lvdstripe = 0;
+
+ if (lvds->dual_link)
+ /*
+* Configure vertical stripe based on the mode of
+* operation of the connected device.
+*
+* ST_SWAP from LVD1STRIPE is reserved, do not set
+* in the companion LVDS
+*/
+ lvdstripe = LVDSTRIPE_ST_ON |
+ (lvds->companion && lvds->stripe_swap_data ?
+LVDSTRIPE_ST_SWAP : 0);
+ rcar_lvds_write(lvds, LVDSTRIPE, lvdstripe);
}
/*
@@ -702,17 +711,33 @@ static int rcar_lvds_parse_dt_companion(struct rcar_lvds
*lvds)
dual_link = drm_of_lvds_get_dual_link_pixel_order(p0, p1);
of_node_put(p0);
of_node_put(p1);
- if (dual_link >= DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS) {
+
+ switch (dual_link) {
+ case DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS:
+ /*
+* By default we generate even pixels from this encoder and odd
+* pixels from the companion encoder, but since p0 is connected
+* to the port expecting ood pixels, and p1 is connected to the
+* port expecting even pixels, we need to swap even and odd
+* pixels around.
+*/
+ lvds->stripe_swap_data = true;
+ lvds->dual_link = true;
+ break;
+ case DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS:
lvds->dual_link = true;
- } else if (lvds->next_bridge && lvds->next_bridge->timings) {
+ break;
+ default:
/*
* Early dual-link bridge specific implementations populate the
* timings field of drm_bridge, read the dual_link flag off the
* bridge directly for backward compatibility.
*/
- lvds->dual_link = lvds->next_bridge->timings->dual_link;
+ if (lvds->next_bridge && lvds->next_bridge->timings)
+ lvds->dual_link = lvds->next_bridge->timings->dual_link;
}
+
if (!lvds->dual_link) {
dev_dbg(dev, "Single-link configuration detected\n");
goto done;
@@ -728,6 +753,9 @@ static int rcar_lvds_parse_dt_companion(struct rcar_lvds
*lvds)
"Dual-link configuration detected (companion encoder %pOF)\n",
companion);
+ if (lvds->stripe_swap_data)
+ dev_dbg(dev, "Data swapping required\n");
+
companion_lvds = bridge_to_rcar_lvds(lvds->companion);
/*
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/7] Add dual-LVDS panel support to EK874
Dear All, this series adds support for dual-LVDS panel IDK-2121WR from Advantech: https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.htm V4 incorporates most of the comments received from v3, making it significantly different from v3: patch "drm: rcar-du: lvds: Add dual-LVDS panels support" has been split in 4 patches, patches "dt-bindings: display: Add bindings for LVDS bus-timings" and "dt-bindings: display: Add idk-2121wr binding" have been merged together, and a few issues have been fixed. Thanks, Fab Fabrizio Castro (7): drm: of: Add drm_of_lvds_get_dual_link_pixel_order drm: rcar-du: lvds: Improve identification of panels drm: rcar-du: lvds: Get dual link configuration from DT drm: rcar-du: lvds: Allow for even and odd pixels swap drm: rcar-du: lvds: Fix mode for companion encoder dt-bindings: display: Add idk-2121wr binding arm64: dts: renesas: Add EK874 board with idk-2121wr display support .../display/panel/advantech,idk-2121wr.yaml| 128 ++ arch/arm64/boot/dts/renesas/Makefile | 3 +- .../boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts | 116 + drivers/gpu/drm/drm_of.c | 104 +++ drivers/gpu/drm/rcar-du/rcar_lvds.c| 143 ++--- include/drm/drm_of.h | 20 +++ 6 files changed, 468 insertions(+), 46 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml create mode 100644 arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v3 5/8] drm: bridge: thc63: Do not report input bus mode through bridge timings
Hi Laurent,
Thank you for your feedback!
> From: linux-kernel-ow...@vger.kernel.org
> On Behalf Of Laurent Pinchart
> Sent: 07 November 2019 19:52
> Subject: Re: [PATCH v3 5/8] drm: bridge: thc63: Do not report input bus mode
> through bridge timings
>
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Wed, Aug 28, 2019 at 07:36:39PM +0100, Fabrizio Castro wrote:
> > No need to report the input bus mode through bridge timings
> > anymore, that's now done through the DT, as specified by the
> > dt-bindings.
>
> Doesn't this break backward compatibility with older DT, as mentioned in
> the review of 4/8 ?
>
I'll drop this patch in v4
Thanks,
Fab
> > Signed-off-by: Fabrizio Castro
> >
> > ---
> > v2->v3:
> > * new patch
> > ---
> > drivers/gpu/drm/bridge/thc63lvd1024.c | 9 -
> > include/drm/drm_bridge.h | 8
> > 2 files changed, 4 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c
> > b/drivers/gpu/drm/bridge/thc63lvd1024.c
> > index 3d74129b..730f682 100644
> > --- a/drivers/gpu/drm/bridge/thc63lvd1024.c
> > +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
> > @@ -34,7 +34,7 @@ struct thc63_dev {
> > struct drm_bridge bridge;
> > struct drm_bridge *next;
> >
> > - struct drm_bridge_timings timings;
> > + bool dual_link;
> > };
> >
> > static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
> > @@ -62,7 +62,7 @@ static enum drm_mode_status thc63_mode_valid(struct
> > drm_bridge *bridge,
> > * isn't supported by the driver yet, simply derive the limits from the
> > * input mode.
> > */
> > - if (thc63->timings.dual_link) {
> > + if (thc63->dual_link) {
> > min_freq = 4;
> > max_freq = 15;
> > } else {
> > @@ -157,13 +157,13 @@ static int thc63_parse_dt(struct thc63_dev *thc63)
> >
> > if (remote) {
> > if (of_device_is_available(remote))
> > - thc63->timings.dual_link = true;
> > + thc63->dual_link = true;
> > of_node_put(remote);
> > }
> > }
> >
> > dev_dbg(thc63->dev, "operating in %s-link mode\n",
> > - thc63->timings.dual_link ? "dual" : "single");
> > + thc63->dual_link ? "dual" : "single");
> >
> > return 0;
> > }
> > @@ -221,7 +221,6 @@ static int thc63_probe(struct platform_device *pdev)
> > thc63->bridge.driver_private = thc63;
> > thc63->bridge.of_node = pdev->dev.of_node;
> > thc63->bridge.funcs = _bridge_func;
> > - thc63->bridge.timings = >timings;
> >
> > drm_bridge_add(>bridge);
> >
> > diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> > index 7616f65..3228018 100644
> > --- a/include/drm/drm_bridge.h
> > +++ b/include/drm/drm_bridge.h
> > @@ -362,14 +362,6 @@ struct drm_bridge_timings {
> > * input signal after the clock edge.
> > */
> > u32 hold_time_ps;
> > - /**
> > -* @dual_link:
> > -*
> > -* True if the bus operates in dual-link mode. The exact meaning is
> > -* dependent on the bus type. For LVDS buses, this indicates that even-
> > -* and odd-numbered pixels are received on separate links.
> > -*/
> > - bool dual_link;
> > };
> >
> > /**
>
> --
> Regards,
>
> Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 6/7] dt-bindings: display: Add idk-2121wr binding
Add binding for the idk-2121wr LVDS panel from Advantech.
Some panel-specific documentation can be found here:
https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.htm
Signed-off-by: Fabrizio Castro
---
v3->v4:
* Absorbed patch "dt-bindings: display: Add bindings for LVDS
bus-timings"
* Big restructuring after Rob's and Laurent's comments
v2->v3:
* new patch
---
.../display/panel/advantech,idk-2121wr.yaml| 128 +
1 file changed, 128 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
new file mode 100644
index 000..24cd38b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
@@ -0,0 +1,128 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/advantech,idk-2121wr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Advantech IDK-2121WR 21.5" Full-HD dual-LVDS panel
+
+maintainers:
+ - Fabrizio Castro
+ - Thierry Reding
+
+description: |
+ The IDK-2121WR from Advantech is a Full-HD dual-LVDS panel.
+ A dual-LVDS interface is a dual-link connection with even pixels traveling
+ on one link, and with odd pixels traveling on the other link.
+
+ The panel expects odd pixels on the first port, and even pixels on the
+ second port, therefore the ports must be marked accordingly (with either
+ dual-lvds-odd-pixels or dual-lvds-even-pixels).
+
+properties:
+ compatible:
+items:
+ - const: advantech,idk-2121wr
+ - {} # panel-lvds, but not listed here to avoid false select
+
+ width-mm:
+const: 476
+
+ height-mm:
+const: 268
+
+ data-mapping:
+const: vesa-24
+
+ ports:
+type: object
+properties:
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+ port@0:
+type: object
+description: The sink for odd pixels.
+properties:
+ reg:
+const: 0
+
+ dual-lvds-odd-pixels: true
+
+required:
+ - reg
+ - dual-lvds-odd-pixels
+
+ port@1:
+type: object
+description: The sink for even pixels.
+properties:
+ reg:
+const: 1
+
+ dual-lvds-even-pixels: true
+
+required:
+ - reg
+ - dual-lvds-even-pixels
+
+ panel-timing: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - width-mm
+ - height-mm
+ - data-mapping
+ - panel-timing
+ - ports
+
+examples:
+ - |+
+panel-lvds {
+ compatible = "advantech,idk-2121wr", "panel-lvds";
+
+ width-mm = <476>;
+ height-mm = <268>;
+
+ data-mapping = "vesa-24";
+
+ panel-timing {
+clock-frequency = <14850>;
+hactive = <1920>;
+vactive = <1080>;
+hsync-len = <44>;
+hfront-porch = <88>;
+hback-porch = <148>;
+vfront-porch = <4>;
+vback-porch = <36>;
+vsync-len = <5>;
+ };
+
+ ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+ reg = <0>;
+ dual-lvds-odd-pixels;
+ panel_in0: endpoint {
+remote-endpoint = <_out>;
+ };
+};
+
+port@1 {
+ reg = <1>;
+ dual-lvds-even-pixels;
+ panel_in1: endpoint {
+remote-endpoint = <_out>;
+ };
+};
+ };
+};
+
+...
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 7/7] arm64: dts: renesas: Add EK874 board with idk-2121wr display support
The EK874 is advertised as compatible with panel IDK-2121WR from
Advantech, however the panel isn't sold alongside the board.
A new dts, adding everything that's required to get the panel to
to work with the EK874, is the most convenient way to support the
EK874 when it's connected to the IDK-2121WR.
Signed-off-by: Fabrizio Castro
Acked-by: Laurent Pinchart
---
v3->v4:
* no change
v2->v3:
* removed renesas,swap-data property
* added dual-lvds-odd-pixels and dual-lvds-even-pixels properties
v1->v2:
* Added comment for lvds-connector-en-gpio
* Renamed _panel_in to panel_in0
* Renamed _panel_in to panel_in1
---
arch/arm64/boot/dts/renesas/Makefile | 3 +-
.../boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts | 116 +
2 files changed, 118 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts
diff --git a/arch/arm64/boot/dts/renesas/Makefile
b/arch/arm64/boot/dts/renesas/Makefile
index 8fdbd22..2635799 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -3,7 +3,8 @@ dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m.dtb
dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m-ex.dtb
dtb-$(CONFIG_ARCH_R8A774B1) += r8a774b1-hihope-rzg2n.dtb
dtb-$(CONFIG_ARCH_R8A774B1) += r8a774b1-hihope-rzg2n-ex.dtb
-dtb-$(CONFIG_ARCH_R8A774C0) += r8a774c0-cat874.dtb r8a774c0-ek874.dtb
+dtb-$(CONFIG_ARCH_R8A774C0) += r8a774c0-cat874.dtb r8a774c0-ek874.dtb \
+ r8a774c0-ek874-idk-2121wr.dtb
dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-salvator-x.dtb r8a7795-h3ulcb.dtb
dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-h3ulcb-kf.dtb
dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-salvator-xs.dtb
diff --git a/arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts
b/arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts
new file mode 100644
index 000..a7b27d0
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts
@@ -0,0 +1,116 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the Silicon Linux RZ/G2E evaluation kit (EK874),
+ * connected to an Advantech IDK-2121WR 21.5" LVDS panel
+ *
+ * Copyright (C) 2019 Renesas Electronics Corp.
+ */
+
+#include "r8a774c0-ek874.dts"
+
+/ {
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = < 0 5>;
+
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <6>;
+
+ power-supply = <_12p0v>;
+ enable-gpios = < 12 GPIO_ACTIVE_HIGH>;
+ };
+
+ panel-lvds {
+ compatible = "advantech,idk-2121wr", "panel-lvds";
+
+ width-mm = <476>;
+ height-mm = <268>;
+
+ data-mapping = "vesa-24";
+
+ panel-timing {
+ clock-frequency = <14850>;
+ hactive = <1920>;
+ vactive = <1080>;
+ hsync-len = <44>;
+ hfront-porch = <88>;
+ hback-porch = <148>;
+ vfront-porch = <4>;
+ vback-porch = <36>;
+ vsync-len = <5>;
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dual-lvds-odd-pixels;
+ panel_in0: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dual-lvds-even-pixels;
+ panel_in1: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+ };
+};
+
+ {
+ /*
+* When GP0_17 is low LVDS[01] are connected to the LVDS connector
+* When GP0_17 is high LVDS[01] are connected to the LT8918L
+*/
+ lvds-connector-en-gpio{
+ gpio-hog;
+ gpios = <17 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "lvds-connector-en-gpio";
+ };
+};
+
+ {
+ ports {
+ port@1 {
+ lvds0_out: endpoint {
+ remote-endpoint = <_in0>;
+ };
+ };
+ };
+};
+
+ {
+ status = "okay";
+
+ clocks
[PATCH v4 5/7] drm: rcar-du: lvds: Fix mode for companion encoder
Primary and companion encoders need to set the same mode for
things to work properly.
rcar_lvds_mode_set gets called into for the primary encoder only,
therefore initialize the companion encoder mode while sorting
the primary encoder mode out.
Fixes: fa440d870358 ("drm: rcar-du: lvds: Add support for dual-link mode")
Signed-off-by: Fabrizio Castro
---
v3->v4:
* New patch extracted from patch:
"drm: rcar-du: lvds: Add dual-LVDS panels support"
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index cb2147c..eed5611 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -614,6 +614,18 @@ static void rcar_lvds_mode_set(struct drm_bridge *bridge,
lvds->display_mode = *adjusted_mode;
rcar_lvds_get_lvds_mode(lvds);
+ if (lvds->companion) {
+ struct rcar_lvds *companion_lvds = bridge_to_rcar_lvds(
+ lvds->companion);
+
+ /*
+* FIXME: We should not be messing with the companion encoder
+* private data from the primary encoder, but since
+* rcar_lvds_mode_set gets called into for the primary encoder
+* only, we don't have much of a choice for now.
+*/
+ companion_lvds->mode = lvds->mode;
+ }
}
static int rcar_lvds_attach(struct drm_bridge *bridge)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v3 2/8] dt-bindings: display: Add idk-2121wr binding
Hi Laurent,
Thank you for your feedback!
> From: Laurent Pinchart
> Sent: 07 November 2019 18:12
> Subject: Re: [PATCH v3 2/8] dt-bindings: display: Add idk-2121wr binding
>
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Wed, Aug 28, 2019 at 07:36:36PM +0100, Fabrizio Castro wrote:
> > Add binding for the idk-2121wr LVDS panel from Advantech.
> >
> > Some panel-specific documentation can be found here:
> > https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.htm
> >
> > Signed-off-by: Fabrizio Castro
> >
> > ---
> > v2->v3:
> > * new patch
> > ---
> > .../display/panel/advantech,idk-2121wr.yaml| 90
> > ++
> > 1 file changed, 90 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
> b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
> > new file mode 100644
> > index 000..b2ccdc8
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
> > @@ -0,0 +1,90 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/panel/advantech,idk-2121wr.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Advantech IDK-2121WR 21.5" Full-HD dual-LVDS panel
> > +
> > +maintainers:
> > + - Fabrizio Castro
> > + - Thierry Reding
> > +
> > +description: |
> > + The IDK-2121WR from Advantech is a Full-HD dual-LVDS panel.
> > +
> > + The panels expects odd pixels from the first port, and even pixels from
>
> s/panels/panel/
> Maybe s/from the/on the/g ?
Will fix
>
> > + the second port, therefore the ports must be marked accordingly.
> > +
> > +allOf:
> > + - $ref: lvds.yaml#
> > + - $ref: ../bus-timings/lvds.yaml#
> > +
> > +properties:
> > + compatible:
> > +items:
> > + - const: advantech,idk-2121wr
> > + - {} # panel-lvds, but not listed here to avoid false select
> > +
> > + data-mapping:
> > +const: vesa-24
> > +
> > + width-mm:
> > +const: 476
> > +
> > + height-mm:
> > +const: 268
> > +
> > + panel-timing: true
> > + ports: true
> > +
> > +additionalProperties: false
> > +
> > +required:
> > + - compatible
>
> Shouldn't data-mapping, width-mm, height-mm and ports be required too ?
Those are required by lvds.yaml, and this file has a reference to it.
Anyhow, I think the best course of action is to merge this with the
generic bus-timings/lvds.yaml for the time being, and maybe split
them back later on once we have another use case.
Thanks,
Fab
>
> As you mentioned in the cover letter, validating ports, port and the new
> dual-lvds-*-pixels properties would be nice. I'm not YAML schema
> specialist, so I'm fine with a best effort approach here, but as far as
> I understand Rob proposed a way forward, could you try it ?
>
> Apart from that, the bindings look sne to me, so
>
> Reviewed-by: Laurent Pinchart
>
> once the above issues get addressed.
>
> > +
> > +examples:
> > + - |+
> > +panel-lvds {
> > + compatible = "advantech,idk-2121wr", "panel-lvds";
> > +
> > + width-mm = <476>;
> > + height-mm = <268>;
> > +
> > + data-mapping = "vesa-24";
> > +
> > + panel-timing {
> > +clock-frequency = <14850>;
> > +hactive = <1920>;
> > +vactive = <1080>;
> > +hsync-len = <44>;
> > +hfront-porch = <88>;
> > +hback-porch = <148>;
> > +vfront-porch = <4>;
> > +vback-porch = <36>;
> > +vsync-len = <5>;
> > + };
> > +
> > + ports {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +port@0 {
> > + reg = <0>;
> > + dual-lvds-odd-pixels;
> > + panel_in0: endpoint {
> > +remote-endpoint = <_out>;
> > + };
> > +};
> > +
> > +port@1 {
> > + reg = <1>;
> > + dual-lvds-even-pixels;
> > + panel_in1: endpoint {
> > +remote-endpoint = <_out>;
> > + };
> > +};
> > + };
> > +};
> > +
> > +...
>
> --
> Regards,
>
> Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v3 3/8] drm: Add bus timings helper
Hi Laurent,
Thank you for your feedback!
> From: linux-kernel-ow...@vger.kernel.org
> On Behalf Of Laurent Pinchart
> Sent: 07 November 2019 19:26
> Subject: Re: [PATCH v3 3/8] drm: Add bus timings helper
>
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Wed, Aug 28, 2019 at 07:36:37PM +0100, Fabrizio Castro wrote:
> > Helper to provide bus timing information.
>
> You may want to expand this a bit. And actually fix it too, as the
> helper you introduce isn't related to timings (same for the subject
> line).
I'll rework this completely
>
> > Signed-off-by: Fabrizio Castro
> >
> > ---
> > v2->v3:
> > * new patch
> > ---
> > drivers/gpu/drm/Makefile | 3 +-
> > drivers/gpu/drm/drm_bus_timings.c | 97
> > +++
> > include/drm/drm_bus_timings.h | 21 +
> > 3 files changed, 120 insertions(+), 1 deletion(-)
> > create mode 100644 drivers/gpu/drm/drm_bus_timings.c
> > create mode 100644 include/drm/drm_bus_timings.h
> >
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > index 9f0d2ee..a270063 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -17,7 +17,8 @@ drm-y :=drm_auth.o drm_cache.o \
> > drm_plane.o drm_color_mgmt.o drm_print.o \
> > drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
> > drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
> > - drm_client_modeset.o drm_atomic_uapi.o drm_hdcp.o
> > + drm_client_modeset.o drm_atomic_uapi.o drm_hdcp.o \
> > + drm_bus_timings.o
> >
> > drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o drm_context.o
> > drm_dma.o drm_scatter.o drm_lock.o
> > drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
> > diff --git a/drivers/gpu/drm/drm_bus_timings.c
> > b/drivers/gpu/drm/drm_bus_timings.c
> > new file mode 100644
> > index 000..e2ecd22
> > --- /dev/null
> > +++ b/drivers/gpu/drm/drm_bus_timings.c
> > @@ -0,0 +1,97 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define DRM_OF_LVDS_ODD1
> > +#define DRM_OF_LVDS_EVEN 2
> > +
> > +static int drm_of_lvds_get_port_pixels_type(struct device_node *port_node)
> > +{
> > + bool even_pixels, odd_pixels;
> > +
> > + even_pixels = of_property_read_bool(port_node, "dual-lvds-even-pixels");
> > + odd_pixels = of_property_read_bool(port_node, "dual-lvds-odd-pixels");
> > + return even_pixels * DRM_OF_LVDS_EVEN + odd_pixels * DRM_OF_LVDS_ODD;
>
> s/ / /
>
> But I would make these bitflags.
>
> enum drm_of_lvds_pixels {
> DRM_OF_LVDS_EVEN = BIT(0),
> DRM_OF_LVDS_ODD = BIT(1),
> };
>
> static int drm_of_lvds_get_port_pixels_type(struct device_node *port)
> {
> bool even_pixels = of_property_read_bool(port, "dual-lvds-even-pixels");
> bool odd_pixels = of_property_read_bool(port, "dual-lvds-odd-pixels");
>
> return (even_pixels ? DRM_OF_LVDS_EVEN : 0) |
> (odd_pixels ? DRM_OF_LVDS_ODD : 0);
> }
Will do
>
> > +}
> > +
> > +/**
> > + * drm_of_lvds_get_dual_link_configuration - get the dual-LVDS
> > configuration
>
> Should we name this drm_of_lvds_get_dual_link_pixel_order to better
> reflect its purpose ?
>
> > + * @p1: device tree node corresponding to the first port of the source
> > + * @p2: device tree node corresponding to the second port of the source
>
> Maybe port1 and port2 to make this more explicit ?
yeah
>
> > + *
> > + * An LVDS dual-link bus is made of two connections, even pixels transit
> > on one
> > + * connection, and odd pixels transit on the other connection.
>
> To match the DT bindings documentation, I would recommand
>
> "An LVDS dual-link connection is made of two links, with even pixels
> transitting on one link, and odd pixels on the other link."
>
> > + * This function walks the DT (from the source ports to the sink ports)
> > looking
> > + * for a dual-LVDS bus. A dual-LVDS bus is identfied by markers found on
> > the DT
> > + * ports of the sink device(s). If such a bus is found, this function
> > returns
> > + * its configuration (either p1 connected to the even pixels port and p2
> > + * connected to the odd pixels port, or p1 connected to the odd pixels
> > port and
> > + * p2 co
RE: [PATCH v3 1/8] dt-bindings: display: Add bindings for LVDS bus-timings
Hi Laurent, Thank you for your feedback! > From: devicetree-ow...@vger.kernel.org On > Behalf Of Laurent Pinchart > Sent: 07 November 2019 18:01 > Subject: Re: [PATCH v3 1/8] dt-bindings: display: Add bindings for LVDS > bus-timings > > Hello Fabrizio, > > On Thu, Aug 29, 2019 at 02:38:06PM +, Fabrizio Castro wrote: > > On 29 August 2019 15:03 Rob Herring wrote: > > > On Wed, Aug 28, 2019 at 1:36 PM Fabrizio Castro wrote: > > >> > > >> Dual-LVDS connections need markers in the DT, this patch adds > > >> some common documentation to be referenced by both panels and > > >> bridges. > > >> > > >> Signed-off-by: Fabrizio Castro > > >> > > >> --- > > >> v2->v3: > > >> * new patch > > >> --- > > >> .../bindings/display/bus-timings/lvds.yaml | 38 > > >> ++ > > >> 1 file changed, 38 insertions(+) > > >> create mode 100644 > > >> Documentation/devicetree/bindings/display/bus-timings/lvds.yaml > > >> > > >> diff --git > > >> a/Documentation/devicetree/bindings/display/bus-timings/lvds.yaml > b/Documentation/devicetree/bindings/display/bus-timings/lvds.yaml > > >> new file mode 100644 > > >> index 000..f35b55a > > >> --- /dev/null > > >> +++ b/Documentation/devicetree/bindings/display/bus-timings/lvds.yaml > > >> @@ -0,0 +1,38 @@ > > >> +# SPDX-License-Identifier: GPL-2.0 > > > > > > (GPL-2.0-only OR BSD-2-Clause) is preferred for new bindings. > > > > > >> +%YAML 1.2 > > >> +--- > > >> +$id: http://devicetree.org/schemas/display/bus-timings/lvds.yaml# > > >> +$schema: http://devicetree.org/meta-schemas/core.yaml# > > >> + > > >> +title: Common Properties for bus timings of LVDS interfaces > > >> + > > >> +maintainers: > > >> + - Thierry Reding > > >> + - Fabrizio Castro > > >> + > > >> +description: | > > >> + This document defines device tree properties common to LVDS and > > >> dual-LVDS > > >> + interfaces, where a dual-LVDS interface is a dual-link connection > > >> with even > > >> + pixels traveling on one connection, and with odd pixels traveling on > > >> the other > > >> + connection. > > As you define a dual-LVDS interface as "a dual-link connection", should > this be "even pixels traveling on one link, and with odd pixels > traveling on the other link" ? Will change. Thanks, Fab > > > >> + This document doesn't constitue a device tree binding specification > > >> by itself > > > > > > typo: constitute > > > > Well spotted! > > > > >> + but is meant to be referenced by device tree bindings. > > >> + When referenced from panel or bridge device tree bindings, the > > >> properties > > >> + defined in this document are defined as follows. The panel and bridge > > >> device > > >> + tree bindings are responsible for defining whether each property is > > >> required > > >> + or optional. > > >> + > > >> +properties: > > >> + dual-lvds-even-pixels: > > >> +type: boolean > > >> +description: > > >> + This property is specific to an input port of a sink device. When > > > > > > The schema should define what nodes these go in. The description seems > > > to indicate in 'port' nodes (or endpoint?), but your use in the panel > > > binding puts them in the parent. > > > > Did you manage to read this? > > https://patchwork.kernel.org/cover/9607/ > > > > Could you please advice on how to do this properly? > > > > >> + specified, it marks the port as recipient of even-pixels. > > >> + > > >> + dual-lvds-odd-pixels: > > >> +type: boolean > > >> +description: > > >> + This property is specific to an input port of a sink device. When > > >> + specified, it marks the port as recipient of odd-pixels. > > > > > > However, I don't think you even need these. A panel's port numbers are > > > fixed can imply even or odd. For example port@0 can be even and port@1 > > > can be odd. The port numbering is typically panel specific, but we may > > > be able to define the
RE: [PATCH v3 3/8] drm: Add bus timings helper
Hi Daniel,
Thank you for your feedback!
> From: Daniel Vetter On Behalf Of Daniel Vetter
> Sent: 07 November 2019 19:30
> Subject: Re: [PATCH v3 3/8] drm: Add bus timings helper
>
> On Thu, Nov 07, 2019 at 09:26:21PM +0200, Laurent Pinchart wrote:
> > Hi Fabrizio,
> >
> > Thank you for the patch.
> >
> > On Wed, Aug 28, 2019 at 07:36:37PM +0100, Fabrizio Castro wrote:
> > > Helper to provide bus timing information.
> >
> > You may want to expand this a bit. And actually fix it too, as the
> > helper you introduce isn't related to timings (same for the subject
> > line).
>
> Also the kerneldoc needs to be pulled into the templates under
> Documentation/gpu. And since it's just one function, why not put this into
> drm_of.c? Gets rid of a pile of overhead.
Yeah, you are right, will try and pull this into drm_of.c in v4.
Thanks!
Fab
>
> >
> > > Signed-off-by: Fabrizio Castro
> > >
> > > ---
> > > v2->v3:
> > > * new patch
> > > ---
> > > drivers/gpu/drm/Makefile | 3 +-
> > > drivers/gpu/drm/drm_bus_timings.c | 97
> > > +++
> > > include/drm/drm_bus_timings.h | 21 +
> > > 3 files changed, 120 insertions(+), 1 deletion(-)
> > > create mode 100644 drivers/gpu/drm/drm_bus_timings.c
> > > create mode 100644 include/drm/drm_bus_timings.h
> > >
> > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > > index 9f0d2ee..a270063 100644
> > > --- a/drivers/gpu/drm/Makefile
> > > +++ b/drivers/gpu/drm/Makefile
> > > @@ -17,7 +17,8 @@ drm-y := drm_auth.o drm_cache.o \
> > > drm_plane.o drm_color_mgmt.o drm_print.o \
> > > drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
> > > drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
> > > - drm_client_modeset.o drm_atomic_uapi.o drm_hdcp.o
> > > + drm_client_modeset.o drm_atomic_uapi.o drm_hdcp.o \
> > > + drm_bus_timings.o
> > >
> > > drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o drm_context.o
> > > drm_dma.o drm_scatter.o drm_lock.o
> > > drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
> > > diff --git a/drivers/gpu/drm/drm_bus_timings.c
> > > b/drivers/gpu/drm/drm_bus_timings.c
> > > new file mode 100644
> > > index 000..e2ecd22
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/drm_bus_timings.c
> > > @@ -0,0 +1,97 @@
> > > +// SPDX-License-Identifier: GPL-2.0
>
> DRM core is supposed to be MIT.
> -Daniel
>
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#define DRM_OF_LVDS_ODD 1
> > > +#define DRM_OF_LVDS_EVEN 2
> > > +
> > > +static int drm_of_lvds_get_port_pixels_type(struct device_node
> > > *port_node)
> > > +{
> > > + bool even_pixels, odd_pixels;
> > > +
> > > + even_pixels = of_property_read_bool(port_node, "dual-lvds-even-pixels");
> > > + odd_pixels = of_property_read_bool(port_node, "dual-lvds-odd-pixels");
> > > + return even_pixels * DRM_OF_LVDS_EVEN + odd_pixels * DRM_OF_LVDS_ODD;
> >
> > s/ / /
> >
> > But I would make these bitflags.
> >
> > enum drm_of_lvds_pixels {
> > DRM_OF_LVDS_EVEN = BIT(0),
> > DRM_OF_LVDS_ODD = BIT(1),
> > };
> >
> > static int drm_of_lvds_get_port_pixels_type(struct device_node *port)
> > {
> > bool even_pixels = of_property_read_bool(port, "dual-lvds-even-pixels");
> > bool odd_pixels = of_property_read_bool(port, "dual-lvds-odd-pixels");
> >
> > return (even_pixels ? DRM_OF_LVDS_EVEN : 0) |
> >(odd_pixels ? DRM_OF_LVDS_ODD : 0);
> > }
> >
> > > +}
> > > +
> > > +/**
> > > + * drm_of_lvds_get_dual_link_configuration - get the dual-LVDS
> > > configuration
> >
> > Should we name this drm_of_lvds_get_dual_link_pixel_order to better
> > reflect its purpose ?
> >
> > > + * @p1: device tree node corresponding to the first port of the source
> > > + * @p2: device tree node corresponding to the second port of the source
> >
> > Maybe port1 and port2 to make this more explicit ?
> >
> > > + *
> > > + * An LVDS dual-link bus is made of two connections, even pixels transit
> > > on one
>
RE: [PATCH v3 1/8] dt-bindings: display: Add bindings for LVDS bus-timings
Hi Rob, > From: Rob Herring > Sent: 29 August 2019 15:03 > Subject: Re: [PATCH v3 1/8] dt-bindings: display: Add bindings for LVDS > bus-timings > > On Wed, Aug 28, 2019 at 1:36 PM Fabrizio Castro > wrote: > > > > Dual-LVDS connections need markers in the DT, this patch adds > > some common documentation to be referenced by both panels and > > bridges. > > > > Signed-off-by: Fabrizio Castro > > > > --- > > v2->v3: > > * new patch > > --- > > .../bindings/display/bus-timings/lvds.yaml | 38 > > ++ > > 1 file changed, 38 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/bus-timings/lvds.yaml > > > > diff --git > > a/Documentation/devicetree/bindings/display/bus-timings/lvds.yaml > > b/Documentation/devicetree/bindings/display/bus- > timings/lvds.yaml > > new file mode 100644 > > index 000..f35b55a > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/bus-timings/lvds.yaml > > @@ -0,0 +1,38 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > (GPL-2.0-only OR BSD-2-Clause) is preferred for new bindings. > > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/display/bus-timings/lvds.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Common Properties for bus timings of LVDS interfaces > > + > > +maintainers: > > + - Thierry Reding > > + - Fabrizio Castro > > + > > +description: | > > + This document defines device tree properties common to LVDS and dual-LVDS > > + interfaces, where a dual-LVDS interface is a dual-link connection with > > even > > + pixels traveling on one connection, and with odd pixels traveling on the > > other > > + connection. > > + This document doesn't constitue a device tree binding specification by > > itself > > typo: constitute > > > + but is meant to be referenced by device tree bindings. > > + When referenced from panel or bridge device tree bindings, the properties > > + defined in this document are defined as follows. The panel and bridge > > device > > + tree bindings are responsible for defining whether each property is > > required > > + or optional. > > + > > +properties: > > + dual-lvds-even-pixels: > > +type: boolean > > +description: > > + This property is specific to an input port of a sink device. When > > The schema should define what nodes these go in. The description seems > to indicate in 'port' nodes (or endpoint?), but your use in the panel > binding puts them in the parent. > > > + specified, it marks the port as recipient of even-pixels. > > + > > + dual-lvds-odd-pixels: > > +type: boolean > > +description: > > + This property is specific to an input port of a sink device. When > > + specified, it marks the port as recipient of odd-pixels. > > However, I don't think you even need these. A panel's port numbers are > fixed can imply even or odd. For example port@0 can be even and port@1 > can be odd. The port numbering is typically panel specific, but we may > be able to define the numbering generically if we don't already have > panels with multiple ports. The ports on the receiving end of the link can be identified by any number, not necessarily 0 and 1. Since at this point in time we only have 1 use case for this I'll merge the generic and panel specific dt-schemas together, for simplicity. Perhaps we can split them back once we have a second use case? I'll send a new patch shortly. Thank you very much for your help and your patience! Fab > > Also, aren't there dual link DSI panels? > > Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm: rcar-du: lvds: Get mode from state
Hello Laurent,
Thank you for your patch!
> From: linux-renesas-soc-ow...@vger.kernel.org
> On Behalf Of Laurent Pinchart
> Sent: 16 October 2019 00:25
> Subject: [PATCH] drm: rcar-du: lvds: Get mode from state
>
> The R-Car LVDS encoder driver implements the bridge .mode_set()
> operation for the sole purpose of storing the mode in the LVDS private
> data, to be used later when enabling the encoder.
>
> Switch to the bridge .atomic_enable() and .atomic_disable() operations
> in order to access the global atomic state, and get the mode from the
> state instead. Remove both the unneeded .mode_set() operation and the
> display_mode and mode fields storing state data from the rcar_lvds
> private structure.
>
> As a side effect we get the CRTC from the state, replace the CRTC
> pointer retrieved through the bridge's encoder that shouldn't be used by
> atomic drivers.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 125 ++--
> 1 file changed, 61 insertions(+), 64 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> index 8c6c172bbf2e..8f355ea07cb5 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -65,9 +65,6 @@ struct rcar_lvds {
> struct clk *dotclkin[2];/* External DU clocks */
> } clocks;
>
> - struct drm_display_mode display_mode;
> - enum rcar_lvds_mode mode;
> -
> struct drm_bridge *companion;
> bool dual_link;
> };
> @@ -402,10 +399,51 @@ EXPORT_SYMBOL_GPL(rcar_lvds_clk_disable);
> * Bridge
> */
>
> -static void rcar_lvds_enable(struct drm_bridge *bridge)
> +static enum rcar_lvds_mode rcar_lvds_get_lvds_mode(struct rcar_lvds *lvds,
> + const struct drm_connector *connector)
> +{
> + const struct drm_display_info *info;
> + enum rcar_lvds_mode mode;
> +
> + /*
> + * There is no API yet to retrieve LVDS mode from a bridge, only panels
> + * are supported.
> + */
> + if (!lvds->panel)
> + return RCAR_LVDS_MODE_JEIDA;
> +
> + info = >display_info;
> + if (!info->num_bus_formats || !info->bus_formats) {
> + dev_err(lvds->dev, "no LVDS bus format reported\n");
> + return RCAR_LVDS_MODE_JEIDA;
> + }
> +
> + switch (info->bus_formats[0]) {
> + case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
> + case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA:
> + mode = RCAR_LVDS_MODE_JEIDA;
> + break;
> + case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG:
> + mode = RCAR_LVDS_MODE_VESA;
> + break;
> + default:
> + dev_err(lvds->dev, "unsupported LVDS bus format 0x%04x\n",
> + info->bus_formats[0]);
> + return RCAR_LVDS_MODE_JEIDA;
> + }
> +
> + if (info->bus_flags & DRM_BUS_FLAG_DATA_LSB_TO_MSB)
> + mode |= RCAR_LVDS_MODE_MIRROR;
> +
> + return mode;
> +}
> +
> +static void rcar_lvds_atomic_enable(struct drm_bridge *bridge,
> + struct drm_atomic_state *state)
> {
> struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);
> - const struct drm_display_mode *mode = >display_mode;
> + struct drm_connector *connector;
> + struct drm_crtc *crtc;
> u32 lvdhcr;
> u32 lvdcr0;
> int ret;
> @@ -414,6 +452,11 @@ static void rcar_lvds_enable(struct drm_bridge *bridge)
> if (ret < 0)
> return;
>
> + /* Retrieve the connector and CRTC through the atomic state. */
> + connector = drm_atomic_get_new_connector_for_encoder(state,
> + bridge->encoder);
> + crtc = drm_atomic_get_new_connector_state(state, connector)->crtc;
> +
> /* Enable the companion LVDS encoder in dual-link mode. */
> if (lvds->dual_link && lvds->companion)
> lvds->companion->funcs->enable(lvds->companion);
This should call atomic_enable now, therefore I take this won't work as-is on
a system with a companion encoder. Do you mind testing this patch on a dual-LVDS
capable system?
Thanks,
Fab
> @@ -452,18 +495,20 @@ static void rcar_lvds_enable(struct drm_bridge *bridge)
>* PLL clock configuration on all instances but the companion in
>* dual-link mode.
>*/
> - if (!lvds->dual_link || lvds->companion)
> + if (!lvds->dual_link || lvds->companion) {
> + const struct drm_crtc_state *crtc_state =
> + drm_atomic_get_new_crtc_state(state, crtc);
> + const struct drm_display_mode *mode =
> + _state->adjusted_mode;
> +
> lvds->info->pll_setup(lvds, mode->clock * 1000);
> + }
>
> /* Set the LVDS mode and select the input. */
> - lvdcr0 = lvds->mode << LVDCR0_LVMD_SHIFT;
> + lvdcr0 = rcar_lvds_get_lvds_mode(lvds, connector) <<
RE: [PATCH v4 12/13] [HACK] drm/bridge: lvds-codec: Enforce device specific compatible strings
Hi Geert, > From: Geert Uytterhoeven > Sent: 22 November 2019 08:17 > Subject: Re: [PATCH v4 12/13] [HACK] drm/bridge: lvds-codec: Enforce device > specific compatible strings > > Hi Fabrizio, > > On Thu, Nov 21, 2019 at 5:00 PM Fabrizio Castro > wrote: > > > From: devicetree-ow...@vger.kernel.org > > > On Behalf Of Laurent Pinchart > > > Sent: 19 November 2019 21:52 > > > Subject: Re: [PATCH v4 12/13] [HACK] drm/bridge: lvds-codec: Enforce > > > device specific compatible strings > > > > > > On Tue, Nov 19, 2019 at 11:17:34AM +, Fabrizio Castro wrote: > > > > On 19 November 2019 00:16 Laurent Pinchart wrote: > > > > > On Wed, Nov 13, 2019 at 03:51:31PM +, Fabrizio Castro wrote: > > > > > > The lvds-codec driver is a generic stub for transparent LVDS > > > > > > encoders and decoders. > > > > > > It's good practice to list a device specific compatible string > > > > > > before the generic fallback (if any) in the DT node for the relevant > > > > > > LVDS encoder/decoder, and it's also required by the dt-bindings. > > > > > > A notable exception to the generic fallback mechanism is the case > > > > > > of "thine,thc63lvdm83d", as documented in: > > > > > > Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt > > > > > > This patch enforces the adoption of a device specific compatible > > > > > > string (as fist string in the list), by using markers for the > > > > > > compatible string we match against and the index of the matching > > > > > > compatible string in the list. > > > > > > > > > > > > Signed-off-by: Fabrizio Castro > > > > > > > > > > > > --- > > > > > > Hi Laurent, > > > > > > > > > > > > I don't think we need to do anything in the driver to address your > > > > > > comment, as we can "enforce" this with the bindings (please see the > > > > > > next patch, as it would help with the "enforcing" of the compatible > > > > > > string for the thine device). > > > > > > I am sending this patch only so that you can see what a possible > > > > > > solution in the driver could look like. > > > > > > > > > > > > v3->v4: > > > > > > * New patch addressing the below comment from Laurent: > > > > > > "I think the lvds-decoder driver should error out at probe time if > > > > > > only > > > > > > one compatible string is listed." > > > > > > > --- a/drivers/gpu/drm/bridge/lvds-codec.c > > > > > > +++ b/drivers/gpu/drm/bridge/lvds-codec.c > > > > > > > @@ -65,7 +70,30 @@ static int lvds_codec_probe(struct > > > > > > platform_device *pdev) > > > > > > if (!lvds_codec) > > > > > > return -ENOMEM; > > > > > > > > > > > > - lvds_codec->connector_type = > > > > > > (u32)of_device_get_match_data(>dev); > > > > > > + lvds_codec->data = of_device_get_match_data(>dev); > > > > > > + if (!lvds_codec->data) > > > > > > + return -EINVAL; > > > > > > + > > > > > > + /* > > > > > > +* If we haven't matched a device specific compatible > > > > > > string, we need > > > > > > +* to work out if the generic compatible string we matched > > > > > > against was > > > > > > +* listed first in the compatible property. > > > > > > +*/ > > > > > > > > > > Can't we do this unconditionally, and thus drop the lvds_codec_data > > > > > structure ? > > > > > > > > I don't think so, and the reason for this is that we have a corner case > > > > for > > > > thine,thc63lvdm83d. Here is what's allowed (according to the > > > > documentation) > > > > from what's supported upstream (+ this series): > > > > "ti,ds90c185", "lvds-encoder" > > > > "ti,ds90c187", "lvds-encoder" > > > > "ti,sn75lvds83", "lvds-encoder" > > > > &quo
RE: [PATCH v4 12/13] [HACK] drm/bridge: lvds-codec: Enforce device specific compatible strings
Hi Laurent,
Thank you for your feedback!
> From: devicetree-ow...@vger.kernel.org On
> Behalf Of Laurent Pinchart
> Sent: 19 November 2019 21:52
> Subject: Re: [PATCH v4 12/13] [HACK] drm/bridge: lvds-codec: Enforce device
> specific compatible strings
>
> Hi Fabrizio,
>
> On Tue, Nov 19, 2019 at 11:17:34AM +, Fabrizio Castro wrote:
> > On 19 November 2019 00:16 Laurent Pinchart wrote:
> > > On Wed, Nov 13, 2019 at 03:51:31PM +, Fabrizio Castro wrote:
> > > > The lvds-codec driver is a generic stub for transparent LVDS
> > > > encoders and decoders.
> > > > It's good practice to list a device specific compatible string
> > >
> > > s/good practice/mandatory/
> >
> > Will fix
> >
> > > > before the generic fallback (if any) in the DT node for the relevant
> > > > LVDS encoder/decoder, and it's also required by the dt-bindings.
> > > > A notable exception to the generic fallback mechanism is the case
> > > > of "thine,thc63lvdm83d", as documented in:
> > > > Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt
> > > > This patch enforces the adoption of a device specific compatible
> > > > string (as fist string in the list), by using markers for the
> > >
> > > s/fist/first/
> >
> > Well spotted
> >
> > >
> > > > compatible string we match against and the index of the matching
> > > > compatible string in the list.
> > > >
> > > > Signed-off-by: Fabrizio Castro
> > > >
> > > > ---
> > > > Hi Laurent,
> > > >
> > > > I don't think we need to do anything in the driver to address your
> > > > comment, as we can "enforce" this with the bindings (please see the
> > > > next patch, as it would help with the "enforcing" of the compatible
> > > > string for the thine device).
> > > > I am sending this patch only so that you can see what a possible
> > > > solution in the driver could look like.
> > > >
> > > > v3->v4:
> > > > * New patch addressing the below comment from Laurent:
> > > > "I think the lvds-decoder driver should error out at probe time if only
> > > > one compatible string is listed."
> > > > ---
> > > > drivers/gpu/drm/bridge/lvds-codec.c | 55
> > > > +
> > > > 1 file changed, 49 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
> > > > b/drivers/gpu/drm/bridge/lvds-codec.c
> > > > index 784bbd3..145c25d 100644
> > > > --- a/drivers/gpu/drm/bridge/lvds-codec.c
> > > > +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> > > > @@ -14,11 +14,16 @@
> > > > #include
> > > > #include
> > > >
> > > > +struct lvds_codec_data {
> > > > + u32 connector_type;
> > > > + bool device_specific;
> > > > +};
> > > > +
> > > > struct lvds_codec {
> > > > struct drm_bridge bridge;
> > > > struct drm_bridge *panel_bridge;
> > > > struct gpio_desc *powerdown_gpio;
> > > > - u32 connector_type;
> > > > + const struct lvds_codec_data *data;
> > > > };
> > > >
> > > > static int lvds_codec_attach(struct drm_bridge *bridge)
> > > > @@ -65,7 +70,30 @@ static int lvds_codec_probe(struct platform_device
> > > > *pdev)
> > > > if (!lvds_codec)
> > > > return -ENOMEM;
> > > >
> > > > - lvds_codec->connector_type =
> > > > (u32)of_device_get_match_data(>dev);
> > > > + lvds_codec->data = of_device_get_match_data(>dev);
> > > > + if (!lvds_codec->data)
> > > > + return -EINVAL;
> > > > +
> > > > + /*
> > > > +* If we haven't matched a device specific compatible string,
> > > > we need
> > > > +* to work out if the generic compatible string we matched
> > > > against was
> > > > +* listed first in the compatible property.
> > > > +*/
> > >
> > > Can't we do this unconditionally, and thus drop the lvds_codec_data
> > > structure ?
> >
> > I don't think so, and the
RE: [PATCH v4 08/13] dt-bindings: display: bridge: Repurpose lvds-encoder
Hi Laurent,
Thank you for your feedback!
> From: Laurent Pinchart
> Sent: 19 November 2019 00:08
> Subject: Re: [PATCH v4 08/13] dt-bindings: display: bridge: Repurpose
> lvds-encoder
>
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Wed, Nov 13, 2019 at 03:51:27PM +, Fabrizio Castro wrote:
> > In an effort to repurpose lvds-encoder.c to also serve the
> > function of LVDS decoders, we ended up defining a new "generic"
> > compatible string ("lvds-decoder"), therefore adapt the dt schema
> > to allow for the new compatible string.
> >
> > Signed-off-by: Fabrizio Castro
> >
> > ---
> > v3->v4:
> > * Improved title and description according to Laurent's comments
> > * Reworked definition of the compatible property
> > v2->v3:
> > * Extracted conversion to lvds-codec as per Rob's comment
> > v1->v2:
> > * Converted to dt-schema as per Neil's comment
> > ---
> > .../{lvds-transmitter.yaml => lvds-codec.yaml} | 54
> > +-
> > 1 file changed, 42 insertions(+), 12 deletions(-)
> > rename
> > Documentation/devicetree/bindings/display/bridge/{lvds-transmitter.yaml =>
> > lvds-codec.yaml} (61%)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
> b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> > similarity index 61%
> > rename from
> > Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
> > rename to Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> > index 27de616..0ecc8a4 100644
> > --- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
> > +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> > @@ -1,17 +1,17 @@
> > # SPDX-License-Identifier: GPL-2.0
> > %YAML 1.2
> > ---
> > -$id: http://devicetree.org/schemas/display/bridge/lvds-transmitter.yaml#
> > +$id: http://devicetree.org/schemas/display/bridge/lvds-codec.yaml#
> > $schema: http://devicetree.org/meta-schemas/core.yaml#
> >
> > -title: Parallel to LVDS Encoder
> > +title: Transparent LVDS encoders and decoders
> >
> > maintainers:
> >- Laurent Pinchart
> >
> > description: |
> > - This binding supports the parallel to LVDS encoders that don't require
> > any
> > - configuration.
> > + This binding supports transparent LVDS encoders and decoders that don't
> > + require any configuration.
> >
> >LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
> > Multiple
> >incompatible data link layers have been used over time to transmit image
> > data
> > @@ -33,12 +33,14 @@ properties:
> > description: |
> >Must list the device specific compatible string first, followed by
> > the
> >generic compatible string.
> > -items:
> > - - enum:
> > -- ti,ds90c185 # For the TI DS90C185 FPD-Link Serializer
> > -- ti,ds90c187 # For the TI DS90C187 FPD-Link Serializer
> > -- ti,sn75lvds83 # For the TI SN75LVDS83 FlatLink transmitter
> > - - const: lvds-encoder # Generic LVDS encoder compatible fallback
> > +oneOf:
> > + - items:
> > +- enum:
> > + - ti,ds90c185 # For the TI DS90C185 FPD-Link Serializer
> > + - ti,ds90c187 # For the TI DS90C187 FPD-Link Serializer
> > + - ti,sn75lvds83 # For the TI SN75LVDS83 FlatLink transmitter
> > +- const: lvds-encoder # Generic LVDS encoder compatible fallback
> > + - const: lvds-decoder # Generic LVDS decoders compatible fallback
> >
> >ports:
> > type: object
> > @@ -49,12 +51,14 @@ properties:
> >port@0:
> > type: object
> > description: |
> > - Port 0 is for parallel input
> > + With LVDS encoders port 0 is for parallel input
> > + With LVDS decoders port 0 is for LVDS input
>
> How about
>
> For LVDS encoders, port 0 is the parallel input
> For LVDS decoders, port 0 is the LVDS input
It's ok with me
>
> >
> >port@1:
> > type: object
> > description: |
> > - Port 1 is for LVDS output
> > + With LVDS encoders port 1 is for LVDS output
> > + With LVDS decoders port 1 is for parallel output
>
> And similarly here ?
Here too
>
> If you're fine
RE: [PATCH v4 12/13] [HACK] drm/bridge: lvds-codec: Enforce device specific compatible strings
Hi Laurent,
Thank you for your feedback!
> From: Laurent Pinchart
> Sent: 19 November 2019 00:16
> Subject: Re: [PATCH v4 12/13] [HACK] drm/bridge: lvds-codec: Enforce device
> specific compatible strings
>
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Wed, Nov 13, 2019 at 03:51:31PM +, Fabrizio Castro wrote:
> > The lvds-codec driver is a generic stub for transparent LVDS
> > encoders and decoders.
> > It's good practice to list a device specific compatible string
>
> s/good practice/mandatory/
Will fix
>
> > before the generic fallback (if any) in the DT node for the relevant
> > LVDS encoder/decoder, and it's also required by the dt-bindings.
> > A notable exception to the generic fallback mechanism is the case
> > of "thine,thc63lvdm83d", as documented in:
> > Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt
> > This patch enforces the adoption of a device specific compatible
> > string (as fist string in the list), by using markers for the
>
> s/fist/first/
Well spotted
>
> > compatible string we match against and the index of the matching
> > compatible string in the list.
> >
> > Signed-off-by: Fabrizio Castro
> >
> > ---
> > Hi Laurent,
> >
> > I don't think we need to do anything in the driver to address your
> > comment, as we can "enforce" this with the bindings (please see the
> > next patch, as it would help with the "enforcing" of the compatible
> > string for the thine device).
> > I am sending this patch only so that you can see what a possible
> > solution in the driver could look like.
> >
> > v3->v4:
> > * New patch addressing the below comment from Laurent:
> > "I think the lvds-decoder driver should error out at probe time if only
> > one compatible string is listed."
> > ---
> > drivers/gpu/drm/bridge/lvds-codec.c | 55
> > +
> > 1 file changed, 49 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
> > b/drivers/gpu/drm/bridge/lvds-codec.c
> > index 784bbd3..145c25d 100644
> > --- a/drivers/gpu/drm/bridge/lvds-codec.c
> > +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> > @@ -14,11 +14,16 @@
> > #include
> > #include
> >
> > +struct lvds_codec_data {
> > + u32 connector_type;
> > + bool device_specific;
> > +};
> > +
> > struct lvds_codec {
> > struct drm_bridge bridge;
> > struct drm_bridge *panel_bridge;
> > struct gpio_desc *powerdown_gpio;
> > - u32 connector_type;
> > + const struct lvds_codec_data *data;
> > };
> >
> > static int lvds_codec_attach(struct drm_bridge *bridge)
> > @@ -65,7 +70,30 @@ static int lvds_codec_probe(struct platform_device *pdev)
> > if (!lvds_codec)
> > return -ENOMEM;
> >
> > - lvds_codec->connector_type = (u32)of_device_get_match_data(>dev);
> > + lvds_codec->data = of_device_get_match_data(>dev);
> > + if (!lvds_codec->data)
> > + return -EINVAL;
> > +
> > + /*
> > +* If we haven't matched a device specific compatible string, we need
> > +* to work out if the generic compatible string we matched against was
> > +* listed first in the compatible property.
> > +*/
>
> Can't we do this unconditionally, and thus drop the lvds_codec_data
> structure ?
I don't think so, and the reason for this is that we have a corner case for
thine,thc63lvdm83d. Here is what's allowed (according to the documentation)
from what's supported upstream (+ this series):
"ti,ds90c185", "lvds-encoder"
"ti,ds90c187", "lvds-encoder"
"ti,sn75lvds83", "lvds-encoder"
"ti,ds90cf384a", "lvds-decoder"
"thine,thc63lvdm83d"
As you can see from the examples above, in most cases it's enough to say it's
all good when we match a compatible string with index > 0, but for the thine
device you _have_ to match the string with index 0 as that's what's currently
documented (please see thine,thc63lvdm83d.txt) and that's what's supported
by device trees already (please see arch/arm/boot/dts/r8a7779-marzen.dts).
This patch "classifies" compatible strings, and it considers a good match
device specific compatible strings, or generic compatible strings as long
as they are not listed first.
These days you can leverage the yaml files to validate the device trees,
therefore we should be focusing on writing yaml files in such a way we only
pass the checks we mean to, and by ch
[PATCH v4 08/13] dt-bindings: display: bridge: Repurpose lvds-encoder
In an effort to repurpose lvds-encoder.c to also serve the
function of LVDS decoders, we ended up defining a new "generic"
compatible string ("lvds-decoder"), therefore adapt the dt schema
to allow for the new compatible string.
Signed-off-by: Fabrizio Castro
---
v3->v4:
* Improved title and description according to Laurent's comments
* Reworked definition of the compatible property
v2->v3:
* Extracted conversion to lvds-codec as per Rob's comment
v1->v2:
* Converted to dt-schema as per Neil's comment
---
.../{lvds-transmitter.yaml => lvds-codec.yaml} | 54 +-
1 file changed, 42 insertions(+), 12 deletions(-)
rename Documentation/devicetree/bindings/display/bridge/{lvds-transmitter.yaml
=> lvds-codec.yaml} (61%)
diff --git
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
similarity index 61%
rename from
Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
rename to Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
index 27de616..0ecc8a4 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
@@ -1,17 +1,17 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
-$id: http://devicetree.org/schemas/display/bridge/lvds-transmitter.yaml#
+$id: http://devicetree.org/schemas/display/bridge/lvds-codec.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Parallel to LVDS Encoder
+title: Transparent LVDS encoders and decoders
maintainers:
- Laurent Pinchart
description: |
- This binding supports the parallel to LVDS encoders that don't require any
- configuration.
+ This binding supports transparent LVDS encoders and decoders that don't
+ require any configuration.
LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
Multiple
incompatible data link layers have been used over time to transmit image data
@@ -33,12 +33,14 @@ properties:
description: |
Must list the device specific compatible string first, followed by the
generic compatible string.
-items:
- - enum:
-- ti,ds90c185 # For the TI DS90C185 FPD-Link Serializer
-- ti,ds90c187 # For the TI DS90C187 FPD-Link Serializer
-- ti,sn75lvds83 # For the TI SN75LVDS83 FlatLink transmitter
- - const: lvds-encoder # Generic LVDS encoder compatible fallback
+oneOf:
+ - items:
+- enum:
+ - ti,ds90c185 # For the TI DS90C185 FPD-Link Serializer
+ - ti,ds90c187 # For the TI DS90C187 FPD-Link Serializer
+ - ti,sn75lvds83 # For the TI SN75LVDS83 FlatLink transmitter
+- const: lvds-encoder # Generic LVDS encoder compatible fallback
+ - const: lvds-decoder # Generic LVDS decoders compatible fallback
ports:
type: object
@@ -49,12 +51,14 @@ properties:
port@0:
type: object
description: |
- Port 0 is for parallel input
+ With LVDS encoders port 0 is for parallel input
+ With LVDS decoders port 0 is for LVDS input
port@1:
type: object
description: |
- Port 1 is for LVDS output
+ With LVDS encoders port 1 is for LVDS output
+ With LVDS decoders port 1 is for parallel output
required:
- port@0
@@ -96,4 +100,30 @@ examples:
};
};
+ - |
+lvds-decoder {
+ compatible = "lvds-decoder";
+
+ ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+ reg = <0>;
+
+ lvds_dec_in: endpoint {
+remote-endpoint = <_out_lvds>;
+ };
+};
+
+port@1 {
+ reg = <1>;
+
+ lvds_dec_out: endpoint {
+remote-endpoint = <_panel_in>;
+ };
+};
+ };
+};
+
...
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 10/13] ARM: dts: iwg20d-q7-common: Add LCD support
The iwg20d comes with a 7" capacitive touch screen, therefore
add support for it.
Signed-off-by: Fabrizio Castro
---
v3->v4:
* Reworked compatibility of DT node lvds-receiver
* s/powerdown/powerdown-gpios/g in lvds-receiver
* Reworked compatibility of DT node panel
v2->v3:
* No change
v1->v2:
* No change
---
arch/arm/boot/dts/iwg20d-q7-common.dtsi | 85
arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi | 1 -
2 files changed, 85 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
index ae75a1db..ab5ae93 100644
--- a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
@@ -46,6 +46,49 @@
clock-frequency = <2600>;
};
+ lcd_backlight: backlight {
+ compatible = "pwm-backlight";
+
+ pwms = < 0 500 0>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <7>;
+ enable-gpios = < 14 GPIO_ACTIVE_HIGH>;
+ };
+
+ lvds-receiver {
+ compatible = "ti,ds90cf384a", "lvds-decoder";
+ powerdown-gpios = < 25 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ lvds_receiver_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ lvds_receiver_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+ };
+
+ panel {
+ compatible = "edt,etm0700g0dh6";
+ backlight = <_backlight>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <_receiver_out>;
+ };
+ };
+ };
+
reg_1p5v: 1p5v {
compatible = "regulator-fixed";
regulator-name = "1P5V";
@@ -120,6 +163,18 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
+ {
+ touch-interrupt {
+ gpio-hog;
+ gpios = <12 GPIO_ACTIVE_LOW>;
+ input;
+ };
+};
+
{
status = "okay";
pinctrl-0 = <_pins>;
@@ -147,6 +202,25 @@
VDDIO-supply = <_3p3v>;
VDDD-supply = <_1p5v>;
};
+
+ touch: touchpanel@38 {
+ compatible = "edt,edt-ft5406";
+ reg = <0x38>;
+ interrupt-parent = <>;
+ interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
+ };
+};
+
+ {
+ status = "okay";
+
+ ports {
+ port@1 {
+ lvds0_out: endpoint {
+ remote-endpoint = <_receiver_in>;
+ };
+ };
+ };
};
{
@@ -180,6 +254,11 @@
function = "i2c2";
};
+ pwm3_pins: pwm3 {
+ groups = "pwm3";
+ function = "pwm3";
+ };
+
scif0_pins: scif0 {
groups = "scif0_data_d";
function = "scif0";
@@ -218,6 +297,12 @@
};
};
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
_sound {
pinctrl-0 = <_pins>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
b/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
index 0e99df2..ede2e0c 100644
--- a/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
@@ -39,7 +39,6 @@
{
pinctrl-0 = <_pins>;
pinctrl-names = "default";
- status = "okay";
ports {
port@0 {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 11/13] ARM: shmobile_defconfig: Enable support for panels from EDT
The iwg20d comes with an LCD panel from Emerging Display Technologies Corporation (EDT), therefore enable what's required to support it. Signed-off-by: Fabrizio Castro --- v3->v4: * No change v2->v3: * No change v1->v2: * No change --- arch/arm/configs/shmobile_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig index c6c7035..ab416a5 100644 --- a/arch/arm/configs/shmobile_defconfig +++ b/arch/arm/configs/shmobile_defconfig @@ -66,6 +66,7 @@ CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_GPIO=y # CONFIG_INPUT_MOUSE is not set CONFIG_INPUT_TOUCHSCREEN=y +CONFIG_TOUCHSCREEN_EDT_FT5X06=y CONFIG_TOUCHSCREEN_ST1232=y CONFIG_INPUT_MISC=y CONFIG_INPUT_ADXL34X=y @@ -125,7 +126,9 @@ CONFIG_VIDEO_ADV7604=y CONFIG_VIDEO_ML86V7667=y CONFIG_DRM=y CONFIG_DRM_RCAR_DU=y +CONFIG_DRM_PANEL_SIMPLE=y CONFIG_DRM_DUMB_VGA_DAC=y +CONFIG_DRM_LVDS_CODEC=y CONFIG_DRM_SII902X=y CONFIG_DRM_I2C_ADV7511=y CONFIG_DRM_I2C_ADV7511_AUDIO=y -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 09/13] dt-bindings: display: bridge: lvds-codec: Document ti, ds90cf384a
The DS90CF384A from TI is a transparent LVDS receiver (decoder),
and therefore it is compatible with the lvds-codec driver and
bindings.
Document the ti,ds90cf384a compatible string with the dt-bindings.
No driver change required.
Signed-off-by: Fabrizio Castro
---
v3->v4:
* New patch
---
Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
index 0ecc8a4..21f8c6e 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
@@ -40,7 +40,10 @@ properties:
- ti,ds90c187 # For the TI DS90C187 FPD-Link Serializer
- ti,sn75lvds83 # For the TI SN75LVDS83 FlatLink transmitter
- const: lvds-encoder # Generic LVDS encoder compatible fallback
- - const: lvds-decoder # Generic LVDS decoders compatible fallback
+ - items:
+- enum:
+ - ti,ds90cf384a # For the DS90CF384A FPD-Link LVDS Receiver
+- const: lvds-decoder # Generic LVDS decoders compatible fallback
ports:
type: object
@@ -102,7 +105,7 @@ examples:
- |
lvds-decoder {
- compatible = "lvds-decoder";
+ compatible = "ti,ds90cf384a", "lvds-decoder";
ports {
#address-cells = <1>;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 01/13] dt-bindings: display: bridge: Convert lvds-transmitter binding to json-schema
Convert the lvds-transmitter binding to DT schema format using
json-schema.
Signed-off-by: Fabrizio Castro
---
v3->v4:
* Fixed the description of property "compatible" according to Laurent's
comments
v2->v3:
* Extracted conversion to dt-schema as per Rob's comment
v1->v2:
* Converted to dt-schema as per Neil's comment
---
.../bindings/display/bridge/lvds-transmitter.txt | 66
.../bindings/display/bridge/lvds-transmitter.yaml | 91 ++
2 files changed, 91 insertions(+), 66 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
create mode 100644
Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
deleted file mode 100644
index 60091db..000
--- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
+++ /dev/null
@@ -1,66 +0,0 @@
-Parallel to LVDS Encoder
-
-
-This binding supports the parallel to LVDS encoders that don't require any
-configuration.
-
-LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. Multiple
-incompatible data link layers have been used over time to transmit image data
-to LVDS panels. This binding targets devices compatible with the following
-specifications only.
-
-[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February
-1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA)
-[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
-Semiconductor
-[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video
-Electronics Standards Association (VESA)
-
-Those devices have been marketed under the FPD-Link and FlatLink brand names
-among others.
-
-
-Required properties:
-
-- compatible: Must be "lvds-encoder"
-
- Any encoder compatible with this generic binding, but with additional
- properties not listed here, must list a device specific compatible first
- followed by this generic compatible.
-
-Required nodes:
-
-This device has two video ports. Their connections are modeled using the OF
-graph bindings specified in Documentation/devicetree/bindings/graph.txt.
-
-- Video port 0 for parallel input
-- Video port 1 for LVDS output
-
-
-Example
-
-lvds-encoder {
- compatible = "lvds-encoder";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
-
- lvds_enc_in: endpoint {
- remote-endpoint = <_out_rgb>;
- };
- };
-
- port@1 {
- reg = <1>;
-
- lvds_enc_out: endpoint {
- remote-endpoint = <_panel_in>;
- };
- };
- };
-};
diff --git
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
new file mode 100644
index 000..b5dd0da
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/lvds-transmitter.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Parallel to LVDS Encoder
+
+maintainers:
+ - Laurent Pinchart
+
+description: |
+ This binding supports the parallel to LVDS encoders that don't require any
+ configuration.
+
+ LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
Multiple
+ incompatible data link layers have been used over time to transmit image data
+ to LVDS panels. This binding targets devices compatible with the following
+ specifications only.
+
+ [JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February
+ 1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA)
+ [LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
+ Semiconductor
+ [VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video
+ Electronics Standards Association (VESA)
+
+ Those devices have been marketed under the FPD-Link and FlatLink brand names
+ among others.
+
+properties:
+ compatible:
+description: |
+ Any encoder compatible with this generic binding, but with additional
+ properties not listed here, must define its own binding and list a device
+ specific compatible first followed by the generic compatible.
+enum:
+ - lvds-encoder
+
+ ports:
+type: object
+description: |
+ This device has two video ports. Their connections
[PATCH v4 03/13] dt-bindings: display: bridge: lvds-transmitter: Absorb ti, ds90c185.txt
ti,ds90c185.txt documents LVDS encoders using the same driver
as the one documented by lvds-transmitter.yaml.
Since the properties listed in ti,ds90c185.txt are the same
as the ones listed in lvds-transmitter.yaml, absorb the dt-binding
into lvds-transmitter.yaml.
Signed-off-by: Fabrizio Castro
---
v3->v4:
* New patch
---
.../bindings/display/bridge/lvds-transmitter.yaml | 14 +++---
.../bindings/display/bridge/ti,ds90c185.txt| 55 --
2 files changed, 8 insertions(+), 61 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt
diff --git
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
index 2484737..a8326ce 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
@@ -31,11 +31,13 @@ description: |
properties:
compatible:
description: |
- Any encoder compatible with this generic binding, but with additional
- properties not listed here, must define its own binding and list a device
- specific compatible first followed by the generic compatible.
-enum:
- - lvds-encoder
+ Must list the device specific compatible string first, followed by the
+ generic compatible string.
+items:
+ - enum:
+- ti,ds90c185 # For the TI DS90C185 FPD-Link Serializer
+- ti,ds90c187 # For the TI DS90C187 FPD-Link Serializer
+ - const: lvds-encoder # Generic LVDS encoder compatible fallback
ports:
type: object
@@ -69,7 +71,7 @@ required:
examples:
- |
lvds-encoder {
- compatible = "lvds-encoder";
+ compatible = "ti,ds90c185", "lvds-encoder";
ports {
#address-cells = <1>;
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt
b/Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt
deleted file mode 100644
index e575f99..000
--- a/Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt
+++ /dev/null
@@ -1,55 +0,0 @@
-Texas Instruments FPD-Link (LVDS) Serializer
-
-
-The DS90C185 and DS90C187 are low-power serializers for portable
-battery-powered applications that reduces the size of the RGB
-interface between the host GPU and the display.
-
-Required properties:
-
-- compatible: Should be
- "ti,ds90c185", "lvds-encoder" for the TI DS90C185 FPD-Link Serializer
- "ti,ds90c187", "lvds-encoder" for the TI DS90C187 FPD-Link Serializer
-
-Optional properties:
-
-- powerdown-gpios: Power down control GPIO (the PDB pin, active-low)
-
-Required nodes:
-
-The devices have two video ports. Their connections are modeled using the OF
-graph bindings specified in Documentation/devicetree/bindings/graph.txt.
-
-- Video port 0 for parallel input
-- Video port 1 for LVDS output
-
-
-Example
-
-lvds-encoder {
- compatible = "ti,ds90c185", "lvds-encoder";
-
- powerdown-gpios = < 17 GPIO_ACTIVE_LOW>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
-
- lvds_enc_in: endpoint {
- remote-endpoint = <_out_rgb>;
- };
- };
-
- port@1 {
- reg = <1>;
-
- lvds_enc_out: endpoint {
- remote-endpoint = <_panel_in>;
- };
- };
- };
-};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 13/13] [HACK] dt-bindings: display: bridge: lvds-codec: Absorb thine, thc63lvdm83d.txt
At this point in time, compatible string "thine,thc63lvdm83d" is
backed by the lvds-codec driver, and the documentation contained
in thine,thc63lvdm83d.txt is basically the same as the one
contained in lvds-codec.yaml (generic fallback compatible string
aside), therefore absorb thine,thc63lvdm83d.txt.
Signed-off-by: Fabrizio Castro
---
Hi Laurent,
what do you think about this patch?
Thanks,
Fab
v3->v4:
* New patch
---
.../bindings/display/bridge/lvds-codec.yaml| 5 +--
.../bindings/display/bridge/thine,thc63lvdm83d.txt | 50 --
2 files changed, 2 insertions(+), 53 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
index 21f8c6e..420bfce 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
@@ -30,9 +30,6 @@ description: |
properties:
compatible:
-description: |
- Must list the device specific compatible string first, followed by the
- generic compatible string.
oneOf:
- items:
- enum:
@@ -44,6 +41,8 @@ properties:
- enum:
- ti,ds90cf384a # For the DS90CF384A FPD-Link LVDS Receiver
- const: lvds-decoder # Generic LVDS decoders compatible fallback
+ - enum:
+- thine,thc63lvdm83d # For the THC63LVDM83D LVDS serializer
ports:
type: object
diff --git
a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt
b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt
deleted file mode 100644
index fee3c88..000
--- a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-THine Electronics THC63LVDM83D LVDS serializer
---
-
-The THC63LVDM83D is an LVDS serializer designed to support pixel data
-transmission between a host and a flat panel.
-
-Required properties:
-
-- compatible: Should be "thine,thc63lvdm83d"
-
-Optional properties:
-
-- powerdown-gpios: Power down control GPIO (the /PWDN pin, active low).
-
-Required nodes:
-
-The THC63LVDM83D has two video ports. Their connections are modeled using the
-OFgraph bindings specified in Documentation/devicetree/bindings/graph.txt.
-
-- Video port 0 for CMOS/TTL input
-- Video port 1 for LVDS output
-
-
-Example
-
- lvds_enc: encoder@0 {
- compatible = "thine,thc63lvdm83d";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
-
- lvds_enc_in: endpoint@0 {
- remote-endpoint = <_out>;
- };
- };
-
- port@1 {
- reg = <1>;
-
- lvds_enc_out: endpoint@0 {
- remote-endpoint = <_in>;
- };
- };
- };
- };
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 05/13] drm/bridge: Repurpose lvds-encoder.c
lvds-encoder.c implementation is also suitable for LVDS decoders,
not just LVDS encoders.
Instead of creating a new driver for addressing support for
transparent LVDS decoders, repurpose lvds-encoder.c for the greater
good with this patch.
This patch only "rebrands" the lvds-encoder.c driver, to make it
suitable for hosting LVDS decoders support. The actual support for
LVDS decoders will come with a later patch.
Signed-off-by: Fabrizio Castro
---
v3->v4:
* The patch now only renames the driver (with related data structures
and build options), changes the description of the module, and
refreshes the copyright
v2->v3:
* No change
v1->v2:
* No change
---
drivers/gpu/drm/bridge/Kconfig | 8 +-
drivers/gpu/drm/bridge/Makefile| 2 +-
.../drm/bridge/{lvds-encoder.c => lvds-codec.c}| 97 +++---
3 files changed, 53 insertions(+), 54 deletions(-)
rename drivers/gpu/drm/bridge/{lvds-encoder.c => lvds-codec.c} (45%)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3436297..fbbea46 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -45,14 +45,14 @@ config DRM_DUMB_VGA_DAC
Support for non-programmable RGB to VGA DAC bridges, such as ADI
ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs.
-config DRM_LVDS_ENCODER
- tristate "Transparent parallel to LVDS encoder support"
+config DRM_LVDS_CODEC
+ tristate "Transparent LVDS encoders and decoders support"
depends on OF
select DRM_KMS_HELPER
select DRM_PANEL_BRIDGE
help
- Support for transparent parallel to LVDS encoders that don't require
- any configuration.
+ Support for transparent LVDS encoders and decoders that don't
+ require any configuration.
config DRM_MEGACHIPS_STDP_GE_B850V3_FW
tristate "MegaChips stdp4028-ge-b850v3-fw and stdp2690-ge-b850v3-fw"
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 4934fcf..8a9178a 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,7 +2,7 @@
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
-obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
+obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c
b/drivers/gpu/drm/bridge/lvds-codec.c
similarity index 45%
rename from drivers/gpu/drm/bridge/lvds-encoder.c
rename to drivers/gpu/drm/bridge/lvds-codec.c
index e2132a8..b5801a2 100644
--- a/drivers/gpu/drm/bridge/lvds-encoder.c
+++ b/drivers/gpu/drm/bridge/lvds-codec.c
@@ -1,5 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
+ * Copyright (C) 2019 Renesas Electronics Corporation
* Copyright (C) 2016 Laurent Pinchart
*/
@@ -12,65 +13,62 @@
#include
#include
-struct lvds_encoder {
+struct lvds_codec {
struct drm_bridge bridge;
struct drm_bridge *panel_bridge;
struct gpio_desc *powerdown_gpio;
};
-static int lvds_encoder_attach(struct drm_bridge *bridge)
+static int lvds_codec_attach(struct drm_bridge *bridge)
{
- struct lvds_encoder *lvds_encoder = container_of(bridge,
-struct lvds_encoder,
-bridge);
+ struct lvds_codec *lvds_codec = container_of(bridge,
+struct lvds_codec, bridge);
- return drm_bridge_attach(bridge->encoder, lvds_encoder->panel_bridge,
+ return drm_bridge_attach(bridge->encoder, lvds_codec->panel_bridge,
bridge);
}
-static void lvds_encoder_enable(struct drm_bridge *bridge)
+static void lvds_codec_enable(struct drm_bridge *bridge)
{
- struct lvds_encoder *lvds_encoder = container_of(bridge,
-struct lvds_encoder,
-bridge);
+ struct lvds_codec *lvds_codec = container_of(bridge,
+struct lvds_codec, bridge);
- if (lvds_encoder->powerdown_gpio)
- gpiod_set_value_cansleep(lvds_encoder->powerdown_gpio, 0);
+ if (lvds_codec->powerdown_gpio)
+ gpiod_set_value_cansleep(lvds_codec->powerdown_gpio, 0);
}
-static void lvds_encoder_disable(struct drm_bridge *bridge)
+static void lvds_codec_disable(struct drm_bridge *bridge)
{
- struct lvds_encoder *lvds_encoder = container_of(bridg
[PATCH v4 12/13] [HACK] drm/bridge: lvds-codec: Enforce device specific compatible strings
The lvds-codec driver is a generic stub for transparent LVDS
encoders and decoders.
It's good practice to list a device specific compatible string
before the generic fallback (if any) in the DT node for the relevant
LVDS encoder/decoder, and it's also required by the dt-bindings.
A notable exception to the generic fallback mechanism is the case
of "thine,thc63lvdm83d", as documented in:
Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt
This patch enforces the adoption of a device specific compatible
string (as fist string in the list), by using markers for the
compatible string we match against and the index of the matching
compatible string in the list.
Signed-off-by: Fabrizio Castro
---
Hi Laurent,
I don't think we need to do anything in the driver to address your
comment, as we can "enforce" this with the bindings (please see the
next patch, as it would help with the "enforcing" of the compatible
string for the thine device).
I am sending this patch only so that you can see what a possible
solution in the driver could look like.
v3->v4:
* New patch addressing the below comment from Laurent:
"I think the lvds-decoder driver should error out at probe time if only
one compatible string is listed."
---
drivers/gpu/drm/bridge/lvds-codec.c | 55 +
1 file changed, 49 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
b/drivers/gpu/drm/bridge/lvds-codec.c
index 784bbd3..145c25d 100644
--- a/drivers/gpu/drm/bridge/lvds-codec.c
+++ b/drivers/gpu/drm/bridge/lvds-codec.c
@@ -14,11 +14,16 @@
#include
#include
+struct lvds_codec_data {
+ u32 connector_type;
+ bool device_specific;
+};
+
struct lvds_codec {
struct drm_bridge bridge;
struct drm_bridge *panel_bridge;
struct gpio_desc *powerdown_gpio;
- u32 connector_type;
+ const struct lvds_codec_data *data;
};
static int lvds_codec_attach(struct drm_bridge *bridge)
@@ -65,7 +70,30 @@ static int lvds_codec_probe(struct platform_device *pdev)
if (!lvds_codec)
return -ENOMEM;
- lvds_codec->connector_type = (u32)of_device_get_match_data(>dev);
+ lvds_codec->data = of_device_get_match_data(>dev);
+ if (!lvds_codec->data)
+ return -EINVAL;
+
+ /*
+* If we haven't matched a device specific compatible string, we need
+* to work out if the generic compatible string we matched against was
+* listed first in the compatible property.
+*/
+ if (!lvds_codec->data->device_specific) {
+ const struct of_device_id *match;
+ int compatible_index;
+
+ match = of_match_node(dev->driver->of_match_table,
+ dev->of_node);
+ compatible_index = of_property_match_string(dev->of_node,
+ "compatible",
+ match->compatible);
+ if (compatible_index == 0) {
+ dev_err(dev, "Device specific compatible needed\n");
+ return -EINVAL;
+ }
+ }
+
lvds_codec->powerdown_gpio = devm_gpiod_get_optional(dev, "powerdown",
GPIOD_OUT_HIGH);
if (IS_ERR(lvds_codec->powerdown_gpio)) {
@@ -92,7 +120,7 @@ static int lvds_codec_probe(struct platform_device *pdev)
lvds_codec->panel_bridge =
devm_drm_panel_bridge_add_typed(dev, panel,
- lvds_codec->connector_type);
+ lvds_codec->data->connector_type);
if (IS_ERR(lvds_codec->panel_bridge))
return PTR_ERR(lvds_codec->panel_bridge);
@@ -119,18 +147,33 @@ static int lvds_codec_remove(struct platform_device *pdev)
return 0;
}
+static const struct lvds_codec_data lvds_codec_decoder_data = {
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+ .device_specific = false,
+};
+
+static const struct lvds_codec_data lvds_codec_encoder_data = {
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+ .device_specific = false,
+};
+
+static const struct lvds_codec_data lvds_codec_thc63lvdm83d_data = {
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+ .device_specific = true,
+};
+
static const struct of_device_id lvds_codec_match[] = {
{
.compatible = "lvds-decoder",
- .data = (void *)DRM_MODE_CONNECTOR_DPI,
+ .data = _codec_decoder_data,
},
{
.compatible = "lvds-encoder",
- .data = (void *)DRM_MODE_CONNECTOR_LVDS,
+ .data = _codec_encoder_data
[PATCH v4 06/13] drm/bridge: lvds-codec: Add "lvds-decoder" support
Add support for transparent LVDS decoders by adding a new
compatible string ("lvds-decoder") to the driver.
This patch also adds member connector_type to struct lvds_codec,
and that's because LVDS decoders have a different connector type
from LVDS encoders. We fill this new member up with the data
matching the compatible string.
Signed-off-by: Fabrizio Castro
---
v3->v4:
* New patch
---
drivers/gpu/drm/bridge/lvds-codec.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
b/drivers/gpu/drm/bridge/lvds-codec.c
index b5801a2..c32e125 100644
--- a/drivers/gpu/drm/bridge/lvds-codec.c
+++ b/drivers/gpu/drm/bridge/lvds-codec.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
@@ -17,6 +18,7 @@ struct lvds_codec {
struct drm_bridge bridge;
struct drm_bridge *panel_bridge;
struct gpio_desc *powerdown_gpio;
+ u32 connector_type;
};
static int lvds_codec_attach(struct drm_bridge *bridge)
@@ -65,6 +67,7 @@ static int lvds_codec_probe(struct platform_device *pdev)
if (!lvds_codec)
return -ENOMEM;
+ lvds_codec->connector_type = (u32)of_device_get_match_data(>dev);
lvds_codec->powerdown_gpio = devm_gpiod_get_optional(dev, "powerdown",
GPIOD_OUT_HIGH);
if (IS_ERR(lvds_codec->powerdown_gpio)) {
@@ -105,7 +108,7 @@ static int lvds_codec_probe(struct platform_device *pdev)
lvds_codec->panel_bridge =
devm_drm_panel_bridge_add_typed(dev, panel,
- DRM_MODE_CONNECTOR_LVDS);
+ lvds_codec->connector_type);
if (IS_ERR(lvds_codec->panel_bridge))
return PTR_ERR(lvds_codec->panel_bridge);
@@ -133,8 +136,18 @@ static int lvds_codec_remove(struct platform_device *pdev)
}
static const struct of_device_id lvds_codec_match[] = {
- { .compatible = "lvds-encoder" },
- { .compatible = "thine,thc63lvdm83d" },
+ {
+ .compatible = "lvds-decoder",
+ .data = (void *)DRM_MODE_CONNECTOR_DPI,
+ },
+ {
+ .compatible = "lvds-encoder",
+ .data = (void *)DRM_MODE_CONNECTOR_LVDS,
+ },
+ {
+ .compatible = "thine,thc63lvdm83d",
+ .data = (void *)DRM_MODE_CONNECTOR_LVDS,
+ },
{},
};
MODULE_DEVICE_TABLE(of, lvds_codec_match);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 02/13] dt-bindings: display: bridge: lvds-transmitter: Document powerdown-gpios
Add documentation for property powerdown-gpios. The property is optional. Signed-off-by: Fabrizio Castro --- v3->v4: * New patch --- .../devicetree/bindings/display/bridge/lvds-transmitter.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml index b5dd0da..2484737 100644 --- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml +++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml @@ -57,6 +57,11 @@ properties: - port@0 - port@1 + powerdown-gpios: +description: + The GPIO used to control the power down line of this device. +maxItems: 1 + required: - compatible - ports -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 04/13] dt-bindings: display: bridge: lvds-transmitter: Document "ti, sn75lvds83"
Compatible string "ti,sn75lvds83" is being used by device tree rk3188-bqedison2qc.dts, but it's not documented anywhere, therefore document it within lvds-transmitter.yaml. Signed-off-by: Fabrizio Castro --- v3->v4: * New patch --- Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml index a8326ce..27de616 100644 --- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml +++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml @@ -37,6 +37,7 @@ properties: - enum: - ti,ds90c185 # For the TI DS90C185 FPD-Link Serializer - ti,ds90c187 # For the TI DS90C187 FPD-Link Serializer +- ti,sn75lvds83 # For the TI SN75LVDS83 FlatLink transmitter - const: lvds-encoder # Generic LVDS encoder compatible fallback ports: -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 00/13] Add LCD panel support to iwg20d
The iW-RainboW-G20D-Qseven RZ/G1M,G1N Qseven Development Platform
comes with a 7" capacitive display kit from Emerging Display
Technologies Corporation (EDT). This series adds all that's
necessary for supporting it.
Thanks,
Fab
v3->v4:
* Reworked according to Laurent's and Jacopo's comments
v2->v3:
* Split the dt-schema patch in two patches as per Rob's comment
* Made fixes to the dt-schema according to Rob's comment
* Made fixes to the lvds-codec driver according to Jacopo's comments
* Added two new patches:
* drm: Define DRM_MODE_CONNECTOR_PARALLEL
* drm/panel: panel-simple: Add connector type for etm0700g0dh6
v1->v2:
* Convert dt-bindings to dt-schema
Fabrizio Castro (13):
dt-bindings: display: bridge: Convert lvds-transmitter binding to
json-schema
dt-bindings: display: bridge: lvds-transmitter: Document
powerdown-gpios
dt-bindings: display: bridge: lvds-transmitter: Absorb ti,ds90c185.txt
dt-bindings: display: bridge: lvds-transmitter: Document
"ti,sn75lvds83"
drm/bridge: Repurpose lvds-encoder.c
drm/bridge: lvds-codec: Add "lvds-decoder" support
drm/bridge: lvds-codec: Simplify panel DT node localisation
dt-bindings: display: bridge: Repurpose lvds-encoder
dt-bindings: display: bridge: lvds-codec: Document ti,ds90cf384a
ARM: dts: iwg20d-q7-common: Add LCD support
ARM: shmobile_defconfig: Enable support for panels from EDT
[HACK] drm/bridge: lvds-codec: Enforce device specific compatible
strings
[HACK] dt-bindings: display: bridge: lvds-codec: Absorb
thine,thc63lvdm83d.txt
.../bindings/display/bridge/lvds-codec.yaml| 131 +++
.../bindings/display/bridge/lvds-transmitter.txt | 66
.../bindings/display/bridge/thine,thc63lvdm83d.txt | 50 --
.../bindings/display/bridge/ti,ds90c185.txt| 55 ---
arch/arm/boot/dts/iwg20d-q7-common.dtsi| 85 ++
arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi | 1 -
arch/arm/configs/shmobile_defconfig| 3 +
drivers/gpu/drm/bridge/Kconfig | 8 +-
drivers/gpu/drm/bridge/Makefile| 2 +-
.../drm/bridge/{lvds-encoder.c => lvds-codec.c}| 179 +
10 files changed, 333 insertions(+), 247 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
delete mode 100644
Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
delete mode 100644
Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt
delete mode 100644
Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt
rename drivers/gpu/drm/bridge/{lvds-encoder.c => lvds-codec.c} (25%)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 07/13] drm/bridge: lvds-codec: Simplify panel DT node localisation
The probe function needs to get ahold of the panel device tree
node, and it achieves that by using a combination of
of_graph_get_port_by_id, of_get_child_by_name, and
of_graph_get_remote_port_parent. We can achieve the same goal
by replacing those calls with a call to of_graph_get_remote_node
these days.
Signed-off-by: Fabrizio Castro
---
v3->v4:
* New patch
---
drivers/gpu/drm/bridge/lvds-codec.c | 20 ++--
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
b/drivers/gpu/drm/bridge/lvds-codec.c
index c32e125..784bbd3 100644
--- a/drivers/gpu/drm/bridge/lvds-codec.c
+++ b/drivers/gpu/drm/bridge/lvds-codec.c
@@ -57,8 +57,6 @@ static struct drm_bridge_funcs funcs = {
static int lvds_codec_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
- struct device_node *port;
- struct device_node *endpoint;
struct device_node *panel_node;
struct drm_panel *panel;
struct lvds_codec *lvds_codec;
@@ -79,23 +77,9 @@ static int lvds_codec_probe(struct platform_device *pdev)
}
/* Locate the panel DT node. */
- port = of_graph_get_port_by_id(dev->of_node, 1);
- if (!port) {
- dev_dbg(dev, "port 1 not found\n");
- return -ENXIO;
- }
-
- endpoint = of_get_child_by_name(port, "endpoint");
- of_node_put(port);
- if (!endpoint) {
- dev_dbg(dev, "no endpoint for port 1\n");
- return -ENXIO;
- }
-
- panel_node = of_graph_get_remote_port_parent(endpoint);
- of_node_put(endpoint);
+ panel_node = of_graph_get_remote_node(dev->of_node, 1, 0);
if (!panel_node) {
- dev_dbg(dev, "no remote endpoint for port 1\n");
+ dev_dbg(dev, "panel DT node not found\n");
return -ENXIO;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v3 6/7] ARM: dts: iwg20d-q7-common: Add LCD support
Hi Laurent,
Thank you for your feedback!
> From: linux-renesas-soc-ow...@vger.kernel.org
> On Behalf Of Laurent Pinchart
> Sent: 07 November 2019 20:55
> Subject: Re: [PATCH v3 6/7] ARM: dts: iwg20d-q7-common: Add LCD support
>
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Thu, Nov 07, 2019 at 08:11:02PM +, Fabrizio Castro wrote:
> > The iwg20d comes with a 7" capacitive touch screen, therefore
> > add support for it.
> >
> > Signed-off-by: Fabrizio Castro
> >
> > ---
> > v2->v3:
> > * No change
> > v1->v2:
> > * No change
> > ---
> > arch/arm/boot/dts/iwg20d-q7-common.dtsi | 85
> >
> > arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi | 1 -
> > 2 files changed, 85 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
> > b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
> > index ae75a1db..3428b8d 100644
> > --- a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
> > +++ b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
> > @@ -46,6 +46,49 @@
> > clock-frequency = <2600>;
> > };
> >
> > + lcd_backlight: backlight {
> > + compatible = "pwm-backlight";
> > +
> > + pwms = < 0 500 0>;
> > + brightness-levels = <0 4 8 16 32 64 128 255>;
> > + default-brightness-level = <7>;
> > + enable-gpios = < 14 GPIO_ACTIVE_HIGH>;
> > + };
> > +
> > + lvds-receiver {
> > + compatible = "lvds-decoder";
>
> A specific compatible string is required.
Will document the specific compatible in the binding doc
>
> I think the lvds-decoder driver should error out at probe time if only
> one compatible string is listed.
Ok, will modify the driver accordingly
>
> > + powerdown = < 25 GPIO_ACTIVE_LOW>;
>
> powerdown-gpios ?
That's a bug, well spotted.
>
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > + lvds_receiver_in: endpoint {
> > + remote-endpoint = <_out>;
> > + };
> > + };
> > + port@1 {
> > + reg = <1>;
> > + lvds_receiver_out: endpoint {
> > + remote-endpoint = <_in>;
> > + };
> > + };
> > + };
> > + };
> > +
> > + panel {
> > + compatible = "edt,etm0700g0dh6", "simple-panel";
>
> There's no "simple-panel" compatible string defined anywhere as far as I
> can tell.
The usage of "simple-panel" as a compatible is widespread and really confusing.
The fact that you made this comment is good enough for me to say we don't
need it, I'll take it out.
>
> > + backlight = <_backlight>;
> > +
> > + port {
> > + panel_in: endpoint {
> > + remote-endpoint = <_receiver_out>;
> > + };
> > + };
> > + };
> > +
> > reg_1p5v: 1p5v {
> > compatible = "regulator-fixed";
> > regulator-name = "1P5V";
> > @@ -120,6 +163,18 @@
> > status = "okay";
> > };
> >
> > + {
> > + status = "okay";
> > +};
> > +
> > + {
> > + touch-interrupt {
> > + gpio-hog;
> > + gpios = <12 GPIO_ACTIVE_LOW>;
> > + input;
> > + };
>
> Do you need this, with the touchpanel@38 node already listing the
> interrupt ?
Yes, unfortunately we do need this as the bootloader is poking with the gpio.
I can't fix this in the bootloader as we have no control over it.
Thanks,
Fab
>
> > +};
> > +
> > {
> > status = "okay";
> > pinctrl-0 = <_pins>;
> > @@ -147,6 +202,25 @@
> > VDDIO-supply = <_3p3v>;
> > VDDD-supply = <_1p5v>;
> > };
> > +
> > + touch: touchpanel@38 {
> > + compatible = "edt,edt-ft5406";
> > + reg = <0x38>;
> > + interrupt-parent = <>
RE: [PATCH v3 1/7] dt-bindings: display: bridge: Convert lvds-transmitter binding to json-schema
Hello Laurent,
Thank you for your feedback!
> From: linux-renesas-soc-ow...@vger.kernel.org
> On Behalf Of Laurent Pinchart
> Sent: 07 November 2019 20:21
> Subject: Re: [PATCH v3 1/7] dt-bindings: display: bridge: Convert
> lvds-transmitter binding to json-schema
>
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Thu, Nov 07, 2019 at 08:10:57PM +, Fabrizio Castro wrote:
> > Convert the lvds-transmitter binding to DT schema format using
> > json-schema.
> >
> > Signed-off-by: Fabrizio Castro
> >
> > ---
> > v2->v3:
> > * Extracted conversion to dt-schema as per Rob's comment
> > v1->v2:
> > * Converted to dt-schema as per Neil's comment
> > ---
> > .../bindings/display/bridge/lvds-transmitter.txt | 66
> > .../bindings/display/bridge/lvds-transmitter.yaml | 91
> > ++
> > 2 files changed, 91 insertions(+), 66 deletions(-)
> > delete mode 100644
> > Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
> b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
> > deleted file mode 100644
> > index 60091db..000
> > --- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
> > +++ /dev/null
> > @@ -1,66 +0,0 @@
> > -Parallel to LVDS Encoder
> > -
> > -
> > -This binding supports the parallel to LVDS encoders that don't require any
> > -configuration.
> > -
> > -LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
> > Multiple
> > -incompatible data link layers have been used over time to transmit image
> > data
> > -to LVDS panels. This binding targets devices compatible with the following
> > -specifications only.
> > -
> > -[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February
> > -1999 (Version 1.0), Japan Electronic Industry Development Association
> > (JEIDA)
> > -[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
> > -Semiconductor
> > -[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video
> > -Electronics Standards Association (VESA)
> > -
> > -Those devices have been marketed under the FPD-Link and FlatLink brand
> > names
> > -among others.
> > -
> > -
> > -Required properties:
> > -
> > -- compatible: Must be "lvds-encoder"
> > -
> > - Any encoder compatible with this generic binding, but with additional
> > - properties not listed here, must list a device specific compatible first
> > - followed by this generic compatible.
> > -
> > -Required nodes:
> > -
> > -This device has two video ports. Their connections are modeled using the OF
> > -graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> > -
> > -- Video port 0 for parallel input
> > -- Video port 1 for LVDS output
> > -
> > -
> > -Example
> >
> > -
> > -lvds-encoder {
> > - compatible = "lvds-encoder";
> > -
> > - ports {
> > - #address-cells = <1>;
> > - #size-cells = <0>;
> > -
> > - port@0 {
> > - reg = <0>;
> > -
> > - lvds_enc_in: endpoint {
> > - remote-endpoint = <_out_rgb>;
> > - };
> > - };
> > -
> > - port@1 {
> > - reg = <1>;
> > -
> > - lvds_enc_out: endpoint {
> > - remote-endpoint = <_panel_in>;
> > - };
> > - };
> > - };
> > -};
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
> b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
> > new file mode 100644
> > index 000..5be163a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
> > @@ -0,0 +1,91 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/bridge/lvds-transmitter.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +titl
RE: [PATCH v3 5/7] drm/panel: panel-simple: Add connector type for etm0700g0dh6
Hi Laurent,
Thank you for your feedback!
> From: linux-renesas-soc-ow...@vger.kernel.org
> On Behalf Of Laurent Pinchart
> Sent: 07 November 2019 20:49
> Subject: Re: [PATCH v3 5/7] drm/panel: panel-simple: Add connector type for
> etm0700g0dh6
>
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Thu, Nov 07, 2019 at 08:11:01PM +, Fabrizio Castro wrote:
> > Add connector type for the etm0700g0dh6 from Emerging Display
> > Technologies (EDT).
> >
> > Signed-off-by: Fabrizio Castro
> >
> > ---
> > v2->v3:
> > * New patch
> > ---
> > drivers/gpu/drm/panel/panel-simple.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > b/drivers/gpu/drm/panel/panel-simple.c
> > index 5d48768..82065ff 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -1342,6 +1342,7 @@ static const struct panel_desc edt_etm0700g0dh6 = {
> > },
> > .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> > .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
> > + .connector_type = DRM_MODE_CONNECTOR_PARALLEL,
>
> I still think we should have a DRM_MODE_CONNECTOR_PANEL, but regardless,
> this panel seems to match DRM_MODE_CONNECTOR_DPI.
Thank you! I wasn't really sure about which definition to pick,
DRM_MODE_CONNECTOR_DPI
will surely work just fine.
Thanks,
Fab
>
> > };
> >
> > static const struct panel_desc edt_etm0700g0bdh6 = {
>
> --
> Regards,
>
> Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v3 4/7] drm: Define DRM_MODE_CONNECTOR_PARALLEL
Hi Laurent,
Thank you for your feedback!
> From: devicetree-ow...@vger.kernel.org On
> Behalf Of Laurent Pinchart
> Sent: 07 November 2019 20:47
> Subject: Re: [PATCH v3 4/7] drm: Define DRM_MODE_CONNECTOR_PARALLEL
>
> Hi Fabrizio,
>
> (CC'ing Sam)
>
> Thank you for the patch.
>
> On Thu, Nov 07, 2019 at 08:11:00PM +, Fabrizio Castro wrote:
> > The existing DRM_MODE_CONNECTOR_ definitions don't seem to
> > describe the connector for RGB/Parallel embedded displays,
> > hence add DRM_MODE_CONNECTOR_PARALLEL.
>
> Please, no. We already have too many connector types for panels, when
> userspace should really not care. DRM_MODE_CONNECTOR_LVDS,
> DRM_MODE_CONNECTOR_eDP, DRM_MODE_CONNECTOR_DSI, DRM_MODE_CONNECTOR_DPI
> and probably DRM_MODE_CONNECTOR_SPI should have been
> DRM_MODE_CONNECTOR_PANEL.
>
> This has been discussed in [1]. Let's instead define a
> DRM_MODE_CONNECTOR_PANEL, possibly as an alias to one of the existing
> types, and deprecate the other types.
>
> [1] https://www.spinics.net/lists/dri-devel/msg224638.html
Thank you for the pointer and the for the details. That clarifies things a lot.
In my case, as you mentioned in the patch to simple panel, I can use an
existing definition, therefore I think it's best if DRM_MODE_CONNECTOR_PANEL
gets added when there is a valid use case.
Thanks,
Fab
>
> > Signed-off-by: Fabrizio Castro
> >
> > ---
> > v2->v3:
> > * New patch
> > ---
> > drivers/gpu/drm/drm_connector.c | 1 +
> > include/uapi/drm/drm_mode.h | 1 +
> > 2 files changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c
> > index 2166000..b233029 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -93,6 +93,7 @@ static struct drm_conn_prop_enum_list
> > drm_connector_enum_list[] = {
> > { DRM_MODE_CONNECTOR_DPI, "DPI" },
> > { DRM_MODE_CONNECTOR_WRITEBACK, "Writeback" },
> > { DRM_MODE_CONNECTOR_SPI, "SPI" },
> > + { DRM_MODE_CONNECTOR_PARALLEL, "Parallel" },
> > };
> >
> > void drm_connector_ida_init(void)
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index 735c8cf..5852f47 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -362,6 +362,7 @@ enum drm_mode_subconnector {
> > #define DRM_MODE_CONNECTOR_DPI 17
> > #define DRM_MODE_CONNECTOR_WRITEBACK 18
> > #define DRM_MODE_CONNECTOR_SPI 19
> > +#define DRM_MODE_CONNECTOR_PARALLEL20
> >
> > struct drm_mode_get_connector {
> >
>
> --
> Regards,
>
> Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 1/4] drm/bridge: Repurpose lvds-encoder.c
Hi Geert,
Thank you for your feedback!
> From: Geert Uytterhoeven
> Sent: 08 November 2019 09:21
> Subject: Re: [PATCH 1/4] drm/bridge: Repurpose lvds-encoder.c
>
> Hi Fabrizio,
>
> On Mon, Nov 4, 2019 at 11:42 AM Fabrizio Castro
> wrote:
> > > From: Neil Armstrong
> > > Sent: 04 November 2019 09:18
> > > Subject: Re: [PATCH 1/4] drm/bridge: Repurpose lvds-encoder.c
> > >
> > > On 30/10/2019 14:43, Fabrizio Castro wrote:
> > > > lvds-encoder.c implementation is also suitable for LVDS decoders,
> > > > not just LVDS encoders.
> > > > Instead of creating a new driver for addressing support for
> > > > transparent LVDS decoders, repurpose lvds-encoder.c for the greater
> > > > good.
> > > >
> > > > Signed-off-by: Fabrizio Castro
> > > > ---
> > > > drivers/gpu/drm/bridge/Kconfig| 8 +-
> > > > drivers/gpu/drm/bridge/Makefile | 2 +-
> > > > drivers/gpu/drm/bridge/lvds-codec.c | 169
> > > > ++
> > > > drivers/gpu/drm/bridge/lvds-encoder.c | 155
> > > > ---
> > > > 4 files changed, 174 insertions(+), 160 deletions(-)
> > > > create mode 100644 drivers/gpu/drm/bridge/lvds-codec.c
> > > > delete mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c
> > > >
> > > > diff --git a/drivers/gpu/drm/bridge/Kconfig
> > > > b/drivers/gpu/drm/bridge/Kconfig
> > > > index 3436297..9e75ca4e 100644
> > > > --- a/drivers/gpu/drm/bridge/Kconfig
> > > > +++ b/drivers/gpu/drm/bridge/Kconfig
> > > > @@ -45,14 +45,14 @@ config DRM_DUMB_VGA_DAC
> > > > Support for non-programmable RGB to VGA DAC bridges, such as ADI
> > > > ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs.
> > > >
> > > > -config DRM_LVDS_ENCODER
> > > > - tristate "Transparent parallel to LVDS encoder support"
> > > > +config DRM_LVDS_CODEC
> > >
> > >
> > > I'm not CCed on other patches, but I'm pretty sure you should fix other
> > > Kconfig and defconfigs selecting this config in this patch to avoid
> > > breaking bisect.
> >
> > My understanding is that no defconfig and no other option refer directly to
> > DRM_LVDS_ENCODER, do you mind being a little bit
> more specific here?
>
> Sidenote: it looks like CONFIG_DRM_LVDS_ENCODER should have been enabled
> in shmobile_defconfig since commits 381ddfe478871588 ("drm: rcar-du:
> Hardcode encoders types to DRM_MODE_ENCODER_NONE") and 7160d57b6f81185c
> ("drm: bridge: lvds-encoder: Add thine,thc63lvdm83d compatible string"),
> to support thine,thc63lvdm83d in arch/arm/boot/dts/r8a7779-marzen.dts?
Interesting, well the defconfig patch from this series should help then.
Thanks,
Fab
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v3 3/7] dt-bindings: display: bridge: Repurpose lvds-encoder
Hello Laurent, Thank you for your feedback! > From: linux-renesas-soc-ow...@vger.kernel.org > On Behalf Of Laurent Pinchart > Sent: 07 November 2019 20:38 > Subject: Re: [PATCH v3 3/7] dt-bindings: display: bridge: Repurpose > lvds-encoder > > Hi Fabrizio, > > Thank you for the patch. > > On Thu, Nov 07, 2019 at 08:10:59PM +, Fabrizio Castro wrote: > > In an effort to repurpose lvds-encoder.c to also serve the > > function of LVDS decoders, we ended up defining a new "generic" > > compatible string, therefore adapt the dt-bindings to fit the > > new purpose. > > > > Signed-off-by: Fabrizio Castro > > > > --- > > v2->v3: > > * Extracted conversion to lvds-codec as per Rob's comment > > v1->v2: > > * Converted to dt-schema as per Neil's comment > > --- > > .../bindings/display/bridge/lvds-codec.yaml| 120 > > + > > .../bindings/display/bridge/lvds-transmitter.yaml | 91 > > -M1 would also help a lot here. Will do > > > 2 files changed, 120 insertions(+), 91 deletions(-) > > create mode 100644 > > Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > > delete mode 100644 > > Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml > > > > diff --git > > a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > > new file mode 100644 > > index 000..3ebdf96 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > > @@ -0,0 +1,120 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/display/bridge/lvds-codec.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Transparent LVDS encoders and LVDS decoders > > s/LVDS decoders/decoders/ ? Will replace > > > + > > +maintainers: > > + - Laurent Pinchart > > + > > +description: | > > + This binding supports transparent LVDS encoders and LVDS decoders that > > don't > > Same here. Will do Thanks, Fab > > Reviewed-by: Laurent Pinchart > > > + require any configuration. > > + > > + LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. > > Multiple > > + incompatible data link layers have been used over time to transmit image > > data > > + to LVDS panels. This binding targets devices compatible with the > > following > > + specifications only. > > + > > + [JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, > > February > > + 1999 (Version 1.0), Japan Electronic Industry Development Association > > (JEIDA) > > + [LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National > > + Semiconductor > > + [VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video > > + Electronics Standards Association (VESA) > > + > > + Those devices have been marketed under the FPD-Link and FlatLink brand > > names > > + among others. > > + > > +properties: > > + compatible: > > +description: | > > + Any encoder or decoder compatible with this generic binding, but with > > + additional properties not listed here, must define its own binding > > and > > + list a device specific compatible first followed by the generic > > compatible > > +enum: > > + - lvds-encoder # for LVDS encoders > > + - lvds-decoder # for LVDS decoders > > + > > + ports: > > +type: object > > +description: | > > + This device has two video ports. Their connections are modeled using > > the > > + OF graph bindings specified in > > Documentation/devicetree/bindings/graph.txt > > +properties: > > + port@0: > > +type: object > > +description: | > > + With LVDS encoders port 0 is for parallel input > > + With LVDS decoders port 0 is for LVDS input > > + > > + port@1: > > +type: object > > +description: | > > + With LVDS encoders port 1 is for LVDS output > > + With LVDS decoders port 1 is for parallel output > > + > > +required: > > + - port@0 > > + - port@1 > > + > > +required: > > + - compatible > > + - ports > > + > > +examples: > > + - |
RE: [PATCH v3 2/7] drm/bridge: Repurpose lvds-encoder.c
Hello Laurent,
Thank you for your feedback!
> From: devicetree-ow...@vger.kernel.org On
> Behalf Of Laurent Pinchart
> Sent: 07 November 2019 20:35
> Subject: Re: [PATCH v3 2/7] drm/bridge: Repurpose lvds-encoder.c
>
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Thu, Nov 07, 2019 at 08:10:58PM +, Fabrizio Castro wrote:
> > lvds-encoder.c implementation is also suitable for LVDS decoders,
> > not just LVDS encoders.
> > Instead of creating a new driver for addressing support for
> > transparent LVDS decoders, repurpose lvds-encoder.c for the greater
> > good.
> >
> > Signed-off-by: Fabrizio Castro
> >
> > ---
> > v2->v3:
> > * No change
> > v1->v2:
> > * No change
> > ---
> > drivers/gpu/drm/bridge/Kconfig| 8 +-
> > drivers/gpu/drm/bridge/Makefile | 2 +-
> > drivers/gpu/drm/bridge/lvds-codec.c | 131
> > drivers/gpu/drm/bridge/lvds-encoder.c | 155
> > --
> > 4 files changed, 136 insertions(+), 160 deletions(-)
>
> It would help if you added the -M1 option to git-format-patch to detect
> the rename, the result would be easier to review.
Will do, thank you for the hint
>
> > create mode 100644 drivers/gpu/drm/bridge/lvds-codec.c
> > delete mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c
> >
> > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> > index 3436297..9e75ca4e 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -45,14 +45,14 @@ config DRM_DUMB_VGA_DAC
> > Support for non-programmable RGB to VGA DAC bridges, such as ADI
> > ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs.
> >
> > -config DRM_LVDS_ENCODER
> > - tristate "Transparent parallel to LVDS encoder support"
> > +config DRM_LVDS_CODEC
> > + tristate "Transparent LVDS encoders and decoders support"
> > depends on OF
> > select DRM_KMS_HELPER
> > select DRM_PANEL_BRIDGE
> > help
> > - Support for transparent parallel to LVDS encoders that don't require
> > - any configuration.
> > + Support for transparent LVDS encoders and LVDS decoders that don't
> > + require any configuration.
> >
> > config DRM_MEGACHIPS_STDP_GE_B850V3_FW
> > tristate "MegaChips stdp4028-ge-b850v3-fw and stdp2690-ge-b850v3-fw"
> > diff --git a/drivers/gpu/drm/bridge/Makefile
> > b/drivers/gpu/drm/bridge/Makefile
> > index 4934fcf..8a9178a 100644
> > --- a/drivers/gpu/drm/bridge/Makefile
> > +++ b/drivers/gpu/drm/bridge/Makefile
> > @@ -2,7 +2,7 @@
> > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
> > -obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
> > +obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
> > obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
> > megachips-stdp-ge-b850v3-fw.o
> > obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> > obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> > diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
> > b/drivers/gpu/drm/bridge/lvds-codec.c
> > new file mode 100644
> > index 000..d57a8eb
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> > @@ -0,0 +1,131 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Copyright (C) 2019 Renesas Electronics Corporation
> > + * Copyright (C) 2016 Laurent Pinchart
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +
> > +struct lvds_codec {
> > + struct drm_bridge bridge;
> > + struct drm_bridge *panel_bridge;
> > + struct gpio_desc *powerdown_gpio;
> > +};
> > +
> > +static int lvds_codec_attach(struct drm_bridge *bridge)
> > +{
> > + struct lvds_codec *lvds_codec = container_of(bridge,
> > +struct lvds_codec, bridge);
> > +
> > + return drm_bridge_attach(bridge->encoder, lvds_codec->panel_bridge,
> > +bridge);
> > +}
> > +
> > +static void lvds_codec_enable(struct drm_bridge *bridge)
> > +{
> > + struct lvds_codec *lvds_codec = container_of(bridge,
> > +struct lvds_co
[PATCH v3 5/7] drm/panel: panel-simple: Add connector type for etm0700g0dh6
Add connector type for the etm0700g0dh6 from Emerging Display
Technologies (EDT).
Signed-off-by: Fabrizio Castro
---
v2->v3:
* New patch
---
drivers/gpu/drm/panel/panel-simple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 5d48768..82065ff 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1342,6 +1342,7 @@ static const struct panel_desc edt_etm0700g0dh6 = {
},
.bus_format = MEDIA_BUS_FMT_RGB666_1X18,
.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_PARALLEL,
};
static const struct panel_desc edt_etm0700g0bdh6 = {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/7] Add LCD panel support to iwg20d
The iW-RainboW-G20D-Qseven RZ/G1M,G1N Qseven Development Platform comes with a 7" capacitive display kit from Emerging Display Technologies Corporation (EDT). This series adds all that's necessary for supporting it. Thanks, Fab v2->v3: * Split the dt-schema patch in two pathes as per Rob's comment * Made fixes to the dt-schema according to Rob's comment * Made fixes to the lvds-codec driver according to Jacopo's comments * Added two new patches: * drm: Define DRM_MODE_CONNECTOR_PARALLEL * drm/panel: panel-simple: Add connector type for etm0700g0dh6 v1->v2: * Convert dt-bindings to dt-schema Fabrizio Castro (7): dt-bindings: display: bridge: Convert lvds-transmitter binding to json-schema drm/bridge: Repurpose lvds-encoder.c dt-bindings: display: bridge: Repurpose lvds-encoder drm: Define DRM_MODE_CONNECTOR_PARALLEL drm/panel: panel-simple: Add connector type for etm0700g0dh6 ARM: dts: iwg20d-q7-common: Add LCD support ARM: shmobile_defconfig: Enable support for panels from EDT .../bindings/display/bridge/lvds-codec.yaml| 120 .../bindings/display/bridge/lvds-transmitter.txt | 66 - arch/arm/boot/dts/iwg20d-q7-common.dtsi| 85 +++ arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi | 1 - arch/arm/configs/shmobile_defconfig| 3 + drivers/gpu/drm/bridge/Kconfig | 8 +- drivers/gpu/drm/bridge/Makefile| 2 +- drivers/gpu/drm/bridge/lvds-codec.c| 131 + drivers/gpu/drm/bridge/lvds-encoder.c | 155 - drivers/gpu/drm/drm_connector.c| 1 + drivers/gpu/drm/panel/panel-simple.c | 1 + include/uapi/drm/drm_mode.h| 1 + 12 files changed, 347 insertions(+), 227 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml delete mode 100644 Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt create mode 100644 drivers/gpu/drm/bridge/lvds-codec.c delete mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2 2/4] dt-bindings: display: bridge: Repurpose lvds-encoder
Hello Rob, Thank you for your feedback! > From: Rob Herring > Sent: 05 November 2019 17:08 > Subject: Re: [PATCH v2 2/4] dt-bindings: display: bridge: Repurpose > lvds-encoder > > On Tue, Nov 5, 2019 at 3:33 AM Fabrizio Castro > wrote: > > > > Hello Rob, > > > > Thank you for your feedback! > > > > > From: Rob Herring > > > Sent: 04 November 2019 21:23 > > > Subject: Re: [PATCH v2 2/4] dt-bindings: display: bridge: Repurpose > > > lvds-encoder > > > > > > On Mon, Nov 4, 2019 at 10:58 AM Fabrizio Castro > > > wrote: > > > > > > > > In an effort to repurpose lvds-encoder.c to also serve the > > > > function of LVDS decoders, we ended up defining a new "generic" > > > > compatible string, therefore adapt the dt-bindings to fit the > > > > new purpose. Also, convert the dt-bindings from .txt to .yaml > > > > while at it. > > > > > > "Also, ... while at it." is a sign for split into 2 patches. > > > > Will split into 2 patches > > > > > > > > > Signed-off-by: Fabrizio Castro > > > > > > > > --- > > > > v1->v2: > > > > * Converted to dt-schema as per Neil's comment > > > > --- > > > > .../bindings/display/bridge/lvds-codec.yaml| 117 > > > > + > > > > .../bindings/display/bridge/lvds-transmitter.txt | 66 > > > > 2 files changed, 117 insertions(+), 66 deletions(-) > > > > create mode 100644 > > > > Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > > > > delete mode 100644 > > > > Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt > > > > > > > > diff --git > > > > a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > > > b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > > > > new file mode 100644 > > > > index 000..ff79bc2 > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > > > > @@ -0,0 +1,117 @@ > > > > +# SPDX-License-Identifier: GPL-2.0 > > > > +%YAML 1.2 > > > > +--- > > > > +$id: http://devicetree.org/schemas/display/bridge/lvds-codec.yaml# > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > + > > > > +title: Trasnparent LVDS encoders and LVDS decoders > > > > > > Typo > > > > Will fix > > > > > > > > > + > > > > +maintainers: > > > > + - Laurent Pinchart > > > > + > > > > +description: | > > > > + This binding supports transparent LVDS encoders and LVDS decoders > > > > that don't > > > > + require any configuration. > > > > + > > > > + LVDS is a physical layer specification defined in > > > > ANSI/TIA/EIA-644-A. Multiple > > > > + incompatible data link layers have been used over time to transmit > > > > image data > > > > + to LVDS panels. This binding targets devices compatible with the > > > > following > > > > + specifications only. > > > > + > > > > + [JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, > > > > February > > > > + 1999 (Version 1.0), Japan Electronic Industry Development > > > > Association (JEIDA) > > > > + [LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), > > > > National > > > > + Semiconductor > > > > + [VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), > > > > Video > > > > + Electronics Standards Association (VESA) > > > > + > > > > + Those devices have been marketed under the FPD-Link and FlatLink > > > > brand names > > > > + among others. > > > > + > > > > +properties: > > > > + compatible: > > > > +description: | > > > > + Any encoder or decoder compatible with this generic binding, but > > > > with > > > > + additional properties not listed here, must define its own > > > > binding and > > > > + list a device specific compatible first followed by the generic > > > > compatible > > > > +items: > > >
[PATCH v3 6/7] ARM: dts: iwg20d-q7-common: Add LCD support
The iwg20d comes with a 7" capacitive touch screen, therefore
add support for it.
Signed-off-by: Fabrizio Castro
---
v2->v3:
* No change
v1->v2:
* No change
---
arch/arm/boot/dts/iwg20d-q7-common.dtsi | 85
arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi | 1 -
2 files changed, 85 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
index ae75a1db..3428b8d 100644
--- a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
@@ -46,6 +46,49 @@
clock-frequency = <2600>;
};
+ lcd_backlight: backlight {
+ compatible = "pwm-backlight";
+
+ pwms = < 0 500 0>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <7>;
+ enable-gpios = < 14 GPIO_ACTIVE_HIGH>;
+ };
+
+ lvds-receiver {
+ compatible = "lvds-decoder";
+ powerdown = < 25 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ lvds_receiver_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ lvds_receiver_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+ };
+
+ panel {
+ compatible = "edt,etm0700g0dh6", "simple-panel";
+ backlight = <_backlight>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <_receiver_out>;
+ };
+ };
+ };
+
reg_1p5v: 1p5v {
compatible = "regulator-fixed";
regulator-name = "1P5V";
@@ -120,6 +163,18 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
+ {
+ touch-interrupt {
+ gpio-hog;
+ gpios = <12 GPIO_ACTIVE_LOW>;
+ input;
+ };
+};
+
{
status = "okay";
pinctrl-0 = <_pins>;
@@ -147,6 +202,25 @@
VDDIO-supply = <_3p3v>;
VDDD-supply = <_1p5v>;
};
+
+ touch: touchpanel@38 {
+ compatible = "edt,edt-ft5406";
+ reg = <0x38>;
+ interrupt-parent = <>;
+ interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
+ };
+};
+
+ {
+ status = "okay";
+
+ ports {
+ port@1 {
+ lvds0_out: endpoint {
+ remote-endpoint = <_receiver_in>;
+ };
+ };
+ };
};
{
@@ -180,6 +254,11 @@
function = "i2c2";
};
+ pwm3_pins: pwm3 {
+ groups = "pwm3";
+ function = "pwm3";
+ };
+
scif0_pins: scif0 {
groups = "scif0_data_d";
function = "scif0";
@@ -218,6 +297,12 @@
};
};
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
_sound {
pinctrl-0 = <_pins>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
b/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
index 0e99df2..ede2e0c 100644
--- a/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
@@ -39,7 +39,6 @@
{
pinctrl-0 = <_pins>;
pinctrl-names = "default";
- status = "okay";
ports {
port@0 {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/7] dt-bindings: display: bridge: Repurpose lvds-encoder
In an effort to repurpose lvds-encoder.c to also serve the
function of LVDS decoders, we ended up defining a new "generic"
compatible string, therefore adapt the dt-bindings to fit the
new purpose.
Signed-off-by: Fabrizio Castro
---
v2->v3:
* Extracted conversion to lvds-codec as per Rob's comment
v1->v2:
* Converted to dt-schema as per Neil's comment
---
.../bindings/display/bridge/lvds-codec.yaml| 120 +
.../bindings/display/bridge/lvds-transmitter.yaml | 91
2 files changed, 120 insertions(+), 91 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
delete mode 100644
Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
new file mode 100644
index 000..3ebdf96
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
@@ -0,0 +1,120 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/lvds-codec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Transparent LVDS encoders and LVDS decoders
+
+maintainers:
+ - Laurent Pinchart
+
+description: |
+ This binding supports transparent LVDS encoders and LVDS decoders that don't
+ require any configuration.
+
+ LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
Multiple
+ incompatible data link layers have been used over time to transmit image data
+ to LVDS panels. This binding targets devices compatible with the following
+ specifications only.
+
+ [JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February
+ 1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA)
+ [LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
+ Semiconductor
+ [VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video
+ Electronics Standards Association (VESA)
+
+ Those devices have been marketed under the FPD-Link and FlatLink brand names
+ among others.
+
+properties:
+ compatible:
+description: |
+ Any encoder or decoder compatible with this generic binding, but with
+ additional properties not listed here, must define its own binding and
+ list a device specific compatible first followed by the generic
compatible
+enum:
+ - lvds-encoder # for LVDS encoders
+ - lvds-decoder # for LVDS decoders
+
+ ports:
+type: object
+description: |
+ This device has two video ports. Their connections are modeled using the
+ OF graph bindings specified in
Documentation/devicetree/bindings/graph.txt
+properties:
+ port@0:
+type: object
+description: |
+ With LVDS encoders port 0 is for parallel input
+ With LVDS decoders port 0 is for LVDS input
+
+ port@1:
+type: object
+description: |
+ With LVDS encoders port 1 is for LVDS output
+ With LVDS decoders port 1 is for parallel output
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - ports
+
+examples:
+ - |
+lvds-encoder {
+ compatible = "lvds-encoder";
+
+ ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+ reg = <0>;
+
+ lvds_enc_in: endpoint {
+remote-endpoint = <_out_rgb>;
+ };
+};
+
+port@1 {
+ reg = <1>;
+
+ lvds_enc_out: endpoint {
+remote-endpoint = <_panel_in>;
+ };
+};
+ };
+};
+
+ - |
+lvds-decoder {
+ compatible = "lvds-decoder";
+
+ ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+ reg = <0>;
+
+ lvds_dec_in: endpoint {
+remote-endpoint = <_out_lvds>;
+ };
+};
+
+port@1 {
+ reg = <1>;
+
+ lvds_dec_out: endpoint {
+remote-endpoint = <_panel_in>;
+ };
+};
+ };
+};
+
+...
diff --git
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
deleted file mode 100644
index 5be163a..000
--- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
+++ /dev/null
@@ -1,91 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2
-$id: http://devicetree.org/schemas/display/bridge/lvds-transmitter.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Parallel to LVDS Encoder
-
-maintainers:
- - Laurent Pinchart
-
-description: |
- This binding supports the parallel to LVDS encoders that don't require any
- configuration.
-
-
[PATCH v3 1/7] dt-bindings: display: bridge: Convert lvds-transmitter binding to json-schema
Convert the lvds-transmitter binding to DT schema format using
json-schema.
Signed-off-by: Fabrizio Castro
---
v2->v3:
* Extracted conversion to dt-schema as per Rob's comment
v1->v2:
* Converted to dt-schema as per Neil's comment
---
.../bindings/display/bridge/lvds-transmitter.txt | 66
.../bindings/display/bridge/lvds-transmitter.yaml | 91 ++
2 files changed, 91 insertions(+), 66 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
create mode 100644
Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
deleted file mode 100644
index 60091db..000
--- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
+++ /dev/null
@@ -1,66 +0,0 @@
-Parallel to LVDS Encoder
-
-
-This binding supports the parallel to LVDS encoders that don't require any
-configuration.
-
-LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. Multiple
-incompatible data link layers have been used over time to transmit image data
-to LVDS panels. This binding targets devices compatible with the following
-specifications only.
-
-[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February
-1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA)
-[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
-Semiconductor
-[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video
-Electronics Standards Association (VESA)
-
-Those devices have been marketed under the FPD-Link and FlatLink brand names
-among others.
-
-
-Required properties:
-
-- compatible: Must be "lvds-encoder"
-
- Any encoder compatible with this generic binding, but with additional
- properties not listed here, must list a device specific compatible first
- followed by this generic compatible.
-
-Required nodes:
-
-This device has two video ports. Their connections are modeled using the OF
-graph bindings specified in Documentation/devicetree/bindings/graph.txt.
-
-- Video port 0 for parallel input
-- Video port 1 for LVDS output
-
-
-Example
-
-lvds-encoder {
- compatible = "lvds-encoder";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
-
- lvds_enc_in: endpoint {
- remote-endpoint = <_out_rgb>;
- };
- };
-
- port@1 {
- reg = <1>;
-
- lvds_enc_out: endpoint {
- remote-endpoint = <_panel_in>;
- };
- };
- };
-};
diff --git
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
new file mode 100644
index 000..5be163a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/lvds-transmitter.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Parallel to LVDS Encoder
+
+maintainers:
+ - Laurent Pinchart
+
+description: |
+ This binding supports the parallel to LVDS encoders that don't require any
+ configuration.
+
+ LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
Multiple
+ incompatible data link layers have been used over time to transmit image data
+ to LVDS panels. This binding targets devices compatible with the following
+ specifications only.
+
+ [JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February
+ 1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA)
+ [LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
+ Semiconductor
+ [VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video
+ Electronics Standards Association (VESA)
+
+ Those devices have been marketed under the FPD-Link and FlatLink brand names
+ among others.
+
+properties:
+ compatible:
+description: |
+ Any encoder or decoder compatible with this generic binding, but with
+ additional properties not listed here, must define its own binding and
+ list a device specific compatible first followed by the generic
compatible
+enum:
+ - lvds-encoder
+
+ ports:
+type: object
+description: |
+ This device has two video ports. Their connections are modeled using the
+ OF graph bindings specified in
Documentation/devicetree/bindings/graph
RE: [PATCH v2 1/4] drm/bridge: Repurpose lvds-encoder.c
Hi Jacopo,
Thank you for your feedback!
> From: Jacopo Mondi
> Sent: 07 November 2019 18:19
> Subject: Re: [PATCH v2 1/4] drm/bridge: Repurpose lvds-encoder.c
>
> Hi Fabrizio,
> thanks for the patch.
>
> On Mon, Nov 04, 2019 at 04:58:00PM +, Fabrizio Castro wrote:
> > lvds-encoder.c implementation is also suitable for LVDS decoders,
> > not just LVDS encoders.
> > Instead of creating a new driver for addressing support for
> > transparent LVDS decoders, repurpose lvds-encoder.c for the greater
> > good.
> >
> > Signed-off-by: Fabrizio Castro
> >
> > ---
> > v1->v2:
> > * No change
> > ---
> > drivers/gpu/drm/bridge/Kconfig| 8 +-
> > drivers/gpu/drm/bridge/Makefile | 2 +-
> > drivers/gpu/drm/bridge/lvds-codec.c | 169
> > ++
> > drivers/gpu/drm/bridge/lvds-encoder.c | 155 ---
> > 4 files changed, 174 insertions(+), 160 deletions(-)
> > create mode 100644 drivers/gpu/drm/bridge/lvds-codec.c
> > delete mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c
> >
> > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> > index 3436297..9e75ca4e 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -45,14 +45,14 @@ config DRM_DUMB_VGA_DAC
> > Support for non-programmable RGB to VGA DAC bridges, such as ADI
> > ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs.
> >
> > -config DRM_LVDS_ENCODER
> > - tristate "Transparent parallel to LVDS encoder support"
> > +config DRM_LVDS_CODEC
> > + tristate "Transparent LVDS encoders and decoders support"
> > depends on OF
> > select DRM_KMS_HELPER
> > select DRM_PANEL_BRIDGE
> > help
> > - Support for transparent parallel to LVDS encoders that don't require
> > - any configuration.
> > + Support for transparent LVDS encoders and LVDS decoders that don't
> > + require any configuration.
> >
> > config DRM_MEGACHIPS_STDP_GE_B850V3_FW
> > tristate "MegaChips stdp4028-ge-b850v3-fw and stdp2690-ge-b850v3-fw"
> > diff --git a/drivers/gpu/drm/bridge/Makefile
> > b/drivers/gpu/drm/bridge/Makefile
> > index 4934fcf..8a9178a 100644
> > --- a/drivers/gpu/drm/bridge/Makefile
> > +++ b/drivers/gpu/drm/bridge/Makefile
> > @@ -2,7 +2,7 @@
> > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
> > -obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
> > +obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
> > obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
> > megachips-stdp-ge-b850v3-fw.o
> > obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> > obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> > diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
> > b/drivers/gpu/drm/bridge/lvds-codec.c
> > new file mode 100644
> > index 000..8a1979c
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> > @@ -0,0 +1,169 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Copyright (C) 2016 Laurent Pinchart
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +
> > +struct lvds_codec {
> > + struct drm_bridge bridge;
> > + struct drm_bridge *panel_bridge;
> > + struct gpio_desc *powerdown_gpio;
> > + u32 connector_type;
> > +};
> > +
> > +static int lvds_codec_attach(struct drm_bridge *bridge)
> > +{
> > + struct lvds_codec *lvds_codec = container_of(bridge,
> > +struct lvds_codec,
> > +bridge);
> > +
>
> Weird indentation. Align to open ( to match the rest of the driver's
> style.
Will do, throughout the file.
>
> > + return drm_bridge_attach(bridge->encoder, lvds_codec->panel_bridge,
> > +bridge);
> > +}
> > +
> > +static void lvds_codec_enable(struct drm_bridge *bridge)
> > +{
> > + struct lvds_codec *lvds_codec = container_of(bridge,
> > +struct lvds_codec,
> > +bridge);
> > +
>
[PATCH v3 2/7] drm/bridge: Repurpose lvds-encoder.c
lvds-encoder.c implementation is also suitable for LVDS decoders,
not just LVDS encoders.
Instead of creating a new driver for addressing support for
transparent LVDS decoders, repurpose lvds-encoder.c for the greater
good.
Signed-off-by: Fabrizio Castro
---
v2->v3:
* No change
v1->v2:
* No change
---
drivers/gpu/drm/bridge/Kconfig| 8 +-
drivers/gpu/drm/bridge/Makefile | 2 +-
drivers/gpu/drm/bridge/lvds-codec.c | 131
drivers/gpu/drm/bridge/lvds-encoder.c | 155 --
4 files changed, 136 insertions(+), 160 deletions(-)
create mode 100644 drivers/gpu/drm/bridge/lvds-codec.c
delete mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3436297..9e75ca4e 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -45,14 +45,14 @@ config DRM_DUMB_VGA_DAC
Support for non-programmable RGB to VGA DAC bridges, such as ADI
ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs.
-config DRM_LVDS_ENCODER
- tristate "Transparent parallel to LVDS encoder support"
+config DRM_LVDS_CODEC
+ tristate "Transparent LVDS encoders and decoders support"
depends on OF
select DRM_KMS_HELPER
select DRM_PANEL_BRIDGE
help
- Support for transparent parallel to LVDS encoders that don't require
- any configuration.
+ Support for transparent LVDS encoders and LVDS decoders that don't
+ require any configuration.
config DRM_MEGACHIPS_STDP_GE_B850V3_FW
tristate "MegaChips stdp4028-ge-b850v3-fw and stdp2690-ge-b850v3-fw"
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 4934fcf..8a9178a 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,7 +2,7 @@
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
-obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
+obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
b/drivers/gpu/drm/bridge/lvds-codec.c
new file mode 100644
index 000..d57a8eb
--- /dev/null
+++ b/drivers/gpu/drm/bridge/lvds-codec.c
@@ -0,0 +1,131 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2019 Renesas Electronics Corporation
+ * Copyright (C) 2016 Laurent Pinchart
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+struct lvds_codec {
+ struct drm_bridge bridge;
+ struct drm_bridge *panel_bridge;
+ struct gpio_desc *powerdown_gpio;
+};
+
+static int lvds_codec_attach(struct drm_bridge *bridge)
+{
+ struct lvds_codec *lvds_codec = container_of(bridge,
+struct lvds_codec, bridge);
+
+ return drm_bridge_attach(bridge->encoder, lvds_codec->panel_bridge,
+bridge);
+}
+
+static void lvds_codec_enable(struct drm_bridge *bridge)
+{
+ struct lvds_codec *lvds_codec = container_of(bridge,
+struct lvds_codec, bridge);
+
+ if (lvds_codec->powerdown_gpio)
+ gpiod_set_value_cansleep(lvds_codec->powerdown_gpio, 0);
+}
+
+static void lvds_codec_disable(struct drm_bridge *bridge)
+{
+ struct lvds_codec *lvds_codec = container_of(bridge,
+struct lvds_codec, bridge);
+
+ if (lvds_codec->powerdown_gpio)
+ gpiod_set_value_cansleep(lvds_codec->powerdown_gpio, 1);
+}
+
+static struct drm_bridge_funcs funcs = {
+ .attach = lvds_codec_attach,
+ .enable = lvds_codec_enable,
+ .disable = lvds_codec_disable,
+};
+
+static int lvds_codec_probe(struct platform_device *pdev)
+{
+ struct device *dev = >dev;
+ struct device_node *panel_node;
+ struct drm_panel *panel;
+ struct lvds_codec *lvds_codec;
+
+ lvds_codec = devm_kzalloc(dev, sizeof(*lvds_codec), GFP_KERNEL);
+ if (!lvds_codec)
+ return -ENOMEM;
+
+ lvds_codec->powerdown_gpio = devm_gpiod_get_optional(dev, "powerdown",
+GPIOD_OUT_HIGH);
+ if (IS_ERR(lvds_codec->powerdown_gpio))
+ return PTR_ERR(lvds_codec->powerdown_gpio);
+
+ panel_node = of_graph_get_remote_node(dev->of_node, 1, 0);
+ if (!panel_node) {
+ dev_dbg(dev, "panel DT node not found\n");
+ return -ENXIO;
+ }
+
+ p
[PATCH v3 7/7] ARM: shmobile_defconfig: Enable support for panels from EDT
The iwg20d comes with an LCD panel from Emerging Display Technologies Corporation (EDT), therefore enable what's required to support it. Signed-off-by: Fabrizio Castro --- v2->v3: * No change v1->v2: * No change --- arch/arm/configs/shmobile_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig index c6c7035..ab416a5 100644 --- a/arch/arm/configs/shmobile_defconfig +++ b/arch/arm/configs/shmobile_defconfig @@ -66,6 +66,7 @@ CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_GPIO=y # CONFIG_INPUT_MOUSE is not set CONFIG_INPUT_TOUCHSCREEN=y +CONFIG_TOUCHSCREEN_EDT_FT5X06=y CONFIG_TOUCHSCREEN_ST1232=y CONFIG_INPUT_MISC=y CONFIG_INPUT_ADXL34X=y @@ -125,7 +126,9 @@ CONFIG_VIDEO_ADV7604=y CONFIG_VIDEO_ML86V7667=y CONFIG_DRM=y CONFIG_DRM_RCAR_DU=y +CONFIG_DRM_PANEL_SIMPLE=y CONFIG_DRM_DUMB_VGA_DAC=y +CONFIG_DRM_LVDS_CODEC=y CONFIG_DRM_SII902X=y CONFIG_DRM_I2C_ADV7511=y CONFIG_DRM_I2C_ADV7511_AUDIO=y -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/7] drm: Define DRM_MODE_CONNECTOR_PARALLEL
The existing DRM_MODE_CONNECTOR_ definitions don't seem to
describe the connector for RGB/Parallel embedded displays,
hence add DRM_MODE_CONNECTOR_PARALLEL.
Signed-off-by: Fabrizio Castro
---
v2->v3:
* New patch
---
drivers/gpu/drm/drm_connector.c | 1 +
include/uapi/drm/drm_mode.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 2166000..b233029 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -93,6 +93,7 @@ static struct drm_conn_prop_enum_list
drm_connector_enum_list[] = {
{ DRM_MODE_CONNECTOR_DPI, "DPI" },
{ DRM_MODE_CONNECTOR_WRITEBACK, "Writeback" },
{ DRM_MODE_CONNECTOR_SPI, "SPI" },
+ { DRM_MODE_CONNECTOR_PARALLEL, "Parallel" },
};
void drm_connector_ida_init(void)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 735c8cf..5852f47 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -362,6 +362,7 @@ enum drm_mode_subconnector {
#define DRM_MODE_CONNECTOR_DPI 17
#define DRM_MODE_CONNECTOR_WRITEBACK 18
#define DRM_MODE_CONNECTOR_SPI 19
+#define DRM_MODE_CONNECTOR_PARALLEL20
struct drm_mode_get_connector {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2 2/4] dt-bindings: display: bridge: Repurpose lvds-encoder
Hello Rob, Thank you for your feedback! > From: Rob Herring > Sent: 04 November 2019 21:23 > Subject: Re: [PATCH v2 2/4] dt-bindings: display: bridge: Repurpose > lvds-encoder > > On Mon, Nov 4, 2019 at 10:58 AM Fabrizio Castro > wrote: > > > > In an effort to repurpose lvds-encoder.c to also serve the > > function of LVDS decoders, we ended up defining a new "generic" > > compatible string, therefore adapt the dt-bindings to fit the > > new purpose. Also, convert the dt-bindings from .txt to .yaml > > while at it. > > "Also, ... while at it." is a sign for split into 2 patches. Will split into 2 patches > > > Signed-off-by: Fabrizio Castro > > > > --- > > v1->v2: > > * Converted to dt-schema as per Neil's comment > > --- > > .../bindings/display/bridge/lvds-codec.yaml| 117 > > + > > .../bindings/display/bridge/lvds-transmitter.txt | 66 > > 2 files changed, 117 insertions(+), 66 deletions(-) > > create mode 100644 > > Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > > delete mode 100644 > > Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt > > > > diff --git > > a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > > new file mode 100644 > > index 000..ff79bc2 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > > @@ -0,0 +1,117 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/display/bridge/lvds-codec.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Trasnparent LVDS encoders and LVDS decoders > > Typo Will fix > > > + > > +maintainers: > > + - Laurent Pinchart > > + > > +description: | > > + This binding supports transparent LVDS encoders and LVDS decoders that > > don't > > + require any configuration. > > + > > + LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. > > Multiple > > + incompatible data link layers have been used over time to transmit image > > data > > + to LVDS panels. This binding targets devices compatible with the > > following > > + specifications only. > > + > > + [JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, > > February > > + 1999 (Version 1.0), Japan Electronic Industry Development Association > > (JEIDA) > > + [LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National > > + Semiconductor > > + [VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video > > + Electronics Standards Association (VESA) > > + > > + Those devices have been marketed under the FPD-Link and FlatLink brand > > names > > + among others. > > + > > +properties: > > + compatible: > > +description: | > > + Any encoder or decoder compatible with this generic binding, but with > > + additional properties not listed here, must define its own binding > > and > > + list a device specific compatible first followed by the generic > > compatible > > +items: > > + - enum: > > You can drop 'items' when there's only 1. Will drop > > > +- lvds-encoder # for LVDS encoders > > +- lvds-decoder # for LVDS decoders > > + > > + ports: > > +type: object > > +description: | > > + This device has two video ports. Their connections are modeled using > > the > > + OF graph bindings specified in > > Documentation/devicetree/bindings/graph.txt > > +properties: > > + port@0: > > +type: object > > +description: | > > + With LVDS encoders port 0 is for parallel input > > + With LVDS decoders port 0 is for LVDS input > > + > > + port@1: > > +type: object > > +description: | > > + With LVDS encoders port 1 is for LVDS output > > + With LVDS decoders port 1 is for parallel output > > port@* are required, right? Yes, port@0 and port@1 are both required, similarly to: Documentation/devicetree/bindings/display/st,stm32-dsi.yaml therefore I have put "ports" under "required", in a similar fashion. What's the right way of specifying this? Thanks, Fab > > > + > >
[PATCH v2 3/4] ARM: dts: iwg20d-q7-common: Add LCD support
The iwg20d comes with a 7" capacitive touch screen, therefore
add support for it.
Signed-off-by: Fabrizio Castro
---
v1->v2:
* No change
---
arch/arm/boot/dts/iwg20d-q7-common.dtsi | 85
arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi | 1 -
2 files changed, 85 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
index ae75a1db..3428b8d 100644
--- a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
@@ -46,6 +46,49 @@
clock-frequency = <2600>;
};
+ lcd_backlight: backlight {
+ compatible = "pwm-backlight";
+
+ pwms = < 0 500 0>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <7>;
+ enable-gpios = < 14 GPIO_ACTIVE_HIGH>;
+ };
+
+ lvds-receiver {
+ compatible = "lvds-decoder";
+ powerdown = < 25 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ lvds_receiver_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ lvds_receiver_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+ };
+
+ panel {
+ compatible = "edt,etm0700g0dh6", "simple-panel";
+ backlight = <_backlight>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <_receiver_out>;
+ };
+ };
+ };
+
reg_1p5v: 1p5v {
compatible = "regulator-fixed";
regulator-name = "1P5V";
@@ -120,6 +163,18 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
+ {
+ touch-interrupt {
+ gpio-hog;
+ gpios = <12 GPIO_ACTIVE_LOW>;
+ input;
+ };
+};
+
{
status = "okay";
pinctrl-0 = <_pins>;
@@ -147,6 +202,25 @@
VDDIO-supply = <_3p3v>;
VDDD-supply = <_1p5v>;
};
+
+ touch: touchpanel@38 {
+ compatible = "edt,edt-ft5406";
+ reg = <0x38>;
+ interrupt-parent = <>;
+ interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
+ };
+};
+
+ {
+ status = "okay";
+
+ ports {
+ port@1 {
+ lvds0_out: endpoint {
+ remote-endpoint = <_receiver_in>;
+ };
+ };
+ };
};
{
@@ -180,6 +254,11 @@
function = "i2c2";
};
+ pwm3_pins: pwm3 {
+ groups = "pwm3";
+ function = "pwm3";
+ };
+
scif0_pins: scif0 {
groups = "scif0_data_d";
function = "scif0";
@@ -218,6 +297,12 @@
};
};
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
_sound {
pinctrl-0 = <_pins>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
b/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
index 0e99df2..ede2e0c 100644
--- a/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
@@ -39,7 +39,6 @@
{
pinctrl-0 = <_pins>;
pinctrl-names = "default";
- status = "okay";
ports {
port@0 {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/4] drm/bridge: Repurpose lvds-encoder.c
lvds-encoder.c implementation is also suitable for LVDS decoders,
not just LVDS encoders.
Instead of creating a new driver for addressing support for
transparent LVDS decoders, repurpose lvds-encoder.c for the greater
good.
Signed-off-by: Fabrizio Castro
---
v1->v2:
* No change
---
drivers/gpu/drm/bridge/Kconfig| 8 +-
drivers/gpu/drm/bridge/Makefile | 2 +-
drivers/gpu/drm/bridge/lvds-codec.c | 169 ++
drivers/gpu/drm/bridge/lvds-encoder.c | 155 ---
4 files changed, 174 insertions(+), 160 deletions(-)
create mode 100644 drivers/gpu/drm/bridge/lvds-codec.c
delete mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3436297..9e75ca4e 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -45,14 +45,14 @@ config DRM_DUMB_VGA_DAC
Support for non-programmable RGB to VGA DAC bridges, such as ADI
ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs.
-config DRM_LVDS_ENCODER
- tristate "Transparent parallel to LVDS encoder support"
+config DRM_LVDS_CODEC
+ tristate "Transparent LVDS encoders and decoders support"
depends on OF
select DRM_KMS_HELPER
select DRM_PANEL_BRIDGE
help
- Support for transparent parallel to LVDS encoders that don't require
- any configuration.
+ Support for transparent LVDS encoders and LVDS decoders that don't
+ require any configuration.
config DRM_MEGACHIPS_STDP_GE_B850V3_FW
tristate "MegaChips stdp4028-ge-b850v3-fw and stdp2690-ge-b850v3-fw"
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 4934fcf..8a9178a 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,7 +2,7 @@
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
-obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
+obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
b/drivers/gpu/drm/bridge/lvds-codec.c
new file mode 100644
index 000..8a1979c
--- /dev/null
+++ b/drivers/gpu/drm/bridge/lvds-codec.c
@@ -0,0 +1,169 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2016 Laurent Pinchart
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+struct lvds_codec {
+ struct drm_bridge bridge;
+ struct drm_bridge *panel_bridge;
+ struct gpio_desc *powerdown_gpio;
+ u32 connector_type;
+};
+
+static int lvds_codec_attach(struct drm_bridge *bridge)
+{
+ struct lvds_codec *lvds_codec = container_of(bridge,
+struct lvds_codec,
+bridge);
+
+ return drm_bridge_attach(bridge->encoder, lvds_codec->panel_bridge,
+bridge);
+}
+
+static void lvds_codec_enable(struct drm_bridge *bridge)
+{
+ struct lvds_codec *lvds_codec = container_of(bridge,
+struct lvds_codec,
+bridge);
+
+ if (lvds_codec->powerdown_gpio)
+ gpiod_set_value_cansleep(lvds_codec->powerdown_gpio, 0);
+}
+
+static void lvds_codec_disable(struct drm_bridge *bridge)
+{
+ struct lvds_codec *lvds_codec = container_of(bridge,
+struct lvds_codec,
+bridge);
+
+ if (lvds_codec->powerdown_gpio)
+ gpiod_set_value_cansleep(lvds_codec->powerdown_gpio, 1);
+}
+
+static struct drm_bridge_funcs funcs = {
+ .attach = lvds_codec_attach,
+ .enable = lvds_codec_enable,
+ .disable = lvds_codec_disable,
+};
+
+static int lvds_codec_probe(struct platform_device *pdev)
+{
+ struct device *dev = >dev;
+ struct device_node *port;
+ struct device_node *endpoint;
+ struct device_node *panel_node;
+ struct drm_panel *panel;
+ struct lvds_codec *lvds_codec;
+
+ lvds_codec = devm_kzalloc(dev, sizeof(*lvds_codec), GFP_KERNEL);
+ if (!lvds_codec)
+ return -ENOMEM;
+
+ lvds_codec->connector_type = (u32)
+ of_device_get_match_data(>dev);
+ lvds_codec->powerdown_gpio = devm_gpiod_get_optional(dev, "powerdown",
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(lv
[PATCH v2 0/4] Add LCD panel support to iwg20d
The iW-RainboW-G20D-Qseven RZ/G1M,G1N Qseven Development Platform comes with a 7" capacitive display kit from Emerging Display Technologies Corporation (EDT). This series adds all that's necessary for supporting it. Thanks, Fab v1->v2: * Convert dt-bindings to dt-schema Fabrizio Castro (4): drm/bridge: Repurpose lvds-encoder.c dt-bindings: display: bridge: Repurpose lvds-encoder ARM: dts: iwg20d-q7-common: Add LCD support ARM: shmobile_defconfig: Enable support for panels from EDT .../bindings/display/bridge/lvds-codec.yaml| 117 ++ .../bindings/display/bridge/lvds-transmitter.txt | 66 arch/arm/boot/dts/iwg20d-q7-common.dtsi| 85 +++ arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi | 1 - arch/arm/configs/shmobile_defconfig| 3 + drivers/gpu/drm/bridge/Kconfig | 8 +- drivers/gpu/drm/bridge/Makefile| 2 +- drivers/gpu/drm/bridge/lvds-codec.c| 169 + drivers/gpu/drm/bridge/lvds-encoder.c | 155 --- 9 files changed, 379 insertions(+), 227 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml delete mode 100644 Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt create mode 100644 drivers/gpu/drm/bridge/lvds-codec.c delete mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/4] dt-bindings: display: bridge: Repurpose lvds-encoder
In an effort to repurpose lvds-encoder.c to also serve the
function of LVDS decoders, we ended up defining a new "generic"
compatible string, therefore adapt the dt-bindings to fit the
new purpose. Also, convert the dt-bindings from .txt to .yaml
while at it.
Signed-off-by: Fabrizio Castro
---
v1->v2:
* Converted to dt-schema as per Neil's comment
---
.../bindings/display/bridge/lvds-codec.yaml| 117 +
.../bindings/display/bridge/lvds-transmitter.txt | 66
2 files changed, 117 insertions(+), 66 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
delete mode 100644
Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
new file mode 100644
index 000..ff79bc2
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
@@ -0,0 +1,117 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/lvds-codec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Trasnparent LVDS encoders and LVDS decoders
+
+maintainers:
+ - Laurent Pinchart
+
+description: |
+ This binding supports transparent LVDS encoders and LVDS decoders that don't
+ require any configuration.
+
+ LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
Multiple
+ incompatible data link layers have been used over time to transmit image data
+ to LVDS panels. This binding targets devices compatible with the following
+ specifications only.
+
+ [JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February
+ 1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA)
+ [LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
+ Semiconductor
+ [VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video
+ Electronics Standards Association (VESA)
+
+ Those devices have been marketed under the FPD-Link and FlatLink brand names
+ among others.
+
+properties:
+ compatible:
+description: |
+ Any encoder or decoder compatible with this generic binding, but with
+ additional properties not listed here, must define its own binding and
+ list a device specific compatible first followed by the generic
compatible
+items:
+ - enum:
+- lvds-encoder # for LVDS encoders
+- lvds-decoder # for LVDS decoders
+
+ ports:
+type: object
+description: |
+ This device has two video ports. Their connections are modeled using the
+ OF graph bindings specified in
Documentation/devicetree/bindings/graph.txt
+properties:
+ port@0:
+type: object
+description: |
+ With LVDS encoders port 0 is for parallel input
+ With LVDS decoders port 0 is for LVDS input
+
+ port@1:
+type: object
+description: |
+ With LVDS encoders port 1 is for LVDS output
+ With LVDS decoders port 1 is for parallel output
+
+required:
+ - compatible
+ - ports
+
+examples:
+ - |
+lvds-encoder {
+ compatible = "lvds-encoder";
+
+ ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+ reg = <0>;
+
+ lvds_enc_in: endpoint {
+remote-endpoint = <_out_rgb>;
+ };
+};
+
+port@1 {
+ reg = <1>;
+
+ lvds_enc_out: endpoint {
+remote-endpoint = <_panel_in>;
+ };
+};
+ };
+};
+
+ - |
+lvds-decoder {
+ compatible = "lvds-decoder";
+
+ ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+ reg = <0>;
+
+ lvds_dec_in: endpoint {
+remote-endpoint = <_out_lvds>;
+ };
+};
+
+port@1 {
+ reg = <1>;
+
+ lvds_dec_out: endpoint {
+remote-endpoint = <_panel_in>;
+ };
+};
+ };
+};
+
+...
diff --git
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
deleted file mode 100644
index 60091db..000
--- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
+++ /dev/null
@@ -1,66 +0,0 @@
-Parallel to LVDS Encoder
-
-
-This binding supports the parallel to LVDS encoders that don't require any
-configuration.
-
-LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. Multiple
-incompatible data link layers have been used over time to transmit image data
-to LVDS panels. This binding targets devices compatible with the following
-specifications only.
-
-[JEIDA] &q
[PATCH v2 4/4] ARM: shmobile_defconfig: Enable support for panels from EDT
The iwg20d comes with an LCD panel from Emerging Display Technologies Corporation (EDT), therefore enable what's required to support it. Signed-off-by: Fabrizio Castro --- v1->v2: * No change --- arch/arm/configs/shmobile_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig index c6c7035..ab416a5 100644 --- a/arch/arm/configs/shmobile_defconfig +++ b/arch/arm/configs/shmobile_defconfig @@ -66,6 +66,7 @@ CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_GPIO=y # CONFIG_INPUT_MOUSE is not set CONFIG_INPUT_TOUCHSCREEN=y +CONFIG_TOUCHSCREEN_EDT_FT5X06=y CONFIG_TOUCHSCREEN_ST1232=y CONFIG_INPUT_MISC=y CONFIG_INPUT_ADXL34X=y @@ -125,7 +126,9 @@ CONFIG_VIDEO_ADV7604=y CONFIG_VIDEO_ML86V7667=y CONFIG_DRM=y CONFIG_DRM_RCAR_DU=y +CONFIG_DRM_PANEL_SIMPLE=y CONFIG_DRM_DUMB_VGA_DAC=y +CONFIG_DRM_LVDS_CODEC=y CONFIG_DRM_SII902X=y CONFIG_DRM_I2C_ADV7511=y CONFIG_DRM_I2C_ADV7511_AUDIO=y -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 2/4] dt-bindings: display: bridge: Repurpose lvds-encoder
Hi Neil,
Thank you for your feedback!
> From: Neil Armstrong
> Sent: 04 November 2019 09:17
> Subject: Re: [PATCH 2/4] dt-bindings: display: bridge: Repurpose lvds-encoder
>
> Hi,
>
>
> On 30/10/2019 14:43, Fabrizio Castro wrote:
> > In an effort to repurpose lvds-encoder.c to also serve the
> > function of LVDS decoders, we ended up defining a new "generic"
> > compatible string, therefore adapt the dt-bindings to fit the
> > new purpose.
>
> You should convert it to dt-schemas in this case.
Will do.
Thanks,
Fab
>
> Neil
>
> >
> > Signed-off-by: Fabrizio Castro
> > ---
> > .../bindings/display/bridge/lvds-codec.txt | 100
> > +
> > .../bindings/display/bridge/lvds-transmitter.txt | 66 --
> > 2 files changed, 100 insertions(+), 66 deletions(-)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/lvds-codec.txt
> > delete mode 100644
> > Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
> >
> > diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.txt
> b/Documentation/devicetree/bindings/display/bridge/lvds-codec.txt
> > new file mode 100644
> > index 000..45fd81c
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.txt
> > @@ -0,0 +1,100 @@
> > +Trasnparent LVDS encoders and LVDS decoders
> > +---
> > +
> > +This binding supports transparent LVDS encoders and LVDS decoders that
> > don't
> > +require any configuration.
> > +
> > +LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
> > Multiple
> > +incompatible data link layers have been used over time to transmit image
> > data
> > +to LVDS panels. This binding targets devices compatible with the following
> > +specifications only.
> > +
> > +[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February
> > +1999 (Version 1.0), Japan Electronic Industry Development Association
> > (JEIDA)
> > +[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
> > +Semiconductor
> > +[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video
> > +Electronics Standards Association (VESA)
> > +
> > +Those devices have been marketed under the FPD-Link and FlatLink brand
> > names
> > +among others.
> > +
> > +
> > +Required properties:
> > +
> > +- compatible: Must be "lvds-encoder" for LVDS encoders or "lvds-decoder"
> > for
> > + LVDS decoders.
> > +
> > + Any encoder compatible with this generic binding, but with additional
> > + properties not listed here, must list a device specific compatible first
> > + followed by the generic compatible.
> > +
> > +Required nodes:
> > +
> > +This device has two video ports. Their connections are modeled using the OF
> > +graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> > +
> > +For LVDS encoders:
> > +- Video port 0 for parallel input
> > +- Video port 1 for LVDS output
> > +
> > +For LVDS decoders:
> > +- Video port 0 for LVDS input
> > +- Video port 1 for parallel output
> > +
> > +
> > +LVDS encoder example
> > +
> > +
> > +lvds-encoder {
> > + compatible = "lvds-encoder";
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > +
> > + lvds_enc_in: endpoint {
> > + remote-endpoint = <_out_rgb>;
> > + };
> > + };
> > +
> > + port@1 {
> > + reg = <1>;
> > +
> > + lvds_enc_out: endpoint {
> > + remote-endpoint = <_panel_in>;
> > + };
> > + };
> > + };
> > +};
> > +
> > +LVDS decoder example
> > +
> > +
> > +lvds-decoder {
> > + compatible = "lvds-decoder";
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > +
> > + lv
RE: [PATCH 1/4] drm/bridge: Repurpose lvds-encoder.c
Hi Neil,
Thank you for your feedback!
> From: Neil Armstrong
> Sent: 04 November 2019 09:18
> Subject: Re: [PATCH 1/4] drm/bridge: Repurpose lvds-encoder.c
>
> Hi,
>
> On 30/10/2019 14:43, Fabrizio Castro wrote:
> > lvds-encoder.c implementation is also suitable for LVDS decoders,
> > not just LVDS encoders.
> > Instead of creating a new driver for addressing support for
> > transparent LVDS decoders, repurpose lvds-encoder.c for the greater
> > good.
> >
> > Signed-off-by: Fabrizio Castro
> > ---
> > drivers/gpu/drm/bridge/Kconfig| 8 +-
> > drivers/gpu/drm/bridge/Makefile | 2 +-
> > drivers/gpu/drm/bridge/lvds-codec.c | 169
> > ++
> > drivers/gpu/drm/bridge/lvds-encoder.c | 155 ---
> > 4 files changed, 174 insertions(+), 160 deletions(-)
> > create mode 100644 drivers/gpu/drm/bridge/lvds-codec.c
> > delete mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c
> >
> > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> > index 3436297..9e75ca4e 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -45,14 +45,14 @@ config DRM_DUMB_VGA_DAC
> > Support for non-programmable RGB to VGA DAC bridges, such as ADI
> > ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs.
> >
> > -config DRM_LVDS_ENCODER
> > - tristate "Transparent parallel to LVDS encoder support"
> > +config DRM_LVDS_CODEC
>
>
> I'm not CCed on other patches, but I'm pretty sure you should fix other
> Kconfig and defconfigs selecting this config in this patch to avoid breaking
> bisect.
My understanding is that no defconfig and no other option refer directly to
DRM_LVDS_ENCODER, do you mind being a little bit more specific here?
Thanks,
Fab
>
> Neil
>
> > + tristate "Transparent LVDS encoders and decoders support"
> > depends on OF
> > select DRM_KMS_HELPER
> > select DRM_PANEL_BRIDGE
> > help
> > - Support for transparent parallel to LVDS encoders that don't require
> > - any configuration.
> > + Support for transparent LVDS encoders and LVDS decoders that don't
> > + require any configuration.
> >
> > config DRM_MEGACHIPS_STDP_GE_B850V3_FW
> > tristate "MegaChips stdp4028-ge-b850v3-fw and stdp2690-ge-b850v3-fw"
> > diff --git a/drivers/gpu/drm/bridge/Makefile
> > b/drivers/gpu/drm/bridge/Makefile
> > index 4934fcf..8a9178a 100644
> > --- a/drivers/gpu/drm/bridge/Makefile
> > +++ b/drivers/gpu/drm/bridge/Makefile
> > @@ -2,7 +2,7 @@
> > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
> > -obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
> > +obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
> > obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
> > megachips-stdp-ge-b850v3-fw.o
> > obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> > obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> > diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
> > b/drivers/gpu/drm/bridge/lvds-codec.c
> > new file mode 100644
> > index 000..8a1979c
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> > @@ -0,0 +1,169 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Copyright (C) 2016 Laurent Pinchart
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +
> > +struct lvds_codec {
> > + struct drm_bridge bridge;
> > + struct drm_bridge *panel_bridge;
> > + struct gpio_desc *powerdown_gpio;
> > + u32 connector_type;
> > +};
> > +
> > +static int lvds_codec_attach(struct drm_bridge *bridge)
> > +{
> > + struct lvds_codec *lvds_codec = container_of(bridge,
> > +struct lvds_codec,
> > +bridge);
> > +
> > + return drm_bridge_attach(bridge->encoder, lvds_codec->panel_bridge,
> > +bridge);
> > +}
> > +
> > +static void lvds_codec_enable(struct drm_bridge *bridge)
> > +{
> > + struct lvds_codec *lvds_codec = container_of(bridge,
> > +struct lvds_co
[PATCH 4/4] ARM: shmobile_defconfig: Enable support for panels from EDT
The iwg20d comes with an LCD panel from Emerging Display Technologies Corporation (EDT), therefore enable what's required to support it. Signed-off-by: Fabrizio Castro --- arch/arm/configs/shmobile_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig index c6c7035..ab416a5 100644 --- a/arch/arm/configs/shmobile_defconfig +++ b/arch/arm/configs/shmobile_defconfig @@ -66,6 +66,7 @@ CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_GPIO=y # CONFIG_INPUT_MOUSE is not set CONFIG_INPUT_TOUCHSCREEN=y +CONFIG_TOUCHSCREEN_EDT_FT5X06=y CONFIG_TOUCHSCREEN_ST1232=y CONFIG_INPUT_MISC=y CONFIG_INPUT_ADXL34X=y @@ -125,7 +126,9 @@ CONFIG_VIDEO_ADV7604=y CONFIG_VIDEO_ML86V7667=y CONFIG_DRM=y CONFIG_DRM_RCAR_DU=y +CONFIG_DRM_PANEL_SIMPLE=y CONFIG_DRM_DUMB_VGA_DAC=y +CONFIG_DRM_LVDS_CODEC=y CONFIG_DRM_SII902X=y CONFIG_DRM_I2C_ADV7511=y CONFIG_DRM_I2C_ADV7511_AUDIO=y -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] dt-bindings: display: bridge: Repurpose lvds-encoder
In an effort to repurpose lvds-encoder.c to also serve the
function of LVDS decoders, we ended up defining a new "generic"
compatible string, therefore adapt the dt-bindings to fit the
new purpose.
Signed-off-by: Fabrizio Castro
---
.../bindings/display/bridge/lvds-codec.txt | 100 +
.../bindings/display/bridge/lvds-transmitter.txt | 66 --
2 files changed, 100 insertions(+), 66 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/bridge/lvds-codec.txt
delete mode 100644
Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.txt
b/Documentation/devicetree/bindings/display/bridge/lvds-codec.txt
new file mode 100644
index 000..45fd81c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.txt
@@ -0,0 +1,100 @@
+Trasnparent LVDS encoders and LVDS decoders
+---
+
+This binding supports transparent LVDS encoders and LVDS decoders that don't
+require any configuration.
+
+LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. Multiple
+incompatible data link layers have been used over time to transmit image data
+to LVDS panels. This binding targets devices compatible with the following
+specifications only.
+
+[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February
+1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA)
+[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
+Semiconductor
+[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video
+Electronics Standards Association (VESA)
+
+Those devices have been marketed under the FPD-Link and FlatLink brand names
+among others.
+
+
+Required properties:
+
+- compatible: Must be "lvds-encoder" for LVDS encoders or "lvds-decoder" for
+ LVDS decoders.
+
+ Any encoder compatible with this generic binding, but with additional
+ properties not listed here, must list a device specific compatible first
+ followed by the generic compatible.
+
+Required nodes:
+
+This device has two video ports. Their connections are modeled using the OF
+graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+For LVDS encoders:
+- Video port 0 for parallel input
+- Video port 1 for LVDS output
+
+For LVDS decoders:
+- Video port 0 for LVDS input
+- Video port 1 for parallel output
+
+
+LVDS encoder example
+
+
+lvds-encoder {
+ compatible = "lvds-encoder";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ lvds_enc_in: endpoint {
+ remote-endpoint = <_out_rgb>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ lvds_enc_out: endpoint {
+ remote-endpoint = <_panel_in>;
+ };
+ };
+ };
+};
+
+LVDS decoder example
+
+
+lvds-decoder {
+ compatible = "lvds-decoder";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ lvds_dec_in: endpoint {
+ remote-endpoint = <_out_lvds>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ lvds_dec_out: endpoint {
+ remote-endpoint = <_panel_in>;
+ };
+ };
+ };
+};
diff --git
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
deleted file mode 100644
index 60091db..000
--- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
+++ /dev/null
@@ -1,66 +0,0 @@
-Parallel to LVDS Encoder
-
-
-This binding supports the parallel to LVDS encoders that don't require any
-configuration.
-
-LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. Multiple
-incompatible data link layers have been used over time to transmit image data
-to LVDS panels. This binding targets devices compatible with the following
-specifications only.
-
-[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February
-1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA)
-[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
-Semiconductor
-[VESA] "VESA Notebook Panel Standard", October 2007
[PATCH 1/4] drm/bridge: Repurpose lvds-encoder.c
lvds-encoder.c implementation is also suitable for LVDS decoders,
not just LVDS encoders.
Instead of creating a new driver for addressing support for
transparent LVDS decoders, repurpose lvds-encoder.c for the greater
good.
Signed-off-by: Fabrizio Castro
---
drivers/gpu/drm/bridge/Kconfig| 8 +-
drivers/gpu/drm/bridge/Makefile | 2 +-
drivers/gpu/drm/bridge/lvds-codec.c | 169 ++
drivers/gpu/drm/bridge/lvds-encoder.c | 155 ---
4 files changed, 174 insertions(+), 160 deletions(-)
create mode 100644 drivers/gpu/drm/bridge/lvds-codec.c
delete mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3436297..9e75ca4e 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -45,14 +45,14 @@ config DRM_DUMB_VGA_DAC
Support for non-programmable RGB to VGA DAC bridges, such as ADI
ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs.
-config DRM_LVDS_ENCODER
- tristate "Transparent parallel to LVDS encoder support"
+config DRM_LVDS_CODEC
+ tristate "Transparent LVDS encoders and decoders support"
depends on OF
select DRM_KMS_HELPER
select DRM_PANEL_BRIDGE
help
- Support for transparent parallel to LVDS encoders that don't require
- any configuration.
+ Support for transparent LVDS encoders and LVDS decoders that don't
+ require any configuration.
config DRM_MEGACHIPS_STDP_GE_B850V3_FW
tristate "MegaChips stdp4028-ge-b850v3-fw and stdp2690-ge-b850v3-fw"
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 4934fcf..8a9178a 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,7 +2,7 @@
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
-obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
+obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
b/drivers/gpu/drm/bridge/lvds-codec.c
new file mode 100644
index 000..8a1979c
--- /dev/null
+++ b/drivers/gpu/drm/bridge/lvds-codec.c
@@ -0,0 +1,169 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2016 Laurent Pinchart
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+struct lvds_codec {
+ struct drm_bridge bridge;
+ struct drm_bridge *panel_bridge;
+ struct gpio_desc *powerdown_gpio;
+ u32 connector_type;
+};
+
+static int lvds_codec_attach(struct drm_bridge *bridge)
+{
+ struct lvds_codec *lvds_codec = container_of(bridge,
+struct lvds_codec,
+bridge);
+
+ return drm_bridge_attach(bridge->encoder, lvds_codec->panel_bridge,
+bridge);
+}
+
+static void lvds_codec_enable(struct drm_bridge *bridge)
+{
+ struct lvds_codec *lvds_codec = container_of(bridge,
+struct lvds_codec,
+bridge);
+
+ if (lvds_codec->powerdown_gpio)
+ gpiod_set_value_cansleep(lvds_codec->powerdown_gpio, 0);
+}
+
+static void lvds_codec_disable(struct drm_bridge *bridge)
+{
+ struct lvds_codec *lvds_codec = container_of(bridge,
+struct lvds_codec,
+bridge);
+
+ if (lvds_codec->powerdown_gpio)
+ gpiod_set_value_cansleep(lvds_codec->powerdown_gpio, 1);
+}
+
+static struct drm_bridge_funcs funcs = {
+ .attach = lvds_codec_attach,
+ .enable = lvds_codec_enable,
+ .disable = lvds_codec_disable,
+};
+
+static int lvds_codec_probe(struct platform_device *pdev)
+{
+ struct device *dev = >dev;
+ struct device_node *port;
+ struct device_node *endpoint;
+ struct device_node *panel_node;
+ struct drm_panel *panel;
+ struct lvds_codec *lvds_codec;
+
+ lvds_codec = devm_kzalloc(dev, sizeof(*lvds_codec), GFP_KERNEL);
+ if (!lvds_codec)
+ return -ENOMEM;
+
+ lvds_codec->connector_type = (u32)
+ of_device_get_match_data(>dev);
+ lvds_codec->powerdown_gpio = devm_gpiod_get_optional(dev, "powerdown",
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(lvds_codec->powerd
[PATCH 3/4] ARM: dts: iwg20d-q7-common: Add LCD support
The iwg20d comes with a 7" capacitive touch screen, therefore
add support for it.
Signed-off-by: Fabrizio Castro
---
arch/arm/boot/dts/iwg20d-q7-common.dtsi | 85
arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi | 1 -
2 files changed, 85 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
index ae75a1db..3428b8d 100644
--- a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
@@ -46,6 +46,49 @@
clock-frequency = <2600>;
};
+ lcd_backlight: backlight {
+ compatible = "pwm-backlight";
+
+ pwms = < 0 500 0>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <7>;
+ enable-gpios = < 14 GPIO_ACTIVE_HIGH>;
+ };
+
+ lvds-receiver {
+ compatible = "lvds-decoder";
+ powerdown = < 25 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ lvds_receiver_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ lvds_receiver_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+ };
+
+ panel {
+ compatible = "edt,etm0700g0dh6", "simple-panel";
+ backlight = <_backlight>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <_receiver_out>;
+ };
+ };
+ };
+
reg_1p5v: 1p5v {
compatible = "regulator-fixed";
regulator-name = "1P5V";
@@ -120,6 +163,18 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
+ {
+ touch-interrupt {
+ gpio-hog;
+ gpios = <12 GPIO_ACTIVE_LOW>;
+ input;
+ };
+};
+
{
status = "okay";
pinctrl-0 = <_pins>;
@@ -147,6 +202,25 @@
VDDIO-supply = <_3p3v>;
VDDD-supply = <_1p5v>;
};
+
+ touch: touchpanel@38 {
+ compatible = "edt,edt-ft5406";
+ reg = <0x38>;
+ interrupt-parent = <>;
+ interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
+ };
+};
+
+ {
+ status = "okay";
+
+ ports {
+ port@1 {
+ lvds0_out: endpoint {
+ remote-endpoint = <_receiver_in>;
+ };
+ };
+ };
};
{
@@ -180,6 +254,11 @@
function = "i2c2";
};
+ pwm3_pins: pwm3 {
+ groups = "pwm3";
+ function = "pwm3";
+ };
+
scif0_pins: scif0 {
groups = "scif0_data_d";
function = "scif0";
@@ -218,6 +297,12 @@
};
};
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
_sound {
pinctrl-0 = <_pins>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
b/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
index 0e99df2..ede2e0c 100644
--- a/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
@@ -39,7 +39,6 @@
{
pinctrl-0 = <_pins>;
pinctrl-names = "default";
- status = "okay";
ports {
port@0 {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] Add LCD panel support to iwg20d
The iW-RainboW-G20D-Qseven RZ/G1M,G1N Qseven Development Platform comes with a 7" capacitive display kit from Emerging Display Technologies Corporation (EDT). This series adds all that's necessary for supporting it. Thanks, Fab Fabrizio Castro (4): drm/bridge: Repurpose lvds-encoder.c dt-bindings: display: bridge: Repurpose lvds-encoder ARM: dts: iwg20d-q7-common: Add LCD support ARM: shmobile_defconfig: Enable support for panels from EDT .../bindings/display/bridge/lvds-codec.txt | 100 .../bindings/display/bridge/lvds-transmitter.txt | 66 arch/arm/boot/dts/iwg20d-q7-common.dtsi| 85 +++ arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi | 1 - arch/arm/configs/shmobile_defconfig| 3 + drivers/gpu/drm/bridge/Kconfig | 8 +- drivers/gpu/drm/bridge/Makefile| 2 +- drivers/gpu/drm/bridge/lvds-codec.c| 169 + drivers/gpu/drm/bridge/lvds-encoder.c | 155 --- 9 files changed, 362 insertions(+), 227 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/lvds-codec.txt delete mode 100644 Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt create mode 100644 drivers/gpu/drm/bridge/lvds-codec.c delete mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v3 0/8] Add dual-LVDS panel support to EK874
Hi Laurent, Did you have any time to look into this series? Thanks, Fab > From: Fabrizio Castro > Sent: 28 August 2019 19:37 > Subject: [PATCH v3 0/8] Add dual-LVDS panel support to EK874 > > Dear All, > > this series adds support for dual-LVDS panel IDK-2121WR > from Advantech: > https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.htm > > V3 approaches the problem in a completely different way, we now > have two new properties to mark the ports in the DT as receiving > even pixels and odd pixels: dual-lvds-even-pixels and dual-lvds-odd-pixels, > which means device drivers should not use bridge specific or panel > specific dual_link flags. Also, in this case the DT describes the > connection fully. > > In order for the solution to be generic, I have exported a new helper > (drm_of_lvds_get_dual_link_configuration) to walk the device tree, > and figure out if the connection is dual-LVDS. The same helper gives > information about the configuration of the connection. If Px is connected > to a port expecting even pixels and Py is connected to a port expecting > odd pixels, then the helper returns DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS > (like in the example below), otherwise it returns > DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS. > > > dual-lvds-even-pixels > || || > || Px |-->| Pn || > || || > | SOURCE | dual-lvds-odd-pixels | SINK | > || || > || Py |-->| Pm || > || || > > > The device driver for the encoder then will work out if with the current > wiring the pixels need swapping or not. > > The same solution works for both panels and bridges. > > Since the DT describes the connection fully, driver > drivers/gpu/drm/panel/panel-lvds.c works out-of-the-box, no changes > required, however, this implementation opens up a problem with the > dt-bindings. > Driver drivers/gpu/drm/panel/panel-lvds.c can still be pleased by > a port node, but also by a ports node. > I have created Documentation/devicetree/bindings/display/bus-timings/lvds.yaml > with the idea of including it from panels and bridges dt-bindings > supporting dual-LVDS (and of course the dt-bindings for the specific > devices should say which port should be marked as what), but file > Documentation/devicetree/bindings/display/panel/lvds.yaml formally > requires property "port", while with this implementation it should require > OneOf "port" and "ports", and unfortunately I can't seem to find a neat way > aroud that, other than creating a new compatible string > (e.g. "panel-dual-lvds"), a new dt-binding document for it, and of course > adding > support for the new compatible string to drivers/gpu/drm/panel/panel-lvds.c. > As a result, this series is missing (at least) a patch necessary to fully > document the new implementation within > Documentation/devicetree/bindings/display/panel/lvds.yaml > > Rob, do you have any suggestions? Do you think this idea works ok from a > documentation point of view? By the way, I don't really know what I am doing > with the yaml dt-bindings, I hope you won't be horrified by this series :-P > > I hope I was able to deliver the concept clearly, if not please just ask. > > Comments are very much appreciated. > > Thanks, > Fab > > Fabrizio Castro (8): > dt-bindings: display: Add bindings for LVDS bus-timings > dt-bindings: display: Add idk-2121wr binding > drm: Add bus timings helper > drm: rcar-du: lvds: Add dual-LVDS panels support > drm: bridge: thc63: Do not report input bus mode through bridge > timings > arm64: dts: renesas: Add EK874 board with idk-2121wr display support > [HACK] arm64: dts: renesas: draak: Enable LVDS > [HACK] arm64: dts: renesas: draak: Enable LVDS dual-link operation > > .../bindings/display/bus-timings/lvds.yaml | 38 +++ > .../display/panel/advantech,idk-2121wr.yaml| 90 > arch/arm64/boot/dts/renesas/Makefile | 3 +- > .../boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts | 116 > + > arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 21 +++- > arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 26 +++-- > drivers/gpu/drm/Makefile | 3 +- > drivers/gpu/drm/bridge/thc63lvd1024.c | 9 +- > drivers/gpu/drm/drm_bus_timin
RE: [PATCH v3 0/8] Add dual-LVDS panel support to EK874
Hi Rob, Thank you for your feedback! > From: Rob Herring > Sent: 29 August 2019 16:27 > To: Fabrizio Castro > Subject: Re: [PATCH v3 0/8] Add dual-LVDS panel support to EK874 > > On Wed, Aug 28, 2019 at 1:36 PM Fabrizio Castro > wrote: > > > > Dear All, > > > > this series adds support for dual-LVDS panel IDK-2121WR > > from Advantech: > > https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.htm > > > > V3 approaches the problem in a completely different way, we now > > have two new properties to mark the ports in the DT as receiving > > even pixels and odd pixels: dual-lvds-even-pixels and dual-lvds-odd-pixels, > > which means device drivers should not use bridge specific or panel > > specific dual_link flags. Also, in this case the DT describes the > > connection fully. > > > > In order for the solution to be generic, I have exported a new helper > > (drm_of_lvds_get_dual_link_configuration) to walk the device tree, > > and figure out if the connection is dual-LVDS. The same helper gives > > information about the configuration of the connection. If Px is connected > > to a port expecting even pixels and Py is connected to a port expecting > > odd pixels, then the helper returns DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS > > (like in the example below), otherwise it returns > > DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS. > > > > > > dual-lvds-even-pixels > > || || > > || Px |-->| Pn || > > || || > > | SOURCE | dual-lvds-odd-pixels | SINK | > > || || > > || Py |-->| Pm || > > || || > > > > > > The device driver for the encoder then will work out if with the current > > wiring the pixels need swapping or not. > > > > The same solution works for both panels and bridges. > > > > Since the DT describes the connection fully, driver > > drivers/gpu/drm/panel/panel-lvds.c works out-of-the-box, no changes > > required, however, this implementation opens up a problem with the > > dt-bindings. > > Driver drivers/gpu/drm/panel/panel-lvds.c can still be pleased by > > a port node, but also by a ports node. > > I have created > > Documentation/devicetree/bindings/display/bus-timings/lvds.yaml > > with the idea of including it from panels and bridges dt-bindings > > supporting dual-LVDS (and of course the dt-bindings for the specific > > devices should say which port should be marked as what), but file > > Documentation/devicetree/bindings/display/panel/lvds.yaml formally > > requires property "port", while with this implementation it should require > > OneOf "port" and "ports", and unfortunately I can't seem to find a neat way > > aroud that, other than creating a new compatible string > > Just add 'ports' and drop 'port' from being required in the common > binding. Then it is up to the panel specific bindings to define which > one is required. Or we just leave it to allow either form which the > graph code can handle. > > We could have this in the common binding: > > oneOf: > - required: [ports] > - required: [port] Thank you for Rob for looking into this. I will wait for a feedback from Laurent on the code before sending out v4. Thanks, Fab > > Rob
RE: [PATCH v3 1/8] dt-bindings: display: Add bindings for LVDS bus-timings
Hi Rob, Thank you for your feedback! > From: Rob Herring > Sent: 29 August 2019 15:03 > Subject: Re: [PATCH v3 1/8] dt-bindings: display: Add bindings for LVDS > bus-timings > > On Wed, Aug 28, 2019 at 1:36 PM Fabrizio Castro > wrote: > > > > Dual-LVDS connections need markers in the DT, this patch adds > > some common documentation to be referenced by both panels and > > bridges. > > > > Signed-off-by: Fabrizio Castro > > > > --- > > v2->v3: > > * new patch > > --- > > .../bindings/display/bus-timings/lvds.yaml | 38 > > ++ > > 1 file changed, 38 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/bus-timings/lvds.yaml > > > > diff --git > > a/Documentation/devicetree/bindings/display/bus-timings/lvds.yaml > > b/Documentation/devicetree/bindings/display/bus- > timings/lvds.yaml > > new file mode 100644 > > index 000..f35b55a > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/bus-timings/lvds.yaml > > @@ -0,0 +1,38 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > (GPL-2.0-only OR BSD-2-Clause) is preferred for new bindings. > > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/display/bus-timings/lvds.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Common Properties for bus timings of LVDS interfaces > > + > > +maintainers: > > + - Thierry Reding > > + - Fabrizio Castro > > + > > +description: | > > + This document defines device tree properties common to LVDS and dual-LVDS > > + interfaces, where a dual-LVDS interface is a dual-link connection with > > even > > + pixels traveling on one connection, and with odd pixels traveling on the > > other > > + connection. > > + This document doesn't constitue a device tree binding specification by > > itself > > typo: constitute Well spotted! > > > + but is meant to be referenced by device tree bindings. > > + When referenced from panel or bridge device tree bindings, the properties > > + defined in this document are defined as follows. The panel and bridge > > device > > + tree bindings are responsible for defining whether each property is > > required > > + or optional. > > + > > +properties: > > + dual-lvds-even-pixels: > > +type: boolean > > +description: > > + This property is specific to an input port of a sink device. When > > The schema should define what nodes these go in. The description seems > to indicate in 'port' nodes (or endpoint?), but your use in the panel > binding puts them in the parent. Did you manage to read this? https://patchwork.kernel.org/cover/9607/ Could you please advice on how to do this properly? > > > + specified, it marks the port as recipient of even-pixels. > > + > > + dual-lvds-odd-pixels: > > +type: boolean > > +description: > > + This property is specific to an input port of a sink device. When > > + specified, it marks the port as recipient of odd-pixels. > > However, I don't think you even need these. A panel's port numbers are > fixed can imply even or odd. For example port@0 can be even and port@1 > can be odd. The port numbering is typically panel specific, but we may > be able to define the numbering generically if we don't already have > panels with multiple ports. > > Also, aren't there dual link DSI panels? This is the result of a discussion on here: https://patchwork.kernel.org/patch/11095547/ Have you come across it? Thanks! Fab > > Rob
[PATCH v2 1/2] dt-bindings: display: Add idk-1110wr binding
Add binding for the idk-1110wr LVDS panel from Advantech.
Some panel-specific documentation can be found here:
https://buy.advantech.eu/Displays/Embedded-LCD-Kits-LCD-Kit-Modules/model-IDK-1110WR-55WSA1E.htm
Signed-off-by: Fabrizio Castro
---
v1->v2:
* no change
.../display/panel/advantech,idk-1110wr.yaml| 69 ++
1 file changed, 69 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
b/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
new file mode 100644
index 000..e5fdaa0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/advantech,idk-1110wr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Advantech IDK-1110WR 10.1" WSVGA LVDS Display Panel
+
+maintainers:
+ - Fabrizio Castro
+ - Thierry Reding
+
+allOf:
+ - $ref: lvds.yaml#
+
+properties:
+ compatible:
+items:
+ - const: advantech,idk-1110wr
+ - {} # panel-lvds, but not listed here to avoid false select
+
+ data-mapping:
+const: jeida-24
+
+ width-mm:
+const: 223
+
+ height-mm:
+const: 125
+
+ panel-timing: true
+ port: true
+
+additionalProperties: false
+
+required:
+ - compatible
+
+examples:
+ - |+
+panel {
+ compatible = "advantech,idk-1110wr", "panel-lvds";
+
+ width-mm = <223>;
+ height-mm = <125>;
+
+ data-mapping = "jeida-24";
+
+ panel-timing {
+/* 1024x600 @60Hz */
+clock-frequency = <5120>;
+hactive = <1024>;
+vactive = <600>;
+hsync-len = <240>;
+hfront-porch = <40>;
+hback-porch = <40>;
+vsync-len = <10>;
+vfront-porch = <15>;
+vback-porch = <10>;
+ };
+
+ port {
+panel_in: endpoint {
+ remote-endpoint = <_encoder>;
+};
+ };
+};
+
+...
--
2.7.4
[PATCH v2 2/2] arm64: dts: renesas: Add HiHope RZ/G2M board with idk-1110wr display
The HiHope RZ/G2M is advertised as compatible with panel idk-1110wr
from Advantech, however the panel isn't sold alongside the board.
A new dts, adding everything that's required to get the panel to
work the HiHope RZ/G2M, is the most convenient way to support the
HiHope RZ/G2M when it's connected to the idk-1110wr.
Signed-off-by: Fabrizio Castro
---
v1->v2:
* added space between lvds-connector-en-gpio and curly brace
arch/arm64/boot/dts/renesas/Makefile | 1 +
.../r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts| 86 ++
2 files changed, 87 insertions(+)
create mode 100644
arch/arm64/boot/dts/renesas/r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts
diff --git a/arch/arm64/boot/dts/renesas/Makefile
b/arch/arm64/boot/dts/renesas/Makefile
index 42b74c2..5d94301 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m.dtb
dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m-ex.dtb
+dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m-ex-idk-1110wr.dtb
dtb-$(CONFIG_ARCH_R8A774C0) += r8a774c0-cat874.dtb r8a774c0-ek874.dtb
dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-salvator-x.dtb r8a7795-h3ulcb.dtb
dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-h3ulcb-kf.dtb
diff --git
a/arch/arm64/boot/dts/renesas/r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts
b/arch/arm64/boot/dts/renesas/r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts
new file mode 100644
index 000..67fe04c
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts
@@ -0,0 +1,86 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the HiHope RZ/G2M sub board connected to an
+ * Advantech IDK-1110WR 10.1" LVDS panel
+ *
+ * Copyright (C) 2019 Renesas Electronics Corp.
+ */
+
+#include "r8a774a1-hihope-rzg2m-ex.dts"
+
+/ {
+ backlight {
+ compatible = "pwm-backlight";
+ pwms = < 0 5>;
+
+ brightness-levels = <0 2 8 16 32 64 128 255>;
+ default-brightness-level = <6>;
+ };
+
+ panel-lvds {
+ compatible = "advantech,idk-1110wr", "panel-lvds";
+
+ width-mm = <223>;
+ height-mm = <125>;
+
+ data-mapping = "jeida-24";
+
+ panel-timing {
+ /* 1024x600 @60Hz */
+ clock-frequency = <5120>;
+ hactive = <1024>;
+ vactive = <600>;
+ hsync-len = <240>;
+ hfront-porch = <40>;
+ hback-porch = <40>;
+ vfront-porch = <15>;
+ vback-porch = <10>;
+ vsync-len = <10>;
+ };
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+};
+
+ {
+ /*
+* When GP1_20 is LOW LVDS0 is connected to the LVDS connector
+* When GP1_20 is HIGH LVDS0 is connected to the LT8918L
+*/
+ lvds-connector-en-gpio {
+ gpio-hog;
+ gpios = <20 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "lvds-connector-en-gpio";
+ };
+};
+
+ {
+ status = "okay";
+
+ ports {
+ port@1 {
+ lvds0_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+};
+
+ {
+ pwm0_pins: pwm0 {
+ groups = "pwm0";
+ function = "pwm0";
+ };
+};
+
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
--
2.7.4
[PATCH v2 0/2] Add LVDS panel support to HiHope RZ/G2M
Dear All, the HiHope RZ/G2M is advertised as supporting panel idk-1110wr from Advantech, but the panel doesn't come with the board, it has to purchased separatey, therefore this series adds panel support to a new DT. v1->v2 * fixed a space according to Geert's feedback. Thanks, Fab Fabrizio Castro (2): dt-bindings: display: Add idk-1110wr binding arm64: dts: renesas: Add HiHope RZ/G2M board with idk-1110wr display .../display/panel/advantech,idk-1110wr.yaml| 69 + arch/arm64/boot/dts/renesas/Makefile | 1 + .../r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts| 86 ++ 3 files changed, 156 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml create mode 100644 arch/arm64/boot/dts/renesas/r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts -- 2.7.4
RE: [PATCH 2/2] arm64: dts: renesas: Add HiHope RZ/G2M board with idk-1110wr display
Hi Geert,
Thank you for your feedback!
> From: Geert Uytterhoeven
> Sent: 29 August 2019 11:51
> Subject: Re: [PATCH 2/2] arm64: dts: renesas: Add HiHope RZ/G2M board with
> idk-1110wr display
>
> Hi Fabrizio,
>
> On Thu, Aug 29, 2019 at 12:22 PM Fabrizio Castro
> wrote:
> > The HiHope RZ/G2M is advertised as compatible with panel idk-1110wr
> > from Advantech, however the panel isn't sold alongside the board.
> > A new dts, adding everything that's required to get the panel to
> > work the HiHope RZ/G2M, is the most convenient way to support the
> > HiHope RZ/G2M when it's connected to the idk-1110wr.
> >
> > Signed-off-by: Fabrizio Castro
>
> Thanks for your patch!
>
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/renesas/r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts
>
> > + {
> > + /*
> > +* When GP1_20 is LOW LVDS0 is connected to the LVDS connector
> > +* When GP1_20 is HIGH LVDS0 is connected to the LT8918L
> > +*/
> > + lvds-connector-en-gpio{
>
> Missing space before curly brace.
Doh, thank you for spotting this, I'll send a v2.
Cheers,
Fab
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
[PATCH 0/2] Add LVDS panel support to HiHope RZ/G2M
Dear All, the HiHope RZ/G2M is advertised as supporting panel idk-1110wr from Advantech, but the panel doesn't come with the board, it has to purchased separatey, therefore this series adds panel support to a new DT. Thanks, Fab Fabrizio Castro (2): dt-bindings: display: Add idk-1110wr binding arm64: dts: renesas: Add HiHope RZ/G2M board with idk-1110wr display .../display/panel/advantech,idk-1110wr.yaml| 69 + arch/arm64/boot/dts/renesas/Makefile | 1 + .../r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts| 86 ++ 3 files changed, 156 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml create mode 100644 arch/arm64/boot/dts/renesas/r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts -- 2.7.4
