All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@avionic-design.de>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>,
	Tomasz Figa <t.figa@samsung.com>,
	Thomas Abraham <thomas.abraham@linaro.org>,
	Kukjin Kim <kgene.kim@samsung.com>,
	Tushar Behera <tushar.behera@linaro.org>,
	Deepak Saxena <dsaxena@linaro.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-samsung-soc@vger.kernel.org,
	Olof Johansson <olof@lixom.net>
Subject: Re: [PATCH 00/23] RFC: exynos multiplatform support
Date: Thu, 7 Mar 2013 08:22:03 +0100	[thread overview]
Message-ID: <20130307072203.GC3451@avionic-0098.mockup.avionic-design.de> (raw)
In-Reply-To: <201303070302.46593.arnd@arndb.de>

[-- Attachment #1: Type: text/plain, Size: 1537 bytes --]

On Thu, Mar 07, 2013 at 03:02:46AM +0000, Arnd Bergmann wrote:
> On Wednesday 06 March 2013, Thierry Reding wrote:
> > > Option 2 would probably come down to having a trivial MFD driver exposing
> > > a regmap. You can probably reuse drivers/mfd/syscon.c for this and make
> > > the node compatible with "syscon" to designate the clock registers as
> > > a system-wide resource, making the other device nodes register-less.
> > 
> > I think option 2 is the standard method if one hardware block provides
> > several logical devices. I find it to be a pretty nice solution to this
> > problem. We also have precedent in the PWM subsystem. The TWL chips for
> > instance use it to create a platform device which is later driven by a
> > PWM driver.
> 
> One difference though is that the TWL chip is a heterogenous MFD that has
> a lot of different sub-devices, where in case of Exynos the timer device
> has a set of identical units, each of which can be used either as a PWM or
> as a clocksource or other timer.

I didn't know that. However I still making this an MFD driver is a good
fit because it'll move the logic of defining the mode of each unit is
kept in a parent driver which can instantiate the proper child devices
for the corresponding subsystems.

One big disadvantage of this approach is that if this is continued there
is a risk that MFD will turn into a dump for all kinds of devices that
provide more than a single service.

So if people prefer option 3 I'm fine with it as well.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: thierry.reding@avionic-design.de (Thierry Reding)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 00/23] RFC: exynos multiplatform support
Date: Thu, 7 Mar 2013 08:22:03 +0100	[thread overview]
Message-ID: <20130307072203.GC3451@avionic-0098.mockup.avionic-design.de> (raw)
In-Reply-To: <201303070302.46593.arnd@arndb.de>

On Thu, Mar 07, 2013 at 03:02:46AM +0000, Arnd Bergmann wrote:
> On Wednesday 06 March 2013, Thierry Reding wrote:
> > > Option 2 would probably come down to having a trivial MFD driver exposing
> > > a regmap. You can probably reuse drivers/mfd/syscon.c for this and make
> > > the node compatible with "syscon" to designate the clock registers as
> > > a system-wide resource, making the other device nodes register-less.
> > 
> > I think option 2 is the standard method if one hardware block provides
> > several logical devices. I find it to be a pretty nice solution to this
> > problem. We also have precedent in the PWM subsystem. The TWL chips for
> > instance use it to create a platform device which is later driven by a
> > PWM driver.
> 
> One difference though is that the TWL chip is a heterogenous MFD that has
> a lot of different sub-devices, where in case of Exynos the timer device
> has a set of identical units, each of which can be used either as a PWM or
> as a clocksource or other timer.

I didn't know that. However I still making this an MFD driver is a good
fit because it'll move the logic of defining the mode of each unit is
kept in a parent driver which can instantiate the proper child devices
for the corresponding subsystems.

One big disadvantage of this approach is that if this is continued there
is a risk that MFD will turn into a dump for all kinds of devices that
provide more than a single service.

So if people prefer option 3 I'm fine with it as well.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130307/44a92c5e/attachment.sig>

  reply	other threads:[~2013-03-07  7:22 UTC|newest]

Thread overview: 99+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-05 17:42 [PATCH 00/23] RFC: exynos multiplatform support Arnd Bergmann
2013-03-05 17:42 ` Arnd Bergmann
2013-03-05 17:42 ` [PATCH 01/23] ARM: exynos: introduce EXYNOS_ATAGS symbol Arnd Bergmann
2013-03-05 17:42   ` Arnd Bergmann
2013-03-05 17:42 ` [PATCH 02/23] irqchip: exynos: remove dependency on mach/irqs.h Arnd Bergmann
2013-03-05 17:42   ` Arnd Bergmann
2013-03-05 17:42 ` [PATCH 03/23] tty: serial/samsung: prepare for common clock API Arnd Bergmann
2013-03-05 17:42   ` Arnd Bergmann
2013-03-05 17:42 ` [PATCH 04/23] tty: serial/samsung: make register definitions global Arnd Bergmann
2013-03-05 17:42   ` Arnd Bergmann
2013-03-05 17:42 ` [PATCH 05/23] tty: serial/samsung: fix modular build Arnd Bergmann
2013-03-05 17:42   ` Arnd Bergmann
2013-03-05 17:42 ` [PATCH 06/23] ARM: exynos: move debug-macro.S to include/debug/ Arnd Bergmann
2013-03-05 17:42   ` Arnd Bergmann
2013-03-05 17:42 ` [PATCH 07/23] i2c: s3c2410: make header file local Arnd Bergmann
2013-03-05 17:42   ` Arnd Bergmann
2013-04-02 20:36   ` Heiko Stübner
2013-04-02 20:36     ` Heiko Stübner
2013-03-05 17:42 ` [PATCH 08/23] mmc: sdhci-s3c: remove platform dependencies Arnd Bergmann
2013-03-05 17:42   ` Arnd Bergmann
2013-03-05 17:42 ` [PATCH 09/23] usb: exynos: do not include plat/usb-phy.h Arnd Bergmann
2013-03-05 17:42   ` Arnd Bergmann
2013-03-05 17:42 ` [PATCH 10/23] [media] exynos: remove unnecessary header inclusions Arnd Bergmann
2013-03-05 17:42   ` Arnd Bergmann
2013-04-02 13:08   ` Sylwester Nawrocki
2013-04-02 13:08     ` Sylwester Nawrocki
2013-04-02 13:17     ` Sylwester Nawrocki
2013-03-05 17:42 ` [PATCH 11/23] video/exynos: " Arnd Bergmann
2013-03-05 17:42   ` Arnd Bergmann
2013-03-05 17:42 ` [PATCH 12/23] thermal/exynos: " Arnd Bergmann
2013-03-05 17:42   ` Arnd Bergmann
2013-03-05 17:42 ` [PATCH 13/23] mtd: onenand/samsung: make regs-onenand.h file local Arnd Bergmann
2013-03-05 17:42   ` Arnd Bergmann
2013-03-05 17:42 ` [PATCH 14/23] rtc: s3c: make header " Arnd Bergmann
2013-03-05 17:42   ` Arnd Bergmann
2013-03-05 17:42 ` [PATCH 15/23] spi: s3c64xx: move to generic dmaengine API Arnd Bergmann
2013-03-05 17:42   ` Arnd Bergmann
2013-03-06  9:14   ` Padma Venkat
2013-03-06  9:14     ` Padma Venkat
2013-03-05 17:42 ` [PATCH 16/23] pwm: samsung: repair the worst MMIO abuses Arnd Bergmann
2013-03-05 17:42   ` Arnd Bergmann
2013-03-05 17:42 ` [PATCH 17/23] ASoC: samsung: move plat/ headers to local directory Arnd Bergmann
2013-03-05 17:42   ` Arnd Bergmann
2013-03-05 17:42 ` [PATCH 18/23] ASoC: samsung: convert to dmaengine API Arnd Bergmann
2013-03-05 17:42   ` Arnd Bergmann
2013-03-06  8:58   ` Padma Venkat
2013-03-06  8:58     ` Padma Venkat
2013-03-06 12:01     ` Arnd Bergmann
2013-03-06 12:01       ` Arnd Bergmann
2013-03-05 17:42 ` [PATCH 19/23] ASoC: samsung: use irq resource for idma Arnd Bergmann
2013-03-05 17:42   ` Arnd Bergmann
2013-03-05 17:42 ` [PATCH 20/23] ARM: exynos: prepare for sparse IRQ Arnd Bergmann
2013-03-05 17:42   ` Arnd Bergmann
2013-03-05 17:42 ` [PATCH 21/23] ARM: exynos: hack to disable private clock code Arnd Bergmann
2013-03-05 17:42   ` Arnd Bergmann
2013-03-05 17:42 ` [PATCH 22/23] ARM: exynos: work around missing gpio code on multiplatform Arnd Bergmann
2013-03-05 17:42   ` Arnd Bergmann
2013-03-05 17:42 ` [PATCH 23/23] ARM: exynos: experimental multiplatform support Arnd Bergmann
2013-03-05 17:42   ` Arnd Bergmann
2013-03-05 18:27 ` [PATCH 00/23] RFC: exynos " Tony Lindgren
2013-03-05 18:27   ` Tony Lindgren
2013-03-05 18:28 ` Tomasz Figa
2013-03-05 18:28   ` Tomasz Figa
2013-03-05 19:19   ` Arnd Bergmann
2013-03-05 19:19     ` Arnd Bergmann
2013-03-05 22:48     ` Tomasz Figa
2013-03-05 22:48       ` Tomasz Figa
2013-03-06 10:50       ` Arnd Bergmann
2013-03-06 10:50         ` Arnd Bergmann
2013-03-06 12:34         ` Thierry Reding
2013-03-06 12:34           ` Thierry Reding
2013-03-06 22:57           ` Tomasz Figa
2013-03-06 22:57             ` Tomasz Figa
2013-03-07  3:02           ` Arnd Bergmann
2013-03-07  3:02             ` Arnd Bergmann
2013-03-07  7:22             ` Thierry Reding [this message]
2013-03-07  7:22               ` Thierry Reding
2013-03-08  0:40               ` Tomasz Figa
2013-03-08  0:40                 ` Tomasz Figa
2013-03-08 12:52                 ` Arnd Bergmann
2013-03-08 12:52                   ` Arnd Bergmann
2013-03-06 22:14       ` Heiko Stübner
2013-03-06 22:14         ` Heiko Stübner
2013-03-06 22:55         ` Tomasz Figa
2013-03-06 22:55           ` Tomasz Figa
2013-03-05 20:50 ` Heiko Stübner
2013-03-05 20:50   ` Heiko Stübner
2013-03-05 21:24   ` Arnd Bergmann
2013-03-05 21:24     ` Arnd Bergmann
2013-03-05 21:54     ` Arnd Bergmann
2013-03-05 21:54       ` Arnd Bergmann
2013-03-05 22:12       ` Tomasz Figa
2013-03-05 22:12         ` Tomasz Figa
2013-03-05 22:21         ` Arnd Bergmann
2013-03-05 22:21           ` Arnd Bergmann
2013-03-05 22:25       ` Heiko Stübner
2013-03-05 22:25         ` Heiko Stübner
2013-03-05 22:43         ` Arnd Bergmann
2013-03-05 22:43           ` Arnd Bergmann

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=20130307072203.GC3451@avionic-0098.mockup.avionic-design.de \
    --to=thierry.reding@avionic-design.de \
    --cc=arnd@arndb.de \
    --cc=dsaxena@linaro.org \
    --cc=kgene.kim@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=t.figa@samsung.com \
    --cc=thomas.abraham@linaro.org \
    --cc=tomasz.figa@gmail.com \
    --cc=tushar.behera@linaro.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.