чт, 28 серп. 2025 р. о 11:13 Mikko Perttunen <[email protected]> пише:
>
> On Wednesday, August 27, 2025 7:45 PM Svyatoslav Ryhel wrote:
> > ср, 27 серп. 2025 р. о 13:36 Mikko Perttunen <[email protected]> пише:
> > > On Wednesday, August 27, 2025 1:32 PM Svyatoslav wrote:
> > > > 27 серпня 2025 р. 07:09:45 GMT+03:00, Mikko Perttunen
> > >
> > > <[email protected]> пише:
> > > > >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 <[email protected]>
> > > > >> ---
> > > > >>
> > > > >> 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.
> > >
> > > AIUI vi_sensor is an internal clock so the sensor cannot be receiving it
> > > directly. Perhaps the sensor is actually connected to csus, and the reason
> > > we need to enable it is to allow the vi_sensor clock to pass through the
> > > csus gate?
> > >
> > > That leaves the question of why the csus pad would be muxed to vi_sensor
> > > by
> > > default, but perhaps there's an explanation for that.
> >
> > From downstream T30 sources csus and vi_sensor are always called in
> > pair (6MHz csus and 24MHz for vi_sensor), naturally I assumed that
> > latter is used as camera reference clock since most sensors has
> > reference clock around 24 MHz
>
> It's possible that the csus pad is still outputting 24MHz. The pinmux options
> for the csus pad are various clocks, so it would seem logical that the clock
> source for the pad is one of those clocks. However, on the clock framework
> side, the csus clock is just a gate. What I'm confused about is that since on
> the clock framework side the parent of csus is currently set to clk_m, I don't
> know why setting the rate of csus would affect the output of the pad, given
> clk_m is not one of the options for the pinmux.
>
> It's be good to verify the register value for the csus pinmux to see where it
> thinks the clock is coming from, and then check how that matches with what we
> are seeing.
>
TRM does not provide such data, it has only register address with
layout for it as a plain pad control, that register has only DRVDN,
DRVUP, SLWR and SLWF and I don't see a way to decode clock value or
parent or anything similar. If you give me a method I will calculate
those values.
Another theory is that maybe csus is used for VIP cameras only and
vi_sensor is used for CSI cameras, but they both have to be on in
order to work correctly. Csus was removed from Tegra114 along with
VIP, might not be a coincidence. Moreover, T124 uses vi_sensor as
camera mclk source.
Here is a fragment of Tegra124 clock tree (dumped from Mi pad 1)
pll_p on 13 x34 408000000
vi_sensor2 $ off 0 3.0 136000000
mclk2 $ off 0 136000000
vi_sensor $ off 0 3.0 136000000
mclk $ off 0 136000000
> >
> > > > >Cheers,
> > > > >Mikko
>
>
>
>
