Re: [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate clock names

[Tudor Ambarus]

Hi, Krzysztof,

On 12/15/23 08:13, Krzysztof Kozlowski wrote:
> On 14/12/2023 11:52, Tudor Ambarus wrote:
>> The gs101 clock names are derived from the clock register names under
>> some certain rules. In particular, for the gate clocks the following is
>> documented and expected in the gs101 clock driver:
>>
>>   Replace CLK_CON_GAT_CLKCMU      with CLK_GOUT_CMU and gout_cmu
>>   Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
>>
>>   For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC
> 
> I don't understand what it has to do with the bindings.
> 
>>
>> The CMU TOP gate clock names missed to include the required "CMU"
>> differentiator which will cause name collisions with the gate clock names
>> of other clock units. Fix the TOP gate clock names and include "CMU" in
>> their name.
> 
> Neither here. Clock names are not related to defines.
> 

When saying "clock names" I meant the clock symbolic names that are
defined in the bindings, the _id passed in GATE(_id, ) if you want.

>>
>> Fixes: 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock management unit bindings")
>> Signed-off-by: Tudor Ambarus <tudor.ambarus@xxxxxxxxxx>
>> ---
>>  drivers/clk/samsung/clk-gs101.c          | 167 ++++++++++++-----------
>>  include/dt-bindings/clock/google,gs101.h | 144 +++++++++----------
> 
> I miss the point why bindings must be changed with driver.

The clock symbolic names that are defined in the bindings file are used
as IDs in the clock driver. Having the changes split per file will
result in compilation errors breaking bisect.
> 
> Really, guys, we are milling the first GS101 patches for entire cycle.
> Almost 3 months. The moment I merge bindings you tell me they are wrong.
> Few days after merging them.

I apologize. It happens when we work in parallel. The clock symbolic
names were mangled just in v6. It was considered that the clock names
used in the datasheet are too long and the dt becomes unreadable. I just
recently updated the peric0 clock symbolic names according to the clock
symbolic name mangling strategy, that's why we spot the inconsistency
and the symbolic name collision so late.

Cheers,
ta