[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <37cc424e-cafd-acb6-d7d2-c6c98abf53de@ysoft.com>
Date: Fri, 14 Dec 2018 16:40:30 +0000
From: Vokáč Michal <Michal.Vokac@...ft.com>
To: Uwe Kleine-König <uwe@...ine-koenig.org>
CC: Thierry Reding <thierry.reding@...il.com>,
"linux-pwm@...r.kernel.org" <linux-pwm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [3/3] pwm: imx: Implement get_state() function for hardware
readout
On 12.12.2018 11:51, Uwe Kleine-König wrote:
> Hello,
>
> On Mon, Oct 01, 2018 at 04:19:48PM +0200, Michal Vokáč wrote:
>> Implement the get_state() function and set the initial state to reflect
>> real state of the hardware. This allows to keep the PWM running if it was
>> enabled in bootloader. It is very similar to the GPIO behavior. GPIO pin
>> set as output in bootloader keep the same setting in Linux unless it is
>> reconfigured.
>>
>> If we find the PWM block enabled we need to prepare and enable its source
>> clock otherwise the clock will be disabled late in the boot as unused.
>> That will leave the PWM in enabled state but with disabled clock. That has
>> a side effect that the PWM output is left at its current level at which
>> the clock was disabled. It is totally non-deterministic and it may be LOW
>> or HIGH.
>
> Does this problem still exist if the pwm-imx driver is a module?
Yes. The source clock for PWM is stopped by the clock core shortly
before init process is started and it does not matter if the pwm-imx
driver is built as a module or built into the kernel.
When the module is loaded, the .get_state function is executed and
reads the PWM registers. If the EN bit is set the clock is started
and PWM continues from where it was stopped.
Michal
Powered by blists - more mailing lists