03:29 <lumag> flamingradian[m], I have been looking onto the IOMMU since that email. Unfortunately, as always happens with msm devices, it's a bit more complicated than I initially expected. Things got complicated because of the 8996 mmu

03:37 <flamingradian[m]> ah, so I guess that means the series that I originally sent can be applied as-is?

10:06 <aka_[m]> Marijn: I feel like I'm going to revamp this entire code with regmap update bits and others

10:29 <lumag> flamingradian[m], as we are not in a hurry, let's try finishing the refactoring first.

12:10 <flamingradian[m]> lumag: Sorry, I'm confused because there are some replies in the thread which you haven't responded to. One of the emails said, "If the devices are really different, even though it is not visible in Linux driver, then indeed there is no point for fake compatibility." Are we still going to add a generic compat string?

12:10 <lumag> flamingradian[m], I'd try to

12:13 <flamingradian[m]> lumag: so is there still a reason to add it? Here's the original reply: https://lore.kernel.org/linux-arm-msm/f6c8e1d4-54bd-811c-7322-375f755ad460@linaro.org/

12:25 <lumag> flamingradian[m], yes, I saw that email.

12:27 <lumag> For me there is a reason. I'd say, we already have the arm,mmu-500 compat. So we are already declaring that these IOMMUs are somewhat the same story.

12:28 <lumag> And adding a separate qcom,mmu-500 seems logical.

12:28 <lumag> The idea of having identical compat lines makes me itch.

12:33 <flamingradian[m]> lumag: ok, make sure that the quirks still work

12:33 <lumag> yep

12:35 <Marijn[m]> <aka_[m]> "Marijn: I feel like I'm going to..." <- Be careful with this though, if the reference implementation constructs a local variable and writes the final register value qt once you shouldn't replace that with multiple regmap writes (even though it supports some form of caching/flushing, I'm not sure if it's desirable to use it that way - never seen it)

12:36 <Marijn[m]> s/qt/at.

12:38 <Marijn[m]> There's also reg_field but it looks even more verbose...

13:43 <aka_[m]> <Marijn[m]> "Be careful with this though..." <- i think i can kang clk-pll.c and clk-alpha-pll.c atleast part which touch "user_reg"

13:43 <aka_[m]> because here we have "magic"

13:43 <aka_[m]> which in reality sets early output

13:44 <aka_[m]> names are missleading tho

13:45 <aka_[m]> PLL_USER_CTL in clk-hfpll.c is "user_reg"

13:45 <aka_[m]> PLL_CONFIG_CTL is "config_reg"

13:45 <aka_[m]> im going to rework user_reg because config_reg isn't that much described even in 8916 TRM

13:49 <aka_[m]> CONFIG stuff which is written at once can be left, but we need to handle different VCO/rates

13:49 <aka_[m]> but only for A53 cluster

13:50 <aka_[m]> 652-902Mhz range ships with VCO_BIT set to 0(HIGH VCO range) and config of 0x141400

13:51 <aka_[m]> SR2 PLL docs from 8916

13:52 <aka_[m]> its wondering why high clock ship with low freq VCO,probably some pll internals about which i know nothing

13:52 <aka_[m]> a72 always low freq vco