linux-kernel - Re: Re: [RFC PATCH v1 5/5] arm64: tegra: Add Tegra VI CSI suppport in device tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200130123607.GB2584455@ulmo>
Date:   Thu, 30 Jan 2020 13:36:07 +0100
From:   Thierry Reding <thierry.reding@...il.com>
To:     Sowjanya Komatineni <skomatineni@...dia.com>
Cc:     jonathanh@...dia.com, frankc@...dia.com, hverkuil@...all.nl,
        linux-media@...r.kernel.org, devicetree@...r.kernel.org,
        linux-clk@...r.kernel.org, linux-tegra@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: Re: [RFC PATCH v1 5/5] arm64: tegra: Add Tegra VI CSI suppport
 in device tree

On Wed, Jan 29, 2020 at 08:22:48AM -0800, Sowjanya Komatineni wrote:
> 
> On 1/29/20 1:46 AM, Thierry Reding wrote:
> > On Tue, Jan 28, 2020 at 10:23:21AM -0800, Sowjanya Komatineni wrote:
> > > Tegra210 contains VI controller for video input capture from MIPI
> > > CSI camera sensors and also supports built-in test pattern generator.
> > > 
> > > CSI ports can be one-to-one mapped to VI channels for capturing from
> > > an external sensor or from built-in test pattern generator.
> > > 
> > > This patch adds support for VI and CSI and enables them in Tegra210
> > > device tree.
> > > 
> > > Signed-off-by: Sowjanya Komatineni <skomatineni@...dia.com>
> > > ---
> > >   arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi |  8 +++++++
> > >   arch/arm64/boot/dts/nvidia/tegra210.dtsi       | 31 +++++++++++++++++++++++++-
> > >   2 files changed, 38 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi b/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
> > > index b0095072bc28..ec1b3033fa03 100644
> > > --- a/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
> > > +++ b/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
> > > @@ -10,6 +10,14 @@
> > >   			status = "okay";
> > >   		};
> > > +		vi@...80000 {
> > > +			status = "okay";
> > > +		};
> > > +
> > > +		csi@...4080838 {
> > > +			status = "okay";
> > > +		};
> > > +
> > >   		sor@...80000 {
> > >   			status = "okay";
> > > diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> > > index 48c63256ba7f..c6107ec03ad1 100644
> > > --- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> > > +++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> > > @@ -136,9 +136,38 @@
> > >   		vi@...80000 {
> > >   			compatible = "nvidia,tegra210-vi";
> > > -			reg = <0x0 0x54080000 0x0 0x00040000>;
> > > +			reg = <0x0 0x54080000 0x0 0x808>;
> > >   			interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
> > >   			status = "disabled";
> > > +			assigned-clocks = <&tegra_car TEGRA210_CLK_VI>;
> > > +			assigned-clock-parents = <&tegra_car TEGRA210_CLK_PLL_C4_OUT0>;
> > > +
> > > +			clocks = <&tegra_car TEGRA210_CLK_VI>;
> > > +			clock-names = "vi";
> > > +			resets = <&tegra_car 20>;
> > > +			reset-names = "vi";
> > > +		};
> > > +
> > > +		csi@...4080838 {
> > > +			compatible = "nvidia,tegra210-csi";
> > > +			reg = <0x0 0x54080838 0x0 0x2000>;
> > > +			status = "disabled";
> > > +			assigned-clocks = <&tegra_car TEGRA210_CLK_CILAB>,
> > > +					  <&tegra_car TEGRA210_CLK_CILCD>,
> > > +					  <&tegra_car TEGRA210_CLK_CILE>;
> > > +			assigned-clock-parents = <&tegra_car TEGRA210_CLK_PLL_P>,
> > > +						 <&tegra_car TEGRA210_CLK_PLL_P>,
> > > +						 <&tegra_car TEGRA210_CLK_PLL_P>;
> > > +			assigned-clock-rates = <102000000>,
> > > +					       <102000000>,
> > > +					       <102000000>;
> > > +
> > > +			clocks = <&tegra_car TEGRA210_CLK_CSI>,
> > > +				 <&tegra_car TEGRA210_CLK_CILAB>,
> > > +				 <&tegra_car TEGRA210_CLK_CILCD>,
> > > +				 <&tegra_car TEGRA210_CLK_CILE>;
> > > +			clock-names = "csi", "cilab", "cilcd", "cile";
> > > +
> > >   		};
> > Can this be a child of the vi node? Looking at the register ranges it
> > seems like these are actually a single IP block. If they have separate
> > blocks with clearly separate functionality, then it makes sense to have
> > CSI be a child node of VI, though it may also be okay to merge both and
> > have a single node with the driver doing all of the differentiation
> > between what's VI and what's CSI.
> > 
> > Looking at later chips, the split between VI and CSI is more explicit,
> > so having the split in DT for Tegra210 may make sense for consistency.
> > 
> > I know we've discussed this before, but for some reason I keep coming
> > back to this. I'll go through the other patches to see if I can get a
> > clearer picture of how this could all work together.
> > 
> > Thierry
> 
> We can keep it separate as we discussed.
> 
> But as Tegra186 onwards, CSI is separate device to be all cosistent I kept
> CSI as separate node for Tegra210 as well.

From our discussion, my understanding was that CSI would be a separate
device, but it would still be a subdevice of VI. The address offset of
the CSI registers not being aligned to a power of two is a strong
indication that this is really all part of the same block.

Looking at this again, I'm having second thoughts about even that
suggestion. It wouldn't be technically wrong to have an additional
subdevice for CSI, but I don't think it's really necessary.

Now, given that the DT part is going to be somewhat crucial because it
will be ABI once merged, I'd like to make sure we're not painting
ourselves into a corner. Could you post a few examples of how this
currently looks? In addition to this TPG-only example, do you have a
variant of what it looks with the current proposal? I can only find an
example of the CSI-as-subdevice-of-VI that we had discussed earlier.

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)