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. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |