On 06/10/2020 08:53, Weiyi Lu wrote:

On Fri, 2020-09-25 at 16:04 +0200, Matthias Brugger wrote:

quoted

On 25/09/2020 12:06, Weiyi Lu wrote:

quoted

On Thu, 2020-09-10 at 19:28 +0200, Enric Balletbo i Serra wrote:

quoted

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.

quoted

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel