Hello, On Thu, Dec 05, 2024 at 09:29:35AM +0000, Biju Das wrote: > > -----Original Message----- > > From: Uwe Kleine-König <ukleinek@xxxxxxxxxx> > > Sent: 05 December 2024 08:28 > > Subject: Re: [PATCH v22 3/4] pwm: Add support for RZ/G2L GPT > > > > Hello Biju, > > > > > According to me, we should not allow updating periods for second enabled channel. > > > > Not entirely sure you mean the right thing here. If IO A operates at 5ns and IO B is requested to > > set .period = 5 ms, every operation that also changes A is out-of-bounds. So your options are only: > > Use the 5ns, or return an error. The latter is hard for consumers because it's unclear what to do > > then. > > > I guess, these 2 IO's mostly used in switching circuits. So, can't we return error, if period of IO_A != IO_B? > Then the user know the mistake and he will configure with proper values?? You can do that. However in general the user (or consumer driver) of IO A won't know about the connection between the two PWMs and so they only see their request failing. > Here IO_B has faster switching(MHz) compared to IO_A (kHZ), > So, by allowing IO_A to operate at IO_B frequency, we are doing > Some incorrect operation for IO_A. "incorrect" is very subjective and depends on the use case. Many drivers only care about the relative duty cycle. So if they initially want .duty_cycle = 1ms .period = 5ms and then learn that only period = 5ns is possible, they are also happy with .duty_cycle = 1ns .period = 5ns Some other drivers are happy with a given duty cycle and hardly care about the period, so they only care that .duty_cycle is 3ns and both .period = 5ms and .period = 5ns is ok. Or a driver that requests .duty_cycle = 0ms .period = 5ms doesn't care about the period at all if only .duty_cycle is zero. So the only way to make everybody happy, is to be able to query the hardware possibilities. Best regards Uwe
Attachment:
signature.asc
Description: PGP signature
