lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5480C51E.1010401@broadcom.com>
Date:	Thu, 4 Dec 2014 12:33:34 -0800
From:	Jonathan Richardson <jonathar@...adcom.com>
To:	Tim Kryger <tim.kryger@...il.com>
CC:	Arun Ramamurthy <arun.ramamurthy@...adcom.com>,
	Scott Branden <sbranden@...adcom.com>,
	Thierry Reding <thierry.reding@...il.com>,
	Ray Jui <rjui@...adcom.com>,
	Arun Ramamurthy <arunrama@...adcom.com>,
	<bcm-kernel-feedback-list@...adcom.com>,
	<linux-pwm@...r.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 2/4] pwm: kona: Fix incorrect enable after channel
 polarity change

Comments below.

On 14-11-28 06:02 PM, Tim Kryger wrote:
> On Fri, Nov 28, 2014 at 3:48 PM, Arun Ramamurthy
> <arun.ramamurthy@...adcom.com> wrote:
>>
>>
>> On 14-11-25 10:22 PM, Tim Kryger wrote:
>>>
>>> On Tue, Nov 25, 2014 at 11:40 AM, Scott Branden <sbranden@...adcom.com>
>>> wrote:
>>>>
>>>> From: Arun Ramamurthy <arunrama@...adcom.com>
>>>>
>>>> The pwm core code requires a separate call for enabling the channel
>>>> and hence the driver does not need to set pwm_trigger after a
>>>> polarity change
>>>
>>>
>>> The framework does restrict when polarity changes can occur but it
>>> isn't clear to me that there is any reason to delay applying the
>>> polarity change.
>>
>> I examined several other drivers such as pwm-atmel-tcb.c, pwm-ep93xx.c,
>> pwm-renesas-tpu.c, pwm-samsung.c in the 3.17 kernel tree and none of them
>> enable the channel after changing polarity. We would be the first driver to
>> do so.
> 
> We are not "enabling" the channel as much as we are "triggering an
> application of settings" by hardware.
> 
> Both pwm-ep93xx and pwm-samsung write polarity settings to the
> hardware immediately, presumably resulting in an immediate change in
> output.
> 
> Alternatively, the pwm-atmel-tcb and pwm-renesas-tpu drivers save the
> polarity and write it to hardware later.
> 
> There may be advantages to deferring the application of the polarity
> till a subsequent enable but both approaches appear to be acceptable.
> 
>>
>>> Keep in mind that polarity matters even when a PWM
>>> is disabled.  While disabled, the output should be equivalent to an
>>> enabled configuration with zero duty.  Thus for normal polarity the
>>> output is constant low and for inversed polarity the output is
>>> constant high.
>>
>> The driver does set the duty cycle to zero when disabling the pwm
>> channel.However since the frame work prevents polarity change when the pwm
>> is enabled, I don’t see how one could expect the polarity change to be
>> reflected immediately without a separate call to pwm enable.
>>
>>
>>> I believe there is an expectation that the output is
>>> updated to reflect the requested polarity change prior to returning to
>>> the caller.
>>
>>
>> Once again I disagree with this based on other pwm drivers which only change
>> the polarity and do not enable the channel when their set polarity functions
>> are called.
> 
> I don't know why you keep calling this an enable.  Its not an enable,
> it is only a trigger.
> 
> Perhaps this would be best explained with an example:
> 
> # Export PWM for access by userspace
> cd /sys/class/pwm/pwmchip0
> echo 0 > export
> cd pwm0
> 
> # Request 50% duty output when PWM is enabled
> echo 50000 > duty_cycle
> echo 100000 > period
> 
> # Command Inversed Polarity
> echo inversed > polarity
> 
> # Command Normal Polarity
> echo normal > polarity
> 
> # Enable PWM
> echo 1 > enable
> 
> The polarity changes trigger immediate output updates but the PWM is
> not enabled until the end.
> 
> Prior to the last step the output is either a constant high or low
> signal, not the 50% duty waveform.
> 

I just want to clarify so we're on the same page here. The pwm channel
needs to be disabled when polarity is set. When the set polarity
callback is called it just needs to update the polarity so that when the
channel is enabled again the new polarity value is used. We write this
to the polarity register in the callback which seems appropriate. Also
note that the clock is disabled at the end of the routine so the signal
is just going to be floating anyway. Hopefully this makes sense.


>>
>>
>>>
>>>>
>>>> Signed-off-by: Arun Ramamurthy <arunrama@...adcom.com>
>>>> Reviewed-by: Ray Jui <rjui@...adcom.com>
>>>> Signed-off-by: Scott Branden <sbranden@...adcom.com>
>>>> ---
>>>>   drivers/pwm/pwm-bcm-kona.c | 5 -----
>>>>   1 file changed, 5 deletions(-)
>>>>
>>>> diff --git a/drivers/pwm/pwm-bcm-kona.c b/drivers/pwm/pwm-bcm-kona.c
>>>> index 29eef9e..fa0b5bf 100644
>>>> --- a/drivers/pwm/pwm-bcm-kona.c
>>>> +++ b/drivers/pwm/pwm-bcm-kona.c
>>>> @@ -173,11 +173,6 @@ static int kona_pwmc_set_polarity(struct pwm_chip
>>>> *chip, struct pwm_device *pwm,
>>>>
>>>>          writel(value, kp->base + PWM_CONTROL_OFFSET);
>>>>
>>>> -       kona_pwmc_apply_settings(kp, chan);
>>>> -
>>>> -       /* Wait for waveform to settle before gating off the clock */
>>>> -       ndelay(400);
>>>> -
>>>>          clk_disable_unprepare(kp->clk);
>>>>
>>>>          return 0;
>>>> --
>>>> 2.1.3
>>>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ