[Intel-gfx] [PATCH v4 06/16] pwm: lpss: Correct get_state result for base_unit == 0

Uwe Kleine-König u.kleine-koenig at pengutronix.de
Sat Jul 11 06:11:20 UTC 2020


On Thu, Jul 09, 2020 at 05:47:59PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 7/9/20 4:50 PM, Andy Shevchenko wrote:
> > On Wed, Jul 08, 2020 at 11:14:22PM +0200, Hans de Goede wrote:
> > > The datasheet specifies that programming the base_unit part of the
> > > ctrl register to 0 results in a contineous low signal.
> > > 
> > > Adjust the get_state method to reflect this by setting pwm_state.period
> > > to 1 and duty_cycle to 0.
> > 
> > ...
> > 
> > > +	if (freq == 0) {
> > > +		/* In this case the PWM outputs a continous low signal */
> > 
> > > +		state->period = 1;
> > 
> > I guess this should be something like half of the range (so base unit calc
> > will give 128). Because with period = 1 (too small) it will give too small
> > base unit (if apply) and as a result we get high frequency pulses.
> 
> You are right, that if after this the user only changes the duty-cycle
> things will work very poorly, we will end up with a base_unit value of
> e.g 65535 and then have almost no duty-cycle resolution at all.

Is this a problem of the consumer that we don't need to solve? Are there
known consumers running into this problem?

pwm_lpss_prepare() is buggy here, a request for a too low period should be
refused.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20200711/dae180e6/attachment-0001.sig>


More information about the Intel-gfx mailing list