Hi Linus,
On 2017-01-26 10:43, Linus Walleij wrote:
On Thu, Jan 19, 2017 at 2:48 PM, Marek Szyprowski
<m.szyprowski@xxxxxxxxxxx> wrote:
PMU is something like a SoC wide service, so add a helper function to get
PMU regmap. This will be used by other Exynos device drivers. This way it
can be avoided to model this dependency in device tree (as phandles to PMU
node) for almost every device in the SoC.
Signed-off-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>
Reviewed-by: Tomasz Figa <tomasz.figa@xxxxxxxxx>
But why? I could understand it as a local header in
drivers/soc/samsung/*.h for those files.
For the global kernel scope we usually look up the syscon
regmap we need using a phandle, DT node or even
compatible string directly from the device tree.
Just
#include <linux/mfd/syscon.h>
syscon_node_to_regmap()
syscon_regmap_lookup_by_compatible()
syscon_regmap_lookup_by_pdevname()
syscon_regmap_lookup_by_phandle()
what is wrong with just using one of these?
Introducing a special header just creates compile time problems
with global interfaces when merging code and just litter the kernel
for no good reason.
Can you explain why this necessarily different approach is
needed?
syscon_regmap_lookup_by_phandle() requires to have a phandle in the client
node. This has been used in v0 of this patchset and rejected as breaking
the old DT "compatibility".
syscon_regmap_lookup_by_compatible() requires to have a compatible string
hardcoded in the client driver. This might be used, but will require to have
(and maintain) a duplicated list of PMU compatibles in pin control driver.
There is a little problem with exynos4212 and exynos4412, which have same
pinctrl compatible (samsung,exynos4x12-pinctrl), but separate PMU
compatibles
(samsung,exynos4212-pmu and samsung,exynos4412-pmu). Luckily support for
Exynos4212 has been scheduled for removal, so we can ignore this issue for
now. The problem with maintaining a duplicated list of compatibles remains.
syscon_regmap_lookup_by_pdevname() requires the provider to register regmap
first, then to hardcode the provider name in all client drivers. A bit
similar
approach was used in v1, but the drawback was runtime probe order dependency
between PMU driver and pin control driver. I was requested to move the code
for acquiring PMU regmap to PMU driver, what in turn ended in the solution
presented in v2/v3 of this patchset, which requires least code for handling,
has no maintenance overhead, and doesn't cause any probe dependency issues.
It can be also later used for almost every driver found on the newer Exynos
SoCs, because for most of them there is a need to poke some registers in
the PMU not handled separately by any of the existing frameworks.
Various other drivers in the drivers/soc/ provide EXPORT_SYMBOL() based API,
so I don't think that this is a totally wrong approach.
I guess I should have said this earlier, mea culpa.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
