On Wed, Jan 05, 2022 at 04:34:21PM +0300, Sergey Organov wrote: > Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> writes: > > > On Tue, Jan 04, 2022 at 12:38:01PM +0100, Greg Kroah-Hartman wrote: > >> On Tue, Jan 04, 2022 at 12:13:06PM +0100, Tomasz Moń wrote: > >> > On 04.01.2022 11:54, Greg Kroah-Hartman wrote: > >> > > Why can't you do this dynamically based on the baud rate so as to always > >> > > work properly for all speeds without increased delays for slower ones? > >> > > >> > Could you please advise on which baud rates to consider as slow? Does it > >> > sound good to have the old trigger level for rates up to and including > >> > 115200 and the new one for faster ones? > >> > >> You tell me, you are the one seeing this issue and are seeing delays on > >> slower values with your change. Do some testing to see where the curve > >> is. > > > > Maybe it's more sensible to make this even more dynamic: e.g. keep it at > > 1 as default and increase the water level when a certain irq frequency > > is reached? > > Too complex, and too many questions, I'm afraid. What is "irq > frequency", exactly? For this particular driver, or overall system? > Measured on what time interval? What is the threshold? Do we drop the > water level back to 1 when "irq frequency" is down again? Will we just > create re-configure storm at some conditions? Etc..... It could be as easy as increasing the waterlevel by one if an RX irq happens with USR1.AGTIM = 0 and reset to 1 if USR1.AGTIM = 1. This makes sure that receiving at a low frequency makes the hardware interrupt the CPU early, and a burst doesn't starve the CPU. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |
Attachment:
signature.asc
Description: PGP signature
