[v3,2/9] soc: samsung: Convert exynos-chipid driver to use the regmap API
diff mbox series

Message ID 20190813150827.31972-3-s.nawrocki@samsung.com
State Accepted
Headers show
Series
  • [v3,1/9] soc: samsung: Add exynos chipid driver support
Related show

Commit Message

Sylwester Nawrocki Aug. 13, 2019, 3:08 p.m. UTC
Convert the driver to use regmap API in order to allow other
drivers, like ASV, to access the CHIPID registers.

This patch adds definition of selected CHIPID register offsets
and register bit fields for Exynos5422 SoC.

Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
Changes since v2:
 - s/_EXYNOS_ASV_H/__LINU_SOC_EXYNOS_ASV_H,
 - removed __func__ from error log,
 - removed unneeded <linux/of_address.h> header inclusion.

Changes since v1 (RFC):
 - new patch
---
 drivers/soc/samsung/exynos-chipid.c       | 34 ++++++---------
 include/linux/soc/samsung/exynos-chipid.h | 52 +++++++++++++++++++++++
 2 files changed, 65 insertions(+), 21 deletions(-)
 create mode 100644 include/linux/soc/samsung/exynos-chipid.h

Comments

Krzysztof Kozlowski Aug. 15, 2019, 6:22 p.m. UTC | #1
On Tue, Aug 13, 2019 at 05:08:20PM +0200, Sylwester Nawrocki wrote:
> Convert the driver to use regmap API in order to allow other
> drivers, like ASV, to access the CHIPID registers.
> 
> This patch adds definition of selected CHIPID register offsets
> and register bit fields for Exynos5422 SoC.
> 
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> ---
> Changes since v2:
>  - s/_EXYNOS_ASV_H/__LINU_SOC_EXYNOS_ASV_H,
>  - removed __func__ from error log,
>  - removed unneeded <linux/of_address.h> header inclusion.
> 
> Changes since v1 (RFC):
>  - new patch
> ---
>  drivers/soc/samsung/exynos-chipid.c       | 34 ++++++---------
>  include/linux/soc/samsung/exynos-chipid.h | 52 +++++++++++++++++++++++
>  2 files changed, 65 insertions(+), 21 deletions(-)

Thanks, applied.

Best regards,
Krzysztof
Jon Hunter Aug. 20, 2019, 7:24 p.m. UTC | #2
On 13/08/2019 16:08, Sylwester Nawrocki wrote:
> Convert the driver to use regmap API in order to allow other
> drivers, like ASV, to access the CHIPID registers.
> 
> This patch adds definition of selected CHIPID register offsets
> and register bit fields for Exynos5422 SoC.
> 
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> ---
> Changes since v2:
>  - s/_EXYNOS_ASV_H/__LINU_SOC_EXYNOS_ASV_H,
>  - removed __func__ from error log,
>  - removed unneeded <linux/of_address.h> header inclusion.
> 
> Changes since v1 (RFC):
>  - new patch
> ---
>  drivers/soc/samsung/exynos-chipid.c       | 34 ++++++---------
>  include/linux/soc/samsung/exynos-chipid.h | 52 +++++++++++++++++++++++
>  2 files changed, 65 insertions(+), 21 deletions(-)
>  create mode 100644 include/linux/soc/samsung/exynos-chipid.h
> 
> diff --git a/drivers/soc/samsung/exynos-chipid.c b/drivers/soc/samsung/exynos-chipid.c
> index bcf691f2b650..006a95feb618 100644
> --- a/drivers/soc/samsung/exynos-chipid.c
> +++ b/drivers/soc/samsung/exynos-chipid.c
> @@ -9,16 +9,13 @@
>   */
>  
>  #include <linux/io.h>
> +#include <linux/mfd/syscon.h>
>  #include <linux/of.h>
> -#include <linux/of_address.h>
> +#include <linux/regmap.h>
>  #include <linux/slab.h>
> +#include <linux/soc/samsung/exynos-chipid.h>
>  #include <linux/sys_soc.h>
>  
> -#define EXYNOS_SUBREV_MASK	(0xF << 4)
> -#define EXYNOS_MAINREV_MASK	(0xF << 0)
> -#define EXYNOS_REV_MASK		(EXYNOS_SUBREV_MASK | EXYNOS_MAINREV_MASK)
> -#define EXYNOS_MASK		0xFFFFF000
> -
>  static const struct exynos_soc_id {
>  	const char *name;
>  	unsigned int id;
> @@ -51,29 +48,24 @@ static const char * __init product_id_to_soc_id(unsigned int product_id)
>  int __init exynos_chipid_early_init(void)
>  {
>  	struct soc_device_attribute *soc_dev_attr;
> -	void __iomem *exynos_chipid_base;
>  	struct soc_device *soc_dev;
>  	struct device_node *root;
> -	struct device_node *np;
> +	struct regmap *regmap;
>  	u32 product_id;
>  	u32 revision;
> +	int ret;
>  
> -	/* look up for chipid node */
> -	np = of_find_compatible_node(NULL, NULL, "samsung,exynos4210-chipid");
> -	if (!np)
> -		return -ENODEV;
> -
> -	exynos_chipid_base = of_iomap(np, 0);
> -	of_node_put(np);
> -
> -	if (!exynos_chipid_base) {
> -		pr_err("Failed to map SoC chipid\n");
> -		return -ENXIO;
> +	regmap = syscon_regmap_lookup_by_compatible("samsung,exynos4210-chipid");
> +	if (IS_ERR(regmap)) {
> +		pr_err("Failed to get CHIPID regmap\n");
> +		return PTR_ERR(regmap);
>  	}

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.

Cheers
Jon
Krzysztof Kozlowski Aug. 20, 2019, 7:37 p.m. UTC | #3
On Tue, 20 Aug 2019 at 21:24, Jon Hunter <jonathanh@nvidia.com> wrote:
>
>
> On 13/08/2019 16:08, Sylwester Nawrocki wrote:
> > Convert the driver to use regmap API in order to allow other
> > drivers, like ASV, to access the CHIPID registers.
> >
> > This patch adds definition of selected CHIPID register offsets
> > and register bit fields for Exynos5422 SoC.
> >
> > Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> > ---
> > Changes since v2:
> >  - s/_EXYNOS_ASV_H/__LINU_SOC_EXYNOS_ASV_H,
> >  - removed __func__ from error log,
> >  - removed unneeded <linux/of_address.h> header inclusion.
> >
> > Changes since v1 (RFC):
> >  - new patch
> > ---
> >  drivers/soc/samsung/exynos-chipid.c       | 34 ++++++---------
> >  include/linux/soc/samsung/exynos-chipid.h | 52 +++++++++++++++++++++++
> >  2 files changed, 65 insertions(+), 21 deletions(-)
> >  create mode 100644 include/linux/soc/samsung/exynos-chipid.h
> >
> > diff --git a/drivers/soc/samsung/exynos-chipid.c b/drivers/soc/samsung/exynos-chipid.c
> > index bcf691f2b650..006a95feb618 100644
> > --- a/drivers/soc/samsung/exynos-chipid.c
> > +++ b/drivers/soc/samsung/exynos-chipid.c
> > @@ -9,16 +9,13 @@
> >   */
> >
> >  #include <linux/io.h>
> > +#include <linux/mfd/syscon.h>
> >  #include <linux/of.h>
> > -#include <linux/of_address.h>
> > +#include <linux/regmap.h>
> >  #include <linux/slab.h>
> > +#include <linux/soc/samsung/exynos-chipid.h>
> >  #include <linux/sys_soc.h>
> >
> > -#define EXYNOS_SUBREV_MASK   (0xF << 4)
> > -#define EXYNOS_MAINREV_MASK  (0xF << 0)
> > -#define EXYNOS_REV_MASK              (EXYNOS_SUBREV_MASK | EXYNOS_MAINREV_MASK)
> > -#define EXYNOS_MASK          0xFFFFF000
> > -
> >  static const struct exynos_soc_id {
> >       const char *name;
> >       unsigned int id;
> > @@ -51,29 +48,24 @@ static const char * __init product_id_to_soc_id(unsigned int product_id)
> >  int __init exynos_chipid_early_init(void)
> >  {
> >       struct soc_device_attribute *soc_dev_attr;
> > -     void __iomem *exynos_chipid_base;
> >       struct soc_device *soc_dev;
> >       struct device_node *root;
> > -     struct device_node *np;
> > +     struct regmap *regmap;
> >       u32 product_id;
> >       u32 revision;
> > +     int ret;
> >
> > -     /* look up for chipid node */
> > -     np = of_find_compatible_node(NULL, NULL, "samsung,exynos4210-chipid");
> > -     if (!np)
> > -             return -ENODEV;
> > -
> > -     exynos_chipid_base = of_iomap(np, 0);
> > -     of_node_put(np);
> > -
> > -     if (!exynos_chipid_base) {
> > -             pr_err("Failed to map SoC chipid\n");
> > -             return -ENXIO;
> > +     regmap = syscon_regmap_lookup_by_compatible("samsung,exynos4210-chipid");
> > +     if (IS_ERR(regmap)) {
> > +             pr_err("Failed to get CHIPID regmap\n");
> > +             return PTR_ERR(regmap);
> >       }
>
> 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.

This is very old patchset, revived recently. I see that in v6 it was a
platform driver:
https://patchwork.kernel.org/patch/9134949/
Pankaj, apparently based on these comments, made it initcall... but why?

Another point is that Arnd complained there about exposing global
header and no change here - we still expose the global header, but not
with soc revisions but register internals... although it has its
purpose - other Exynos-specific drivers need to access through regmap.

Best regards,
Krzysztof
Sylwester Nawrocki Aug. 20, 2019, 9:38 p.m. UTC | #4
On 8/20/19 21:37, Krzysztof Kozlowski wrote:
>>> diff --git a/drivers/soc/samsung/exynos-chipid.c b/drivers/soc/samsung/exynos-chipid.c

>>> @@ -51,29 +48,24 @@ static const char * __init product_id_to_soc_id(unsigned int product_id)
>>>   int __init exynos_chipid_early_init(void)
>>>   {
>>>        struct soc_device_attribute *soc_dev_attr;
>>> -     void __iomem *exynos_chipid_base;
>>>        struct soc_device *soc_dev;
>>>        struct device_node *root;
>>> -     struct device_node *np;
>>> +     struct regmap *regmap;
>>>        u32 product_id;
>>>        u32 revision;
>>> +     int ret;
>>>
>>> -     /* look up for chipid node */
>>> -     np = of_find_compatible_node(NULL, NULL, "samsung,exynos4210-chipid");
>>> -     if (!np)
>>> -             return -ENODEV;
>>> -
>>> -     exynos_chipid_base = of_iomap(np, 0);
>>> -     of_node_put(np);
>>> -
>>> -     if (!exynos_chipid_base) {
>>> -             pr_err("Failed to map SoC chipid\n");
>>> -             return -ENXIO;
>>> +     regmap = syscon_regmap_lookup_by_compatible("samsung,exynos4210-chipid");
>>> +     if (IS_ERR(regmap)) {
>>> +             pr_err("Failed to get CHIPID regmap\n");
>>> +             return PTR_ERR(regmap);
>>>        }
>> 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.

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
pull request doesn't appear to be merged to arm-soc yet. Sorry about
that.

--
Regards,
Sylwester
Krzysztof Kozlowski Aug. 21, 2019, 7:49 a.m. UTC | #5
On Tue, 20 Aug 2019 at 23:38, Sylwester Nawrocki <snawrocki@kernel.org> wrote:
>
> On 8/20/19 21:37, Krzysztof Kozlowski wrote:
> >>> diff --git a/drivers/soc/samsung/exynos-chipid.c b/drivers/soc/samsung/exynos-chipid.c
>
> >>> @@ -51,29 +48,24 @@ static const char * __init product_id_to_soc_id(unsigned int product_id)
> >>>   int __init exynos_chipid_early_init(void)
> >>>   {
> >>>        struct soc_device_attribute *soc_dev_attr;
> >>> -     void __iomem *exynos_chipid_base;
> >>>        struct soc_device *soc_dev;
> >>>        struct device_node *root;
> >>> -     struct device_node *np;
> >>> +     struct regmap *regmap;
> >>>        u32 product_id;
> >>>        u32 revision;
> >>> +     int ret;
> >>>
> >>> -     /* look up for chipid node */
> >>> -     np = of_find_compatible_node(NULL, NULL, "samsung,exynos4210-chipid");
> >>> -     if (!np)
> >>> -             return -ENODEV;
> >>> -
> >>> -     exynos_chipid_base = of_iomap(np, 0);
> >>> -     of_node_put(np);
> >>> -
> >>> -     if (!exynos_chipid_base) {
> >>> -             pr_err("Failed to map SoC chipid\n");
> >>> -             return -ENXIO;
> >>> +     regmap = syscon_regmap_lookup_by_compatible("samsung,exynos4210-chipid");
> >>> +     if (IS_ERR(regmap)) {
> >>> +             pr_err("Failed to get CHIPID regmap\n");
> >>> +             return PTR_ERR(regmap);
> >>>        }
> >> 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.
>
> 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
> pull request doesn't appear to be merged to arm-soc yet. Sorry about
> that.

Yes, let's abandon the pull request and rework the concept.

Best regards,
Krzysztof
Bartlomiej Zolnierkiewicz Aug. 21, 2019, 11:51 a.m. UTC | #6
Hi,

On 8/20/19 11:38 PM, Sylwester Nawrocki wrote:
> On 8/20/19 21:37, Krzysztof Kozlowski wrote:
>>>> diff --git a/drivers/soc/samsung/exynos-chipid.c b/drivers/soc/samsung/exynos-chipid.c
> 
>>>> @@ -51,29 +48,24 @@ static const char * __init product_id_to_soc_id(unsigned int product_id)
>>>>   int __init exynos_chipid_early_init(void)
>>>>   {
>>>>        struct soc_device_attribute *soc_dev_attr;
>>>> -     void __iomem *exynos_chipid_base;
>>>>        struct soc_device *soc_dev;
>>>>        struct device_node *root;
>>>> -     struct device_node *np;
>>>> +     struct regmap *regmap;
>>>>        u32 product_id;
>>>>        u32 revision;
>>>> +     int ret;
>>>>
>>>> -     /* look up for chipid node */
>>>> -     np = of_find_compatible_node(NULL, NULL, "samsung,exynos4210-chipid");
>>>> -     if (!np)
>>>> -             return -ENODEV;
>>>> -
>>>> -     exynos_chipid_base = of_iomap(np, 0);
>>>> -     of_node_put(np);
>>>> -
>>>> -     if (!exynos_chipid_base) {
>>>> -             pr_err("Failed to map SoC chipid\n");
>>>> -             return -ENXIO;
>>>> +     regmap = syscon_regmap_lookup_by_compatible("samsung,exynos4210-chipid");
>>>> +     if (IS_ERR(regmap)) {
>>>> +             pr_err("Failed to get CHIPID regmap\n");
>>>> +             return PTR_ERR(regmap);
>>>>        }
>>> 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

> 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.

> pull request doesn't appear to be merged to arm-soc yet. Sorry about
> that.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Krzysztof Kozlowski Aug. 21, 2019, 12:16 p.m. UTC | #7
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
Sylwester Nawrocki Aug. 21, 2019, 12:41 p.m. UTC | #8
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).
Krzysztof Kozlowski Aug. 21, 2019, 1:10 p.m. UTC | #9
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
Bartlomiej Zolnierkiewicz Aug. 21, 2019, 1:31 p.m. UTC | #10
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

Patch
diff mbox series

diff --git a/drivers/soc/samsung/exynos-chipid.c b/drivers/soc/samsung/exynos-chipid.c
index bcf691f2b650..006a95feb618 100644
--- a/drivers/soc/samsung/exynos-chipid.c
+++ b/drivers/soc/samsung/exynos-chipid.c
@@ -9,16 +9,13 @@ 
  */
 
 #include <linux/io.h>
+#include <linux/mfd/syscon.h>
 #include <linux/of.h>
-#include <linux/of_address.h>
+#include <linux/regmap.h>
 #include <linux/slab.h>
+#include <linux/soc/samsung/exynos-chipid.h>
 #include <linux/sys_soc.h>
 
-#define EXYNOS_SUBREV_MASK	(0xF << 4)
-#define EXYNOS_MAINREV_MASK	(0xF << 0)
-#define EXYNOS_REV_MASK		(EXYNOS_SUBREV_MASK | EXYNOS_MAINREV_MASK)
-#define EXYNOS_MASK		0xFFFFF000
-
 static const struct exynos_soc_id {
 	const char *name;
 	unsigned int id;
@@ -51,29 +48,24 @@  static const char * __init product_id_to_soc_id(unsigned int product_id)
 int __init exynos_chipid_early_init(void)
 {
 	struct soc_device_attribute *soc_dev_attr;
-	void __iomem *exynos_chipid_base;
 	struct soc_device *soc_dev;
 	struct device_node *root;
-	struct device_node *np;
+	struct regmap *regmap;
 	u32 product_id;
 	u32 revision;
+	int ret;
 
-	/* look up for chipid node */
-	np = of_find_compatible_node(NULL, NULL, "samsung,exynos4210-chipid");
-	if (!np)
-		return -ENODEV;
-
-	exynos_chipid_base = of_iomap(np, 0);
-	of_node_put(np);
-
-	if (!exynos_chipid_base) {
-		pr_err("Failed to map SoC chipid\n");
-		return -ENXIO;
+	regmap = syscon_regmap_lookup_by_compatible("samsung,exynos4210-chipid");
+	if (IS_ERR(regmap)) {
+		pr_err("Failed to get CHIPID regmap\n");
+		return PTR_ERR(regmap);
 	}
 
-	product_id = readl_relaxed(exynos_chipid_base);
+	ret = regmap_read(regmap, EXYNOS_CHIPID_REG_PRO_ID, &product_id);
+	if (ret < 0)
+		return ret;
+
 	revision = product_id & EXYNOS_REV_MASK;
-	iounmap(exynos_chipid_base);
 
 	soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
 	if (!soc_dev_attr)
diff --git a/include/linux/soc/samsung/exynos-chipid.h b/include/linux/soc/samsung/exynos-chipid.h
new file mode 100644
index 000000000000..8bca6763f99c
--- /dev/null
+++ b/include/linux/soc/samsung/exynos-chipid.h
@@ -0,0 +1,52 @@ 
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2018 Samsung Electronics Co., Ltd.
+ *	      http://www.samsung.com/
+ *
+ * Exynos - CHIPID support
+ */
+#ifndef __LINUX_SOC_EXYNOS_CHIPID_H
+#define __LINUX_SOC_EXYNOS_CHIPID_H
+
+#define EXYNOS_CHIPID_REG_PRO_ID	0x00
+#define EXYNOS_SUBREV_MASK		(0xf << 4)
+#define EXYNOS_MAINREV_MASK		(0xf << 0)
+#define EXYNOS_REV_MASK			(EXYNOS_SUBREV_MASK | \
+					 EXYNOS_MAINREV_MASK)
+#define EXYNOS_MASK			0xfffff000
+
+#define EXYNOS_CHIPID_REG_PKG_ID	0x04
+/* Bit field definitions for EXYNOS_CHIPID_REG_PKG_ID register */
+#define EXYNOS5422_IDS_OFFSET		24
+#define EXYNOS5422_IDS_MASK		0xff
+#define EXYNOS5422_USESG_OFFSET	3
+#define EXYNOS5422_USESG_MASK		0x01
+#define EXYNOS5422_SG_OFFSET		0
+#define EXYNOS5422_SG_MASK		0x07
+#define EXYNOS5422_TABLE_OFFSET	8
+#define EXYNOS5422_TABLE_MASK		0x03
+#define EXYNOS5422_SG_A_OFFSET		17
+#define EXYNOS5422_SG_A_MASK		0x0f
+#define EXYNOS5422_SG_B_OFFSET		21
+#define EXYNOS5422_SG_B_MASK		0x03
+#define EXYNOS5422_SG_BSIGN_OFFSET	23
+#define EXYNOS5422_SG_BSIGN_MASK	0x01
+#define EXYNOS5422_BIN2_OFFSET		12
+#define EXYNOS5422_BIN2_MASK		0x01
+
+#define EXYNOS_CHIPID_REG_LOT_ID	0x14
+
+#define EXYNOS_CHIPID_REG_AUX_INFO	0x1c
+/* Bit field definitions for EXYNOS_CHIPID_REG_AUX_INFO register */
+#define EXYNOS5422_TMCB_OFFSET		0
+#define EXYNOS5422_TMCB_MASK		0x7f
+#define EXYNOS5422_ARM_UP_OFFSET	8
+#define EXYNOS5422_ARM_UP_MASK		0x03
+#define EXYNOS5422_ARM_DN_OFFSET	10
+#define EXYNOS5422_ARM_DN_MASK		0x03
+#define EXYNOS5422_KFC_UP_OFFSET	12
+#define EXYNOS5422_KFC_UP_MASK		0x03
+#define EXYNOS5422_KFC_DN_OFFSET	14
+#define EXYNOS5422_KFC_DN_MASK		0x03
+
+#endif /*__LINUX_SOC_EXYNOS_CHIPID_H */