devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Andrzej Hajda <a.hajda@samsung.com>
Cc: Maciej Purski <m.purski@samsung.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-samsung-soc@vger.kernel.org, devicetree@vger.kernel.org,
	dri-devel@lists.freedesktop.org, David Airlie <airlied@linux.ie>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Kukjin Kim <kgene@kernel.org>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Archit Taneja <architt@codeaurora.org>,
	Inki Dae <inki.dae@samsung.com>,
	Joonyoung Shim <jy0922.shim@samsung.com>,
	Seung-Woo Kim <sw0312.kim@samsung.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Subject: Re: [PATCH 07/12] dt-bindings: tc358754: add DT bindings
Date: Wed, 30 May 2018 16:20:15 +0300	[thread overview]
Message-ID: <2964003.icRy2MNiaL@avalon> (raw)
In-Reply-To: <20180530130731eucas1p160d53c3f8500bcecd000bd8895843817~zbgGgQw3b1079710797eucas1p1H@eucas1p1.samsung.com>

Hi Andrzej,

On Wednesday, 30 May 2018 16:07:29 EEST Andrzej Hajda wrote:
> On 30.05.2018 14:35, Laurent Pinchart wrote:
> > On Wednesday, 30 May 2018 12:59:12 EEST Andrzej Hajda wrote:
> >> On 28.05.2018 12:18, Laurent Pinchart wrote:
> >>> On Monday, 28 May 2018 12:47:11 EEST Maciej Purski wrote:
> >>>> The patch adds bindings to Toshiba DSI/LVDS bridge TC358764.
> >>>> Bindings describe power supplies, reset gpio and video interfaces.
> >>>> 
> >>>> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
> >>>> Signed-off-by: Maciej Purski <m.purski@samsung.com>
> >>>> ---
> >>>> 
> >>>>  .../bindings/display/bridge/toshiba,tc358764.txt   | 42
> >>>>  ++++++++++++++++
> >>>>  1 file changed, 42 insertions(+)
> >>>>  create mode 100644
> >>>> 
> >>>> Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
> >>>> 
> >>>> diff --git
> >>>> a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
> >>>> b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
> >>>> new
> >>>> file mode 100644
> >>>> index 0000000..d09bdc2
> >>>> --- /dev/null
> >>>> +++
> >>>> b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
> >>>> @@ -0,0 +1,42 @@
> >>>> +TC358764 MIPI-DSI to LVDS panel bridge
> >>>> +
> >>>> +Required properties:
> >>>> +  - compatible: "toshiba,tc358764"
> >>>> +  - reg: the virtual channel number of a DSI peripheral
> >>>> +  - vddc-supply: core voltage supply
> >>>> +  - vddio-supply: I/O voltage supply
> >>>> +  - vddmipi-supply: MIPI voltage supply
> >>>> +  - vddlvds133-supply: LVDS1 3.3V voltage supply
> >>>> +  - vddlvds112-supply: LVDS1 1.2V voltage supply
> >>> 
> >>> That's a lot of power supplies. Could some of them be merged together ?
> >>> See https://patchwork.freedesktop.org/patch/216058/ for an earlier
> >>> discussion on the same subject.
> >> 
> >> Specs says about 3 supply voltage values:
> >> - 1.2V - digital core, DSI-RX PHY
> >> - 1.8-3.3V - digital I/O
> >> - 3.3V - LVDS-TX PHY
> >> 
> >> So I guess it should be minimal number of supplies. Natural candidates:
> >> 
> >> - vddc-supply: core voltage supply, 1.2V
> >> - vddio-supply: I/O voltage supply, 1.8V or 3.3V
> >> - vddlvds-supply: LVDS1/2 voltage supply, 3.3V
> >> 
> >> I have changed name of the latest supply to be more consistent with
> >> other supplies, and changed 1.8-3.3 (which incorrectly suggest voltage
> >> range), to more precise voltage alternative.
> > 
> > This looks fine to me.
> > 
> >>>> +  - reset-gpios: a GPIO spec for the reset pin
> >>>> +
> >>>> +The device node can contain zero to two 'port' child nodes, each with
> >>>> one
> >>>> +child
> >>>> +'endpoint' node, according to the bindings defined in [1].
> >>>> +The following are properties specific to those nodes.
> >>>> +
> >>>> +port:
> >>>> +  - reg: (required) can be 0 for DSI port or 1 for LVDS port;
> >>> 
> >>> This seems pretty vague to me. It could be read as meaning that ports
> >>> are
> >>> completely optional, and that the port number you list can be used, but
> >>> that something else could be used to.
> >>> 
> >>> Let's make the port nodes mandatory. I propose the following.
> >>> 
> >>> Required nodes:
> >>> 
> >>> The TC358764 has DSI and LVDS ports whose connections are described
> >>> using
> >>> the OF graph bindings defined in
> >>> Documentation/devicetree/bindings/graph.txt. The device node must
> >>> contain
> >>> one 'port' child node per DSI and LVDS port. The port nodes are numbered
> >>> as follows.
> >>> 
> >>>   Port                  Number
> >>> 
> >>> -------------------------------------------------------------------
> >>> 
> >>>   DSI Input             0
> >>>   LVDS Output           1
> >>> 
> >>> Each port node must contain endpoint nodes describing the hardware
> >>> connections.
> >> 
> >> Since the bridge is controlled via DSI bus, DSI input port is not
> >> necessary.
> > 
> > I don't agree with this. Regardless of how the bridge is controlled, I
> > think we should always use ports to describe the data connections.
> > Otherwise it would get more complicated for display controller drivers to
> > use different types of bridges.
> 
> It was discussed already, and DT guideline is to skip graphs in simple
> case of parent/child nodes, see for example [1].
> 
> [1]: https://marc.info/?l=dri-devel&m=148354108702517&w=2

That's when the child as no other connection at all. I don't think it makes 
sense to mix description of connections through parent/child relationships and 
through ports for a single device.

And that being said, I don't agree with Rob's comment there. Having two 
different methods to describe connections means that you have to implement 
them both in all display controller drivers (and even all bridge drivers in 
the case of chained bridges). That's an extra complexity that can easily be 
avoided by standardizing DT bindings.

I also wonder whether Rob's position hasn't been reconsidered since then; I 
vaguely recalled another more recent discussion on this topic. I'm a bit too 
busy now to try and dig it up now I'm afraid :-/

> >>>> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> >>>> +
> >>>> +Example:
> >>>> +
> >>>> +	bridge@0 {
> >>>> +		reg = <0>;
> >>>> +		compatible = "toshiba,tc358764";
> >>>> +		vddc-supply = <&vcc_1v2_reg>;
> >>>> +		vddio-supply = <&vcc_1v8_reg>;
> >>>> +		vddmipi-supply = <&vcc_1v2_reg>;
> >>>> +		vddlvds133-supply = <&vcc_3v3_reg>;
> >>>> +		vddlvds112-supply = <&vcc_1v2_reg>;
> >>>> +		reset-gpios = <&gpd1 6 GPIO_ACTIVE_LOW>;
> >>>> +		#address-cells = <1>;
> >>>> +		#size-cells = <0>;
> >>>> +		port@1 {
> >>>> +			reg = <1>;
> >>>> +			lvds_ep: endpoint {
> >>>> +				remote-endpoint = <&panel_ep>;
> >>>> +			};
> >>>> +		};
> >>>> +	};

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2018-05-30 13:20 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20180528094721eucas1p22b90fd838ce00f029fec7f5241cc06b5@eucas1p2.samsung.com>
2018-05-28  9:47 ` [PATCH 00/12] Add TOSHIBA TC358764 DSI/LVDS bridge driver Maciej Purski
     [not found]   ` <CGME20180528094722eucas1p28c087e8b9174e0591bf3cb6526885777@eucas1p2.samsung.com>
2018-05-28  9:47     ` [PATCH 01/12] drm/exynos: rename "bridge_node" to "mic_bridge_node" Maciej Purski
     [not found]   ` <CGME20180528094723eucas1p1776829e0b57d2ec6c4e28be872cf88fc@eucas1p1.samsung.com>
2018-05-28  9:47     ` [PATCH 02/12] drm/exynos: move pm_runtime_get_sync() to exynos_dsi_init() Maciej Purski
     [not found]   ` <CGME20180528094724eucas1p17a37e06002ed96d97aaca87231f13bbb@eucas1p1.samsung.com>
2018-05-28  9:47     ` [PATCH 03/12] drm/exynos: move connector creation to attach callback Maciej Purski
     [not found]   ` <CGME20180528094725eucas1p2e80e551edb29dd4ab437246f4896d108@eucas1p2.samsung.com>
2018-05-28  9:47     ` [PATCH 04/12] drm/exynos: add non-panel path to exynos_dsi_enable() Maciej Purski
     [not found]   ` <CGME20180528094726eucas1p14c9d821881865955a4d8b1735a650c8f@eucas1p1.samsung.com>
2018-05-28  9:47     ` [PATCH 05/12] panel/hv070wsa-100: add DT bindings Maciej Purski
     [not found]   ` <CGME20180528094727eucas1p272478562b72a95dac2fc1b03be57c514@eucas1p2.samsung.com>
2018-05-28  9:47     ` [PATCH 06/12] drm/panel: add support for BOE HV070WSA-100 panel to simple-panel Maciej Purski
     [not found]   ` <CGME20180528094727eucas1p153b8116120cd2195b15b74776f171cbe@eucas1p1.samsung.com>
2018-05-28  9:47     ` [PATCH 07/12] dt-bindings: tc358754: add DT bindings Maciej Purski
2018-05-28 10:18       ` Laurent Pinchart
2018-05-30  9:59         ` Andrzej Hajda
2018-05-30 12:35           ` Laurent Pinchart
2018-05-30 13:07             ` Andrzej Hajda
2018-05-30 13:20               ` Laurent Pinchart [this message]
     [not found]   ` <CGME20180528094728eucas1p128e8a44fa6c3bcb29d056a8191c039af@eucas1p1.samsung.com>
2018-05-28  9:47     ` [PATCH 08/12] drm/bridge: tc358764: Add DSI to LVDS bridge driver Maciej Purski
2018-05-28 16:24       ` Randy Dunlap
2018-05-30  7:45       ` kbuild test robot
2018-05-30  8:27         ` Andrzej Hajda
     [not found]   ` <CGME20180528094729eucas1p1cc26ea191a4ee1ba9daa06fae93037bf@eucas1p1.samsung.com>
2018-05-28  9:47     ` [PATCH 09/12] ARM: dts: exynos5250: add mipi-phy node Maciej Purski
2018-05-28 16:24       ` Krzysztof Kozlowski
     [not found]   ` <CGME20180528095444eucas1p222e4054b8fb8997258182e501f37a10b@eucas1p2.samsung.com>
2018-05-28  9:54     ` [PATCH 10/12] ARM: dts: exynos5250: add DSI node Maciej Purski
2018-05-28 16:36       ` Krzysztof Kozlowski
     [not found]   ` <CGME20180528095523eucas1p1039e1b62aaef415b66d6f62e86dbef93@eucas1p1.samsung.com>
2018-05-28  9:55     ` [PATCH 11/12] ARM: dts: exynos5250-arndale: add display regulators Maciej Purski
     [not found]   ` <CGME20180528095555eucas1p2fb61f362a3aa2d0082b8c4001b17f176@eucas1p2.samsung.com>
2018-05-28  9:55     ` [PATCH 12/12] ARM: dts: exynos5250-arndale: add dsi and panel nodes Maciej Purski
2018-05-28 16:41       ` Krzysztof Kozlowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2964003.icRy2MNiaL@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=a.hajda@samsung.com \
    --cc=airlied@linux.ie \
    --cc=architt@codeaurora.org \
    --cc=b.zolnierkie@samsung.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=inki.dae@samsung.com \
    --cc=jy0922.shim@samsung.com \
    --cc=kgene@kernel.org \
    --cc=krzk@kernel.org \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=m.purski@samsung.com \
    --cc=m.szyprowski@samsung.com \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=sw0312.kim@samsung.com \
    --cc=thierry.reding@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).