On Fri, Nov 30, 2012 at 11:04 AM, Thierry Reding <thierry.reding@xxxxxxxxxxxxxxxxx> wrote: >> > 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. > > Yes, I agree. So what we really want is to make this configurable in > some way. For DT this could just be controlled by the gpio-controller > property. The PWM core could easily setup the gpio_chip in the presence > of that property. > > For non-DT it could probably be done via a flag that is passed to the > driver via platform data, in which case the driver would have to call > the helper explicitly based on the setting of this flag. > >> That doesn't prevent the PWM core having some gpio-emulation helper >> functionality, but do need to be careful about it. > > On the other hand, if we turn that support into a helper maybe it is > easier to leave it up to the driver whether to call it or not. A big > advantage of this would be that the driver could pass a period along > that it can choose sensibly according to the chip's capabilities. > > Something as simple as: > > int pwmchip_emulate_gpio(struct pwm_chip *chip, unsigned long period); > > could do. Cleanup could be done automatically in pwmchip_remove(). Looks reasonable. g. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
