On Tue, Mar 18, 2014 at 06:06:03PM -0700, Tim Kryger wrote: > On Tue, Mar 18, 2014 at 4:47 PM, Tim Kryger <tim.kryger@xxxxxxxxxx> wrote: > > On Tue, Mar 18, 2014 at 2:52 PM, Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > >> On Wed, Mar 12, 2014 at 01:15:43PM -0700, Tim Kryger wrote: [...] > >>> +static int kona_pwmc_set_polarity(struct pwm_chip *chip, struct pwm_device *pwm, > >>> + enum pwm_polarity polarity) > >>> +{ > >>> + /* > >>> + * The framework only allows the polarity to be changed when a PWM is > >>> + * disabled so no immediate action is required here. When a channel is > >>> + * enabled, the polarity gets handled as part of the re-config step. > >>> + */ > >>> + > >>> + return 0; > >>> +} > >> > >> See above. If you don't want to implement the hardware support for > >> inversed polarity, then simply don't implement this. > > > > I had originally planned to omit polarity support but because it > > affects the binding (which is treated as ABI), it wouldn't be possible > > to add it in later without defining a new compatible string. > > I would like to get this right but it occurred to me that there may be > a way to defer the implementation of this feature without disrupting > the binding. > > Would it be acceptable to continue using #pwm-cells = <3> and > of_pwm_xlate_with_flags but return -EINVAL from kona_pwmc_set_polarity > if PWM_POLARITY_INVERSED is specified? This was recently discussed for the pwm-imx driver. And you can easily support #pwm-cells = <2> and #pwm-cells = <3> with the same binding. So you could start with #pwm-cells = <2>, leaving out .set_polarity() and implement it later on, extending the binding in a backwards-compatible way to support the polarity flag. Thierry
Attachment:
pgpiZhN9eclUW.pgp
Description: PGP signature