From: ludovic.barre@stericsson•com (frq09524)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 1/7] remoteproc: resource table overhaul
Date: Tue, 22 May 2012 11:14:48 +0200 [thread overview]
Message-ID: <4FBB5908.4010505@stericsson.com> (raw)
In-Reply-To: <CAHTX3dK8rDomYqWvBX1ay200AmM1dBCYD3nJ2UYbzC_SSFankw@mail.gmail.com>
Hi Ohad and Michal
yes I can share my patch, remoteproc has evolved and my patch is not
aligned on latest version of remote proc (especially since remoteproc:
remove the single rpmsg vdev limitation).
Ohad, for alignment I can take the latest branch of kernel.org
(remoteproc) branch for-next?
/BR
Ludovic Barr?
On 05/22/2012 07:51 AM, Michal Simek wrote:
> Hi Ohad and Ludovic,
>
> 2012/5/21 Ohad Ben-Cohen <ohad at wizery.com <mailto:ohad@wizery•com>>
>
> Hi Michal,
>
> On Mon, May 21, 2012 at 4:02 PM, Michal Simek <monstr@monstr•eu
> <mailto:monstr@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 prev parent reply other threads:[~2012-05-22 9:14 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-01 8:11 [PATCH 0/7] remoteproc: additional virtio support Ohad Ben-Cohen
2012-03-01 8:11 ` [PATCH 1/7] remoteproc: resource table overhaul Ohad Ben-Cohen
2012-03-16 14:57 ` Michal Simek
2012-03-17 6:39 ` Ohad Ben-Cohen
2012-03-19 7:07 ` Michal Simek
2012-05-17 18:45 ` Ohad Ben-Cohen
2012-05-21 13:02 ` Michal Simek
2012-05-21 14:00 ` Ohad Ben-Cohen
2012-05-22 5:51 ` Michal Simek
2012-05-22 8:02 ` Ohad Ben-Cohen
2012-05-22 8:18 ` Michal Simek
2012-05-22 9:14 ` frq09524 [this message]
2012-05-22 9:22 ` Ohad Ben-Cohen
2012-05-22 12:51 ` frq09524
2012-05-23 12:41 ` Ohad Ben-Cohen
2012-03-01 8:11 ` [PATCH 2/7] remoteproc: remoteproc_rpmsg -> remoteproc_virtio Ohad Ben-Cohen
2012-03-01 8:11 ` [PATCH 3/7] remoteproc: safer boot/shutdown order Ohad Ben-Cohen
2012-03-01 8:11 ` [PATCH 4/7] remoteproc: remove the single rpmsg vdev limitation Ohad Ben-Cohen
2012-03-01 8:11 ` [PATCH 5/7] remoteproc/omap: remove the mbox_callback limitation Ohad Ben-Cohen
2012-03-01 8:11 ` [PATCH 6/7] remoteproc: remove the hardcoded vring alignment Ohad Ben-Cohen
2012-03-01 8:11 ` [PATCH 7/7] remoteproc: cleanup resource table parsing paths Ohad Ben-Cohen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FBB5908.4010505@stericsson.com \
--to=ludovic.barre@stericsson$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox