Here is a conversation I had with Robert about this issue: > From: Robert Nelson <[email protected]> > Subject: Re: uio_pruss coexist with remoteproc > Date: June 30, 2016 at 11:43:29 AM PDT > To: John Syne <[email protected]> > > Hi John, > > On Thu, Jun 30, 2016 at 12:57 PM, John Syne <[email protected]> wrote: >> Hi Robert, >> >> I’m trying to put this issue to bed. Since you had issues getting uio_pruss >> and remoteproc working together, I’m trying to understand the issue. My >> guess is that both kernel modules should build without conflict, but the DT >> has to choose one or the other. Is there a reason why we cannot move the >> PRUSS specs into a DT overlay, one for uio_pruss and one for remoteproc. > > In our weekly meeting today, we talked about it for a good 30 minutes, > even had Suman come in on the line. TI is watching that thread, and > they have even more meetings scheduled. > > What i would like to try to do, patch the uio_pruss driver so it can > use the same bindings as remoteproc (they use the same node label), > then users can either blacklist remoteproc or uio_pruss
I know this seemed like a painful process, but in the end it looks like this solution will work for everyone. Thank you everyone for your valuable input. Regards, John > On Jun 30, 2016, at 11:45 PM, TJF <[email protected]> wrote: > > Good morning John! > > Am Donnerstag, 30. Juni 2016 17:13:34 UTC+2 schrieb john3909: > Anyway, this discussion is not productive as we are not going to find a > solution if you do not want to propose solutions. Your proposed solution of > making RPMSG/RemoteProc optional isn’t a solution. However, perhaps there is > a way to move the DT PRUSS definition into an DT overlay and not include the > PRUSS definition in the base DT tree. This would allow both uio_pruss and > RemoteProc to live side by side. Perhaps this is what you should be working > on. I’m sure Robert Nelson would be open to a solution like this if you found > a way to make this work. > > Sorry, I disagree again. But this time it doesn't bother me, because your > final proposal sounds like the solution most of us are looking for. Just some > quotes: > > Jason Kridner > I will work to enable uio_pruss functionality, and I think that is what you > want, not just getting remoteproc out. > > William Herman > I do not think anyone is asking to remove remoteproc, and replace it with > uio_pruss. What we've been asking, at least I have been asking is give us > the option. > > Rick Mann > 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) ... > > TJF > I'd try to make both optional and choise in device tree when enabling the > PRUSS. > > ... > > > @All > > From my point of view, we found a common solution and John proposed a way how > to get it working, which sounds reasonable to me. Anybody contrary-minded? > Any additional statements? > > BR > > -- > 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 [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/407ecd81-8bc5-43bd-912a-ae480fb3954d%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/407ecd81-8bc5-43bd-912a-ae480fb3954d%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 --- 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/DDABD4AF-B8D3-4A8D-8566-DC058ECCD99B%40gmail.com. For more options, visit https://groups.google.com/d/optout.
