Hi, On 9/10/20 14:50, Matthias Brugger wrote: > > > On 06/10/2020 08:53, Weiyi Lu wrote: >> On Fri, 2020-09-25 at 16:04 +0200, Matthias Brugger wrote: >>> >>> On 25/09/2020 12:06, Weiyi Lu wrote: >>>> On Thu, 2020-09-10 at 19:28 +0200, Enric Balletbo i Serra wrote: >>>>> Dear all, >>>>> >>>>> This is a new driver with the aim to deprecate the mtk-scpsys driver. >>>>> The problem with that driver is that, in order to support more Mediatek >>>>> SoCs you need to add some logic to handle properly the power-up >>>>> sequence of newer Mediatek SoCs, doesn't handle parent-child power >>>>> domains and need to hardcode all the clocks in the driver itself. The >>>>> result is that the driver is getting bigger and bigger every time a >>>>> new SoC needs to be supported. >>>>> >>>> >>>> Hi Enric and Matthias, >>>> >>>> First of all, thank you for the patch. But I'm worried the problem you >>>> mentioned won't be solved even if we work on this new driver in the >>>> future. My work on the MT8183 scpsys(now v17) is to implement the new >>>> hardware logic. Here, I also see related patches, which means that these >>>> new logics are necessary. Why can't we work on the original driver? >>> >>> Well the decision was to change the driver in a not compatible way to make >>> device tree entries better. If we work on the old driver, we would need to find >>> some creative ways to handle old bindings vs new bindings. >>> >>> So I thought it would be better doing a fresh start implementing mt1873 support >>> for reference and add mt8183 as new SoC. From what I have seen mt8192 and others >>> fit the driver structure too. >>> >>>> Meanwhile, I thought maybe we should separate the driver into general >>>> control and platform data for each SoC, otherwise it'll keep getting >>>> bigger and bigger if it need to be support new SoC. >>>> >>> >>> We could in a later series split the SoC depended data structures and put them >>> in drivers/soc/mediatek/pm-domains-mt8183.h or something like this. Is that what >>> you mean? >>> >> >> Yes, that is what I want. And I guess it could avoid the collisions in >> the different defines to the control registers and power status bits you >> mentioned. Hope this will happen in this series. >> > > Sounds good to me. Enric could you move the soc specific data to separate > include files? > Sure, I'll do this in v4. Thanks, Enric > Regards, > Matthias >
