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. -- With best wishes Dmitry
