[PATCH 00/23] RFC: exynos multiplatform support

On Wed, Mar 06, 2013 at 10:50:42AM +0000, Arnd Bergmann wrote:

On Tuesday 05 March 2013, Tomasz Figa wrote:

quoted

On Tuesday 05 of March 2013 19:19:02 Arnd Bergmann wrote:

quoted

quoted

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.
 

quoted

quoted

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.

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/20130306/fdd76f07/attachment.sig>