[PATCH v6 4/5] ARM: DTS: da850: Add cfgchip syscon node

David Lechner [off-list ref] writes:

On 10/28/2016 12:08 PM, Kevin Hilman wrote:

quoted

Sekhar Nori [off-list ref] writes:

quoted

On Wednesday 26 October 2016 09:38 PM, David Lechner wrote:

quoted

On 10/25/2016 10:06 PM, David Lechner wrote:

quoted

Add a syscon node for the SoC CFGCHIPn registers. This is needed for
the new usb phy driver.

Signed-off-by: David Lechner <david@lechnology.com>
---
 arch/arm/boot/dts/da850.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index f79e1b9..6bbf20d 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi

@@ -188,6 +188,10 @@
             };

         };
+        cfgchip: cfgchip at 1417c {

I wonder if there is a more generic name instead of cfgchip at . Is there a
preferred generic name for syscon nodes?

I did not find anything in ePAPR, but chip-controller might be more
appropriate.

quoted

quoted

+            compatible = "ti,da830-cfgchip", "syscon";

Looks like we need "simple-mfd" too in the compatible list?

I think we can also fold patch 5/5 into this patch and add the cfgchip
along with USB phy child node included.

If you respin the patch, I can drop 4/5 and 5/5 that I have queued and
included the updated patch instead.

Sekhar, what's your opinion of having this syscon just for CFGCHIP* vs
a single syscon for the whole SYSCFG0 region.

The drivers/bus driver from Bartosz is also using SYSCFG0 registers, and
proposing a sysconf ro this region, but it will need to exclude the
CFGCHIPn registers if we also have this syscon.

What about the pinmux registers, which are already being used
separately too?

I guess I/we need to have a closer look at how these are actually shared
and decide if there are really overlapping users.  here are several
different registers packed into this region, but it may be the case that
there really isn't any overlapping usage (e.g. pinmux vs. PHY vs bus
priorities, etc.)

quoted

I tend to think we should just have one for the whole SYSCFG0 which
this series could use.

Unfortunately, the PHY driver is already merged and it references the
syscon by compatible.  The PHY driver should probably be fixed to find
its syscon by phandle, and then maybe we could move to a single syscon
for SYSCFG0?

I agree that this should be change, but I was thinking we should use
syscon_node_to_regmap(np->parent) since the phy node should be a child
of the syscon node.

Even better.

Kevin