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. Thierry
Attachment:
pgpRwngQsV8aN.pgp
Description: PGP signature