Re: [PATCH v1 2/3] drivers: clk: tegra: add DFLL support for Tegra 4

[Krzysztof Kozlowski <krzk@kernel.org>]

On 10/06/2025 13:07, Thierry Reding wrote:
>>
>>> @@ -0,0 +1,13 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause */
>>> +/*
>>> + * This header provides Tegra114-specific constants for binding
>>> + * nvidia,tegra114-car.
>>> + */
>>> +
>>> +#ifndef _DT_BINDINGS_RESET_TEGRA114_CAR_H
>>> +#define _DT_BINDINGS_RESET_TEGRA114_CAR_H
>>> +
>>> +#define TEGRA114_RESET(x)		(5 * 32 + (x))
>>
>>
>> Does not look like a binding, but some sort of register. Binding IDs
>> start from 0 (or 1) and are incremented by 1.
> 
> I'll try and clear up some of the confusion around this. The way that
> resets are handled on these Tegra devices is that there is a set of
> peripheral clocks & resets which are paired up. This is because they
> are laid out in banks within the CAR (clock and reset) controller. In
> most cases we're referring to those resets, so you'll often see a clock
> ID used in conjection with the same reset ID for a given IP block.
> 
> In addition to those peripheral resets, there are a number of extra
> resets that don't have a corresponding clock and which are exposed in
> registers outside of the peripheral banks, but still part of the CAR.
> To support those "special" registers, the TEGRA*_RESET() is used to
> denote resets outside of the regular peripheral resets. Essentially it
> defines the offset within the CAR at which special resets start. In the
> above case, Tegra114 has 5 banks with 32 peripheral resets each. The
> first special reset, TEGRA114_RESET(0), therefore gets ID 5 * 32 + 0.
> 
> So to summarize: We cannot start enumerating these at 0 because that
> would fall into the range of peripheral reset IDs.

So these are hardware values, not bindings. Drop the header or move it
outside of bindings like other headers for hardware constants.

Best regards,
Krzysztof