linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: tomasz.figa@gmail.com (Tomasz Figa)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 00/23] RFC: exynos multiplatform support
Date: Fri, 08 Mar 2013 01:40:53 +0100	[thread overview]
Message-ID: <3271021.WsP8f9ZEBl@flatron> (raw)
In-Reply-To: <20130307072203.GC3451@avionic-0098.mockup.avionic-design.de>

On Thursday 07 of March 2013 08:22:03 Thierry Reding wrote:
> 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.

I have a question regarding making this an MFD driver.

As you know, the main clocksource driver must be initialized early, from 
init_time callback of machine_desc. How does using the MFD subsystem fit 
into this scheme?

P.S. I'm still not convinced about any benefits of options 2 and 3 over 
option 1, which has the obvious advantage of requiring least amount of 
changes to existing code and not binding the PWM and clocksource drivers 
together (on Exynos SoCs only the PWM driver is used, clocksource is 
handled by different hardware block - MCT).

Best regards,
Tomasz

  reply	other threads:[~2013-03-08  0:40 UTC|newest]

Thread overview: 49+ 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 ` [PATCH 01/23] ARM: exynos: introduce EXYNOS_ATAGS symbol 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 ` [PATCH 03/23] tty: serial/samsung: prepare for common clock API Arnd Bergmann
2013-03-05 17:42 ` [PATCH 04/23] tty: serial/samsung: make register definitions global Arnd Bergmann
2013-03-05 17:42 ` [PATCH 05/23] tty: serial/samsung: fix modular build 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 ` [PATCH 07/23] i2c: s3c2410: make header file local Arnd Bergmann
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 ` [PATCH 09/23] usb: exynos: do not include plat/usb-phy.h Arnd Bergmann
2013-03-05 17:42 ` [PATCH 10/23] [media] exynos: remove unnecessary header inclusions Arnd Bergmann
2013-04-02 13:08   ` Sylwester Nawrocki
2013-03-05 17:42 ` [PATCH 11/23] video/exynos: " Arnd Bergmann
2013-03-05 17:42 ` [PATCH 12/23] thermal/exynos: " 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 ` [PATCH 14/23] rtc: s3c: make header " Arnd Bergmann
2013-03-05 17:42 ` [PATCH 15/23] spi: s3c64xx: move to generic dmaengine API Arnd Bergmann
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 ` [PATCH 17/23] ASoC: samsung: move plat/ headers to local directory Arnd Bergmann
2013-03-05 17:42 ` [PATCH 18/23] ASoC: samsung: convert to dmaengine API Arnd Bergmann
2013-03-06  8:58   ` Padma Venkat
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 ` [PATCH 20/23] ARM: exynos: prepare for sparse IRQ 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 ` [PATCH 22/23] ARM: exynos: work around missing gpio code on multiplatform Arnd Bergmann
2013-03-05 17:42 ` [PATCH 23/23] ARM: exynos: experimental multiplatform support Arnd Bergmann
2013-03-05 18:27 ` [PATCH 00/23] RFC: exynos " Tony Lindgren
2013-03-05 18:28 ` Tomasz Figa
2013-03-05 19:19   ` Arnd Bergmann
2013-03-05 22:48     ` Tomasz Figa
2013-03-06 10:50       ` Arnd Bergmann
2013-03-06 12:34         ` Thierry Reding
2013-03-06 22:57           ` Tomasz Figa
2013-03-07  3:02           ` Arnd Bergmann
2013-03-07  7:22             ` Thierry Reding
2013-03-08  0:40               ` Tomasz Figa [this message]
2013-03-08 12:52                 ` Arnd Bergmann
2013-03-06 22:14       ` Heiko Stübner
2013-03-06 22:55         ` Tomasz Figa
2013-03-05 20:50 ` Heiko Stübner
2013-03-05 21:24   ` Arnd Bergmann
2013-03-05 21:54     ` Arnd Bergmann
2013-03-05 22:12       ` Tomasz Figa
2013-03-05 22:21         ` Arnd Bergmann
2013-03-05 22:25       ` Heiko Stübner
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=3271021.WsP8f9ZEBl@flatron \
    --to=tomasz.figa@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).