Anyway, who knows. Maybe in the future remoteproc will evolve into something better than uio_pruss. But I can not help but feeling that a lot of time and effort us being wasted on something, where that effort could instead be put into improving uio_pruss. We do not need userspace interrupts other that how they're already implemented ( through /proc/interrupts, and /proc/irq ). But if we did somehow have userspace interrupts in relation to the PRU's. It would slow things down considerably. Which is why it is generally a bad idea to have userspace interrupts, as such, to begin with.
On Thu, Jun 16, 2016 at 9:54 AM, William Hermans <[email protected]> wrote: > I voiced all these concerns and more months ago and apparently my concerns > fell on deaf ears. > > remoteproc is a really cool concept. But it's not meant for this board, > despite people trying to use a shoehorn to get the beaglebone 'horned in'. > We already have uio_pruss, and it has worked great for how many years now ? > *AND* how does remoteproc make things better in comparison to uio_pruss ? > As far as I can see, it doesn't. It does not make things any easier, and > its all the things TJF mentions above, and more( in the negative ). > > Where remoteproc *would* shine, is on a system without additional on die > computational cores( IPU, PRU, DSP, etc ), but a multi-core applications > processor. So that one core can run an OS, while the other runs bare metal. > *THAT* is the vision I see for remoteproc. > > On Wed, Jun 15, 2016 at 8:53 PM, TJF <[email protected]> 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 >> --- >> 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 [email protected]. >> 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. >> > > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORoDogei37WtJx20hXDnYRkMw61Rp%2BY3DO7r%2BY8pwy-gEw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
