Well, I’m assuming everyone is using the term Remoteproc to refer to the whole echo system because Remoteproc KM doesn’t do anything more than power on, load the code on the PRU, start the code and power off. It doesn’t handle any communications between the PRU and ARM processors. It is Virtio/RPMSG that handle the communications between Linux and PRU.
http://software-dl.ti.com/public/hpmp/sitara/sitara_pru_building_blocks_module_4.pdf <http://software-dl.ti.com/public/hpmp/sitara/sitara_pru_building_blocks_module_4.pdf> Regards, John > On Jun 16, 2016, at 3:25 AM, Jason Kridner <jason.krid...@hangerhead.com> > wrote: > > Thanks John. Remoteproc wasn't derived in a vacuum. Every approach provides > trade-offs. The constant uninformed assertion that everything is faster if > handled by userspace reflects on the struggles we've had to communicate the > value of working in the kernel process. > > I'd like to see a better way of maintaining both, that is to turn the > registers back over to userspace, disabling the kernel driver other than UIO. > I need to work on articulating that desire. > > As to the claim that remoteproc is slower---given that the kernel owns the > interrupts, I don't see how userspace can service them faster. Examples like > BeagleLogic show that remoteproc can be quite fast. The high speed > communication between the PRUs and the rest of the system, coupled with their > high-speed interface to the external world, are what make them so valuable. > Defining some common effective ways of communicating using kernel drivers > would seem to make it much simpler for people to develop code quickly. > > Anyway, we should spend some time with this repo making sure both driver > mechanisms are supported and their values articulated. Simply ignoring the > remoteproc interface supported in the mainline kernel doesn't make sense to > me. > On Thu, Jun 16, 2016 at 2:20 AM John Syne <john3...@gmail.com > <mailto:john3...@gmail.com>> wrote: > One other thing, if you don’t like some features of RPMSG/REMOTEPROC, then > why not provide input to the developers with any suggestions you think will > make things better? I have spoken to Jason Reeder and Suman Anna several > times and they have been very responsive to my input. > > Regards, > John > > > > > >> On Jun 15, 2016, at 8:53 PM, TJF <jeli.freih...@gmail.com >> <mailto:jeli.freih...@gmail.com>> wrote: >> > >> >> >> Am Mittwoch, 15. Juni 2016 23:47:11 UTC+2 schrieb Jason Kridner: >> How is it nonsense? >> >> There's no realistic concept up to now. Significant changes every now and >> then, like the one documented here. >> >> Some developers may see some advantages anytime in the future, at least if >> they use the matching compiler. But currently, from my (and the users) point >> of view, remoteproc has less features, is slower, and takes more kernel >> memory than the prussdrv solution. In short: experimental, not ready for >> productive code. Regretfully I think about every minute I spent in learning >> and testing yet. >> >> -- >> For more options, visit http://beagleboard.org/discuss >> <http://beagleboard.org/discuss> >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to beagleboard+unsubscr...@googlegroups.com >> <mailto:beagleboard+unsubscr...@googlegroups.com>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/beagleboard/bc2d2003-6593-4759-99ca-2b7a95b8d33f%40googlegroups.com >> >> <https://groups.google.com/d/msgid/beagleboard/bc2d2003-6593-4759-99ca-2b7a95b8d33f%40googlegroups.com?utm_medium=email&utm_source=footer>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > For more options, visit http://beagleboard.org/discuss > <http://beagleboard.org/discuss> > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to beagleboard+unsubscr...@googlegroups.com > <mailto:beagleboard+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/F78DF15C-A7CF-4AC5-82DE-604CE7F74E75%40gmail.com > > <https://groups.google.com/d/msgid/beagleboard/F78DF15C-A7CF-4AC5-82DE-604CE7F74E75%40gmail.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > -- > For more options, visit http://beagleboard.org/discuss > <http://beagleboard.org/discuss> > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to beagleboard+unsubscr...@googlegroups.com > <mailto:beagleboard+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPmqZkBh5%3DNxHU75UZLtWWL83JOVoBmdi4P5cNCLnwsjGA%40mail.gmail.com > > <https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPmqZkBh5%3DNxHU75UZLtWWL83JOVoBmdi4P5cNCLnwsjGA%40mail.gmail.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/3AB1F063-E436-4951-84C8-EFF53EBFFAE1%40gmail.com. For more options, visit https://groups.google.com/d/optout.
