> > 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 <[email protected]> wrote: > Doesn't it "discover" devices by looking at the device tree? > > > On Jun 25, 2016, at 18:32 , John Syne <[email protected]> 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 <[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/B5C4860B-52F9-485A-B268-65674695A127%40gmail.com > . > > For more options, visit https://groups.google.com/d/optout. > > > -- > 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/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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORqc-%3D908LdaEq3MMVZiCZTfYwLO81WQba-r%2BA3FXW4e%2Bg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
