Quoting Aisheng DONG (2018-11-20 17:50:47)

quoted

-----Original Message-----
From: Stephen Boyd [mailto:sboyd@kernel.org]

[...]

quoted

quoted

quoted

quoted

+
+       ss_lpcg = of_device_get_match_data(dev);
+       if (!ss_lpcg)
+               return -ENODEV;
+
+       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+       base = devm_ioremap(dev, res->start, resource_size(res));

Why not devm_ioremap_resource()?

Because LPCGs are distributed in various subsystem memory space which
may be overlapped with some IP modules. So we can't use
devm_ioremap_resource which has a request_mem_region() in it.
It's something like what we've done for drivers/mfd/syscon.c.

Ok. Any chance that the various subsystems that are combined with the clk
controller can be split up so that we can use
devm_ioremap_resource() here? 

We can achieve that by describing each LPCGS node in devicetree, but that would
bloat the Devicetree seriously as we have hundreds of LPCGS.

This is similar as what we did for legacy SoCs, e.g MX7D.
The difference is that on MX7D LPCGS are continuous.
e.g.
Table 5-19. CCGR Mapping Table
Gating Register LPCG Enable Offset
CCM_CCGR4 sim_main 0x4040
CCM_CCGR5 sim_display 0x4050
...
CCM_CCGR168 iomux 0x4A80
CCM_CCGR169 iomux_lpsr 0x4A90
CCM_CCGR170 kpp 0x4AA0

But on MX8QXP/QM, they're not continuous anymore and distributed in each SS.
And we probably want to push our IC designer to re-orgnize them into a continuous
memory map again for new chips in the future.

So do you think we can start with this way for MX8 as well?
Then we won't block MX8QXP booting up too long or probably could improve it
Later.

Ok, I don't really understand the memory map of this SoC. I wouldn't
push the IC designer to reorganize everything. I'd push the designer to
make clock controller hw blocks, maybe even one per subsystem is OK, and
then have that build on basic clk types that the clock controller
drivers could use to implement the clk support.

Either way, this hardware must already exist so I think we're done here.
I'm OK with whatever works at this point.

quoted

It may be better to carve up the I/O space of
this SoC into device nodes that map to the hardware IP blocks, and then have
those device drivers generate sub-devices for the various logical subsystems
that the hardware IP spans. Or it could be a big driver that registers with
multiple subsytems/frameworks from one device driver. This way, the logical
structure of the linux kernel device driver design doesn't leak into the DT
description of the SoC.

Yes, we currently already describe them with each subsystems in Devicetree.
https://patchwork.kernel.org/patch/10677311/

Ok.


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