On Fri, 19 Feb 2016 18:15:58 -0600
Adam Ford <aford173@xxxxxxxxx> wrote:
> I did notice that 0 and 100 were not perfect, but it doesn't bother me
> because the visual effect was more important to me than precision. If
> you think it would be better, I could make the limits 1 and 99 for the
> extreme limits.
I think your devicetree itself is fine. If better behavior is required
improving omap-dmtimer-pwm would probably be the right place to fix it.
I think the hardware is capable if programmed in a special way, so we'd
just need to check for those special-case values to handle differently.
Also, If the pwm-backlight binding documentation is correct, the highest
value will always ask for 100% duty cycle, so changing that to 99 wouldn't
have an effect (and I doubt that anyone could discern 99.4% vs 100% anyways).
I was more concerned with the low end, as I would be surprised if 0.6%
brightness is noticeable. At least some LEDs are bright enough to be easily
visible even at such low PWM. But if it's OK in your case, I wouldn't
worry about it.
> On Fri, Feb 19, 2016 at 6:11 PM, David Rivshin (Allworx)
> <drivshin.allworx@xxxxxxxxx> wrote:
> > On Wed, 17 Feb 2016 18:30:12 -0600
> > Adam Ford <aford173@xxxxxxxxx> wrote:
> >
> >> The backlight pin is shared with Timer 10 PWM. This patch allows the
> >> pwm_bl driver to enable the pwm run by this timer to dim the backlight.
> >>
> >> Signed-off-by: Adam Ford <aford173@xxxxxxxxx>
> >> ---
> > [...]
> >> bl: backlight {
> >> - compatible = "gpio-backlight";
> >> + compatible = "pwm-backlight";
> >> pinctrl-names = "default";
> >> pinctrl-0 = <&backlight_pins>;
> >> -
> >> - gpios = <&gpio5 26 GPIO_ACTIVE_HIGH>, /* gpio_154 */
> >> - <&gpio2 24 GPIO_ACTIVE_HIGH>; /* gpio_56 */
> >> - default-on;
> >> + pwms = <&pwm10 0 5000000 0>;
> >> + brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
> >> + default-brightness-level = <7>;
> >> + enable-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH>; /* gpio_154 */
> >> };
> > [...]
> >
> > One thing to note: omap-dmtimer-pwm can't do a perfect 0 or 100% duty cycle.
> > I think with the code in linux-next right now it will just configure the
> > DMTIMER in a way that the TRM says is illegal, and with my [PATCH 2/4] it
> > will set the lowest/highest possible duty-cycle (1-fclk cycle per period).
> > Assuming you're using the 32768Hz fclk for timer10, that would mean the
> > lowest effective duty cycle would be about 0.6%, and the highest 99.4%. If
> > you're using a faster fclk, then the error would be proportionally less.
> > Just wanted to mention that in case it's an issue for your backlight.
> >
> > FYI, I've seen other PWM drivers use a trick for the 0 and 100% cases where
> > they actually force the largest possible period. This then dilutes the
> > unwanted 1-cycle pulse as much as possible. I see no reason that couldn't
> > be done for omap-dmtimer-pwm as well.
> >
> > Looking at the TRM, it may also be possible to turn off the trigger, and
> > use the TCLR.SCPWM bit to force a perfect 0 or 100% duty cycle.
--
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
