Been, seen. It's all the same ;) On Sat, Jun 25, 2016 at 8:51 PM, William Hermans <yyrk...@gmail.com> wrote:
> Doesn't it "discover" devices by looking at the device tree? >> > > For many devices, the kernel is sort of unaware until a device tree is > loaded. Now by "unaware" I just mean that the kernel has been compiled with > that module as a loadable module ( non static ), and a "hook" has been > written into the main board file for specific modules. Which load when the > device tree "hook" status has been changed to "Okay". > > But you've probably been one or two of these yourself already. But here: > https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/uio_pruss_enable-00A0.dts#L22 > > As an example. > > On Sat, Jun 25, 2016 at 7:45 PM, Rick Mann <rm...@latencyzero.com> wrote: > >> Doesn't it "discover" devices by looking at the device tree? >> >> > On Jun 25, 2016, at 18:32 , John Syne <john3...@gmail.com> 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? >> > >> > Regards, >> > John >> > >> > >> > >> > >> >> On Jun 25, 2016, at 6:11 PM, Rick Mann <rm...@latencyzero.com> wrote: >> >> >> >>> >> >>> On Jun 25, 2016, at 14:44 , John Syne <john3...@gmail.com> wrote: >> >>> >> >>>> On Jun 25, 2016, at 2:20 PM, Rick Mann <rm...@latencyzero.com> >> wrote: >> >>>> >> >>>> >> >>>>> On Jun 25, 2016, at 12:56 , John Syne <john3...@gmail.com> wrote: >> >>>> >> >>>>>> On Jun 25, 2016, at 11:56 AM, Jason Kridner < >> jkrid...@beagleboard.org> 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 >> >> rm...@latencyzero.com >> >> >> >> >> >> -- >> >> 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/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 beagleboard+unsubscr...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/beagleboard/B5C4860B-52F9-485A-B268-65674695A127%40gmail.com >> . >> > For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> Rick Mann >> rm...@latencyzero.com >> >> >> -- >> 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/C7759943-C3C3-475D-97E2-A57995AABEE1%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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORo79_bbR2oojiTB8UV1UxQaEZ%3D82QrviJmK7p_7Phc97w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
