Quoting Nikita Travkin (2022-01-07 23:25:19) > Hi, > > Stephen Boyd писал(а) 08.01.2022 05:52: > > Quoting Nikita Travkin (2021-12-09 08:37:17) > I'm adding this error here primarily to bring attention of the > user (e.g. developer enabling some peripheral that needs > duty cycle control) who might have to change their clock tree > to make this control effective. So, assuming that if someone > sets the duty cycle to 50% then they might set it to some other > value later, it makes sense to fail the first call anyway. > > If you think there are some other possibilities for this call > to happen specifically with 50% duty cycle (e.g. some > preparations or cleanups in the clk subsystem or some drivers > that I'm not aware of) then I can make an exemption in the check > for that. > I don't see anywhere in clk_set_duty_cycle() where it would bail out early if the duty cycle was set to what it already is. The default for these clks is 50%, so I worry that some driver may try to set the duty cycle to 50% and then fail now. Either we need to check the duty cycle in the core before calling down into the driver or we need to check it here in the driver. Can you send a patch to check the current duty cycle in the core before calling down into the clk ops?
