RE: [PATCH v2 1/3] media: pci: intel: ivsc: Add CSI submodule

[Wu, Wentong]

> -----Original Message-----
> From: Hillf Danton <hdanton@xxxxxxxx>
> Sent: Wednesday, February 15, 2023 7:54 AM
> 
> On Tue, 14 Feb 2023 12:40:12 +0000 Wentong Wu <wentong.wu@xxxxxxxxx>
> > > -----Original Message-----
> > > From: Hillf Danton <hdanton@xxxxxxxx>
> > > Sent: Tuesday, February 14, 2023 4:36 PM
> > >=20
> > > On Tue, 14 Feb 2023 06:25:35 +0000 Wentong Wu <wentong.wu@xxxxxxxxx>
> > > >
> > > > This allows new command(e.g. 'get status' command to check current
> > > > firmware=3D
> > > >  status) to be downloaded to firmware for debugging purpose in
> > > > case no resp=3D onse for current command though I have never saw this
> happen.
> > > > =3D20
> > >=20
> > > Thanks for your specification.
> > >=20
> > > Another question, is it likely for the wakeup to come after reinit
> > >becaus=
> > e of for
> > > instance timeout on the waiter side?
> >
> > Thanks, first I want to clarify why we have timeout here, in case
> > firmware = stuck somehow or IVSC device is removed suddenly, calling
> > thread can't be w= akeup if wait forever here.
> 
> Fair enough on the waiter side.
> >
> > And firmware gets high priority to handle command and response, also
> > there = is timeout mechanism inside firmware, I think there will be
> > some problem wi= th firmware if driver gets command response after 5s
> > which will be captured=  by driver code(if (csi->cmd_response.cmd_id
> > !=3D cmd->cmd_id)) but I have = never saw this happen.
> 
> The problem with firmware could be emulated by directly skipping the wait for
> completion and returning ETIMEDOUT, in order to see what will happen if
> wakeup comes later than timeout.

Thanks, but what do you mean "emulated"?