On 8/18/25 9:20 AM, Tomi Valkeinen wrote:
Hello Tomi,
If yes, then it might take
much longer until the command can be transferred.
Do you know the upper limit , is that one or two frame times ?
If using DSI video mode and the stream is on, the DSI TX has to
interleave the commands either to the line blanking or frame blanking.
Usually this is configurable in the DSI TX (if the chip can do
interleaving).
A read command will be the most difficult to interleave, as it takes
more time with the BTA and reply.
I think the worst case is one frame delay (next vblank).
I set the timeouts to 50ms, which at 60 Hz refresh should be a bit over
three frame delays, which should be safe.
If not maybe the
function should return an error if the video stream is enabled.
I haven't seen any drivers special casing that, I'd prefer to increase
the timeouts. For V3, I'll update the timeout to 50ms , which is about 3
frame times.
If the docs have no word about interleaving the commands and there are
no related registers, I would guess that it's not supported. If this
can't be tested, I suggest just returning an error if a command is sent
while the video is on.
You should be able to test this, though. E.g. just add a debugfs/sysfs
file to the panel or dsi tx driver, which does a DSI command, possibly a
read. See what happens when the video is enabled.
I patched the ili9881c panel and triggered DCS read of its ID via sysfs
attribute , I could always get valid ID, so I think we are safe here.
[...]
+ /* Wait a bit between commands */
+ usleep_range(1000, 2000);
Why wait and wait a bit between what?
The consecutive command transmission was unreliable unless there was a
slight delay between the consecutive commands. Hence this delay.
This sounds like there's a bug in the driver, or the TX or RX hardware.
Please document the sleep clearly in the comment.
Done.
