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:
signature.asc
Description: PGP signature
