From: Lee Jones <lee.jones@linaro.org>
To: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
linux-arm-kernel@lists.infradead.org, mark.brown@linaro.org,
Tomasz Figa <t.figa@samsung.com>,
linux-samsung-soc@vger.kernel.org,
Kukjin Kim <kgene.kim@samsung.com>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
Samuel Ortiz <sameo@linux.intel.com>,
Pankaj Dubey <pankaj.dubey@samsung.com>,
linux-kernel@vger.kernel.org, joshi@samsung.com,
vikas.sajjan@samsung.com, chow.kim@samsung.com,
michal.simek@xilinx.com
Subject: Re: [PATCH RFC] mfd: syscon: Decouple syscon interface from syscon devices
Date: Wed, 18 Jun 2014 09:26:53 +0100 [thread overview]
Message-ID: <20140618082653.GN21030@lee--X1> (raw)
In-Reply-To: <53A0B27E.5010708@gmail.com>
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.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2014-06-18 8:27 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-10 6:56 [PATCH v4 00/11] ARM: Exynos: PMU cleanup and refactoring for using DT Pankaj Dubey
2014-05-10 6:56 ` [PATCH v4 01/11] ARM: EXYNOS: Make exynos machine_ops as static Pankaj Dubey
2014-06-10 11:43 ` Tomasz Figa
2014-05-10 6:56 ` [PATCH v4 02/11] ARM: EXYNOS: Move cpufreq and cpuidle device registration to init_machine Pankaj Dubey
2014-06-10 11:46 ` Tomasz Figa
2014-06-17 3:48 ` Pankaj Dubey
2014-05-10 6:56 ` [PATCH v4 03/11] ARM: EXYNOS: Move SYSREG definition into sys-reg specific file Pankaj Dubey
2014-05-10 6:56 ` [PATCH v4 04/11] ARM: EXYNOS: Remove file path from comment section Pankaj Dubey
2014-05-10 6:56 ` [PATCH v4 05/11] ARM: EXYNOS: Remove regs-pmu.h header dependency from pm_domain Pankaj Dubey
2014-05-10 6:56 ` [PATCH v4 06/11] ARM: EXYNOS: Add support for mapping PMU base address via DT Pankaj Dubey
2014-06-10 17:10 ` Tomasz Figa
2014-06-17 6:43 ` Pankaj Dubey
2014-06-17 15:26 ` Tomasz Figa
2014-06-17 15:32 ` [PATCH RFC] mfd: syscon: Decouple syscon interface from syscon devices Tomasz Figa
2014-06-17 15:42 ` Arnd Bergmann
2014-06-17 21:26 ` Tomasz Figa
2014-06-18 8:26 ` Lee Jones [this message]
2014-06-24 11:03 ` Pankaj Dubey
2014-06-18 12:57 ` Arnd Bergmann
2014-06-19 0:06 ` Michal Simek
2014-07-28 4:15 ` Pankaj Dubey
2014-05-10 6:56 ` [PATCH v4 07/11] ARM: EXYNOS: Remove "linux/bug.h" from pmu.c Pankaj Dubey
2014-05-10 6:56 ` [PATCH v4 08/11] ARM: EXYNOS: Refactored code for using PMU address via DT Pankaj Dubey
2014-06-17 16:02 ` Tomasz Figa
2014-05-10 6:56 ` [PATCH v4 09/11] ARM: EXYNOS: Move "mach/map.h" inclusion from regs-pmu.h to platsmp.c Pankaj Dubey
2014-06-17 16:04 ` Tomasz Figa
2014-05-10 6:56 ` [PATCH v4 10/11] ARM: EXYNOS: Add platform driver support for Exynos PMU Pankaj Dubey
2014-06-17 17:12 ` Tomasz Figa
2014-06-24 11:28 ` Pankaj Dubey
2014-06-25 0:11 ` Tomasz Figa
2014-06-25 4:30 ` Pankaj Dubey
2014-05-10 6:56 ` [PATCH v4 11/11] ARM: EXYNOS: Move PMU specific definitions from common.h Pankaj Dubey
2014-05-27 11:26 ` [PATCH v4 00/11] ARM: Exynos: PMU cleanup and refactoring for using DT Vikas Sajjan
2014-05-30 11:58 ` Tomasz Figa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140618082653.GN21030@lee--X1 \
--to=lee.jones@linaro.org \
--cc=arnd@arndb.de \
--cc=chow.kim@samsung.com \
--cc=joshi@samsung.com \
--cc=kgene.kim@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mark.brown@linaro.org \
--cc=michal.simek@xilinx.com \
--cc=pankaj.dubey@samsung.com \
--cc=sameo@linux.intel.com \
--cc=t.figa@samsung.com \
--cc=tomasz.figa@gmail.com \
--cc=vikas.sajjan@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox