Hi Uwe,
thanks for taking the time to look into this. :)
On Wed, 2021-03-10 at 12:50 +0100, Uwe Kleine-König wrote:
> Hello Nicolas,
>
> On Mon, Jan 18, 2021 at 01:32:44PM +0100, Nicolas Saenz Julienne wrote:
[...]
> > + /*
> > + * This sets the default duty cycle after resetting the board, we
> > + * updated it every time to mimic Raspberry Pi's downstream's driver
> > + * behaviour.
> > + */
> > + ret = raspberrypi_pwm_set_property(rpipwm->firmware, RPI_PWM_DEF_DUTY_REG,
> > + duty_cycle);
> > + if (ret) {
> > + dev_err(chip->dev, "Failed to set default duty cycle: %pe\n",
> > + ERR_PTR(ret));
> > + return ret;
>
> This only has an effect for the next reboot, right?
It effects all reboots until it's further changed.
> If so I wonder if it is a good idea in general. (Think: The current PWM
> setting enables a motor that makes a self-driving car move at 100 km/h.
> Consider the rpi crashes, do I want to car to pick up driving 100 km/h at
> power up even before Linux is up again?)
I get your point. But this isn't used as a general purpose PWM. For now the
interface is solely there to drive a PWM fan that's arguably harmless. This
doesn't mean that the RPi foundation will not reuse the firmware interface for
other means in the future. In such case we can always use a new DT compatible
and bypass this feature (the current DT string is
'raspberrypi,firmware-poe-pwm', which is specific to this use-case).
My aim here is to be on par feature wise with RPi's downstream implementation.
So as for them to be able to use it as is and avoid duplication. Now, if this
is blocking the driver from being merged, I'd rather remove it. It'll be a
patch for the downstream kernel to maintain, but better than nothing.
> And if we agree it's a good idea: Should raspberrypi_pwm_apply return 0 if
> setting the duty cycle succeeded and only setting the default didn't?
Good point. I don't think so. We'd be also missing on the following by
returning early:
rpipwm->duty_cycle = duty_cycle;
I propose to change it to a 'best effort' approach, if it fails, log it and
continue successfully.
Regards,
Nicolas
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
