On 5/17/24 10:02, Conor Dooley wrote:
On Fri, May 17, 2024 at 06:00:06PM +0100, Conor Dooley wrote:
On that point. How would I explain in the bindings that cell 2 is the
duty cycle, cell 3 is the frequency and cell 4 is the flags?
In the pwm-cells property in the pwm provider binding . You might want to
order it as <index freq flags duty> as usually that's the ordering done
in most (all?) pwm provider bindings that I have seen.
The pwm bindings I think are really unhelpful though - they all say "see
pwm.yaml for info on the cells in #pwm-cells, but then pwm.yaml has no
information. The information is actually in pwm.text, but the binding
conversion did s/pwm.text/pwm.yaml/ in pwm controller bindings.
I'll send a patch that fixes up pwm.yaml.
Possibly cell 4 should be standardised as the period for all pwm
providers and then all you'd have to do for your provider is set
#pwm-cells:
minItems: 4
The chip (and other chips using pwm outputs to control fans) have additional
configuration parameters such as the minimum and maximum permitted pwm duty
cycles, or the startup timeout for various pwm outputs. I may be missing
something, but I don't see any such bindings in pwm.txt or pwm.yaml.
That is probably (likely ?) not needed for Chris' application, but it is an
overall concern since presumably similar bindings should be used for other
fan controllers.
In this context, I think we'll need nested bindings, because the controller
also supports temperature and voltage monitoring. Ultimately we'll also need
tach-ch because the controller specifically supports controlling multiple fans
from a single pwm channel and needs to be configured accordingly, at least
for automatic fan control.
Thanks,
Guenter
