| Message ID | 20200910172826.3074357-1-enric.balletbo@collabora.com |
|---|---|
| Headers | show |
| Series | soc: mediatek: pm-domains: Add new driver for SCPSYS power domains controller | expand |
Hi Enric, > - scpsys: power-controller@10006000 { > - compatible = "mediatek,mt8173-scpsys"; > - #power-domain-cells = <1>; This change generates a lot of warning when compiling the MT8173 device-trees. Warning (power_domains_property): /soc/mutex@14020000: Missing property '#power-domain-cells' in node /soc/syscon@10006000 or bad phandle (referred from power-domains[0])
Hi Fabien, Thank you to look at this. Missatge de Fabien Parent <fparent@baylibre.com> del dia dv., 18 de set. 2020 a les 22:24: > > Hi Enric, > > > - scpsys: power-controller@10006000 { > > - compatible = "mediatek,mt8173-scpsys"; > > - #power-domain-cells = <1>; > > This change generates a lot of warning when compiling the MT8173 device-trees. > > Warning (power_domains_property): /soc/mutex@14020000: Missing > property '#power-domain-cells' in node /soc/syscon@10006000 or bad > phandle (referred from power-domains[0]) I think that there is a mistake in that patch #power-domain-cells = <1>; should not be removed. Anyway, I talked with Matthias and I'm going to redefine this part as doesn't really match with the hardware. We're thinking on something like this: scpsys: syscon@10006000 { compatible = "mediatek,mtk-scpsys", "syscon"; reg = ... power-controller { compatible = "mediatek,mt8173-power-controller"; #power-domain-cells = <1>; <- the list of domains -> Thanks, Enric
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? 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. And consider DVFSRC (dynamic voltage and frequency scaling resource collector), should we keep the original driver name "scpsys" instead of "pm-domains" because it may provide more functions than power domains? > All this information can be getted from a properly defined binding, so > can be cleaner and smaller, hence, we implemented a new driver. For > now, only MT8173 and MT8183 is supported but should be fairly easy to > add support for new SoCs. > > Best regards, > Enric > > Enric Balletbo i Serra (4): > dt-bindings: power: Add bindings for the Mediatek SCPSYS power domains > controller > soc: mediatek: Add MediaTek SCPSYS power domains > arm64: dts: mediatek: Add mt8173 power domain controller > dt-bindings: power: Add MT8183 power domains > > Matthias Brugger (8): > soc: mediatek: pm-domains: Add bus protection protocol > soc: mediatek: pm_domains: Make bus protection generic > soc: mediatek: pm-domains: Add SMI block as bus protection block > soc: mediatek: pm-domains: Add extra sram control > soc: mediatek: pm-domains: Add subsystem clocks > soc: mediatek: pm-domains: Allow bus protection to ignore clear ack > soc: mediatek: pm-domains: Add support for mt8183 > arm64: dts: mediatek: Add mt8183 power domains controller > > .../power/mediatek,power-controller.yaml | 173 ++++ > arch/arm64/boot/dts/mediatek/mt8173.dtsi | 78 +- > arch/arm64/boot/dts/mediatek/mt8183.dtsi | 160 +++ > drivers/soc/mediatek/Kconfig | 13 + > drivers/soc/mediatek/Makefile | 1 + > drivers/soc/mediatek/mtk-infracfg.c | 5 - > drivers/soc/mediatek/mtk-pm-domains.c | 952 ++++++++++++++++++ > include/dt-bindings/power/mt8183-power.h | 26 + > include/linux/soc/mediatek/infracfg.h | 39 + > 9 files changed, 1433 insertions(+), 14 deletions(-) > create mode 100644 Documentation/devicetree/bindings/power/mediatek,power-controller.yaml > create mode 100644 drivers/soc/mediatek/mtk-pm-domains.c > create mode 100644 include/dt-bindings/power/mt8183-power.h >
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? > And consider DVFSRC > (dynamic voltage and frequency scaling resource collector), should we > keep the original driver name "scpsys" instead of "pm-domains" because > it may provide more functions than power domains? > It's on my list to look deeper into this series. The thing with the new driver is, that the binding takes into account, that scpsys has several hardware block, which are represented as child nodes in DTS. The pm-domains is just one of these functionalities and I think DVFSRC should be a new driver with a child node of scpsys in DTS. Does this make sense? Regards, Matthias >> All this information can be getted from a properly defined binding, so >> can be cleaner and smaller, hence, we implemented a new driver. For >> now, only MT8173 and MT8183 is supported but should be fairly easy to >> add support for new SoCs. >> >> Best regards, >> Enric >> >> Enric Balletbo i Serra (4): >> dt-bindings: power: Add bindings for the Mediatek SCPSYS power domains >> controller >> soc: mediatek: Add MediaTek SCPSYS power domains >> arm64: dts: mediatek: Add mt8173 power domain controller >> dt-bindings: power: Add MT8183 power domains >> >> Matthias Brugger (8): >> soc: mediatek: pm-domains: Add bus protection protocol >> soc: mediatek: pm_domains: Make bus protection generic >> soc: mediatek: pm-domains: Add SMI block as bus protection block >> soc: mediatek: pm-domains: Add extra sram control >> soc: mediatek: pm-domains: Add subsystem clocks >> soc: mediatek: pm-domains: Allow bus protection to ignore clear ack >> soc: mediatek: pm-domains: Add support for mt8183 >> arm64: dts: mediatek: Add mt8183 power domains controller >> >> .../power/mediatek,power-controller.yaml | 173 ++++ >> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 78 +- >> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 160 +++ >> drivers/soc/mediatek/Kconfig | 13 + >> drivers/soc/mediatek/Makefile | 1 + >> drivers/soc/mediatek/mtk-infracfg.c | 5 - >> drivers/soc/mediatek/mtk-pm-domains.c | 952 ++++++++++++++++++ >> include/dt-bindings/power/mt8183-power.h | 26 + >> include/linux/soc/mediatek/infracfg.h | 39 + >> 9 files changed, 1433 insertions(+), 14 deletions(-) >> create mode 100644 Documentation/devicetree/bindings/power/mediatek,power-controller.yaml >> create mode 100644 drivers/soc/mediatek/mtk-pm-domains.c >> create mode 100644 include/dt-bindings/power/mt8183-power.h >> >
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. > > And consider DVFSRC > > (dynamic voltage and frequency scaling resource collector), should we > > keep the original driver name "scpsys" instead of "pm-domains" because > > it may provide more functions than power domains? > > > > It's on my list to look deeper into this series. The thing with the new driver > is, that the binding takes into account, that scpsys has several hardware block, > which are represented as child nodes in DTS. The pm-domains is just one of these > functionalities and I think DVFSRC should be a new driver with a child node of > scpsys in DTS. Does this make sense? > > Regards, > Matthias > > >> All this information can be getted from a properly defined binding, so > >> can be cleaner and smaller, hence, we implemented a new driver. For > >> now, only MT8173 and MT8183 is supported but should be fairly easy to > >> add support for new SoCs. > >> > >> Best regards, > >> Enric > >> > >> Enric Balletbo i Serra (4): > >> dt-bindings: power: Add bindings for the Mediatek SCPSYS power domains > >> controller > >> soc: mediatek: Add MediaTek SCPSYS power domains > >> arm64: dts: mediatek: Add mt8173 power domain controller > >> dt-bindings: power: Add MT8183 power domains > >> > >> Matthias Brugger (8): > >> soc: mediatek: pm-domains: Add bus protection protocol > >> soc: mediatek: pm_domains: Make bus protection generic > >> soc: mediatek: pm-domains: Add SMI block as bus protection block > >> soc: mediatek: pm-domains: Add extra sram control > >> soc: mediatek: pm-domains: Add subsystem clocks > >> soc: mediatek: pm-domains: Allow bus protection to ignore clear ack > >> soc: mediatek: pm-domains: Add support for mt8183 > >> arm64: dts: mediatek: Add mt8183 power domains controller > >> > >> .../power/mediatek,power-controller.yaml | 173 ++++ > >> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 78 +- > >> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 160 +++ > >> drivers/soc/mediatek/Kconfig | 13 + > >> drivers/soc/mediatek/Makefile | 1 + > >> drivers/soc/mediatek/mtk-infracfg.c | 5 - > >> drivers/soc/mediatek/mtk-pm-domains.c | 952 ++++++++++++++++++ > >> include/dt-bindings/power/mt8183-power.h | 26 + > >> include/linux/soc/mediatek/infracfg.h | 39 + > >> 9 files changed, 1433 insertions(+), 14 deletions(-) > >> create mode 100644 Documentation/devicetree/bindings/power/mediatek,power-controller.yaml > >> create mode 100644 drivers/soc/mediatek/mtk-pm-domains.c > >> create mode 100644 include/dt-bindings/power/mt8183-power.h > >> > > > > _______________________________________________ > Linux-mediatek mailing list > Linux-mediatek@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek
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? Regards, Matthias
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 >
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. All this information can be getted from a properly defined binding, so can be cleaner and smaller, hence, we implemented a new driver. For now, only MT8173 and MT8183 is supported but should be fairly easy to add support for new SoCs. Best regards, Enric Enric Balletbo i Serra (4): dt-bindings: power: Add bindings for the Mediatek SCPSYS power domains controller soc: mediatek: Add MediaTek SCPSYS power domains arm64: dts: mediatek: Add mt8173 power domain controller dt-bindings: power: Add MT8183 power domains Matthias Brugger (8): soc: mediatek: pm-domains: Add bus protection protocol soc: mediatek: pm_domains: Make bus protection generic soc: mediatek: pm-domains: Add SMI block as bus protection block soc: mediatek: pm-domains: Add extra sram control soc: mediatek: pm-domains: Add subsystem clocks soc: mediatek: pm-domains: Allow bus protection to ignore clear ack soc: mediatek: pm-domains: Add support for mt8183 arm64: dts: mediatek: Add mt8183 power domains controller .../power/mediatek,power-controller.yaml | 173 ++++ arch/arm64/boot/dts/mediatek/mt8173.dtsi | 78 +- arch/arm64/boot/dts/mediatek/mt8183.dtsi | 160 +++ drivers/soc/mediatek/Kconfig | 13 + drivers/soc/mediatek/Makefile | 1 + drivers/soc/mediatek/mtk-infracfg.c | 5 - drivers/soc/mediatek/mtk-pm-domains.c | 952 ++++++++++++++++++ include/dt-bindings/power/mt8183-power.h | 26 + include/linux/soc/mediatek/infracfg.h | 39 + 9 files changed, 1433 insertions(+), 14 deletions(-) create mode 100644 Documentation/devicetree/bindings/power/mediatek,power-controller.yaml create mode 100644 drivers/soc/mediatek/mtk-pm-domains.c create mode 100644 include/dt-bindings/power/mt8183-power.h