Hi,
Le jeu. 13 déc. 2018 à 21:32, Uwe Kleine-König
<u.kleine-koenig@xxxxxxxxxxxxxx> a écrit :
On Thu, Dec 13, 2018 at 02:58:31PM +0100, Paul Cercueil wrote:
Hi,
Le jeu. 13 déc. 2018 à 10:18, Uwe Kleine-König
<u.kleine-koenig@xxxxxxxxxxxxxx> a écrit :
> On Wed, Dec 12, 2018 at 11:09:07PM +0100, Paul Cercueil wrote:
> > The TCU channels 0 and 1 were previously reserved for system
tasks,
> > and
> > thus unavailable for PWM.
> >
> > The driver will now only allow a PWM channel to be requested if
> > memory
> > resources corresponding to the register area of the channel
were
> > supplied to the driver. This allows the TCU channels to be
reserved
> > for
> > system tasks from within the devicetree.
> >
> > Signed-off-by: Paul Cercueil <paul@xxxxxxxxxxxxxxx>
>
> While there is someone caring for this driver I'd like to
complete (a
> bit) my picture about the different capabilities and specialities
of the
> supported PWMs. So I have a few questions:
>
> Is there a publicly available reference manual for this device?
(If
> yes, adding a link to the driver would be great.)
I have them here: https://zcrc.me/~paul/jz_docs/
Is this link good enough to add it to the driver? From a quick view
I'd
say this is another pwm implementation that gets active on
pwm_disable().
Can you confirm this?
It's my website, so if these get moved, I can update the link.
What do you mean it gets active on pwm_disable()? If pwm_disable() gets
called
the PWM line goes back to inactive state, which is what it should do.
> jz4740_pwm_config looks as if the currently running period isn't
> completed before the new config is in effect. Is that correct? If
yes,
> can this be fixed? A similar question for set_polarity: Does
setting the
> JZ_TIMER_CTRL_PWM_ACTIVE_LOW bit in the control register take
effect
> immediately or is this shadowed until the next period starts?
I don't really know. We only use this driver for a rumble motor and
backlight.
Somebody would have to check with a logic analyzer.
depending on the possible timings you might also be able to test this
e.g. by setting:
duty_cycle=1ms, period=5s
and then
duty_cycle=5s, period=5s
. If the implementation is right your display should be dark for
nearly
5 seconds. (And the second call to pwm_apply should also block until
the
display is on.)
So it switches to full ON as soon as I set the duty cycle to 5s. Same
for
the polarity, it is updated as soon as the register is written. So the
registers are not shadowed.
> How does the device's output behave after the PWM is disabled?
> Does it complete the currently running period? How does the output
> behave then? (active/inactive/high/low/high-z?)
There's a bit to toggle between "graceful" shutdown (bit clear) and
"abrupt"
shutdown (bit set). TCSR bit 9. I think that graceful shutdown will
complete
the running period, then keep the level active. Abrupt shutdown
will keep
the
current level of the line.
Can you confirm the things you think above? I'd like to have them
eventually documented in the driver.
From what I can see, with "abrupt" shutdown the line will always
return to
its inactive state (be it low or high, depending on the polarity).
Setting
this bit to "graceful" shutdown, the only difference is that the
hardware
will keep its current state, active or inactive. That's why we use the
"abrupt" shutdown in the PWM driver.
> > @@ -42,11 +68,7 @@ static int jz4740_pwm_request(struct
pwm_chip
> > *chip, struct pwm_device *pwm)
> > char clk_name[16];
> > int ret;
> >
> > - /*
> > - * Timers 0 and 1 are used for system tasks, so they are
> > unavailable
> > - * for use as PWMs.
> > - */
> > - if (pwm->hwpwm < 2)
> > + if (!jz4740_pwm_can_use_chn(jz, pwm->hwpwm))
> > return -EBUSY;
>
> Maybe EBUSY isn't the best choice here. If the needed register
space for
> the requested pwm is not included in the memory resources
provided to
> the device I'd prefer ENXIO or ENODEV.
The idea was that if we don't get the register space we need, that
means
the channel is used for something else, hence the EBUSY. Should I
switch
it to ENXIO?
I understand your reasoning, but I think it's misleading. If I get
-EBUSY from a PWM driver I'd start searching for another user of said
resource. With ENXIO or ENODEV it's more obvious that the driver isn't
responsible for the resource that was requested.
OK.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König
|
Industrial Linux Solutions |
http://www.pengutronix.de/ |
