Hi Uwe Kleine-König, > -----Original Message----- > From: Uwe Kleine-König <ukleinek@xxxxxxxxxx> > Sent: 05 December 2024 16:27 > Subject: Re: [PATCH v22 3/4] pwm: Add support for RZ/G2L GPT > > 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. Ok, thanks. This will make the driver simpler for the initial version. > > > 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 Sorry for my bad english. > 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. I got your point a duty cycle of 50% can be achieved at period/duty configured at ms or in nsec. The former being aimed for low frequency PWM application and later for higher frequency application and the period in ms or nsec are purely application specific. If you allow me, Shall I send simplified version of the driver? ie, will return error if requested_period of IO_A != IO_B. Later we can accommodate adapting duty cycle of first channel, if we allow changing periods from second channel, based on any customer use case. There are some customers using GPT for backlight in LCD panels. Please let me know. Going forward there are lot of features are planned for this driver 1) inverse feature 2) Detecting short circuits between IO's 3) Phase counting 4) Input capture 5) PWM using buffer 6) DMA operation 7) ADC start trigger Cheers, Biju
