linux-kernel - Re: [PATCH v1 01/19] clk: tegra: init CSUS clock for Tegra20 and Tegra30

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: <76B1EB6D-B149-43C2-AA56-A15C9DCCA3AF@gmail.com>
Date: Wed, 27 Aug 2025 07:32:27 +0300
From: Svyatoslav <clamor95@...il.com>
To: Mikko Perttunen <mperttunen@...dia.com>,
 Thierry Reding <thierry.reding@...il.com>,
 Thierry Reding <treding@...dia.com>, Jonathan Hunter <jonathanh@...dia.com>,
 Sowjanya Komatineni <skomatineni@...dia.com>,
 Luca Ceresoli <luca.ceresoli@...tlin.com>, David Airlie <airlied@...il.com>,
 Simona Vetter <simona@...ll.ch>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>,
 Peter De Schrijver <pdeschrijver@...dia.com>,
 Prashant Gaikwad <pgaikwad@...dia.com>,
 Michael Turquette <mturquette@...libre.com>, Stephen Boyd <sboyd@...nel.org>,
 Mauro Carvalho Chehab <mchehab@...nel.org>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Dmitry Osipenko <digetx@...il.com>,
 Charan Pedumuru <charan.pedumuru@...il.com>
CC: linux-media@...r.kernel.org, linux-tegra@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org,
 linux-staging@...ts.linux.dev
Subject: Re: [PATCH v1 01/19] clk: tegra: init CSUS clock for Tegra20 and Tegra30



27 серпня 2025 р. 07:09:45 GMT+03:00, Mikko Perttunen <mperttunen@...dia.com> пише:
>On Tuesday, August 19, 2025 9:16 PM Svyatoslav Ryhel wrote:
>> CSUS clock is required to be enabled on camera device configuration or
>> else camera module refuses to initiate properly.
>> 
>> Signed-off-by: Svyatoslav Ryhel <clamor95@...il.com>
>> ---
>>  drivers/clk/tegra/clk-tegra20.c | 1 +
>>  drivers/clk/tegra/clk-tegra30.c | 1 +
>>  2 files changed, 2 insertions(+)
>> 
>> diff --git a/drivers/clk/tegra/clk-tegra20.c
>> b/drivers/clk/tegra/clk-tegra20.c index 551ef0cf0c9a..42f8150c6110 100644
>> --- a/drivers/clk/tegra/clk-tegra20.c
>> +++ b/drivers/clk/tegra/clk-tegra20.c
>> @@ -1043,6 +1043,7 @@ static struct tegra_clk_init_table init_table[] = {
>>  	{ TEGRA20_CLK_GR3D, TEGRA20_CLK_PLL_C, 300000000, 0 },
>>  	{ TEGRA20_CLK_VDE, TEGRA20_CLK_PLL_C, 300000000, 0 },
>>  	{ TEGRA20_CLK_PWM, TEGRA20_CLK_PLL_P, 48000000, 0 },
>> +	{ TEGRA20_CLK_CSUS, TEGRA20_CLK_CLK_MAX, 6000000, 1 },
>>  	/* must be the last entry */
>>  	{ TEGRA20_CLK_CLK_MAX, TEGRA20_CLK_CLK_MAX, 0, 0 },
>>  };
>> diff --git a/drivers/clk/tegra/clk-tegra30.c
>> b/drivers/clk/tegra/clk-tegra30.c index 82a8cb9545eb..70e85e2949e0 100644
>> --- a/drivers/clk/tegra/clk-tegra30.c
>> +++ b/drivers/clk/tegra/clk-tegra30.c
>> @@ -1237,6 +1237,7 @@ static struct tegra_clk_init_table init_table[] = {
>>  	{ TEGRA30_CLK_HDA, TEGRA30_CLK_PLL_P, 102000000, 0 },
>>  	{ TEGRA30_CLK_HDA2CODEC_2X, TEGRA30_CLK_PLL_P, 48000000, 0 },
>>  	{ TEGRA30_CLK_PWM, TEGRA30_CLK_PLL_P, 48000000, 0 },
>> +	{ TEGRA30_CLK_CSUS, TEGRA30_CLK_CLK_MAX, 6000000, 1 },
>>  	/* must be the last entry */
>>  	{ TEGRA30_CLK_CLK_MAX, TEGRA30_CLK_CLK_MAX, 0, 0 },
>>  };
>
>I looked into what this clock does and it seems to be a gate for the CSUS pin, 
>which provides an output clock for camera sensors (VI MCLK). Default source 
>seems to be PLLC_OUT1. It would be good to note that on the commit message, as 
>I can't find any documentation about the CSUS clock elsewhere.
>
>What is the 6MHz rate based on?
>

6mhz is the statistic value which I was not able to alter while testing. I have tried 12mhz and 24mhz too but it remained 6mhz, so I left it 6mhz.

>Since this seems to be a clock consumed by the sensor, it seems to me that 
>rather than making it always on, we could point to it in the sensor's device 
>tree entry.
>

Sensor device tree uses vi_sensor as clocks source and sensor drivers don't support multiple linked clocks.

>Cheers,
>Mikko
>
>
>