<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 4, 2013 at 5:55 AM, Sascha Hauer <span dir="ltr"><<a href="mailto:s.hauer@pengutronix.de" target="_blank">s.hauer@pengutronix.de</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On Thu, Jan 03, 2013 at 10:01:18AM +0100, Thierry Reding wrote:<br>


</div><div><div class="h5">> On Thu, Oct 25, 2012 at 04:03:49PM +0800, Shawn Guo wrote:<br>
> > On Wed, Oct 24, 2012 at 03:52:46PM +0200, Uwe Kleine-König wrote:<br>
> > > This fixes disabling the LED on i.MX28. The PWM hardware delays using<br>
> > > the newly set pwm-config until the beginning of a new period.  It's very<br>
> > > likely that pwm_disable is called before the current period ends. In<br>
> > > case the LED was on brightness=max before the LED stays on because in<br>
> > > the disabled PWM block the period never ends.<br>
> > ><br>
> > > It's unclear if the mxs-pwm driver doesn't implement the API as expected<br>
> > > (i.e. it should block until the newly set config is effective) or if the<br>
> > > leds-pwm driver makes wrong assumptions. This patch assumes the latter.<br>
> > ><br>
> > > Signed-off-by: Uwe Kleine-König <<a href="mailto:u.kleine-koenig@pengutronix.de">u.kleine-koenig@pengutronix.de</a>><br>
> > > ---<br>
> > > Hello,<br>
> > ><br>
> > > I'm not sure this is correct, but this is the workaround I'm using until<br>
> > > I get some feed back.<br>
> ><br>
> > I'm fine with it, since it fixes a real problem.  Let's see what<br>
> > Thierry says.<br>
><br>
> I lost track of this thread somehow, so sorry for not getting back to<br>
> you earlier. The root cause of this problem seems to be that it isn't<br>
> very well defined (actually not at all) what is supposed to happen in<br>
> the case when a PWM is disabled.<br>
><br>
> There really are only two ways forward: a) we need to write down what<br>
> the PWM subsystem expects to happen when a PWM is disabled or b) keep<br>
> the currently undefined behaviour. With the latter I expect this kind<br>
> of issue to keep popping up every once in a while with all sorts of<br>
> ad-hoc solutions being implemented to solve the problem.<br>
><br>
> I think the best option would be to have some definition about what the<br>
> PWM signal should look like after a call to pwm_disable(). However this<br>
> doesn't turn out to be as trivial as it sounds. For instance, the most<br>
> straightforward definition in my opinion would be to specify that a PWM<br>
> signal should be constantly low after the call to pwm_disable(). It is<br>
> what I think most people would assume is the natural disable state of a<br>
> PWM.<br>
><br>
> However, one case where a similar problem was encountered involved a<br>
> hardware design that used an external inverter to change the polarity of<br>
> a PWM signal that was used to drive a backlight. In such a case, if the<br>
> controller were programmed to keep the output low when disabling, the<br>
> display would in fact be fully lit. This is further complicated by the<br>
> fact that the controller allows the output level of the disabled PWM<br>
> signal to be configured. This is nice because it means that pretty much<br>
> any scenario is covered, but it also doesn't make it any easier to put<br>
> this into a generic framework.<br>
><br>
> Having said that, I'm tempted to go with a simple definition like the<br>
> above anyway and handle obscure cases with board-specific quirks. I<br>
> don't see any other alternative that would allow the PWM framework to<br>
> stay relatively simple and clean.<br>
><br>
> Now I only have access to a limited amount of hardware and use-cases, so<br>
> any comments and suggestions as well as requirements on other platforms<br>
> are very welcome.<br>
<br>
</div></div>How about keeping the current behaviour, so:<br>
<br>
duty cycle 0    -> output constant low<br>
duty cycle 100% -> output constant high<br>
pwm disabled    -> output unspecified<br>
<br>
This would allow the pwm drivers to implement whatever powersaving is<br>
possible for 0/100%, or, if that's not possible, use pwm_disable for<br>
powersaving. A pwm client driver wouldn't have to call pwm_en|disable at<br>
all anymore during runtime (only pwm_enable during probe)<br>
<br>
Background is that some board here needs 100% duty cycle to set the<br>
backlight dark. This inversion can be easily archieved in software, but<br>
on this board we would expect the pwm_disable output state to be high<br>
whereas on most other boards we would expect the pwm_disable output<br>
state to be low. The inversion could also be made in the pwm hardware<br>
(possible on i.MX for example), I currently don't know what this means<br>
for the pwm_disable output state.<br>
<br>
Overall I think with this a client driver would have full control over<br>
the output and we would avoid confusion with the pwm_en|disable calls.<br>
<br>
Sascha<br></blockquote><div><br></div><div><br></div><div style>Ack, I prefer the old method too, but the other way around for reasoning;</div><div style><br></div><div style>It could be that pwm_disable actually turns off LCDs as well, but that "0" brightness is still usable.</div>

<div style><br></div><div style>pwm_config with whatever brightness is "0" the driver (pwm_bl for example) should be just configuring the pwm to the lowest permissible duty cycle (since some panels require the pwm never runs below a certain duty cycle).</div>

<div style><br></div><div style>That doesn't mean you want to turn the backlight off, and in fact having the pwm turned off but other logic still turned on is against some panel datasheets (for instance there may be a backlight enable gpio which also needs to be turned off if the PWM duty cycle is below the abovementioned lowest permissible value, and in this case this would be handled by the abovementioned power management and explicitly pwm_disable somehow).</div>

<div style><br></div><div style><div>In this case, pwm_disable should still disable the unit (i.e. toggle some PWM controller enable bit inside the SoC or peripheral chip), but this is handled by power management - most likely framebuffer or DRM DPMS activity.</div>

</div><div style><br></div><div style>We see however that leds-pwm is an island unto itself and has no clue about other subsystems, so it has no way of knowing that power management is required by some other subsystem like display or so.</div>

<div style><br></div><div style>~</div><div style><br></div><div style>What's really needed for a real fix here is a framebuffer-or-other aware backlight driver which is a subclass of leds-pwm that actually receives fb notifier events and can be informed of display power management (dpms or other) such that it can do the right thing. I think using leds-pwm.c directly - unless you can guarantee it is under some other control - is probably a terrible idea for most real-life panel backlights even if it is a fantastic solution for the big glowing Apple/Sony/Dell logo on the back of the lid the panel lives on - or the systems where it was intended to run where display is either off or the backlight is set to a lovely constant value.</div>

<div style><br></div><div style>I have about 4 panel reference docs to hand, and I mean real laptop panels not just developer board RGB ones with low resolutions or 1990's PDA panels, with some pretty strict requirements and leds-pwm does not cut it. drivers/video/backlight/pwm_bl.c is DT capable and does this properly as described above.</div>

<div style><br></div><div style>So the real fix for i.MX28 is use the correct driver, isn't it?</div><div style><br></div><div style>-- </div><div>Matt Sealey <<a href="mailto:matt@genesi-usa.com">matt@genesi-usa.com</a>><br>

Product Development Analyst, Genesi USA, Inc.</div><div> </div></div><br></div></div>