On 23/03/2023 10:44, Dmitry Baryshkov wrote: > On Thu, 23 Mar 2023 at 08:33, Krzysztof Kozlowski > <krzysztof.kozlowski@xxxxxxxxxx> wrote: >> >> On 22/03/2023 23:28, Dmitry Baryshkov wrote: >>> On Wed, 22 Mar 2023 at 19:37, Krzysztof Kozlowski >>> <krzysztof.kozlowski@xxxxxxxxxx> wrote: >>>> >>>> On 16/03/2023 07:52, Krzysztof Kozlowski wrote: >>>>> On 14/03/2023 13:16, Dmitry Baryshkov wrote: >>>>>> On 14/03/2023 10:09, Krzysztof Kozlowski wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Changes since v1 >>>>>>> ================ >>>>>>> 1. Rebase >>>>>>> 2. Make msm8994 fallback for several variants, not msm8953, because the latter >>>>>>> actually might take some clocks. >>>>>> >>>>>> Although the approach looks correct, I think that in some cases it tries >>>>>> to mark devices compatible judging from the current driver, not from the >>>>>> hardware itself. >>>>> >>>>> Which is what compatibility is about... >>> >>> Well, I was trying to say that once we update the driver, the devices >>> will not be compatible. But probably our definitions of being >>> compatible differ. >> >> What do you want to update in the driver? What's going to happen with >> it? What is missing? > > Some of these platforms do not have CPUfreq support, which will most > likely require programming of cluster and L2/L3 clocks being part of > this region. > > For the reference, I think that sc7180/sm8150/other new platforms are > proper examples of 'compatible' devices, so the patchset itself has a > correct/good idea beneath. It's just that additional research might be > required for the older platforms. I'll split the series so the sc7180/so on bits can go in and we'll figure out compatibility for the rest later... Best regards, Krzysztof
