Re: [PATCH] gpio: New driver for GPO emulation using PWM generators

[Peter Ujfalusi <peter.ujfalusi@ti.com>]

On 11/30/2012 11:20 AM, Grant Likely wrote:
> Umm, I agree with you on duty cycle, but that's got nothing to do with
> period. 100% duty cycle looks exactly the same whether the period is
> 10ns or 100s.

Yes this is true. But some PWM hw can select it's clock based on the period_ns
provided.
In most cases we could hardwire 10000 as period_ns but there might be HW which
checks this and only allow the use of supported frequencies.

>> Unless you're proposing to not include that in the PWM core but rather
>> in individual drivers. Then I suppose the driver could choose some
>> sensible default.
> 
> Mostly I'm asking questions because I'm not familiar with the subsystem.
> If the property is needed then I have no objections, but at the moment
> it doesn't make any sense to me.
> 
>> One other problem is that some PWM devices cannot be setup to achieve a
>> 0% or 100% duty-cycle but instead will toggle for at least one period.
>> This would be another argument in favour of moving the functionality to
>> the individual drivers, perhaps with some functionality provided by the
>> core to do the gpio_chip registration (a period could be passed to that
>> function at registration time), which will likely be the same for all
>> hardware that can and wants to support this feature.
> 
> It is a bit of an oddball case where if the hardware engineer wires up a
> PWM to use as a GPIO, then he better be sure that it is actually fit for
> the purpose.

If we inspect the situation from a different angle: a standard GPIO is a PWM
with either turned off state or with full duty cycle (where the duty cycle
means nothing since the signal on the line is constantly high).

> That doesn't prevent the PWM core having some
> gpio-emulation helper functionality, but do need to be careful about it.

If you give designers a way to take short cuts, they will take it whenever
they can. Even if it makes no sense. IMHO. But the BeagleBoard has been
designed before we had any indication from the SW that we could handle this
case. I guess the thinking was that in the bootloader the SW will configure
the PWM to always on and forget about it in the running code.

As a note: I noticed this during my cleanup work around the twl-core. If you
take a look at the kernel code there are other drivers configuring the PWMs of
twl in various places to handle them.
I wrote the pwm-twl and pwm-twl-led drivers so we can get rid of this whole mess:
- the gpio-twl4030 extends itself to handle the PWMA/B (LEDA/B) as GPIO. So
drivers are doing OMAP_MAX_GPIO + TWL_NUM_GPIO + 1/2 to control the PWMA/B.
- mach-omap2/board-zoom-display.c have custom code to control the same thing
and the list goes.

-- 
Péter