From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rui Miguel Silva Subject: Re: [PATCH v14 08/13] ARM: dts: imx7: Add video mux, csi and mipi_csi and connections Date: Tue, 12 Mar 2019 14:05:24 +0000 Message-ID: References: <20190206151328.21629-1-rui.silva@linaro.org> <20190206151328.21629-9-rui.silva@linaro.org> <20190310214102.GA7578@pendragon.ideasonboard.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-reply-to: <20190310214102.GA7578@pendragon.ideasonboard.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" To: Laurent Pinchart Cc: devel@driverdev.osuosl.org, devicetree@vger.kernel.org, sakari.ailus@linux.intel.com, Greg Kroah-Hartman , Hans Verkuil , Philipp Zabel , Steve Longerbeam , linux-media@vger.kernel.org List-Id: devicetree@vger.kernel.org Hi Laurent, On Sun 10 Mar 2019 at 21:41, Laurent Pinchart wrote: > Hi Rui, > > Thank you for the patch. Where have you been for the latest 14 versions? :) This is already merged, but... follow up patches can address your issues bellow. > > On Wed, Feb 06, 2019 at 03:13:23PM +0000, Rui Miguel Silva > wrote: >> This patch adds the device tree nodes for csi, video >> multiplexer and >> mipi-csi besides the graph connecting the necessary endpoints >> to make >> the media capture entities to work in imx7 Warp board. >> >> Signed-off-by: Rui Miguel Silva >> --- >> arch/arm/boot/dts/imx7s-warp.dts | 51 >> ++++++++++++++++++++++++++++++++ >> arch/arm/boot/dts/imx7s.dtsi | 27 +++++++++++++++++ > > I would have split this in two patches to make backporting > easier, but > it's not a big deal. > > Please see below for a few additional comments. > >> 2 files changed, 78 insertions(+) >> >> diff --git a/arch/arm/boot/dts/imx7s-warp.dts >> b/arch/arm/boot/dts/imx7s-warp.dts >> index 23431faecaf4..358bcae7ebaf 100644 >> --- a/arch/arm/boot/dts/imx7s-warp.dts >> +++ b/arch/arm/boot/dts/imx7s-warp.dts >> @@ -277,6 +277,57 @@ >> status = "okay"; >> }; >> >> +&gpr { >> + csi_mux { >> + compatible = "video-mux"; >> + mux-controls = <&mux 0>; >> + #address-cells = <1>; >> + #size-cells = <0>; >> + >> + port@1 { >> + reg = <1>; >> + >> + csi_mux_from_mipi_vc0: endpoint { >> + remote-endpoint = >> <&mipi_vc0_to_csi_mux>; >> + }; >> + }; >> + >> + port@2 { >> + reg = <2>; >> + >> + csi_mux_to_csi: endpoint { >> + remote-endpoint = >> <&csi_from_csi_mux>; >> + }; >> + }; >> + }; >> +}; >> + >> +&csi { >> + status = "okay"; >> + >> + port { >> + csi_from_csi_mux: endpoint { >> + remote-endpoint = <&csi_mux_to_csi>; >> + }; >> + }; >> +}; > > Shouldn't these two nodes, as well as port@1 of the mipi_csi > node, be > moved to imx7d.dtsi ? Yeah, I guess you are right here. > >> + >> +&mipi_csi { >> + clock-frequency = <166000000>; >> + status = "okay"; >> + #address-cells = <1>; >> + #size-cells = <0>; >> + fsl,csis-hs-settle = <3>; > > Shouldn't this be an endpoint property ? Different sensors > connected > through different endpoints could have different timing > requirements. Hum... I see you point, even tho the phy hs-settle is a common control. > >> + >> + port@1 { >> + reg = <1>; >> + >> + mipi_vc0_to_csi_mux: endpoint { >> + remote-endpoint = >> <&csi_mux_from_mipi_vc0>; >> + }; >> + }; >> +}; >> + >> &wdog1 { >> pinctrl-names = "default"; >> pinctrl-0 = <&pinctrl_wdog>; >> diff --git a/arch/arm/boot/dts/imx7s.dtsi >> b/arch/arm/boot/dts/imx7s.dtsi >> index 792efcd2caa1..01962f85cab6 100644 >> --- a/arch/arm/boot/dts/imx7s.dtsi >> +++ b/arch/arm/boot/dts/imx7s.dtsi >> @@ -8,6 +8,7 @@ >> #include >> #include >> #include >> +#include >> #include "imx7d-pinfunc.h" >> >> / { >> @@ -709,6 +710,17 @@ >> status = "disabled"; >> }; >> >> + csi: csi@30710000 { >> + compatible = "fsl,imx7-csi"; >> + reg = <0x30710000 0x10000>; >> + interrupts = > IRQ_TYPE_LEVEL_HIGH>; >> + clocks = <&clks IMX7D_CLK_DUMMY>, >> + <&clks >> IMX7D_CSI_MCLK_ROOT_CLK>, >> + <&clks >> IMX7D_CLK_DUMMY>; >> + clock-names = "axi", "mclk", >> "dcic"; >> + status = "disabled"; >> + }; >> + >> lcdif: lcdif@30730000 { >> compatible = "fsl,imx7d-lcdif", >> "fsl,imx28-lcdif"; >> reg = <0x30730000 0x10000>; >> @@ -718,6 +730,21 @@ >> clock-names = "pix", "axi"; >> status = "disabled"; >> }; >> + >> + mipi_csi: mipi-csi@30750000 { >> + compatible = "fsl,imx7-mipi-csi2"; >> + reg = <0x30750000 0x10000>; >> + interrupts = > IRQ_TYPE_LEVEL_HIGH>; >> + clocks = <&clks >> IMX7D_IPG_ROOT_CLK>, >> + <&clks >> IMX7D_MIPI_CSI_ROOT_CLK>, >> + <&clks >> IMX7D_MIPI_DPHY_ROOT_CLK>; >> + clock-names = "pclk", "wrap", >> "phy"; >> + power-domains = <&pgc_mipi_phy>; >> + phy-supply = <®_1p0d>; >> + resets = <&src >> IMX7_RESET_MIPI_PHY_MRST>; >> + reset-names = "mrst"; >> + status = "disabled"; > > How about already declaring port@0 here too (but obviously > without any > endoint) ? empty port, do not know if they make much sense. --- Cheers, Rui