From: Paul Walmsley <paul@pwsan.com> To: Suman Anna <s-anna@ti.com> Cc: Kevin Hilman <khilman@linaro.org>, Russ Dill <russ.dill@gmail.com>, Santosh Shilimkar <santosh.shilimkar@ti.com>, Ohad Ben-Cohen <ohad@wizery.com>, Dave Gerlach <d-gerlach@ti.com>, Tony Lindgren <tony@atomide.com>, Vaibhav Bedia <vaibhav.bedia@ti.com>, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCHv3 2/9] ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs Date: Tue, 20 Aug 2013 23:39:25 +0000 (UTC) [thread overview] Message-ID: <alpine.DEB.2.02.1308202317490.6426@utopia.booyaka.com> (raw) In-Reply-To: <520BBDF6.1070103@ti.com> Hi a few comments On Wed, 14 Aug 2013, Suman Anna wrote: > The remoteproc infrastructure is currently tied closely with the > virtio/rpmsg framework, and the boot requires that there are virtio > devices present in the resource table from the firmware image. Using static channels is something that can be added to the existing code, if you don't want to use dynamic channels. > The rpmsg shared memory buffers are currently kinda fixed (512 buffers > of 512 bytes each) and requires 3 pages just for the vring structures > for this many buffers. So, if there are restrictions on DDR access, then > this pretty much rules out remoteproc/rpmsg infrastructure. It should be possible to patch that code to vary the size and count of the memory buffers, based on the remote processor. So no direct DDR access should be required - for that reason, anyway. > If the DDR access is ok, then there are other challenges that needs to > be met. The current firmware definitely requires the addition of the > resource table and the lower level code for handling the virtio_ring > transport for receiving messages. It would also need its own remoteproc > driver for handling the firmware binary format Hmm, could you explain this further? Are you just referring to the process of parsing out the dynamic channel data during initialization? > and the signalling required to trigger the rpmsg buffer processing. The > firmware binary format needs to be adapted to something that this driver > would understand. It definitely doesn't look like ELF currently, so > something on the lines of ste_modem_rproc needs to be done. Or just use ELF or static channels. > Also, the remoteproc/rpmsg infrastructure can support multiple vring > transport channels between the processor, and depending on how many are > supported, we either need to exchange the vq_id (like OMAP remoteproc), > or process the known virtqueues always (like DA8xx remoteproc). The > former requires that a message payload is used, and mandates the usage > of the IPC data registers in the control module given that WkupM3 on > AM335 cannot access any mailbox registers. Any usage of IPC data > registers depends on where we do it. If all the accesses were to be done > within mach-omap2/control.c, then there is no easy way for using this > API from drivers/remoteproc, until we have the control module driver. Yep, real SCM drivers have been needed for some time now, for pretty much all of the OMAP SoCs. It should be pretty easy to prototype for your purposes, though. > The current communication uses the IPC data registers, and sometimes > uses them as plain status registers. There's certain registers used for > sharing status, version etc which are shared by both the processors. > Using rpmsg would require communicating every single message, and if > there were to be some shared variables to be used simultaneously, then > this has to be exchanged through a new remoteproc resource type. I don't quite understand this last part - "shared variables to be used simultaneously". How does the existing code synchronize them? > One additional aspect is that the current remoteproc core does not have > the necessary runtime pm support, but in general the approach would be > to treat the remoteprocs as true slave devices. I would imagine the > driver core to put the remoteprocs into reset state, after asking them > to save their context during suspend. Why is runtime PM support needed in the remoteproc core? Wouldn't that only be needed in the remote processor's device driver? - Paul
WARNING: multiple messages have this Message-ID (diff)
From: paul@pwsan.com (Paul Walmsley) To: linux-arm-kernel@lists.infradead.org Subject: [PATCHv3 2/9] ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs Date: Tue, 20 Aug 2013 23:39:25 +0000 (UTC) [thread overview] Message-ID: <alpine.DEB.2.02.1308202317490.6426@utopia.booyaka.com> (raw) In-Reply-To: <520BBDF6.1070103@ti.com> Hi a few comments On Wed, 14 Aug 2013, Suman Anna wrote: > The remoteproc infrastructure is currently tied closely with the > virtio/rpmsg framework, and the boot requires that there are virtio > devices present in the resource table from the firmware image. Using static channels is something that can be added to the existing code, if you don't want to use dynamic channels. > The rpmsg shared memory buffers are currently kinda fixed (512 buffers > of 512 bytes each) and requires 3 pages just for the vring structures > for this many buffers. So, if there are restrictions on DDR access, then > this pretty much rules out remoteproc/rpmsg infrastructure. It should be possible to patch that code to vary the size and count of the memory buffers, based on the remote processor. So no direct DDR access should be required - for that reason, anyway. > If the DDR access is ok, then there are other challenges that needs to > be met. The current firmware definitely requires the addition of the > resource table and the lower level code for handling the virtio_ring > transport for receiving messages. It would also need its own remoteproc > driver for handling the firmware binary format Hmm, could you explain this further? Are you just referring to the process of parsing out the dynamic channel data during initialization? > and the signalling required to trigger the rpmsg buffer processing. The > firmware binary format needs to be adapted to something that this driver > would understand. It definitely doesn't look like ELF currently, so > something on the lines of ste_modem_rproc needs to be done. Or just use ELF or static channels. > Also, the remoteproc/rpmsg infrastructure can support multiple vring > transport channels between the processor, and depending on how many are > supported, we either need to exchange the vq_id (like OMAP remoteproc), > or process the known virtqueues always (like DA8xx remoteproc). The > former requires that a message payload is used, and mandates the usage > of the IPC data registers in the control module given that WkupM3 on > AM335 cannot access any mailbox registers. Any usage of IPC data > registers depends on where we do it. If all the accesses were to be done > within mach-omap2/control.c, then there is no easy way for using this > API from drivers/remoteproc, until we have the control module driver. Yep, real SCM drivers have been needed for some time now, for pretty much all of the OMAP SoCs. It should be pretty easy to prototype for your purposes, though. > The current communication uses the IPC data registers, and sometimes > uses them as plain status registers. There's certain registers used for > sharing status, version etc which are shared by both the processors. > Using rpmsg would require communicating every single message, and if > there were to be some shared variables to be used simultaneously, then > this has to be exchanged through a new remoteproc resource type. I don't quite understand this last part - "shared variables to be used simultaneously". How does the existing code synchronize them? > One additional aspect is that the current remoteproc core does not have > the necessary runtime pm support, but in general the approach would be > to treat the remoteprocs as true slave devices. I would imagine the > driver core to put the remoteprocs into reset state, after asking them > to save their context during suspend. Why is runtime PM support needed in the remoteproc core? Wouldn't that only be needed in the remote processor's device driver? - Paul
next prev parent reply other threads:[~2013-08-20 23:39 UTC|newest] Thread overview: 212+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-08-06 17:49 [PATCHv3 0/9] ARM: OMAP2+: AM33XX: Add suspend-resume support Dave Gerlach 2013-08-06 17:49 ` Dave Gerlach 2013-08-06 17:49 ` [PATCHv3 1/9] memory: emif: Move EMIF register defines to include/linux/ Dave Gerlach 2013-08-06 17:49 ` Dave Gerlach 2013-08-08 0:48 ` Russ Dill 2013-08-08 0:48 ` Russ Dill 2013-08-08 13:35 ` Santosh Shilimkar 2013-08-08 13:35 ` Santosh Shilimkar 2013-08-12 19:32 ` Greg Kroah-Hartman 2013-08-12 19:32 ` Greg Kroah-Hartman 2013-08-12 19:33 ` Santosh Shilimkar 2013-08-12 19:33 ` Santosh Shilimkar 2013-08-06 17:49 ` [PATCHv3 2/9] ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs Dave Gerlach 2013-08-06 17:49 ` Dave Gerlach 2013-08-08 0:52 ` Russ Dill 2013-08-08 0:52 ` Russ Dill 2013-08-08 13:44 ` Santosh Shilimkar 2013-08-08 13:44 ` Santosh Shilimkar 2013-08-08 16:16 ` Dave Gerlach 2013-08-08 16:16 ` Dave Gerlach 2013-08-09 5:11 ` Tony Lindgren 2013-08-09 5:11 ` Tony Lindgren 2013-08-09 20:55 ` Dave Gerlach 2013-08-09 20:55 ` Dave Gerlach 2013-08-12 7:54 ` Tony Lindgren 2013-08-12 7:54 ` Tony Lindgren 2013-08-12 19:17 ` Kevin Hilman 2013-08-12 19:17 ` Kevin Hilman 2013-08-12 21:40 ` Dave Gerlach 2013-08-12 21:40 ` Dave Gerlach 2013-08-13 14:29 ` Kevin Hilman 2013-08-13 14:29 ` Kevin Hilman 2013-08-13 15:08 ` Santosh Shilimkar 2013-08-13 15:08 ` Santosh Shilimkar 2013-08-13 16:19 ` Kevin Hilman 2013-08-13 16:19 ` Kevin Hilman 2013-08-13 18:18 ` Santosh Shilimkar 2013-08-13 18:18 ` Santosh Shilimkar 2013-08-13 18:30 ` Russ Dill 2013-08-13 18:30 ` Russ Dill 2013-08-13 18:40 ` Santosh Shilimkar 2013-08-13 18:40 ` Santosh Shilimkar 2013-08-13 19:11 ` Kevin Hilman 2013-08-13 19:11 ` Kevin Hilman 2013-08-14 17:27 ` Suman Anna 2013-08-14 17:27 ` Suman Anna 2013-08-14 19:16 ` Russ Dill 2013-08-14 19:16 ` Russ Dill 2013-08-20 23:39 ` Paul Walmsley [this message] 2013-08-20 23:39 ` Paul Walmsley 2013-08-21 17:32 ` Suman Anna 2013-08-21 17:32 ` Suman Anna 2013-08-06 17:49 ` [PATCHv3 3/9] ARM: OMAP: DTB: Update IRQ data for WKUP_M3 Dave Gerlach 2013-08-06 17:49 ` Dave Gerlach 2013-08-08 0:53 ` Russ Dill 2013-08-08 0:53 ` Russ Dill 2013-08-08 13:46 ` Santosh Shilimkar 2013-08-08 13:46 ` Santosh Shilimkar 2013-08-06 17:49 ` [PATCHv3 4/9] ARM: OMAP2+: AM33XX: Reserve memory to comply with EMIF spec Dave Gerlach 2013-08-06 17:49 ` Dave Gerlach 2013-08-08 2:30 ` Russ Dill 2013-08-08 2:30 ` Russ Dill 2013-08-08 14:19 ` Santosh Shilimkar 2013-08-08 14:19 ` Santosh Shilimkar 2013-08-08 18:16 ` Kevin Hilman 2013-08-08 18:16 ` Kevin Hilman 2013-08-08 19:31 ` Santosh Shilimkar 2013-08-08 19:31 ` Santosh Shilimkar 2013-08-08 20:05 ` Kevin Hilman 2013-08-08 20:05 ` Kevin Hilman 2013-08-08 20:11 ` Santosh Shilimkar 2013-08-08 20:11 ` Santosh Shilimkar 2013-08-09 15:11 ` Kevin Hilman 2013-08-09 15:11 ` Kevin Hilman 2013-08-09 16:25 ` Dave Gerlach 2013-08-09 16:25 ` Dave Gerlach 2013-08-06 17:49 ` [PATCHv3 5/9] ARM: OMAP2+: AM33XX: Add assembly code for PM operations Dave Gerlach 2013-08-06 17:49 ` Dave Gerlach 2013-08-08 7:02 ` Russ Dill 2013-08-08 7:02 ` Russ Dill 2013-08-08 14:50 ` Santosh Shilimkar 2013-08-08 14:50 ` Santosh Shilimkar 2013-08-08 15:16 ` Russ Dill 2013-08-08 15:16 ` Russ Dill 2013-08-08 15:22 ` Santosh Shilimkar 2013-08-08 15:22 ` Santosh Shilimkar 2013-08-08 16:03 ` Russ Dill 2013-08-08 16:03 ` Russ Dill 2013-08-19 12:54 ` Gururaja Hebbar 2013-08-19 12:54 ` Gururaja Hebbar 2013-08-19 17:51 ` Dave Gerlach 2013-08-19 17:51 ` Dave Gerlach 2013-08-06 17:49 ` [PATCHv3 6/9] ARM: OMAP2+: timer: Add suspend-resume callbacks for clkevent device Dave Gerlach 2013-08-06 17:49 ` Dave Gerlach 2013-08-08 7:03 ` Russ Dill 2013-08-08 7:03 ` Russ Dill 2013-08-08 14:23 ` Santosh Shilimkar 2013-08-08 14:23 ` Santosh Shilimkar 2013-08-08 16:09 ` Dave Gerlach 2013-08-08 16:09 ` Dave Gerlach 2013-08-08 18:25 ` Kevin Hilman 2013-08-08 18:25 ` Kevin Hilman 2013-08-08 19:49 ` Dave Gerlach 2013-08-08 19:49 ` Dave Gerlach 2013-08-06 17:49 ` [PATCHv3 7/9] ARM: OMAP: omap_device: Add APIs to enable and idle hwmods Dave Gerlach 2013-08-06 17:49 ` Dave Gerlach 2013-08-08 7:05 ` Russ Dill 2013-08-08 7:05 ` Russ Dill 2013-08-08 14:26 ` Santosh Shilimkar 2013-08-08 14:26 ` Santosh Shilimkar 2013-08-06 17:49 ` [PATCHv3 8/9] ARM: OMAP2+: AM33XX: Basic suspend resume support Dave Gerlach 2013-08-06 17:49 ` Dave Gerlach 2013-08-07 16:22 ` Nishanth Menon 2013-08-07 16:22 ` Nishanth Menon 2013-08-07 18:12 ` Dave Gerlach 2013-08-07 18:12 ` Dave Gerlach 2013-08-07 19:16 ` Nishanth Menon 2013-08-07 19:16 ` Nishanth Menon 2013-08-08 8:45 ` Russ Dill 2013-08-08 8:45 ` Russ Dill 2013-08-08 12:26 ` Nishanth Menon 2013-08-08 12:26 ` Nishanth Menon 2013-08-08 15:03 ` Santosh Shilimkar 2013-08-08 15:03 ` Santosh Shilimkar 2013-08-08 16:06 ` Dave Gerlach 2013-08-08 16:06 ` Dave Gerlach 2013-08-08 16:22 ` Nishanth Menon 2013-08-08 16:22 ` Nishanth Menon 2013-08-08 21:14 ` Kevin Hilman 2013-08-08 21:14 ` Kevin Hilman 2013-08-08 21:32 ` Nishanth Menon 2013-08-08 21:32 ` Nishanth Menon 2013-08-08 23:04 ` Kevin Hilman 2013-08-08 23:04 ` Kevin Hilman 2013-08-09 15:11 ` Nishanth Menon 2013-08-09 15:11 ` Nishanth Menon 2013-08-09 16:12 ` Kevin Hilman 2013-08-09 16:12 ` Kevin Hilman 2013-08-09 16:36 ` Nishanth Menon 2013-08-09 16:36 ` Nishanth Menon 2013-08-09 20:34 ` Kevin Hilman 2013-08-09 20:34 ` Kevin Hilman 2013-08-09 21:35 ` Nishanth Menon 2013-08-09 21:35 ` Nishanth Menon 2013-08-09 22:28 ` Russ Dill 2013-08-09 22:28 ` Russ Dill 2013-08-12 16:09 ` Kevin Hilman 2013-08-12 16:09 ` Kevin Hilman 2013-08-30 17:29 ` Vaibhav Bedia 2013-08-30 17:29 ` Vaibhav Bedia 2013-08-20 22:48 ` Paul Walmsley 2013-08-20 22:48 ` Paul Walmsley 2013-08-23 14:56 ` Dave Gerlach 2013-08-23 14:56 ` Dave Gerlach 2013-08-13 7:43 ` Russ Dill 2013-08-13 7:43 ` Russ Dill 2013-08-13 14:59 ` Kevin Hilman 2013-08-13 14:59 ` Kevin Hilman 2013-08-27 21:45 ` Kevin Hilman 2013-08-27 21:45 ` Kevin Hilman 2013-08-29 21:41 ` Dave Gerlach 2013-08-29 21:41 ` Dave Gerlach 2013-08-29 22:02 ` Kevin Hilman 2013-08-29 22:02 ` Kevin Hilman 2013-08-30 17:39 ` Vaibhav Bedia 2013-08-30 17:39 ` Vaibhav Bedia 2013-08-30 21:18 ` Kevin Hilman 2013-08-30 21:18 ` Kevin Hilman 2013-08-06 17:49 ` [PATCHv3 9/9] ARM: OMAP2+: AM33XX: Hookup AM33XX PM code into OMAP builds Dave Gerlach 2013-08-06 17:49 ` Dave Gerlach 2013-08-08 8:47 ` Russ Dill 2013-08-08 8:47 ` Russ Dill 2013-08-08 14:53 ` Santosh Shilimkar 2013-08-08 14:53 ` Santosh Shilimkar 2013-08-08 13:31 ` [PATCHv3 0/9] ARM: OMAP2+: AM33XX: Add suspend-resume support Santosh Shilimkar 2013-08-08 13:31 ` Santosh Shilimkar 2013-08-11 11:53 ` Daniel Mack 2013-08-11 11:53 ` Daniel Mack 2013-08-12 18:59 ` Dave Gerlach 2013-08-12 18:59 ` Dave Gerlach 2013-08-13 12:39 ` Daniel Mack 2013-08-13 12:39 ` Daniel Mack 2013-08-13 15:33 ` Dave Gerlach 2013-08-13 15:33 ` Dave Gerlach 2013-08-13 15:51 ` Daniel Mack 2013-08-13 15:51 ` Daniel Mack 2013-08-19 9:23 ` Gururaja Hebbar 2013-08-19 9:23 ` Gururaja Hebbar 2013-08-19 17:47 ` Dave Gerlach 2013-08-19 17:47 ` Dave Gerlach 2013-08-27 20:23 ` Kevin Hilman 2013-08-27 20:23 ` Kevin Hilman 2013-08-29 21:30 ` Dave Gerlach 2013-08-29 21:30 ` Dave Gerlach 2013-08-29 21:52 ` Kevin Hilman 2013-08-29 21:52 ` Kevin Hilman 2013-08-29 22:20 ` Dave Gerlach 2013-08-29 22:20 ` Dave Gerlach 2013-08-29 22:20 ` Kevin Hilman 2013-08-29 22:20 ` Kevin Hilman 2013-08-29 22:43 ` Russ Dill 2013-08-29 22:43 ` Russ Dill 2013-08-29 23:02 ` Kevin Hilman 2013-08-29 23:02 ` Kevin Hilman 2013-09-03 17:24 ` Dave Gerlach 2013-09-03 17:24 ` Dave Gerlach 2013-09-04 15:01 ` Kevin Hilman 2013-09-04 15:01 ` Kevin Hilman 2013-09-04 15:12 ` Russ Dill 2013-09-04 15:12 ` Russ Dill 2013-09-04 15:18 ` Kevin Hilman 2013-09-04 15:18 ` Kevin Hilman
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=alpine.DEB.2.02.1308202317490.6426@utopia.booyaka.com \ --to=paul@pwsan.com \ --cc=d-gerlach@ti.com \ --cc=khilman@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-omap@vger.kernel.org \ --cc=ohad@wizery.com \ --cc=russ.dill@gmail.com \ --cc=s-anna@ti.com \ --cc=santosh.shilimkar@ti.com \ --cc=tony@atomide.com \ --cc=vaibhav.bedia@ti.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.