On 3/10/20 5:08 AM, Uwe Kleine-König wrote: > Hello Guenter, > > On Mon, Mar 09, 2020 at 02:48:22PM -0700, Guenter Roeck wrote: >> On Mon, Mar 09, 2020 at 12:35:06PM -0700, Guru Das Srinagesh wrote: >>> Because period and duty cycle are defined in the PWM framework structs >>> as ints with units of nanoseconds, the maximum time duration that can be >>> set is limited to ~2.147 seconds. Redefining them as u64 values will >>> enable larger time durations to be set. >>> >>> As a first step, prepare drivers to handle the switch to u64 period and >>> duty_cycle by replacing division operations involving pwm period and duty cycle >>> with their 64-bit equivalents as appropriate. The actual switch to u64 period >>> and duty_cycle follows as a separate patch. >>> >>> Where the dividend is 64-bit but the divisor is 32-bit, use *_ULL >>> macros: >>> - DIV_ROUND_UP_ULL >>> - DIV_ROUND_CLOSEST_ULL >>> - div_u64 >>> >>> Where the divisor is 64-bit (dividend may be 32-bit or 64-bit), use >>> DIV64_* macros: >>> - DIV64_U64_ROUND_CLOSEST >>> - div64_u64 >> >> There is no explanation why this is necessary. What is the use case ? >> It is hard to imagine a real-world use case with a duty cycle of more >> than 2 seconds. > > When my Laptop is in suspend there is an LED that blinks with a period > of approximately 5 seconds. (To be fair, the brightness is more a sinus > than a rectangle, but still.) > I don't see support in the LED subsystem to utilize the PWM framework directly for blinking. Plus, you say yourself that it isn't a _real_ use case, just a theoretic one. Either case, the reason / use case for this series should be explained in the summary patch. That is what it is for. That case is not made. Guenter
