2253116_ja-JP

Yes

VPU v4l2 ドライバ ERESTARTSYS 処理

私は i.MX8MP プロセッサを使用しており、ビデオプロセッシングユニット (VPU) を使用してビデオをエンコードしています。

v4l2 ドライバがユーザー空間の vsidaemon にコマンドを送信し、応答を待機しているときに、Linux シグナルが発行されると、v4l2 ドライバが vsidaemon を停止し、ユーザー空間アプリがビデオのエンコードを続行するために v4l2 デバイスを閉じて再度開く必要があるという問題を発見しました。

具体的には、v4l2ドライバの次の行は、`wait_event_interruptible()`を使用してvsidaemonからの応答を待機します。

Linux-imx/ドライバ/mxc/hantro_v4l2/vsi-v4l2daemon.c at lf-6.12.y · nxp-imx/Linux-imx · GitHub

Linux シグナルが発行された場合 (良性または悪性)、`wait_event_interruptible()` は -ERESTARTSYS を返し、これにより `vsi_v4l2_sendcmd` 関数が呼び出されて -ERESTARTSYS が返され、これにより `vsiv4l2_execcmd()` 関数が呼び出されてコンテキストエラーが設定されます ( https://github.com/nxp-imx/linux-imx/blob/be78e49cb4339fd38c9a40019df49b72fbb8bcb7/drivers/mxc/hantr... )。

その結果、v4l2 ドライバへの次の `ioctl()` 呼び出しによって vsidaemon が閉じられます。

Re: VPU v4l2 driver ERESTARTSYS handling

迅速なご返信ありがとうございます。`wait_event_interruptible()` を再試行するようにドライバを変更します。

Re: VPU v4l2 driver ERESTARTSYS handling

こんにちは、

VPU v4l2 ドライバで発生している問題は、ドライバでの Linux シグナル処理の実装方法に関連しています。ドライバコードで `wait_event_interruptible()` が使用される場合、待機中にシグナルを受信すると `-ERESTARTSYS` を返すように設計されています。これは標準的な Linux カーネルの動作です。

現在の実装では、v4l2 ドライバが vsidaemon からの応答を待機しているときにシグナルが待機プロセスを中断すると、ドライバはシステムコールを単純に再開するのではなく、エラー状態を設定します。これにより、次の `ioctl()` 呼び出しで vsidaemon が閉じられるため、v4l2 デバイスを閉じて再度開く必要があります。

これはドライバの既知の問題です。ドライバは、`-ERESTARTSYS` CASE を別の方法で処理するように変更できます。たとえば、vsidaemon を閉じることになるコンテキストエラーを設定するのではなく、待機を再開したり、回復メカニズムを実装したりすることができます。

ドライバを変更せずに回避策が必要な場合は、次の操作を実行できます。

1. VPUとやりとりする際の重要なセクションでは、アプリケーション内の信号をブロックまたは処理します。
2. アプリケーションに回復ロジックを実装して、この状態を検出し、デバイスを自動的に再起動します。

永続的な修正を行うには、vsidaemon が閉じられないような方法で、`wait_event_interruptible()` からの `-ERESTARTSYS` 戻り値を適切に処理するようにドライバコードを変更する必要があります。

よろしくお願いします。