On Sat, 23 Oct 2021 at 01:18, Chanwoo Choi <cwchoi00@xxxxxxxxx> wrote: > > On 21. 10. 22. 오후 10:39, Sam Protsenko wrote: > > On Fri, 22 Oct 2021 at 11:58, Chanwoo Choi <cwchoi00@xxxxxxxxx> wrote: > >> > >> On 21. 10. 22. 오전 5:31, Sam Protsenko wrote: > >>> CMU_APM clock domain provides clocks for APM IP-core (Active Power > >>> Management). According to Exynos850 TRM, CMU_APM generates I3C, Mailbox, > >>> Speedy, Timer, WDT, RTC and PMU clocks for BLK_ALIVE. > >>> > >>> This patch adds next clocks: > >>> - bus clocks in CMU_TOP needed for CMU_APM > >>> - all internal CMU_APM clocks > >>> - leaf clocks for I3C, Speedy and RTC IP-cores > >>> - bus clocks for CMU_CMGP and CMU_CHUB > >>> > >>> CMU_APM doesn't belong to Power Domains, but platform driver is used for > >>> its registration to keep its bus clock always running. Otherwise rtc-s3c > >>> driver disables that clock and system freezes. > >>> > >>> Signed-off-by: Sam Protsenko <semen.protsenko@xxxxxxxxxx> > >>> --- ...snip... > >> Basically, you can never change the already defined clock id > >> in nclude/dt-bindings/clock/*.h because of supporting > >> the compatibility of dtb files which were using the > >> already defined clock id instead of changed clock id > >> > >> If you want to add new clock with new clock id, > >> you have to define the new clock id at the end of defined clock > >> like the next of CLK_GOUT_PERI_IP for TOP domain case. > >> > > > > Thanks for explaining that in details, Chanwoo. As Krzysztof pointed > > out, right now there are no dts users of this clock driver in upstream > > kernel (I didn't submit it yet), so it'd nice if this one can be taken > > as is. In future I'll increment the last clock ID. Guess it was my OCD > > talking, trying to keep all clock IDs grouped by clock type :) > > I know that there are no user for this clock. So that it doesn't make > the real break for compatibility. But, when some kernel developers might > check the kernel history by git command, they never know the history > only we know. If there are any critical reason, I don't prefer to break > the rule of clock id defintion for patch history. > > Just I want to keep the original rule of clock id patch in order to remove > the potential confusion. It is not a strong objection. But In my case, > I cannot reply the ack. Thanks for your work. > Actually I was thinking about the same -- setting a bad example and stuff. It's not a big deal, I'll send v2 soon :) > -- > Best Regards, > Samsung Electronics > Chanwoo Choi
