Hi Ohad and Ludovic,<br><br><div class="gmail_quote">2012/5/21 Ohad Ben-Cohen <span dir="ltr"><<a href="mailto:ohad@wizery.com" target="_blank">ohad@wizery.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Michal,<br>
<div class="im"><br>
On Mon, May 21, 2012 at 4:02 PM, Michal Simek <<a href="mailto:monstr@monstr.eu">monstr@monstr.eu</a>> wrote:<br>
> I have looked at it and tested on latest and greatest and the problem is<br>
> still there.<br>
<br>
</div>Ok, I see why this is happening.<br>
<br>
We're now allocating the vrings' DMA in ->find_vqs() just before we<br>
boot the remote processor, and we release it on ->del_vqs(). These are<br>
the virtio handlers for setting up and tearing down the vrings, so it<br>
makes sense to do so, but as a result, we still don't get the early<br>
carveout allocation you wanted.<br>
<div class="im"><br>
> I have looked at the code and path is<br>
> rproc_fw_config_virtio -> rproc_handliefirtion_rsc -> rproc_handle_vdev<br>
<br>
</div>Please note that rproc_handle_vdev doesn't allocate any DMA at this<br>
point, and the allocation path is now quite different - it begins with<br>
virtio_rpmsg_bus probing and then calling into the ->find_vqs()<br>
handler. <br></blockquote><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
> For me it is necessary to ensure that dma_alloc_coherent in<br>
> rproc_alloc_vring is called after carveout allocation<br>
> just because dma_alloc_cohorent takes mermory from preallocated pool which<br>
> starts at 0x0.<br>
<br>
</div>ok.<br>
<div class="im"><br>
> I also don't have<br>
> any other advance mechanism how to ensure mapping for the second arm core.<br>
<br>
</div>Probably the best way to ensure this (without it breaking unexpectedly<br>
again as remoteproc evolves) is to have separate sub-devices for<br>
different kind of memories, which remoteproc could then look up using<br>
something like device_find_child().<br>
<br>
Ludovic is exploring this direction too, because STE also needs to<br>
bind specific memory regions with predefined purposes, without<br>
depending on the order of DMA allocations.<br></blockquote><div><br>It is good that someone else has similar requirements.<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br>
I think Ludovic already has a preliminary patch which he may be able<br>
to share with you.<br></blockquote><div><br>Ludovic: Can you share your patch with us? I would like to try it.<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div class="im"><br>
> Here is log which I need to get. Look at attached patch which exactly show<br>
> you what I need to do which I have tested.<br>
<br>
</div>Yes, I see. Another temporary approach might be moving the vrings'<br>
allocations to the rproc_handle_rsc table (in the RSC_VDEV slot), but<br>
I'm not sure we want to merge this as well because this solution too<br>
is only hiding the real issue and not solving it permanently.<br>
<br></blockquote><div><br>Simple enabling RSC_VDEV in rproc_handle_rsc doesn't work.<br><br>BTW: I am using kernel modules and there is no dependency for virtio_rpmsg_bus in remoteproc module<br>in sense if you load remoteproc module you also need to load virtio_rpmsg_bus to get firmware to work.<br>
<br>I think that will be good to create that dependency automatically because you need to load virtio_rpmsg_bus<br>when you problem remoteproc module.<br><br>~ # lsmod<br>~ # modprobe zynq_remoteproc<br>zynq_remoteproc: Unknown symbol rproc_register (err 0)<br>
zynq_remoteproc: Unknown symbol rproc_alloc (err 0)<br>zynq_remoteproc: Unknown symbol rproc_vq_interrupt (err 0)<br>zynq_remoteproc: Unknown symbol rproc_free (err 0)<br>zynq_remoteproc: Unknown symbol rproc_unregister (err 0)<br>
CPU1: shutdown<br>zynq_remoteproc 0.remoteproc-test: 0.remoteproc-test is available<br>zynq_remoteproc 0.remoteproc-test: Note: remoteproc is still under development and considered experimental.<br>zynq_remoteproc 0.remoteproc-test: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.<br>
~ # zynq_remoteproc 0.remoteproc-test: registered virtio0 (type 7)<br><br>~ # lsmod<br>zynq_remoteproc 4346 0 - Live 0xbf01f000<br>remoteproc 13831 1 zynq_remoteproc, Live 0xbf018000<br>virtio 2840 1 remoteproc, Live 0xbf008000<br>
virtio_ring 4965 1 remoteproc, Live 0xbf013000<br>~ # <br>~ # modprobe virtio_rpmsg_bus<br>zynq_remoteproc 0.remoteproc-test: powering up 0.remoteproc-test<br>zynq_remoteproc 0.remoteproc-test: Booting fw image test, size 2351790<br>
zynq_remoteproc 0.remoteproc-test: remote processor 0.remoteproc-test is now up<br>virtio_rpmsg_bus virtio0: rpmsg host is online<br>virtio_rpmsg_bus virtio0: creating channel rpmsg-timer-statistic addr 0x50<br>~ # <br>~ # lsmod<br>
virtio_rpmsg_bus 7575 0 - Live 0xbf024000<br>zynq_remoteproc 4346 1 - Live 0xbf01f000<br>remoteproc 13831 1 zynq_remoteproc, Live 0xbf018000<br>virtio 2840 2 virtio_rpmsg_bus,remoteproc, Live 0xbf008000<br>virtio_ring 4965 2 virtio_rpmsg_bus,remoteproc, Live 0xbf013000<br>
~ # <br><br>Can you see the same behavior on omap?<br><br>Thanks,<br>Michal<br><br><br><br><br><br></div><div><br><br> </div></div><br>