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

[Mikko Perttunen <mperttunen@nvidia.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@gmail.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?

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.

Cheers,
Mikko