From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> To: Claudiu.Beznea@microchip.com Cc: thierry.reding@gmail.com, robh+dt@kernel.org, mark.rutland@arm.com, Nicolas.Ferre@microchip.com, alexandre.belloni@bootlin.com, Ludovic.Desroches@microchip.com, linux-arm-kernel@lists.infradead.org, linux-pwm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 2/4] pwm: atmel: add support for controllers with 32 bit counters Date: Thu, 21 Feb 2019 21:42:14 +0100 [thread overview] Message-ID: <20190221204214.krpobz2ezneynht5@pengutronix.de> (raw) In-Reply-To: <1550570914-26391-3-git-send-email-claudiu.beznea@microchip.com> Hello, On Tue, Feb 19, 2019 at 10:08:57AM +0000, Claudiu.Beznea@microchip.com wrote: > From: Claudiu Beznea <claudiu.beznea@microchip.com> > > New SAM9X60's PWM controller use 32 bits counters thus it could generate > signals with higher period and duty cycles than the old ones. Prepare the > current driver to be able to work with old controllers (that uses 16 bits > counters) and with the new SAM9X60's controller, by providing counters > information based on compatible. I'd write: The PWM controller of the new SAM9X60 SoC uses 32 bit wide counters compared to 16 bit wide counters in the earlier chips. To support this add a new structure to the compatibles' data that describe the counter width and precision and make use of them instead of the hard coded values. Other than that the commit looks fine. > > Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> > --- > drivers/pwm/pwm-atmel.c | 34 +++++++++++++++++++++++----------- > 1 file changed, 23 insertions(+), 11 deletions(-) > > diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c > index 7e86a5266eb6..647d063562db 100644 > --- a/drivers/pwm/pwm-atmel.c > +++ b/drivers/pwm/pwm-atmel.c > @@ -48,15 +48,11 @@ > #define PWMV2_CPRD 0x0C > #define PWMV2_CPRDUPD 0x10 > > -/* > - * Max value for duty and period > - * > - * Although the duty and period register is 32 bit, > - * however only the LSB 16 bits are significant. > - */ > -#define PWM_MAX_DTY 0xFFFF > -#define PWM_MAX_PRD 0xFFFF > -#define PRD_MAX_PRES 10 > +/* Max values for period and prescaler */ > + > +/* Only the LSB 16 bits are significant. */ > +#define PWM_MAXV1_PRD 0xFFFF > +#define PRD_MAXV1_PRES 10 > > struct atmel_pwm_registers { > u8 period; > @@ -65,8 +61,14 @@ struct atmel_pwm_registers { > u8 duty_upd; > }; > > +struct atmel_pwm_config { > + u32 max_period; > + u32 max_pres; > +}; > + > struct atmel_pwm_data { > struct atmel_pwm_registers regs; > + struct atmel_pwm_config cfg; > }; > > struct atmel_pwm_chip { > @@ -125,10 +127,10 @@ static int atmel_pwm_calculate_cprd_and_pres(struct pwm_chip *chip, > cycles *= clk_get_rate(atmel_pwm->clk); > do_div(cycles, NSEC_PER_SEC); > > - for (*pres = 0; cycles > PWM_MAX_PRD; cycles >>= 1) > + for (*pres = 0; cycles > atmel_pwm->data->cfg.max_period; cycles >>= 1) > (*pres)++; Orthogonal to this patch, this could be calculated without a loop. Something like pres = roundup_pow_of_two(cycles); if (pres > bitwidth_of_counter_register) pres -= bitwidth_of_counter_register; else pres = 0 (where bitwidth_of_counter_register is 16 for the older PWMs and 32 for the new one). Maybe it would make more sense to put 16 into the structure describing the PWM then instead of 0xffff (which is easily calculated from 16)? If picking this up, you might have to pay attention to pick functions that support long long arguments. roundup_pow_of_two() doesn't as of now. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ |
WARNING: multiple messages have this Message-ID (diff)
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> To: Claudiu.Beznea@microchip.com Cc: mark.rutland@arm.com, linux-pwm@vger.kernel.org, alexandre.belloni@bootlin.com, devicetree@vger.kernel.org, robh+dt@kernel.org, linux-kernel@vger.kernel.org, Ludovic.Desroches@microchip.com, thierry.reding@gmail.com, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 2/4] pwm: atmel: add support for controllers with 32 bit counters Date: Thu, 21 Feb 2019 21:42:14 +0100 [thread overview] Message-ID: <20190221204214.krpobz2ezneynht5@pengutronix.de> (raw) In-Reply-To: <1550570914-26391-3-git-send-email-claudiu.beznea@microchip.com> Hello, On Tue, Feb 19, 2019 at 10:08:57AM +0000, Claudiu.Beznea@microchip.com wrote: > From: Claudiu Beznea <claudiu.beznea@microchip.com> > > New SAM9X60's PWM controller use 32 bits counters thus it could generate > signals with higher period and duty cycles than the old ones. Prepare the > current driver to be able to work with old controllers (that uses 16 bits > counters) and with the new SAM9X60's controller, by providing counters > information based on compatible. I'd write: The PWM controller of the new SAM9X60 SoC uses 32 bit wide counters compared to 16 bit wide counters in the earlier chips. To support this add a new structure to the compatibles' data that describe the counter width and precision and make use of them instead of the hard coded values. Other than that the commit looks fine. > > Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> > --- > drivers/pwm/pwm-atmel.c | 34 +++++++++++++++++++++++----------- > 1 file changed, 23 insertions(+), 11 deletions(-) > > diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c > index 7e86a5266eb6..647d063562db 100644 > --- a/drivers/pwm/pwm-atmel.c > +++ b/drivers/pwm/pwm-atmel.c > @@ -48,15 +48,11 @@ > #define PWMV2_CPRD 0x0C > #define PWMV2_CPRDUPD 0x10 > > -/* > - * Max value for duty and period > - * > - * Although the duty and period register is 32 bit, > - * however only the LSB 16 bits are significant. > - */ > -#define PWM_MAX_DTY 0xFFFF > -#define PWM_MAX_PRD 0xFFFF > -#define PRD_MAX_PRES 10 > +/* Max values for period and prescaler */ > + > +/* Only the LSB 16 bits are significant. */ > +#define PWM_MAXV1_PRD 0xFFFF > +#define PRD_MAXV1_PRES 10 > > struct atmel_pwm_registers { > u8 period; > @@ -65,8 +61,14 @@ struct atmel_pwm_registers { > u8 duty_upd; > }; > > +struct atmel_pwm_config { > + u32 max_period; > + u32 max_pres; > +}; > + > struct atmel_pwm_data { > struct atmel_pwm_registers regs; > + struct atmel_pwm_config cfg; > }; > > struct atmel_pwm_chip { > @@ -125,10 +127,10 @@ static int atmel_pwm_calculate_cprd_and_pres(struct pwm_chip *chip, > cycles *= clk_get_rate(atmel_pwm->clk); > do_div(cycles, NSEC_PER_SEC); > > - for (*pres = 0; cycles > PWM_MAX_PRD; cycles >>= 1) > + for (*pres = 0; cycles > atmel_pwm->data->cfg.max_period; cycles >>= 1) > (*pres)++; Orthogonal to this patch, this could be calculated without a loop. Something like pres = roundup_pow_of_two(cycles); if (pres > bitwidth_of_counter_register) pres -= bitwidth_of_counter_register; else pres = 0 (where bitwidth_of_counter_register is 16 for the older PWMs and 32 for the new one). Maybe it would make more sense to put 16 into the structure describing the PWM then instead of 0xffff (which is easily calculated from 16)? If picking this up, you might have to pay attention to pick functions that support long long arguments. roundup_pow_of_two() doesn't as of now. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-02-21 20:42 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-02-19 10:08 [PATCH v2 0/4] add support for the new SAM9X60's PWM controller Claudiu.Beznea 2019-02-19 10:08 ` Claudiu.Beznea 2019-02-19 10:08 ` Claudiu.Beznea 2019-02-19 10:08 ` [PATCH v2 1/4] pwm: atmel: add struct atmel_pwm_data Claudiu.Beznea 2019-02-19 10:08 ` Claudiu.Beznea 2019-02-19 10:08 ` Claudiu.Beznea 2019-02-21 20:13 ` Uwe Kleine-König 2019-02-21 20:13 ` Uwe Kleine-König 2019-02-19 10:08 ` [PATCH v2 2/4] pwm: atmel: add support for controllers with 32 bit counters Claudiu.Beznea 2019-02-19 10:08 ` Claudiu.Beznea 2019-02-19 10:08 ` Claudiu.Beznea 2019-02-21 20:42 ` Uwe Kleine-König [this message] 2019-02-21 20:42 ` Uwe Kleine-König 2019-02-22 9:10 ` Claudiu.Beznea 2019-02-22 9:10 ` Claudiu.Beznea 2019-02-22 9:10 ` Claudiu.Beznea 2019-02-19 10:09 ` [PATCH v2 3/4] pwm: atmel: add support for SAM9X60's PWM controller Claudiu.Beznea 2019-02-19 10:09 ` Claudiu.Beznea 2019-02-19 10:09 ` Claudiu.Beznea 2019-02-21 20:45 ` Uwe Kleine-König 2019-02-21 20:45 ` Uwe Kleine-König 2019-02-22 9:07 ` Claudiu.Beznea 2019-02-22 9:07 ` Claudiu.Beznea 2019-02-22 9:07 ` Claudiu.Beznea 2019-02-22 9:27 ` Uwe Kleine-König 2019-02-22 9:27 ` Uwe Kleine-König 2019-02-22 9:27 ` Uwe Kleine-König 2019-02-19 10:09 ` [PATCH v2 4/4] pwm: atmel: add PWM binding for SAM9X60 Claudiu.Beznea 2019-02-19 10:09 ` Claudiu.Beznea 2019-02-19 10:09 ` Claudiu.Beznea
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190221204214.krpobz2ezneynht5@pengutronix.de \ --to=u.kleine-koenig@pengutronix.de \ --cc=Claudiu.Beznea@microchip.com \ --cc=Ludovic.Desroches@microchip.com \ --cc=Nicolas.Ferre@microchip.com \ --cc=alexandre.belloni@bootlin.com \ --cc=devicetree@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pwm@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=robh+dt@kernel.org \ --cc=thierry.reding@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.