[PATCH] pwm: lpc32xx: Set PWM_PIN_LEVEL bit in lpc32xx_pwm_disable
vz at mleia.com
Wed Jun 22 08:10:10 PDT 2016
On 22.06.2016 17:36, Thierry Reding wrote:
> On Wed, Jun 22, 2016 at 09:26:04AM -0400, Sylvain Lemieux wrote:
>> Hi Thierry,
>> On Wed, 2016-06-22 at 14:32 +0200, Thierry Reding wrote:
>>> On Fri, Jun 03, 2016 at 03:37:57PM -0400, Sylvain Lemieux wrote:
>>>> From: Sylvain Lemieux <slemieux at tycoint.com>
>>>> If the PWM_PIN_LEVEL bit is setup to 1 in the bootloader, when the kernel
>>>> disable the PWM, the PWM output is always set as a logic 1.
>>> I presume there's a reason why the bootloader set this bit to 1. Why do
>>> you assume it's the right thing to clear it?
>> There is an alternative mode for the PWM output pin; using the
>> PWM_PIN_LEVEL bit to control the PWM output (logical 0 or 1 on
>> output) when the PWM is disable.
>> In this case, the bootloader is using the PWM_PIN_LEVEL bit
>> to control the PWM output (always 1) to enable the LCD; the
>> application is using the PWM to control the intensity of the
>> LCD output. When disabling the PWM, the line level should be
>> setup to 0.
> But doesn't that mean that if the pin is used in PWM mode there's never
> a use-case for having it go high when disabled? Given that this is a PWM
> driver I don't see how we'd ever be in the case where the alternate
> setting makes sense.
to some extend when PWM is disabled, both options of pin output high
and low level values are valid if we consider variable PWM polarity
setting in general, however this particular controller does not have
this control and thus there is no need to extend it to 2-cell type.
Another alternative to avoid a new property may be to extend period_ns
to its apparently valid boundaries - 0 and duty_ns, both options are not
supported properly in the driver at the moment. But then the question
what to do with it on boot is still open, just leaving it untouched
is nondeterministic in my opinion.
>> A version 2 of this patch will be send with support to select
>> the alternate PWM disable level high from the device tree.
>> For details, you can refer to:
> Given the above I don't think we should add this new device tree
> property until we encounter a setup where it's needed.
With best wishes,
More information about the linux-arm-kernel