Hi Michal, On Mon, May 21, 2012 at 4:02 PM, Michal Simek <monstr@xxxxxxxxx> wrote: > I have looked at it and tested on latest and greatest and the problem is > still there. Ok, I see why this is happening. We're now allocating the vrings' DMA in ->find_vqs() just before we boot the remote processor, and we release it on ->del_vqs(). These are the virtio handlers for setting up and tearing down the vrings, so it makes sense to do so, but as a result, we still don't get the early carveout allocation you wanted. > I have looked at the code and path is > rproc_fw_config_virtio -> rproc_handliefirtion_rsc -> rproc_handle_vdev Please note that rproc_handle_vdev doesn't allocate any DMA at this point, and the allocation path is now quite different - it begins with virtio_rpmsg_bus probing and then calling into the ->find_vqs() handler. > For me it is necessary to ensure that dma_alloc_coherent in > rproc_alloc_vring is called after carveout allocation > just because dma_alloc_cohorent takes mermory from preallocated pool which > starts at 0x0. ok. > I also don't have > any other advance mechanism how to ensure mapping for the second arm core. Probably the best way to ensure this (without it breaking unexpectedly again as remoteproc evolves) is to have separate sub-devices for different kind of memories, which remoteproc could then look up using something like device_find_child(). Ludovic is exploring this direction too, because STE also needs to bind specific memory regions with predefined purposes, without depending on the order of DMA allocations. I think Ludovic already has a preliminary patch which he may be able to share with you. > Here is log which I need to get. Look at attached patch which exactly show > you what I need to do which I have tested. Yes, I see. Another temporary approach might be moving the vrings' allocations to the rproc_handle_rsc table (in the RSC_VDEV slot), but I'm not sure we want to merge this as well because this solution too is only hiding the real issue and not solving it permanently. Thanks, Ohad. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
