*Re: [PATCH v3 2/9] soc: samsung: Convert exynos-chipid driver to use the regmap API
2019-08-21 11:51 ` Bartlomiej Zolnierkiewicz@ 2019-08-21 12:16 ` Krzysztof Kozlowski
2019-08-21 12:41 ` Sylwester Nawrocki
2019-08-21 13:31 ` Bartlomiej Zolnierkiewicz0 siblings, 2 replies; 27+ messages in thread
From: Krzysztof Kozlowski @ 2019-08-21 12:16 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Sylwester Nawrocki, Jon Hunter, Sylwester Nawrocki, robh+dt,
vireshk, devicetree, kgene, pankaj.dubey, linux-samsung-soc,
linux-arm-kernel, linux-kernel, linux-pm, Marek Szyprowski,
linux-tegra, Arnd Bergmann
On Wed, 21 Aug 2019 at 13:51, Bartlomiej Zolnierkiewicz
<b.zolnierkie@samsung.com> wrote:
> >>> Following this change, I am now seeing the above error on our Tegra
> >>> boards where this driver is enabled. This is triggering a kernel
> >>> warnings test we have to fail. Hence, I don't think that you can remove
> >>> the compatible node test here, unless you have a better way to determine
> >>> if this is a samsung device.
> >>
> >> Right, this is really wrong... I missed that it is not a probe but
> >> early init. And this init will be called on every board... Probably it
> >> should be converted to a regular driver.
>
> Early initialization is needed for SoC driver to be used from within
> arch/arm/mach-exynos/ and _initcall() usage is the usual way for SoC
> drivers to be initialized:
>
> drivers/soc/amlogic/meson-gx-socinfo.c
> drivers/soc/amlogic/meson-mx-socinfo.c
> drivers/soc/atmel/soc.c
> drivers/soc/bcm/brcmstb/common.c
> drivers/soc/imx/soc-imx-scu.c
> drivers/soc/imx/soc-imx8.c
> drivers/soc/renesas/renesas-soc.c
> drivers/soc/tegra/fuse/fuse-tegra.c
> drivers/soc/ux500/ux500-soc-id.c
> drivers/soc/versatile/soc-integrator.c
> drivers/soc/versatile/soc-integrator.c
>
> The only SoC drivers that are regular drivers are:
>
> drivers/soc/fsl/guts.c
> drivers/soc/versatile/soc-realview.c
Thanks for pointing it out.
Indeed, the initcall was needed in your set of patches here:
https://patchwork.kernel.org/project/linux-samsung-soc/list/?series=43565&state=*
but this work was not continued here. Maybe it will be later
resubmitted... maybe not... who knows? Therefore I would prefer proper
solution for current case (driver), unless patches for mach are being
brought back to life now.
> > I'm also inclined to have it converted to a regular driver. We already
> > have "exynos-asv" driver matching on the chipid node (patch 3/9).
> > The ASV patches will not be merged soon anyway, all this needs some more
> > thought. Krzysztof, can we abandon the chipid patches for now? Your
>
> chipid driver is good and useful on its own. The preferred solution
> IMHO would be to just revert "soc: samsung: Convert exynos-chipid
> driver to use the regmap API" commit.
I queued the chipid as a dependency for ASV but ASV requires the
regmap. What would be left after reverting the regmap part? Simple
unused printk driver? No need for such. If reverting, then let's drop
entire driver and rework it offline.
Best regards,
Krzysztof
^permalinkrawreply [flat|nested] 27+ messages in thread

*Re: [PATCH v3 2/9] soc: samsung: Convert exynos-chipid driver to use the regmap API
2019-08-21 12:16 ` Krzysztof Kozlowski@ 2019-08-21 12:41 ` Sylwester Nawrocki
2019-08-21 13:10 ` Krzysztof Kozlowski
2019-08-21 13:31 ` Bartlomiej Zolnierkiewicz1 sibling, 1 reply; 27+ messages in thread
From: Sylwester Nawrocki @ 2019-08-21 12:41 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bartlomiej Zolnierkiewicz
Cc: Sylwester Nawrocki, Jon Hunter, robh+dt, vireshk, devicetree,
kgene, pankaj.dubey, linux-samsung-soc, linux-arm-kernel,
linux-kernel, linux-pm, Marek Szyprowski, linux-tegra,
Arnd Bergmann
On 8/21/19 14:16, Krzysztof Kozlowski wrote:
>>> I'm also inclined to have it converted to a regular driver. We already
>>> have "exynos-asv" driver matching on the chipid node (patch 3/9).
>>> The ASV patches will not be merged soon anyway, all this needs some more
>>> thought. Krzysztof, can we abandon the chipid patches for now? Your
>>
>> chipid driver is good and useful on its own. The preferred solution
>> IMHO would be to just revert "soc: samsung: Convert exynos-chipid
>> driver to use the regmap API" commit.
>
> I queued the chipid as a dependency for ASV but ASV requires the
> regmap. What would be left after reverting the regmap part? Simple
> unused printk driver? No need for such. If reverting, then let's drop
> entire driver and rework it offline.
In fact there is now no dependency between the chipid and the ASV
driver (patch 3/9), the regmap is provided by the syscon driver/API.
I should have added "depends on REGMAP && MFD_SYSCON" to Kconfig.
Both drivers (chipid, ASV) share the registers region so the regmap
API seemed appropriate here.
Converting the chipid code to platform driver wouldn't make sense as
it wouldn't be useful early in arch/arm/mach-exynos and we can't have
two drivers for same device (the ASV driver matches on the chipid
compatible now).
--
Regards,
Sylwester
^permalinkrawreply [flat|nested] 27+ messages in thread

*Re: [PATCH v3 2/9] soc: samsung: Convert exynos-chipid driver to use the regmap API
2019-08-21 12:41 ` Sylwester Nawrocki@ 2019-08-21 13:10 ` Krzysztof Kozlowski0 siblings, 0 replies; 27+ messages in thread
From: Krzysztof Kozlowski @ 2019-08-21 13:10 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: Bartlomiej Zolnierkiewicz, Sylwester Nawrocki, Jon Hunter,
robh+dt, vireshk, devicetree, kgene, pankaj.dubey,
linux-samsung-soc, linux-arm-kernel, linux-kernel, linux-pm,
Marek Szyprowski, linux-tegra, Arnd Bergmann
On Wed, 21 Aug 2019 at 14:41, Sylwester Nawrocki <s.nawrocki@samsung.com> wrote:
>
> On 8/21/19 14:16, Krzysztof Kozlowski wrote:
> >>> I'm also inclined to have it converted to a regular driver. We already
> >>> have "exynos-asv" driver matching on the chipid node (patch 3/9).
> >>> The ASV patches will not be merged soon anyway, all this needs some more
> >>> thought. Krzysztof, can we abandon the chipid patches for now? Your
> >>
> >> chipid driver is good and useful on its own. The preferred solution
> >> IMHO would be to just revert "soc: samsung: Convert exynos-chipid
> >> driver to use the regmap API" commit.
> >
> > I queued the chipid as a dependency for ASV but ASV requires the
> > regmap. What would be left after reverting the regmap part? Simple
> > unused printk driver? No need for such. If reverting, then let's drop
> > entire driver and rework it offline.
>
> In fact there is now no dependency between the chipid and the ASV
> driver (patch 3/9), the regmap is provided by the syscon driver/API.
> I should have added "depends on REGMAP && MFD_SYSCON" to Kconfig.
> Both drivers (chipid, ASV) share the registers region so the regmap
> API seemed appropriate here.
Indeed, ASV needs only the header + DT change... Then actually we do
not need chipid driver at all. Just to print the SoC and provide sysfs
entry? If this is the only purpose, then it should be a driver.
> Converting the chipid code to platform driver wouldn't make sense as
> it wouldn't be useful early in arch/arm/mach-exynos and we can't have
> two drivers for same device (the ASV driver matches on the chipid
> compatible now).
There is no use case for arm/mach-exynos. This code was not
resubmitted and I doubt it will be (unless now someone wants to prove
I am wrong and sends it again :) ). The two-device case is indeed a
problem but it is possible. Clocks are doing it with PMU driver. See
CLK_OF_DECLARE_DRIVER(), although I do not remember whether it is
maybe obsolete pattern (discouraged).
Best regards,
Krzysztof
^permalinkrawreply [flat|nested] 27+ messages in thread

*Re: [PATCH v3 2/9] soc: samsung: Convert exynos-chipid driver to use the regmap API
2019-08-21 12:16 ` Krzysztof Kozlowski
2019-08-21 12:41 ` Sylwester Nawrocki@ 2019-08-21 13:31 ` Bartlomiej Zolnierkiewicz1 sibling, 0 replies; 27+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2019-08-21 13:31 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Sylwester Nawrocki, Jon Hunter, Sylwester Nawrocki, robh+dt,
vireshk, devicetree, kgene, pankaj.dubey, linux-samsung-soc,
linux-arm-kernel, linux-kernel, linux-pm, Marek Szyprowski,
linux-tegra, Arnd Bergmann
On 8/21/19 2:16 PM, Krzysztof Kozlowski wrote:
> On Wed, 21 Aug 2019 at 13:51, Bartlomiej Zolnierkiewicz
> <b.zolnierkie@samsung.com> wrote:
>>>>> Following this change, I am now seeing the above error on our Tegra
>>>>> boards where this driver is enabled. This is triggering a kernel
>>>>> warnings test we have to fail. Hence, I don't think that you can remove
>>>>> the compatible node test here, unless you have a better way to determine
>>>>> if this is a samsung device.
>>>>
>>>> Right, this is really wrong... I missed that it is not a probe but
>>>> early init. And this init will be called on every board... Probably it
>>>> should be converted to a regular driver.
>>
>> Early initialization is needed for SoC driver to be used from within
>> arch/arm/mach-exynos/ and _initcall() usage is the usual way for SoC
>> drivers to be initialized:
>>
>> drivers/soc/amlogic/meson-gx-socinfo.c
>> drivers/soc/amlogic/meson-mx-socinfo.c
>> drivers/soc/atmel/soc.c
>> drivers/soc/bcm/brcmstb/common.c
>> drivers/soc/imx/soc-imx-scu.c
>> drivers/soc/imx/soc-imx8.c
>> drivers/soc/renesas/renesas-soc.c
>> drivers/soc/tegra/fuse/fuse-tegra.c
>> drivers/soc/ux500/ux500-soc-id.c
>> drivers/soc/versatile/soc-integrator.c
>> drivers/soc/versatile/soc-integrator.c
>>
>> The only SoC drivers that are regular drivers are:
>>
>> drivers/soc/fsl/guts.c
>> drivers/soc/versatile/soc-realview.c
>
> Thanks for pointing it out.
>
> Indeed, the initcall was needed in your set of patches here:
> https://patchwork.kernel.org/project/linux-samsung-soc/list/?series=43565&state=*
> but this work was not continued here. Maybe it will be later
> resubmitted... maybe not... who knows? Therefore I would prefer proper
The work got delayed mainly because of the request for the formal
audit of each usage vs cache coherency. Since it is rather small
cleanup and such audit is time consuming it became a low priority.
> solution for current case (driver), unless patches for mach are being
> brought back to life now.
>
>>> I'm also inclined to have it converted to a regular driver. We already
>>> have "exynos-asv" driver matching on the chipid node (patch 3/9).
>>> The ASV patches will not be merged soon anyway, all this needs some more
>>> thought. Krzysztof, can we abandon the chipid patches for now? Your
>>
>> chipid driver is good and useful on its own. The preferred solution
>> IMHO would be to just revert "soc: samsung: Convert exynos-chipid
>> driver to use the regmap API" commit.
Or just fix it by re-adding removed Exynos chipid compatible checking:
diff --git a/drivers/soc/samsung/exynos-chipid.c b/drivers/soc/samsung/exynos-chipid.c
index 006a95feb618..d9912bd52479 100644
--- a/drivers/soc/samsung/exynos-chipid.c
+++ b/drivers/soc/samsung/exynos-chipid.c
@@ -55,6 +55,11 @@ int __init exynos_chipid_early_init(void)
u32 revision;
int ret;
+ /* look up for chipid node */
+ np = of_find_compatible_node(NULL, NULL, "samsung,exynos4210-chipid");
+ if (!np)
+ return -ENODEV;
+
regmap = syscon_regmap_lookup_by_compatible("samsung,exynos4210-chipid");
if (IS_ERR(regmap)) {
pr_err("Failed to get CHIPID regmap\n");
> I queued the chipid as a dependency for ASV but ASV requires the
> regmap. What would be left after reverting the regmap part? Simple
> unused printk driver? No need for such. If reverting, then let's drop
It provides sysfs information about SoC/platform and is useful on its
own (for debugging, reporting etc. purposes). Maybe not terrible useful
but on OTOH the driver is only ~100 LOC.
> entire driver and rework it offline.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^permalinkrawreply [flat|nested] 27+ messages in thread