diff mbox

[RFC] mfd: syscon: Decouple syscon interface from syscon devices

Message ID 1403019164-12514-1-git-send-email-t.figa@samsung.com (mailing list archive)
State New, archived
Headers show

Commit Message

Tomasz Figa June 17, 2014, 3:32 p.m. UTC
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated driver. However in certain use
cases it is desirable to make a device used with another driver a syscon
interface provider. For example, certain SoCs (e.g. Exynos) contain
system controller blocks which perform various functions such as power
domain control, CPU power management, low power mode control, but in
addition contain certain IP integration glue, such as various signal
masks, coprocessor power control, etc. In such case, there is a need to
have a dedicated driver for such system controller but also share
registers with other drivers. The latter is where the syscon interface
is helpful.

This patch decouples syscon object from syscon driver, so that it can be
registered from any driver in addition to the original "syscon" platform
driver.

Signed-off-by: Tomasz Figa <t.figa@samsung.com>
---
 drivers/mfd/syscon.c       | 102 +++++++++++++++++++++++++++++----------------
 include/linux/mfd/syscon.h |   9 ++++
 2 files changed, 75 insertions(+), 36 deletions(-)

Comments

Arnd Bergmann June 17, 2014, 3:42 p.m. UTC | #1
On Tuesday 17 June 2014 17:32:44 Tomasz Figa wrote:
> Currently a syscon entity can be only registered directly through a
> platform device that binds to a dedicated driver. However in certain use
> cases it is desirable to make a device used with another driver a syscon
> interface provider. For example, certain SoCs (e.g. Exynos) contain
> system controller blocks which perform various functions such as power
> domain control, CPU power management, low power mode control, but in
> addition contain certain IP integration glue, such as various signal
> masks, coprocessor power control, etc. In such case, there is a need to
> have a dedicated driver for such system controller but also share
> registers with other drivers. The latter is where the syscon interface
> is helpful.
> 
> This patch decouples syscon object from syscon driver, so that it can be
> registered from any driver in addition to the original "syscon" platform
> driver.
> 
> Signed-off-by: Tomasz Figa <t.figa@samsung.com>

Hi Tomasz,

This seems like a reasonable way of solving the problem, but I think
there is an even better one that we have about in the past: if we
promote syscon from a platform driver into a a drivers/base/ helper
that is independent of the platform device matching, we can use
call syscon_regmap_lookup_* for any device node, whether it's already
bound to a driver or not, which do what you need. It would also make
it easier to call the syscon code before the platform_device
infrastructure gets initialized, which is something a number of
people have asked for, e.g. for using regmap to do SMP bringup
or for clock registration.

	Arnd
Tomasz Figa June 17, 2014, 9:26 p.m. UTC | #2
Hi Arnd,

On 17.06.2014 17:42, Arnd Bergmann wrote:
> On Tuesday 17 June 2014 17:32:44 Tomasz Figa wrote:
>> Currently a syscon entity can be only registered directly through a
>> platform device that binds to a dedicated driver. However in certain use
>> cases it is desirable to make a device used with another driver a syscon
>> interface provider. For example, certain SoCs (e.g. Exynos) contain
>> system controller blocks which perform various functions such as power
>> domain control, CPU power management, low power mode control, but in
>> addition contain certain IP integration glue, such as various signal
>> masks, coprocessor power control, etc. In such case, there is a need to
>> have a dedicated driver for such system controller but also share
>> registers with other drivers. The latter is where the syscon interface
>> is helpful.
>>
>> This patch decouples syscon object from syscon driver, so that it can be
>> registered from any driver in addition to the original "syscon" platform
>> driver.
>>
>> Signed-off-by: Tomasz Figa <t.figa@samsung.com>
> 
> Hi Tomasz,
> 
> This seems like a reasonable way of solving the problem, but I think
> there is an even better one that we have about in the past: if we
> promote syscon from a platform driver into a a drivers/base/ helper
> that is independent of the platform device matching, we can use
> call syscon_regmap_lookup_* for any device node, whether it's already
> bound to a driver or not, which do what you need. It would also make
> it easier to call the syscon code before the platform_device
> infrastructure gets initialized, which is something a number of
> people have asked for, e.g. for using regmap to do SMP bringup
> or for clock registration.

Basically, unless I'm missing your point, this is what my patch does,
except that I don't move it to drivers/base/ and the registration
function I added require a pointer to struct device. Indeed, decoupling
it further from the driver model, by adding of_syscon_register() should
be useful for early users.

Should I move this to drivers/base/, even though from current location
it can be used outside the platform driver anyway?

Best regards,
Tomasz
Lee Jones June 18, 2014, 8:26 a.m. UTC | #3
On Tue, 17 Jun 2014, Tomasz Figa wrote:
> On 17.06.2014 17:42, Arnd Bergmann wrote:
> > On Tuesday 17 June 2014 17:32:44 Tomasz Figa wrote:
> >> Currently a syscon entity can be only registered directly through a
> >> platform device that binds to a dedicated driver. However in certain use
> >> cases it is desirable to make a device used with another driver a syscon
> >> interface provider. For example, certain SoCs (e.g. Exynos) contain
> >> system controller blocks which perform various functions such as power
> >> domain control, CPU power management, low power mode control, but in
> >> addition contain certain IP integration glue, such as various signal
> >> masks, coprocessor power control, etc. In such case, there is a need to
> >> have a dedicated driver for such system controller but also share
> >> registers with other drivers. The latter is where the syscon interface
> >> is helpful.
> >>
> >> This patch decouples syscon object from syscon driver, so that it can be
> >> registered from any driver in addition to the original "syscon" platform
> >> driver.

+1 for this approach.

Michal, Pankay,
  Does it also suit your needs?

> >> Signed-off-by: Tomasz Figa <t.figa@samsung.com>
> > 
> > Hi Tomasz,
> > 
> > This seems like a reasonable way of solving the problem, but I think
> > there is an even better one that we have about in the past: if we
> > promote syscon from a platform driver into a a drivers/base/ helper
> > that is independent of the platform device matching, we can use
> > call syscon_regmap_lookup_* for any device node, whether it's already
> > bound to a driver or not, which do what you need. It would also make
> > it easier to call the syscon code before the platform_device
> > infrastructure gets initialized, which is something a number of
> > people have asked for, e.g. for using regmap to do SMP bringup
> > or for clock registration.
> 
> Basically, unless I'm missing your point, this is what my patch does,
> except that I don't move it to drivers/base/ and the registration
> function I added require a pointer to struct device. Indeed, decoupling
> it further from the driver model, by adding of_syscon_register() should
> be useful for early users.

If agreed by Arnd, I think this work can be completed as a subsequent
patch.

> Should I move this to drivers/base/, even though from current location
> it can be used outside the platform driver anyway?

If I'm being honest with myself, I'd say that Syscon wasn't really an
MFD driver.  I'm happy to keep it in there any continue maintaining
it, but wouldn't block a move either.
Arnd Bergmann June 18, 2014, 12:57 p.m. UTC | #4
On Tuesday 17 June 2014 23:26:22 Tomasz Figa wrote:
> On 17.06.2014 17:42, Arnd Bergmann wrote:
> > This seems like a reasonable way of solving the problem, but I think
> > there is an even better one that we have about in the past: if we
> > promote syscon from a platform driver into a a drivers/base/ helper
> > that is independent of the platform device matching, we can use
> > call syscon_regmap_lookup_* for any device node, whether it's already
> > bound to a driver or not, which do what you need. It would also make
> > it easier to call the syscon code before the platform_device
> > infrastructure gets initialized, which is something a number of
> > people have asked for, e.g. for using regmap to do SMP bringup
> > or for clock registration.
> 
> Basically, unless I'm missing your point, this is what my patch does,
> except that I don't move it to drivers/base/ and the registration
> function I added require a pointer to struct device. Indeed, decoupling
> it further from the driver model, by adding of_syscon_register() should
> be useful for early users.

I believe the part you are missing is that with the approach I suggested,
there would be no registration function at all. You can easily do the
lookup from the client drivers using the DT data structures, with no
need for the device at all. The only exception today is the clps711x
platform using syscon_regmap_lookup_by_pdevname(), but that should be
solved in 3.17 when clps711x becomes DT-only.

> Should I move this to drivers/base/, even though from current location
> it can be used outside the platform driver anyway?

Thinking about it some more, drivers/of might be better than drivers/base.
It depends a bit where we are heading with this, in particular if we
expect to see non-DT users in the future.

	Arnd
Michal Simek June 19, 2014, 12:06 a.m. UTC | #5
Hi,

On 06/18/2014 02:57 PM, Arnd Bergmann wrote:
> On Tuesday 17 June 2014 23:26:22 Tomasz Figa wrote:
>> On 17.06.2014 17:42, Arnd Bergmann wrote:
>>> This seems like a reasonable way of solving the problem, but I think
>>> there is an even better one that we have about in the past: if we
>>> promote syscon from a platform driver into a a drivers/base/ helper
>>> that is independent of the platform device matching, we can use
>>> call syscon_regmap_lookup_* for any device node, whether it's already
>>> bound to a driver or not, which do what you need. It would also make
>>> it easier to call the syscon code before the platform_device
>>> infrastructure gets initialized, which is something a number of
>>> people have asked for, e.g. for using regmap to do SMP bringup
>>> or for clock registration.
>>
>> Basically, unless I'm missing your point, this is what my patch does,
>> except that I don't move it to drivers/base/ and the registration
>> function I added require a pointer to struct device. Indeed, decoupling
>> it further from the driver model, by adding of_syscon_register() should
>> be useful for early users.
> 
> I believe the part you are missing is that with the approach I suggested,
> there would be no registration function at all. You can easily do the
> lookup from the client drivers using the DT data structures, with no
> need for the device at all. The only exception today is the clps711x
> platform using syscon_regmap_lookup_by_pdevname(), but that should be
> solved in 3.17 when clps711x becomes DT-only.

I agree with Arnd. This patch is doing the part of what we wanted to do with it.
It means create a list of registered devices.
But you are working with struct device which you can't use in early phase
which is the feature we wanted to use. But currently we have workaround
in the kernel and clk subsystem is not able to work with regmap anyway.

Moving to proper location is just the last step.

Thanks,
Michal
Pankaj Dubey June 24, 2014, 11:03 a.m. UTC | #6
Hi,

On Wednesday, June 18 2014, Lee Jones wrote:
> On Tue, 17 Jun 2014, Tomasz Figa wrote:
> > On 17.06.2014 17:42, Arnd Bergmann wrote:
> > > On Tuesday 17 June 2014 17:32:44 Tomasz Figa wrote:
> > >> Currently a syscon entity can be only registered directly through a
> > >> platform device that binds to a dedicated driver. However in
> > >> certain use cases it is desirable to make a device used with
> > >> another driver a syscon interface provider. For example, certain
> > >> SoCs (e.g. Exynos) contain system controller blocks which perform
> > >> various functions such as power domain control, CPU power
> > >> management, low power mode control, but in addition contain certain
> > >> IP integration glue, such as various signal masks, coprocessor
> > >> power control, etc. In such case, there is a need to have a
> > >> dedicated driver for such system controller but also share
> > >> registers with other drivers. The latter is where the syscon interface is helpful.
> > >>
> > >> This patch decouples syscon object from syscon driver, so that it
> > >> can be registered from any driver in addition to the original
> > >> "syscon" platform driver.
> 
> +1 for this approach.
> 
> Michal, Pankay,
>   Does it also suit your needs?
> 

Sorry for late reply. 
I tested this patch after changing exynos PMU to be a syscon provider and it's working well.
So if we can address Arnd's comments, this patch will be helpful in making exynos PMU a 
complete platform driver.

Thanks,
Pankaj Dubey

> > >> Signed-off-by: Tomasz Figa <t.figa@samsung.com>
> > >
> > > Hi Tomasz,
> > >
> > > This seems like a reasonable way of solving the problem, but I think
> > > there is an even better one that we have about in the past: if we
> > > promote syscon from a platform driver into a a drivers/base/ helper
> > > that is independent of the platform device matching, we can use call
> > > syscon_regmap_lookup_* for any device node, whether it's already
> > > bound to a driver or not, which do what you need. It would also make
> > > it easier to call the syscon code before the platform_device
> > > infrastructure gets initialized, which is something a number of
> > > people have asked for, e.g. for using regmap to do SMP bringup or
> > > for clock registration.
> >
> > Basically, unless I'm missing your point, this is what my patch does,
> > except that I don't move it to drivers/base/ and the registration
> > function I added require a pointer to struct device. Indeed,
> > decoupling it further from the driver model, by adding
> > of_syscon_register() should be useful for early users.
> 
> If agreed by Arnd, I think this work can be completed as a subsequent patch.
> 
> > Should I move this to drivers/base/, even though from current location
> > it can be used outside the platform driver anyway?
> 
> If I'm being honest with myself, I'd say that Syscon wasn't really an MFD driver.  I'm
> happy to keep it in there any continue maintaining it, but wouldn't block a move
> either.
> 
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead Linaro.org ? Open source software
> for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Pankaj Dubey July 28, 2014, 4:15 a.m. UTC | #7
Hi Arnd,

On Wednesday, June 18, 2014 Arnd wrote:
> To: Tomasz Figa
> Cc: linux-arm-kernel@lists.infradead.org; mark.brown@linaro.org; Tomasz
Figa;
> linux-samsung-soc@vger.kernel.org; Kukjin Kim; Russell King - ARM Linux;
Samuel
> Ortiz; Pankaj Dubey; linux-kernel@vger.kernel.org; joshi@samsung.com;
> vikas.sajjan@samsung.com; chow.kim@samsung.com; Lee Jones
> Subject: Re: [PATCH RFC] mfd: syscon: Decouple syscon interface from
syscon
> devices
> 
> On Tuesday 17 June 2014 23:26:22 Tomasz Figa wrote:
> > On 17.06.2014 17:42, Arnd Bergmann wrote:
> > > This seems like a reasonable way of solving the problem, but I think
> > > there is an even better one that we have about in the past: if we
> > > promote syscon from a platform driver into a a drivers/base/ helper
> > > that is independent of the platform device matching, we can use call
> > > syscon_regmap_lookup_* for any device node, whether it's already
> > > bound to a driver or not, which do what you need. It would also make
> > > it easier to call the syscon code before the platform_device
> > > infrastructure gets initialized, which is something a number of
> > > people have asked for, e.g. for using regmap to do SMP bringup or
> > > for clock registration.
> >
> > Basically, unless I'm missing your point, this is what my patch does,
> > except that I don't move it to drivers/base/ and the registration
> > function I added require a pointer to struct device. Indeed,
> > decoupling it further from the driver model, by adding
> > of_syscon_register() should be useful for early users.
> 
> I believe the part you are missing is that with the approach I suggested,
there would
> be no registration function at all. You can easily do the lookup from the
client drivers
> using the DT data structures, with no need for the device at all. 

Will you please elaborate more on this? 

The only exception
> today is the clps711x platform using syscon_regmap_lookup_by_pdevname(),
but
> that should be solved in 3.17 when clps711x becomes DT-only.
> 

Does it mean that this may become a blocking issue for this patch to go
before 3.17?
If yes, isn't it will be good to accept this patch as it is if it's not
causing issue or breaking
anything with existing users of syscon. At least for our use of converting
Exynos PMU and
PM related consolidation this change is working fine and we have verified
it.

> > Should I move this to drivers/base/, even though from current location
> > it can be used outside the platform driver anyway?
> 
> Thinking about it some more, drivers/of might be better than drivers/base.
> It depends a bit where we are heading with this, in particular if we
expect to see non-
> DT users in the future.
> 
> 	Arnd

Thanks,
Pankaj Dubey
diff mbox

Patch

diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
index ca15878..11baaae 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
@@ -14,6 +14,7 @@ 
 
 #include <linux/err.h>
 #include <linux/io.h>
+#include <linux/list.h>
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_address.h>
@@ -23,30 +24,28 @@ 
 #include <linux/regmap.h>
 #include <linux/mfd/syscon.h>
 
-static struct platform_driver syscon_driver;
+static DEFINE_SPINLOCK(syscon_list_slock);
+static LIST_HEAD(syscon_list);
 
 struct syscon {
 	struct regmap *regmap;
+	struct device *dev;
+	struct list_head list;
 };
 
-static int syscon_match_node(struct device *dev, void *data)
-{
-	struct device_node *dn = data;
-
-	return (dev->of_node == dn) ? 1 : 0;
-}
-
 struct regmap *syscon_node_to_regmap(struct device_node *np)
 {
-	struct syscon *syscon;
-	struct device *dev;
+	struct syscon *entry, *syscon = ERR_PTR(-EPROBE_DEFER);
+
+	spin_lock(&syscon_list_slock);
 
-	dev = driver_find_device(&syscon_driver.driver, NULL, np,
-				 syscon_match_node);
-	if (!dev)
-		return ERR_PTR(-EPROBE_DEFER);
+	list_for_each_entry(entry, &syscon_list, list)
+		if (entry->dev->of_node == np) {
+			syscon = entry;
+			break;
+		}
 
-	syscon = dev_get_drvdata(dev);
+	spin_unlock(&syscon_list_slock);
 
 	return syscon->regmap;
 }
@@ -68,22 +67,19 @@  struct regmap *syscon_regmap_lookup_by_compatible(const char *s)
 }
 EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_compatible);
 
-static int syscon_match_pdevname(struct device *dev, void *data)
-{
-	return !strcmp(dev_name(dev), (const char *)data);
-}
-
 struct regmap *syscon_regmap_lookup_by_pdevname(const char *s)
 {
-	struct device *dev;
-	struct syscon *syscon;
+	struct syscon *entry, *syscon = ERR_PTR(-EPROBE_DEFER);
+
+	spin_lock(&syscon_list_slock);
 
-	dev = driver_find_device(&syscon_driver.driver, NULL, (void *)s,
-				 syscon_match_pdevname);
-	if (!dev)
-		return ERR_PTR(-EPROBE_DEFER);
+	list_for_each_entry(entry, &syscon_list, list)
+		if (!strcmp(dev_name(entry->dev), s)) {
+			syscon = entry;
+			break;
+		}
 
-	syscon = dev_get_drvdata(dev);
+	spin_unlock(&syscon_list_slock);
 
 	return syscon->regmap;
 }
@@ -121,17 +117,49 @@  static struct regmap_config syscon_regmap_config = {
 	.reg_stride = 4,
 };
 
+static void devm_syscon_unregister(struct device *dev, void *res)
+{
+	struct syscon *syscon = *(struct syscon **)res;
+
+	spin_lock(&syscon_list_slock);
+	list_del(&syscon->list);
+	spin_unlock(&syscon_list_slock);
+}
+
+int devm_syscon_register(struct device *dev, struct regmap *regmap)
+{
+	struct syscon **ptr, *syscon;
+
+	syscon = devm_kzalloc(dev, sizeof(*syscon), GFP_KERNEL);
+	if (!syscon)
+		return -ENOMEM;
+
+	syscon->regmap = regmap;
+	syscon->dev = dev;
+
+	ptr = devres_alloc(devm_syscon_unregister, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return -ENOMEM;
+
+	spin_lock(&syscon_list_slock);
+	list_add_tail(&syscon->list, &syscon_list);
+	spin_unlock(&syscon_list_slock);
+
+	*ptr = syscon;
+	devres_add(dev, ptr);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(devm_syscon_register);
+
 static int syscon_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct syscon_platform_data *pdata = dev_get_platdata(dev);
-	struct syscon *syscon;
+	struct regmap *regmap;
 	struct resource *res;
 	void __iomem *base;
-
-	syscon = devm_kzalloc(dev, sizeof(*syscon), GFP_KERNEL);
-	if (!syscon)
-		return -ENOMEM;
+	int ret;
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	if (!res)
@@ -144,14 +172,16 @@  static int syscon_probe(struct platform_device *pdev)
 	syscon_regmap_config.max_register = res->end - res->start - 3;
 	if (pdata)
 		syscon_regmap_config.name = pdata->label;
-	syscon->regmap = devm_regmap_init_mmio(dev, base,
+	regmap = devm_regmap_init_mmio(dev, base,
 					&syscon_regmap_config);
-	if (IS_ERR(syscon->regmap)) {
+	if (IS_ERR(regmap)) {
 		dev_err(dev, "regmap init failed\n");
-		return PTR_ERR(syscon->regmap);
+		return PTR_ERR(regmap);
 	}
 
-	platform_set_drvdata(pdev, syscon);
+	ret = devm_syscon_register(dev, regmap);
+	if (ret)
+		return ret;
 
 	dev_dbg(dev, "regmap %pR registered\n", res);
 
diff --git a/include/linux/mfd/syscon.h b/include/linux/mfd/syscon.h
index 75e543b..6a1cadf 100644
--- a/include/linux/mfd/syscon.h
+++ b/include/linux/mfd/syscon.h
@@ -18,8 +18,11 @@ 
 #include <linux/err.h>
 
 struct device_node;
+struct regmap;
 
 #ifdef CONFIG_MFD_SYSCON
+extern int devm_syscon_register(struct device *dev, struct regmap *regmap);
+
 extern struct regmap *syscon_node_to_regmap(struct device_node *np);
 extern struct regmap *syscon_regmap_lookup_by_compatible(const char *s);
 extern struct regmap *syscon_regmap_lookup_by_pdevname(const char *s);
@@ -27,6 +30,12 @@  extern struct regmap *syscon_regmap_lookup_by_phandle(
 					struct device_node *np,
 					const char *property);
 #else
+static inline int devm_syscon_register(struct device *dev,
+				       struct regmap *regmap)
+{
+	return -ENOSYS;
+}
+
 static inline struct regmap *syscon_node_to_regmap(struct device_node *np)
 {
 	return ERR_PTR(-ENOSYS);