Hi Greg,
on my machine the RT-Kernel is already running. I also tried to change the preempt-priority for the uart-irq and set down the scheduling period. Both had no effect on the delays.
I'm pretty sure that the hardware can handle the speed, and even the OS/Kernel; Because at 256000 Baud, the response delay is only 0.7ms!
So at least, this delay-time must also be possible at 19200 Baud.
In my view the delay is not happening on the uart-driver layer, but somewhere above.
Right now perf is not available on the system, but I'll give it a try.
Tanks, Benjamin
-----Original Message-----
From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
Sent: Friday, January 28, 2022 4:39 PM
To: Benjamin Ulrich <Benjamin.Ulrich@xxxxxxxxxxxxxx>
Cc: linux-serial@xxxxxxxxxxxxxxx
Subject: Re: response time of serdev_device
On Fri, Jan 28, 2022 at 01:03:53PM +0000, Benjamin Ulrich wrote:
> Hi all,
>
> I'm using your serdev_device kernel module because it fit my needs pretty well.
> In my application the response delay to an received frame is time critical, because of that I made following observations:
>
> When I'm writing an UART "echo-device" with:
> static int device_receive_buf(struct serdev_device *serdev, const
> unsigned char *pbuf, size_t length) {
> return serdev_device_write_buf(serdev, pbuf, length); }
>
> I can measure the response delay between the TX/RX UART line.
> On my device (IMX8,with preempt-rt) the delay is dependent from the baudrate:
> 19200b -> 4.6ms
> 115200 -> 1ms
> 256000 -> 0.7ms
>
> The result is very surprising to me, at least the baudrate-response dependency.
This all depends on your uart hardware as well.
> I know that there are HW-Flow control stuff for Half-Duplex communication like in many RS485 applications.
> Is it possible that there are some old configs left? In the function: static int ttyport_open(struct serdev_controller *ctrl) the ktermios flags are set properly.
>
> For my driver a response time of 1ms@19200 would be really good.
Why do you think that?
> Can someone help me to archive that?
Are you sure this is possible with your hardware? This depends on your workload and lots of other things happening at the same time. If you need determinisitic behavior, have you tried the -RT kernel?
Have you used perf to measure where the delay is happening?
thanks,
greg k-h
