Re: [PATCH v5 00/16] acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic PWM API

[Thierry Reding <thierry.reding@gmail.com>]

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

On Wed, Jul 29, 2020 at 11:32:28AM +0200, Hans de Goede wrote:
> cHi,
> 
> On 7/29/20 10:23 AM, Andy Shevchenko wrote:
> > On Mon, Jul 27, 2020 at 09:41:20AM +0200, Thierry Reding wrote:
> > > On Fri, Jul 17, 2020 at 03:37:37PM +0200, Hans de Goede wrote:
> > 
> > > I've applied patches 3 through 12 to the PWM tree. I thought it was a
> > > bit odd that only a handful of these patches had been reviewed and there
> > > were no Tested-bys, but I'm going to trust that you know what you're
> > > doing. =) If this breaks things for anyone I'm sure they'll complain.
> 
> Thank you for picking up these patches, but ...
> 
> > Can we postpone a bit?
> 
> I have to agree with Andy here, as mentioned my plan was to push the
> entire series through drm-intel-next-queued once the last few PWM
> patches are reviewed.
> 
> There are some fixes, to the pwm-crc driver which change behavior in
> a possibly undesirable way, unless combined with the i915 changes.
> 
> E.g. there is a fix which makes the pwm-crc driver actually honor
> the requested output frequency (it was not doing this due to a bug)
> and before the i915 changes, the i915 driver was hardcoding an output
> freq, rather then looking at the video-bios-tables as it should.
> 
> So having just the pwm-crc fix, will change the output frequency
> which some LCD panels might not like.
> 
> Note things are probably fine with the hardcoded output freq, but I
> would like to play it safe here.
> 
> Also Andy was still reviewing some of the PWM patches, and has requested
> changes to 1 patch, nothing functional just some code-reshuffling for
> cleaner code, so we could alternatively fix this up with a follow-up patch.
> 
> Either way please let us know how you want to proceed.

Okay, that's fine, I'll drop them again.

> > > That said I see that Rafael has acked patches 1-2 and Jani did so for
> > > patches 13-16. I'm not sure if you expect me to pick those patches up as
> > > well. As far as I can tell the ACPI, PWM and DRM parts are all
> > > independent, so these patches could be applied to the corresponding
> > > subsystem trees.
> > > 
> > > Anyway, if you want me to pick those all up into the PWM tree, I suppose
> > > that's something I can do as well.
> 
> drm-intel-next-queued is usually seeing quite a bit of churn, so the i915
> patches really should go upstream through that branch.

During my build tests I ran into a small issue caused by this series
interacting with the conversion of period and duty-cycle to u64 that
I've queued for v5.9. This causes a build failure on x86.

I have this local diff to fix that:

--- >8 ---
diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
index 370ab826a20b..92e838797733 100644
--- a/drivers/pwm/pwm-crc.c
+++ b/drivers/pwm/pwm-crc.c
@@ -76,7 +76,9 @@ static int crc_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 
 	if (pwm_get_duty_cycle(pwm) != state->duty_cycle ||
 	    pwm_get_period(pwm) != state->period) {
-		int level = state->duty_cycle * PWM_MAX_LEVEL / state->period;
+		u64 level = state->duty_cycle * PWM_MAX_LEVEL;
+
+		do_div(level, state->period);
 
 		err = regmap_write(crc_pwm->regmap, PWM0_DUTY_CYCLE, level);
 		if (err) {
@@ -141,10 +143,9 @@ static void crc_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
 
 	clk_div = (clk_div_reg & ~PWM_OUTPUT_ENABLE) + 1;
 
-	state->period =
-		DIV_ROUND_UP(clk_div * NSEC_PER_USEC * 256, PWM_BASE_CLK_MHZ);
-	state->duty_cycle =
-		DIV_ROUND_UP(duty_cycle_reg * state->period, PWM_MAX_LEVEL);
+	state->period = DIV_ROUND_UP(clk_div * NSEC_PER_USEC * 256, PWM_BASE_CLK_MHZ);
+	state->duty_cycle = duty_cycle_reg * state->period + PWM_MAX_LEVEL - 1;
+	do_div(state->duty_cycle, PWM_MAX_LEVEL);
 	state->polarity = PWM_POLARITY_NORMAL;
 	state->enabled = !!(clk_div_reg & PWM_OUTPUT_ENABLE);
 }
--- >8 ---

So perhaps you want to integrate that or something equivalent into your
series.

Also this could result in a tricky dependency between PWM and drm-misc,
although if you're targetting drm-misc it's too late for v5.9 anyway. In
that case you should be able to rebase your series on v5.9-rc1 when it's
out and then you'll get the prerequisite PWM changes for the u64
conversion as part of that. No need to track the dependency explicitly.

Thierry

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

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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel