On Sat, 25 Jun 2016 18:32:51 -0700, you wrote: >Think about what you are proposing. When the kernel loads, it discovers >devices and then loads the appropriate drivers. Now what happens when it >discovers the PRU, which driver does it load, PRUSS_UIO or RemoteProc?
Why not give it a configuration choice? Both modules can be optional, load or not load only one. Develop your application to match. You already do this with the pin overlays/pin mux. Can you decouple it from the main program/OS and then have resources that you need? Harvey > >Regards, >John > > > > >> On Jun 25, 2016, at 6:11 PM, Rick Mann <[email protected]> wrote: >> >>> >>> On Jun 25, 2016, at 14:44 , John Syne <[email protected]> wrote: >>> >>>> On Jun 25, 2016, at 2:20 PM, Rick Mann <[email protected]> wrote: >>>> >>>> >>>>> On Jun 25, 2016, at 12:56 , John Syne <[email protected]> wrote: >>>> >>>>>> On Jun 25, 2016, at 11:56 AM, Jason Kridner <[email protected]> >>>>>> wrote: >>>>>> >>>>>> I will work to enable uio_pruss functionality, and I think that is what >>>>>> you want, not just getting remoteproc out. >>>>> >>>>> Please don’t do that. Robert Nelson has the “bone” kernel for this >>>>> purpose which supports pruss_uio by default and does not have >>>>> RemoteProc/RPMSG installed. The “ti” kernel however does the reverse, >>>>> with the RemoteProc/RPMSG installed by default and pruss_uio no >>>>> installed. I believe the two frameworks conflict so it is not possible to >>>>> have both installed. >>>> >>>> It sure seems to me that if both can exist in the source tree and be >>>> selected at runtime with configuration (ideally via device tree, >>>> switchable later by loading and unloading modules), that would be the >>>> ideal solution. It sounds like John is saying this is technically not >>>> possible, but I feel like it should be (it is just code, after all). >>> If you read the discussion, TJF and William don’t want to build a custom >>> kernel. So since you cannot have pruss_uio and RemoteProc/RPMSG, configured >>> simultaneously, this is the dilemma we are facing. Currently Robert Nelson >>> has configured the “bone” kernel to have pruss_uio dn the “ti” kernel to >>> have RemoteProc/RPMSG. William is concerned that the “ti” kernel has more >>> features than the “bone” kernel. Solution is to ask Robert Nelson to add >>> the missing features to the “bone” kernel. >> >> I'm not sure specifically what's preventing the two from being configured >> simultaneously, so long as both their code doesn't execute simultaneously. >> It seems one or the other or both can be modified to coexist in the >> configuration, and that may be the best way to ensure the kernel supports >> all users. >> >> We have the source, it should be possible. The kernel can support multiple >> ethernet drivers configured simultaneously, why not multiple PRU drivers? >> >> -- >> Rick Mann >> [email protected] >> >> >> -- >> 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/19C6420A-AF09-4542-B907-AD54429E56B4%40latencyzero.com. >> 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/r2eumbpmal4tma0q3or5rp3q82dkg9d801%404ax.com. For more options, visit https://groups.google.com/d/optout.
