All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Conor Dooley <conor@kernel.org>
Cc: "Conor Dooley" <conor.dooley@microchip.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Daire McNamara" <daire.mcnamara@microchip.com>,
	linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
	linux-riscv@lists.infradead.org
Subject: Re: [PATCH v15 1/2] pwm: add microchip soft ip corePWM driver
Date: Thu, 6 Apr 2023 15:17:45 +0200	[thread overview]
Message-ID: <ZC7GeXJbB9PAF0lb@orome> (raw)
In-Reply-To: <0b91dee7-6c1d-4a33-8235-8fd5d58b200e@spud>

[-- Attachment #1: Type: text/plain, Size: 2084 bytes --]

On Sat, Apr 01, 2023 at 09:50:47PM +0100, Conor Dooley wrote:
> On Thu, Mar 30, 2023 at 08:12:03AM +0100, Conor Dooley wrote:
> 
> > +	/*
> > +	 * Because 0xff is not a permitted value some error will seep into the
> > +	 * calculation of prescale as prescale grows. Specifically, this error
> > +	 * occurs where the remainder of the prescale calculation is less than
> > +	 * prescale.
> > +	 * For small values of prescale, only a handful of values will need
> > +	 * correction, but overall this applies to almost half of the valid
> > +	 * values for tmp.
> > +	 *
> > +	 * To keep the algorithm's decision making consistent, this case is
> > +	 * checked for and the simple solution is to, in these cases,
> > +	 * decrement prescale and check that the resulting value of period_steps
> > +	 * is valid.
> > +	 *
> > +	 * period_steps can be computed from prescale:
> > +	 *                      period * clk_rate
> > +	 * period_steps = ----------------------------- - 1
> > +	 *                NSEC_PER_SEC * (prescale + 1)
> > +	 *
> > +	 */
> > +	if (tmp % (MCHPCOREPWM_PERIOD_STEPS_MAX + 1) < *prescale) {
> 
> Hmm, looks like 32-bit doesn't like this modulus.
> I pushed things out for LKP to test before sending as I felt I'd not be
> allowed to do that operation, but got a build success email from it.
> I'm not sure why the mail wasn't sent as a reply to this, but
> <202304020410.A86IBNES-lkp@intel.com> complains:
> pwm-microchip-core.c:(.text+0x20a): undefined reference to `__aeabi_uldivmod'
> 
> I know that tmp < 65536 at this point, so if the general approach is
> fine, I can always cast it to a non 64-bit type without losing any
> information.

Since you already use some of the helpers from linux/math64.h, perhaps
you can use something like div_u64_rem() here?

Thierry

> 
> > +		u16 smaller_prescale = *prescale - 1;
> > +
> > +		*period_steps = div_u64(tmp, smaller_prescale + 1) - 1;
> > +		if (*period_steps < 255) {
> > +			*prescale = smaller_prescale;
> > +
> > +			return 0;
> > +		}
> > +	}



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding@gmail.com>
To: Conor Dooley <conor@kernel.org>
Cc: "Conor Dooley" <conor.dooley@microchip.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Daire McNamara" <daire.mcnamara@microchip.com>,
	linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
	linux-riscv@lists.infradead.org
Subject: Re: [PATCH v15 1/2] pwm: add microchip soft ip corePWM driver
Date: Thu, 6 Apr 2023 15:17:45 +0200	[thread overview]
Message-ID: <ZC7GeXJbB9PAF0lb@orome> (raw)
In-Reply-To: <0b91dee7-6c1d-4a33-8235-8fd5d58b200e@spud>


[-- Attachment #1.1: Type: text/plain, Size: 2084 bytes --]

On Sat, Apr 01, 2023 at 09:50:47PM +0100, Conor Dooley wrote:
> On Thu, Mar 30, 2023 at 08:12:03AM +0100, Conor Dooley wrote:
> 
> > +	/*
> > +	 * Because 0xff is not a permitted value some error will seep into the
> > +	 * calculation of prescale as prescale grows. Specifically, this error
> > +	 * occurs where the remainder of the prescale calculation is less than
> > +	 * prescale.
> > +	 * For small values of prescale, only a handful of values will need
> > +	 * correction, but overall this applies to almost half of the valid
> > +	 * values for tmp.
> > +	 *
> > +	 * To keep the algorithm's decision making consistent, this case is
> > +	 * checked for and the simple solution is to, in these cases,
> > +	 * decrement prescale and check that the resulting value of period_steps
> > +	 * is valid.
> > +	 *
> > +	 * period_steps can be computed from prescale:
> > +	 *                      period * clk_rate
> > +	 * period_steps = ----------------------------- - 1
> > +	 *                NSEC_PER_SEC * (prescale + 1)
> > +	 *
> > +	 */
> > +	if (tmp % (MCHPCOREPWM_PERIOD_STEPS_MAX + 1) < *prescale) {
> 
> Hmm, looks like 32-bit doesn't like this modulus.
> I pushed things out for LKP to test before sending as I felt I'd not be
> allowed to do that operation, but got a build success email from it.
> I'm not sure why the mail wasn't sent as a reply to this, but
> <202304020410.A86IBNES-lkp@intel.com> complains:
> pwm-microchip-core.c:(.text+0x20a): undefined reference to `__aeabi_uldivmod'
> 
> I know that tmp < 65536 at this point, so if the general approach is
> fine, I can always cast it to a non 64-bit type without losing any
> information.

Since you already use some of the helpers from linux/math64.h, perhaps
you can use something like div_u64_rem() here?

Thierry

> 
> > +		u16 smaller_prescale = *prescale - 1;
> > +
> > +		*period_steps = div_u64(tmp, smaller_prescale + 1) - 1;
> > +		if (*period_steps < 255) {
> > +			*prescale = smaller_prescale;
> > +
> > +			return 0;
> > +		}
> > +	}



[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2023-04-06 13:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-30  7:12 [PATCH v15 0/2] Microchip Soft IP corePWM driver Conor Dooley
2023-03-30  7:12 ` Conor Dooley
2023-03-30  7:12 ` [PATCH v15 1/2] pwm: add microchip soft ip " Conor Dooley
2023-03-30  7:12   ` Conor Dooley
2023-04-01 20:40   ` kernel test robot
2023-04-01 20:50   ` Conor Dooley
2023-04-01 20:50     ` Conor Dooley
2023-04-06 13:17     ` Thierry Reding [this message]
2023-04-06 13:17       ` Thierry Reding
2023-04-06 13:44       ` Conor Dooley
2023-04-06 13:44         ` Conor Dooley
2023-03-30  7:12 ` [PATCH v15 2/2] MAINTAINERS: add pwm to PolarFire SoC entry Conor Dooley
2023-03-30  7:12   ` Conor Dooley

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=ZC7GeXJbB9PAF0lb@orome \
    --to=thierry.reding@gmail.com \
    --cc=conor.dooley@microchip.com \
    --cc=conor@kernel.org \
    --cc=daire.mcnamara@microchip.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=u.kleine-koenig@pengutronix.de \
    /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: link
Be 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.