On Mon, Apr 07, 2014 at 11:28:03AM +0200, Alexandre Belloni wrote: > On 07/04/2014 at 09:52:45 +0100, Russell King - ARM Linux wrote : > > On Mon, Apr 07, 2014 at 10:46:51AM +0200, Alexandre Belloni wrote: > > > > > > This will conflict with my patch (which is still lacking proper review) > > > there: > > > http://thread.gmane.org/gmane.linux.leds/482 > > > > > > I would say that it is better to hide the polarity inversion in the PWM > > > driver for your specific PWM. Else we will end up with all the drivers > > > using PWMs trying to detect whether the PWM supports inversion and if it > > > is not the case, calculating the inverted duty cycle. > > > > > > So, I would go for my patch which is adding the missing polarity > > > inversion setting when using platform data and then implement software > > > polarity inversion in your underlying PWM driver. That also avoids patch > > > 5/5 and I believe not adding a DT property is always a good idea. > > > > > > What is your PWM that is not supporting polarity inversion ? > > > > Did you read the commit message properly, particularly the last sentence > > of the first paragraph which refers to the problem with your approach? > > > > If disabling the PWM is putting the output low, I would then enable the > channel on pwm_request() and disable it on pwm_free() because anyway, > you'll have to let it run continuously to get the correct result. > However, Thierry seems to believe that there is an other underlying > issue in the PWM driver when this happens. > > Going with your approach will end up with all the drivers trying to use > PWMs having to use the same logic and I'm sure a lot of people will get > confused between polarity inversion and using active_low... Whatever. It needs fixing. It's three months on from when I first raised this and so far it remains broken. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe linux-leds" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html