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: Wed, 06 Mar 2013 23:57:51 +0100	[thread overview]
Message-ID: <6522816.XSG9RTSW3x@flatron> (raw)
In-Reply-To: <20130306123426.GB17079@avionic-0098.mockup.avionic-design.de>

On Wednesday 06 of March 2013 13:34:26 Thierry Reding wrote:
> On Wed, Mar 06, 2013 at 10:50:42AM +0000, Arnd Bergmann wrote:
> > On Tuesday 05 March 2013, Tomasz Figa wrote:
> > > On Tuesday 05 of March 2013 19:19:02 Arnd Bergmann wrote:
> > > > If none of these are needed for DT-based systems, we should
> > > > probably
> > > > build that code conditionally based on the CONFIG_EXYNOS_ATAGS
> > > > symbol
> > > > I introduced.
> > > 
> > > Yes, none of them are needed for DT-based systems.
> > 
> > Ah, good. I'll try to make more code conditional then.
> > 
> > > > How are you planning to solve this? Do you want to have a combined
> > > > driver that registers both a clocksource and a pwm?
> > > 
> > > Let's start with a quick introduction to the s3c-pwm hardware. Each
> > > channel has its own timer value, compare and reload value registers,
> > > so
> > > they don't need any extra locking. However there are additional
> > > shared
> > > configuration registers, containing things such as start and reload
> > > bits for all channels, prescaler and main divisor values, etc.
> > > Those registers needs synchronization.
> > > 
> > > Now there are several possible approaches:
> > > 
> > > 1) A brute force one - two separate drivers, based on the fact that
> > > the
> > > 
> > >    clocksource driver will be used only on uniprocessor systems, so
> > >    a simple _irqsave when accessing a shared register in both will
> > >    guarantee correct synchronization.
> > > 
> > > 2) Two separate drivers with some synchronized shared code accessing
> > > 
> > >    registers (_start, _stop, _set_reload, _set_prescaler,
> > >    _set_divisor,
> > >    etc.; all using a shared spinlock).
> > > 
> > > 3) Single driver registering PWM channels, clocksource and clock
> > > event
> > > 
> > >    device. This does not seem like a bad idea, since the whole code
> > >    for
> > >    configuration of the PWM block would reside in one location and
> > >    there
> > >    would be no redundancy. However there is a question where such
> > >    driver
> > >    should be placed - drivers/clocksource, drivers/pwm, or maybe
> > >    somewhere
> > >    else?
> > > 
> > > Personally I wanted to go with first option, which would require
> > > least
> > > amount of changes to existing code, at a cost of some code
> > > duplication
> > > (but some PWM code is duplicated already).
> > 
> > I would prefer option 3. That is also easier to implement with a
> > straightforward DT binding that defines a single node with the clock
> > registers. The location doesn't have an obvious answer, but I would
> > probably put them into drivers/clocksource if the PWM maintainer
> > agrees.
> > 
> > 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.

I prefer this option over 3), because current driver files could be easily 
reused (just cleaned up and moved into appropriate directories), which 
would minimize the amount of needed changes.

Another reason for having two separate drivers is that on Exynos SoCs the 
PWM block is not used for timers at all, just for PWM outputs, so the 
whole part responsible for clocksource would be useless.

Best regards,
Tomasz

  reply	other threads:[~2013-03-06 22:57 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 [this message]
2013-03-07  3:02           ` Arnd Bergmann
2013-03-07  7:22             ` Thierry Reding
2013-03-08  0:40               ` Tomasz Figa
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=6522816.XSG9RTSW3x@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).