> > > On 10/24/24 08:40, Uwe Kleine-König wrote: > > > > On Thu, Oct 24, 2024 at 03:15:46PM +0800, Billy Tsai wrote: > > > >> Aspeed PWM controller has the WDT reload feature, which changes the duty > > > >> cycle to a preprogrammed value after a WDT/EXTRST#. > > > >> > > > >> Billy Tsai (2): > > > >> hwmon: (aspeed-g6-pwm-tacho): Extend the #pwm-cells to 4 > > > >> hwmon: (aspeed-g6-pwm-tacho): Support the WDT reload > > > > > > > > Huh, I'm not convinced that extending #pwm-cells for that feature is a > > > > good idea. Unless I'm missing something none of the other supported PWM > > > > chips can do that, so I hesitate to change a standard for it. I suggest > > > > to make this a separate property instead. > > > > Using a separate property to enable this feature is a straightforward > > method, but I don’t understand why extending #pwm-cells isn’t a good > > idea in my situation. The feature ‘WDT reload’ can be set for > > individual PWM channels, and the PWM subsystem has the of_xlate > > callback hook, which allows each driver to define its arguments for > > the PWM consumer. I’m unsure if I misunderstood this callback usage, > > as I couldn’t find examples. If my understanding is correct, this > > method is better for adding our specific feature, rather than using > > child nodes or separate properties to indicate which PWM channel > > should enable this feature with the corresponding duty cycle values. I > > think using separate properties to achieve this feature would be quite > > cumbersome. > > As I know the arguments for this usage are as follows: > > First: PWM channel index > > Second: PWM period in ns > > Third: PWM polarity > > Therefore, I extended our feature to a fourth argument to avoid any confusion regarding usage and added the description in our yaml file. > > > > If my thinking is incorrect or doesn’t make sense, please let me know. > It might make sense if your bubble only contains that single PWM > hardware. However if you extend the pwm cells semantic for your PWM to > mean "period if the PWM watchdog triggers", i can hardly refuse the next > developer who wants to extend for "period of the secondary output pin of > the PWM" or a step counter or some property that defines how the duty > cycle is modulated over time. And should the next one also use the 4th > u32 for his purpose, or should we consider it reserved now for your > purpose such that the duty_cycle modulation goes into the 7th cell? Hi Uwe, In my view, the order of arguments—such as PWM number, PWM period in ns, and PWM polarity—is just a convention for PWM consumers to follow. Even if another driver doesn’t adhere strictly to this rule, it shouldn’t be considered an error if the YAML file documents the usage of each argument. For example, some PWM controllers set #pwm-cells to 1, where the first argument isn’t necessarily the PWM number. In google,cros-ec-pwm.yaml, it’s treated as the PWM index, while in marvell,pxa-pwm.yaml, it represents the period in ns. If users want to work with these PWM controllers, they should confirm the purpose of each argument from the YAML file, rather than assuming the PWM driver follows a conventional argument order. If the YAML file doesn’t specify details, it can be treated as described in pwm.yaml, which is fine. However, if there are any differences, I think recording them in their own YAML file is sufficient (Like the example google,cros-ec-pwm.yaml and marvell,pxa-pwm.yaml). > Today the bindings are (well nearly) used in the same way for all > hardwares and I want to keep it that way. If your PWM has a special > feature, give it a speaking name that the occasional dts reader has a > chance to understand without reading HW docs or dt bindings. Using another DTS property to achieve this isn’t as elegant as utilizing PWM arguments, which will only be applied when the PWM consumer uses it. This is another reason I want to extend the PWM cells semantics. Thanks Best regards Billy Tsai
