From: Oleksandr Andrushchenko <andr2000@gmail.com> To: Hans Verkuil <hverkuil@xs4all.nl>, "Oleksandr_Andrushchenko@epam.com" <Oleksandr_Andrushchenko@epam.com>, "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "jgross@suse.com" <jgross@suse.com>, "boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>, "mchehab@kernel.org" <mchehab@kernel.org>, "linux-media@vger.kernel.org" <linux-media@vger.kernel.org>, "sakari.ailus@linux.intel.com" <sakari.ailus@linux.intel.com>, "koji.matsuoka.xm@renesas.com" <koji.matsuoka.xm@renesas.com> Subject: Re: [Xen-devel][PATCH v4 1/1] cameraif: add ABI for para-virtual camera Date: Tue, 5 Feb 2019 15:06:48 +0200 [thread overview] Message-ID: <f3fa2587-3641-56ea-31c2-3758ee7ae96f@gmail.com> (raw) In-Reply-To: <5679f9a9-1218-0cdb-0c61-45864159ab29@xs4all.nl> On 2/5/19 3:02 PM, Hans Verkuil wrote: > On 2/5/19 1:30 PM, Oleksandr Andrushchenko wrote: >>> Sorry for paying so much attention to this, but I think it is important that >>> this is documented precisely. >> Thank you for helping with this - your comments are really >> important and make the description precise. Ok, so finally: >> >> * num_bufs - uint8_t, desired number of buffers to be used. >> * >> * If num_bufs is not zero then the backend validates the requested number of >> * buffers and responds with the number of buffers allowed for this frontend. >> * Frontend is responsible for checking the corresponding response in order to >> * see if the values reported back by the backend do match the desired ones >> * and can be accepted. >> * Frontend is allowed to send multiple XENCAMERA_OP_BUF_REQUEST requests >> * before sending XENCAMERA_OP_STREAM_START request to update or tune the >> * final configuration. >> * Frontend is not allowed to change the number of buffers and/or camera >> * configuration after the streaming has started. >> * >> * If num_bufs is 0 and streaming has not started yet, then the backend may >> * free all previously allocated buffers (if any) or do nothing. > I would rephrase this: > > * If num_bufs is 0 and streaming has not started yet, then the backend will > * free all previously allocated buffers (if any). > > The previous text suggested that the backend might choose not to free > the allocated buffers, but that's not the case. > Ok, makes sense >> * Trying to call this if streaming is in progress will result in an error. >> * >> * If camera reconfiguration is required then the streaming must be stopped >> * and this request must be sent with num_bufs set to zero and finally >> * buffers destroyed. >> * >> * Please note, that the number of buffers in this request must not exceed >> * the value configured in XenStore.max-buffers. >> * >> * See response format for this request. > With that small change the text looks good to me. Thank you for your time and help with this! It seems I can push v5 for the (final?) review then > Regards, > > Hans Thank you, Oleksandr
WARNING: multiple messages have this Message-ID (diff)
From: Oleksandr Andrushchenko <andr2000@gmail.com> To: Hans Verkuil <hverkuil@xs4all.nl>, "Oleksandr_Andrushchenko@epam.com" <Oleksandr_Andrushchenko@epam.com>, "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "jgross@suse.com" <jgross@suse.com>, "boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>, "mchehab@kernel.org" <mchehab@kernel.org>, "linux-media@vger.kernel.org" <linux-media@vger.kernel.org>, "sakari.ailus@linux.intel.com" <sakari.ailus@linux.intel.com>, "koji.matsuoka.xm@renesas.com" <koji.matsuoka.xm@renesas.com> Subject: Re: [PATCH v4 1/1] cameraif: add ABI for para-virtual camera Date: Tue, 5 Feb 2019 15:06:48 +0200 [thread overview] Message-ID: <f3fa2587-3641-56ea-31c2-3758ee7ae96f@gmail.com> (raw) In-Reply-To: <5679f9a9-1218-0cdb-0c61-45864159ab29@xs4all.nl> On 2/5/19 3:02 PM, Hans Verkuil wrote: > On 2/5/19 1:30 PM, Oleksandr Andrushchenko wrote: >>> Sorry for paying so much attention to this, but I think it is important that >>> this is documented precisely. >> Thank you for helping with this - your comments are really >> important and make the description precise. Ok, so finally: >> >> * num_bufs - uint8_t, desired number of buffers to be used. >> * >> * If num_bufs is not zero then the backend validates the requested number of >> * buffers and responds with the number of buffers allowed for this frontend. >> * Frontend is responsible for checking the corresponding response in order to >> * see if the values reported back by the backend do match the desired ones >> * and can be accepted. >> * Frontend is allowed to send multiple XENCAMERA_OP_BUF_REQUEST requests >> * before sending XENCAMERA_OP_STREAM_START request to update or tune the >> * final configuration. >> * Frontend is not allowed to change the number of buffers and/or camera >> * configuration after the streaming has started. >> * >> * If num_bufs is 0 and streaming has not started yet, then the backend may >> * free all previously allocated buffers (if any) or do nothing. > I would rephrase this: > > * If num_bufs is 0 and streaming has not started yet, then the backend will > * free all previously allocated buffers (if any). > > The previous text suggested that the backend might choose not to free > the allocated buffers, but that's not the case. > Ok, makes sense >> * Trying to call this if streaming is in progress will result in an error. >> * >> * If camera reconfiguration is required then the streaming must be stopped >> * and this request must be sent with num_bufs set to zero and finally >> * buffers destroyed. >> * >> * Please note, that the number of buffers in this request must not exceed >> * the value configured in XenStore.max-buffers. >> * >> * See response format for this request. > With that small change the text looks good to me. Thank you for your time and help with this! It seems I can push v5 for the (final?) review then > Regards, > > Hans Thank you, Oleksandr _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-02-05 13:06 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-01-15 9:38 [Xen-devel][PATCH v4 0/1] cameraif: add ABI for para-virtual camera Oleksandr Andrushchenko 2019-01-15 9:38 ` [PATCH " Oleksandr Andrushchenko 2019-01-15 9:38 ` [Xen-devel][PATCH v4 1/1] " Oleksandr Andrushchenko 2019-01-15 9:38 ` [PATCH " Oleksandr Andrushchenko 2019-01-15 14:44 ` [Xen-devel][PATCH " Hans Verkuil 2019-01-15 14:44 ` [PATCH " Hans Verkuil 2019-01-15 14:49 ` [Xen-devel][PATCH " Oleksandr Andrushchenko 2019-01-15 14:49 ` [PATCH " Oleksandr Andrushchenko 2019-01-23 8:14 ` [Xen-devel][PATCH " Oleksandr Andrushchenko 2019-01-23 8:14 ` [PATCH " Oleksandr Andrushchenko 2019-02-05 8:48 ` [Xen-devel][PATCH " Oleksandr Andrushchenko 2019-02-05 8:48 ` [PATCH " Oleksandr Andrushchenko 2019-02-05 9:34 ` [Xen-devel][PATCH " Hans Verkuil 2019-02-05 9:34 ` [PATCH " Hans Verkuil 2019-02-05 10:44 ` [Xen-devel][PATCH " Oleksandr Andrushchenko 2019-02-05 10:44 ` [PATCH " Oleksandr Andrushchenko 2019-02-05 10:53 ` [Xen-devel][PATCH " Hans Verkuil 2019-02-05 10:53 ` [PATCH " Hans Verkuil 2019-02-05 11:44 ` [Xen-devel][PATCH " Oleksandr Andrushchenko 2019-02-05 11:44 ` [PATCH " Oleksandr Andrushchenko 2019-02-05 12:14 ` [Xen-devel][PATCH " Hans Verkuil 2019-02-05 12:14 ` [PATCH " Hans Verkuil 2019-02-05 12:30 ` [Xen-devel][PATCH " Oleksandr Andrushchenko 2019-02-05 12:30 ` [PATCH " Oleksandr Andrushchenko 2019-02-05 13:02 ` [Xen-devel][PATCH " Hans Verkuil 2019-02-05 13:02 ` [PATCH " Hans Verkuil 2019-02-05 13:06 ` Oleksandr Andrushchenko [this message] 2019-02-05 13:06 ` Oleksandr Andrushchenko 2019-02-13 12:11 ` [Xen-devel][PATCH " Oleksandr Andrushchenko 2019-02-13 12:11 ` [PATCH " Oleksandr Andrushchenko 2019-01-31 8:24 ` [Xen-devel][PATCH v4 0/1] " Oleksandr Andrushchenko 2019-01-31 8:24 ` [PATCH " Oleksandr Andrushchenko
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=f3fa2587-3641-56ea-31c2-3758ee7ae96f@gmail.com \ --to=andr2000@gmail.com \ --cc=Oleksandr_Andrushchenko@epam.com \ --cc=boris.ostrovsky@oracle.com \ --cc=hverkuil@xs4all.nl \ --cc=jgross@suse.com \ --cc=koji.matsuoka.xm@renesas.com \ --cc=konrad.wilk@oracle.com \ --cc=linux-media@vger.kernel.org \ --cc=mchehab@kernel.org \ --cc=sakari.ailus@linux.intel.com \ --cc=xen-devel@lists.xenproject.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.