[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190213123703.GE647@ulmo>
Date: Wed, 13 Feb 2019 13:37:03 +0100
From: Thierry Reding <thierry.reding@...il.com>
To: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
Cc: Yash Shah <yash.shah@...ive.com>, palmer@...ive.com,
linux-pwm@...r.kernel.org, linux-riscv@...ts.infradead.org,
robh+dt@...nel.org, mark.rutland@....com,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
sachin.ghadi@...ive.com, paul.walmsley@...ive.com
Subject: Re: [PATCH v5 2/2] pwm: sifive: Add a driver for SiFive SoC PWM
On Thu, Feb 07, 2019 at 11:16:57AM +0100, Uwe Kleine-König wrote:
> On Tue, Jan 29, 2019 at 05:13:19PM +0530, Yash Shah wrote:
[...]
> > diff --git a/drivers/pwm/pwm-sifive.c b/drivers/pwm/pwm-sifive.c
[...]
> > + writel(val, pwm->regs + PWM_SIFIVE_PWMCFG);
> > +
> > + writel(frac, pwm->regs + PWM_SIFIVE_PWMCMP0 + dev->hwpwm * SIZE_PWMCMP);
> > +
> > + val &= ~(1 << PWM_SIFIVE_PWMCFG_DEGLITCH);
> > + writel(val, pwm->regs + PWM_SIFIVE_PWMCFG);
> > +
> > + pwm_sifive_get_state(chip, dev, state);
>
> Thierry: This changes the pwm_state. Is this how this should be done?
Yes, I think that's fine. The PWM state should always reflect the
current hardware state. If the configuration that we program does not
reflect the state that was requested, that should be reflected in the
PWM state.
Thierry
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists