Messages in this thread | | | Date | Sun, 28 Oct 2012 22:58:53 +0100 | Subject | Re: [PATCHv7 4/4] virtio_console: Add support for remoteproc serial | From | Sjur Brændeland <> |
| |
Hi Rusty,
> The free-outside-interrupt issue is usually dealt with by offloading to > a wq, but your variant works (and isn't too ugly).
Ok, thanks.
>> +static void reclaim_dma_bufs(void) >> +{ >> + unsigned long flags; >> + struct port_buffer *buf, *tmp; >> + LIST_HEAD(tmp_list); >> + >> + if (list_empty(&pending_free_dma_bufs)) >> + return; ... > Looks like this should be an easy noop even if !is_rproc_serial.
Ok, I'll drop the superfluous check before calling reclaim_dma_bufs().
>> @@ -1415,7 +1524,16 @@ static void remove_port_data(struct port *port) >> >> /* Remove buffers we queued up for the Host to send us data in. */ >> while ((buf = virtqueue_detach_unused_buf(port->in_vq))) >> - free_buf(buf); >> + free_buf(buf, true); >> + >> + /* >> + * Remove buffers from out queue for rproc-serial. We cannot afford >> + * to leak any DMA mem, so reclaim this memory even if this might be >> + * racy for the remote processor. >> + */ >> + if (is_rproc_serial(port->portdev->vdev)) >> + while ((buf = virtqueue_detach_unused_buf(port->out_vq))) >> + free_buf(buf, true); >> } > > This seems wrong; either this is needed even if !is_rproc_serial(), or > it's not necessary as the out_vq is empty. > > Every path I can see has the device reset (in which case the queues > should not be active), or we got a VIRTIO_CONSOLE_PORT_REMOVE event (in > which case, the same). > > I think we can have non-blocking writes which could leave buffers in > out_vq: Amit?
Hm, the remote device could potentially freeze whenever. So I think we should handle the situation where buffer are stuck in the out-queue for the rproc_serial device. But I'll move this piece of code into a new follow-up patch so we can handle this issue separately.
Thanks, Sjur
| |