[PATCH 1/7] remoteproc: resource table overhaul

[Ohad Ben-Cohen]

Hi Michal,

On Mon, May 21, 2012 at 4:02 PM, Michal Simek <monstr at monstr.eu> 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.