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: <bd18711d-ce23-cbee-7824-37a8c78908e6@nvidia.com>
Date:   Wed, 29 Jan 2020 08:22:48 -0800
From:   Sowjanya Komatineni <skomatineni@...dia.com>
To:     Thierry Reding <thierry.reding@...il.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 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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ