Hi,
> > qemu has rather small buffers backend buffers, to keep latencies low.
> > So, yes it would copy data to backend buffers. No, it would most likely
> > not copy over everything immediately. It will most likely leave buffers
> > in the virtqueue, reading the data piecewise in the audio
Version 2 needs to be appended together with version 1 as legacy
interface since we introduce the latest version.
Signed-off-by: Jing Liu
Signed-off-by: Chao Peng
Signed-off-by: Zha Bin
Signed-off-by: Liu Jiang
---
content.tex | 123
Upgrade virtio-mmio to version 3, with the abilities to support
MSI interrupt and notification features.
The details of version 2 will be appended as part of legacy interface
in next patch.
Signed-off-by: Jing Liu
Signed-off-by: Chao Peng
Signed-off-by: Zha Bin
Signed-off-by: Liu Jiang
---
Hi Keiichi,
Thank you for the update. Please see some comments below.
Also, we need to bring the virtio_video_control back as it is in fact used by
the driver to enumerate supported encoder controls. But yes, it still needs to
be documemnted, it's true.
On Mittwoch, 18. Dezember 2019 14:02:14
Hi,
> > However that still doesn't let the driver know which buffers will be
> > dequeued when. A simple example of this scenario is when the guest is
> > done displaying a frame and requeues the buffer back to the decoder.
> > Then the decoder will not choose it for decoding next frames into
Hi,
> > Not clearly defined in the spec: When is the decoder supposed to send
> > the response for a queue request? When it finished decoding (i.e. frame
> > is ready for playback), or when it doesn't need the buffer any more for
> > decoding (i.e. buffer can be re-queued or pages can be
On 19.12.2019 08:17, Gerd Hoffmann wrote:
Hi,
The driver can still split the data from the application into a set of
smaller virtio buffers. And this is how I would write a driver. Create
a bunch of buffers, period_bytes each, enough to cover buffer_bytes.
Then go submit them, re-use them
Hi,
> > I also can't see why the flag is needed in the first place. The driver
> > should know which buffers are queued still and be able to figure
> > whenever the drain is complete or not without depending on that flag.
> > So I'd suggest to simply drop it.
> This flag is used not for drain
On Thu, Dec 19, 2019 at 7:55 PM Dmitry Sepp wrote:
>
> Hi Tomasz,
>
> On Donnerstag, 19. Dezember 2019 10:59:02 CET Tomasz Figa wrote:
> > On Thu, Dec 19, 2019 at 6:48 PM Dmitry Sepp
> wrote:
> > > Hi,
> > >
> > > On Donnerstag, 19. Dezember 2019 08:46:39 CET Gerd Hoffmann wrote:
> > > > On Wed,
Hi Tomasz,
On Donnerstag, 19. Dezember 2019 10:59:02 CET Tomasz Figa wrote:
> On Thu, Dec 19, 2019 at 6:48 PM Dmitry Sepp
wrote:
> > Hi,
> >
> > On Donnerstag, 19. Dezember 2019 08:46:39 CET Gerd Hoffmann wrote:
> > > On Wed, Dec 18, 2019 at 11:08:37PM +0900, Tomasz Figa wrote:
> > > > On Wed,
On Thu, Dec 19, 2019 at 6:48 PM Dmitry Sepp wrote:
>
> Hi,
>
> On Donnerstag, 19. Dezember 2019 08:46:39 CET Gerd Hoffmann wrote:
> > On Wed, Dec 18, 2019 at 11:08:37PM +0900, Tomasz Figa wrote:
> > > On Wed, Dec 18, 2019 at 10:40 PM Gerd Hoffmann wrote:
> > > > Hi,
> > > >
> > > > > +The
On Thu, Dec 19, 2019 at 6:26 PM Dmitry Sepp wrote:
>
> Hi Gerd,
>
> On Mittwoch, 18. Dezember 2019 14:40:37 CET Gerd Hoffmann wrote:
> > Hi,
> >
> > > +The device MUST mark the last buffer with the
> > > +VIRTIO_VIDEO_BUFFER_F_EOS flag to denote completion of the drain
> > > +sequence.
> >
> >
On 18.12.2019 17:54, Mark Brown wrote:
On Wed, Dec 18, 2019 at 04:34:12PM +0100, Anton Yakovlev wrote:
On 18.12.2019 12:52, Gerd Hoffmann wrote:
Well, the driver has to manage buffers, so I can't see how a driver is
not interested in completion notifications. If the driver isn't
interested
Hi,
On Donnerstag, 19. Dezember 2019 08:46:39 CET Gerd Hoffmann wrote:
> On Wed, Dec 18, 2019 at 11:08:37PM +0900, Tomasz Figa wrote:
> > On Wed, Dec 18, 2019 at 10:40 PM Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > +The device MUST mark the last buffer with the
> > > >
Hi Gerd,
On Mittwoch, 18. Dezember 2019 14:40:37 CET Gerd Hoffmann wrote:
> Hi,
>
> > +The device MUST mark the last buffer with the
> > +VIRTIO_VIDEO_BUFFER_F_EOS flag to denote completion of the drain
> > +sequence.
>
> No, that would build a race condition into the protocol. The device
>
15 matches
Mail list logo
