[PATCH 1/7] remoteproc: resource table overhaul

[Michal Simek]

Hi Ohad and Ludovic,

2012/5/21 Ohad Ben-Cohen <ohad at wizery.com>

> 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.
>

It is good that someone else has similar requirements.


>
> I think Ludovic already has a preliminary patch which he may be able
> to share with you.
>

Ludovic: Can you share your patch with us? I would like to try it.


>
> > 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.
>
>
Simple enabling RSC_VDEV in rproc_handle_rsc doesn't work.

BTW: I am using kernel modules and there is no dependency for
virtio_rpmsg_bus in remoteproc module
in sense if you load remoteproc module you also need to load
virtio_rpmsg_bus to get firmware to work.

I think that will be good to create that dependency automatically because
you need to load virtio_rpmsg_bus
when you problem remoteproc module.

~ # lsmod
~ # modprobe zynq_remoteproc
zynq_remoteproc: Unknown symbol rproc_register (err 0)
zynq_remoteproc: Unknown symbol rproc_alloc (err 0)
zynq_remoteproc: Unknown symbol rproc_vq_interrupt (err 0)
zynq_remoteproc: Unknown symbol rproc_free (err 0)
zynq_remoteproc: Unknown symbol rproc_unregister (err 0)
CPU1: shutdown
zynq_remoteproc 0.remoteproc-test: 0.remoteproc-test is available
zynq_remoteproc 0.remoteproc-test: Note: remoteproc is still under
development and considered experimental.
zynq_remoteproc 0.remoteproc-test: THE BINARY FORMAT IS NOT YET FINALIZED,
and backward compatibility isn't yet guaranteed.
~ # zynq_remoteproc 0.remoteproc-test: registered virtio0 (type 7)

~ # lsmod
zynq_remoteproc 4346 0 - Live 0xbf01f000
remoteproc 13831 1 zynq_remoteproc, Live 0xbf018000
virtio 2840 1 remoteproc, Live 0xbf008000
virtio_ring 4965 1 remoteproc, Live 0xbf013000
~ #
~ # modprobe virtio_rpmsg_bus
zynq_remoteproc 0.remoteproc-test: powering up 0.remoteproc-test
zynq_remoteproc 0.remoteproc-test: Booting fw image test, size 2351790
zynq_remoteproc 0.remoteproc-test: remote processor 0.remoteproc-test is
now up
virtio_rpmsg_bus virtio0: rpmsg host is online
virtio_rpmsg_bus virtio0: creating channel rpmsg-timer-statistic addr 0x50
~ #
~ # lsmod
virtio_rpmsg_bus 7575 0 - Live 0xbf024000
zynq_remoteproc 4346 1 - Live 0xbf01f000
remoteproc 13831 1 zynq_remoteproc, Live 0xbf018000
virtio 2840 2 virtio_rpmsg_bus,remoteproc, Live 0xbf008000
virtio_ring 4965 2 virtio_rpmsg_bus,remoteproc, Live 0xbf013000
~ #

Can you see the same behavior on omap?

Thanks,
Michal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120522/0fa99866/attachment-0001.html>