On Thu, Jul 10, 2014 at 12:11 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Thu, Jul 10, 2014 at 08:54:18AM +0300, Ivaylo Dimitrov wrote: > > > > > > On 9.07.2014 10:07, Tony Lindgren wrote: > > >* Suman Anna <s-anna@xxxxxx> [140708 11:40]: > > >>Hi Peter, > > >> > > >>On 07/08/2014 09:36 AM, Greg KH wrote: > > >>>On Tue, Jul 08, 2014 at 03:03:58PM +0200, Peter Meerwald wrote: > > >>>>Hello, > > >>>> > > >>>>>>Given the total lack of response here, I suggest just deleting the > > >>>>>>driver. No one has ever done the "real work" that is going to be > > >>>>>>required to get this code out of staging. It has had build errors > > >>>>>>causing it to not even be usable for some kernel versions with no one > > >>>>>>noticing, so I doubt anyone cares about it anymore here. > > >>>>> > > >>>>>Cc'ing some more people who might be interested. If no one offers to > > >>>>>work on the driver in the next couple of days, I'll send a patch to > > >>>>>remove it. > > >>>> > > >>>>I'm using the driver (with kernel 3.7) and it works reasonably well for > > >>>>me; removing it seems a bit harsh. > > >>> > > >>>Using it is different from being able to maintain the code and move it > > >>>out of the staging tree. Also, 3.7 is really old and obsolete, not much > > >>>we can do with that kernel version :) > > >>> > > >>>Are you able to work on the code and do the effort needed to get it out > > >>>of the staging tree? If so, great, if not, we are going to have to > > >>>delete it, sorry. > > >> > > >>I agree with Greg here. In fact, the current TODO does not do enough > > >>justice to the amount of work required to make it even work on the > > >>latest kernel. Most of the TIers who worked on this driver have moved on > > >>as Kristina would have figured with her bounced emails. So I do suggest > > >>that this driver be deleted from the kernel tree. If there are enough > > >>number of folks using it (not sure how many are out there), it can be > > >>worked on out-of-tree and brought back in a cleaner fashion rather than > > >>keeping a broken stale driver in the kernel. > > > > > >I agree, not much has improved with this driver since it got added into > > >staging except just compile fixes. > > > > > >Regards, > > > > > >Tony > > > > Well, recently I've sent a couple of patches which implement stuff from TODO > > [1]. However, with the migration to DT, my focus now is to have a > > kernel/userspace that boots at all and this leaves no free cycles for DSP. > > Maybe tidspbridge can be left in staging until DT migration is finished, > > that way me (and maybe other people) will have the time needed to try to > > implement what remains in TODO. Also, keep in mind there will (hopefully) be > > another omap3 end-user device released by the end of the year (Neo900), > > which most probably will gain more developers interested in fixing the DSP > > driver. > > I'm really tired of people saying, "maybe sometime in the future we will > work on this" for this driver. It's not the first time I've heard it, > and it has _never_ come true. Honestly, I really don't believe it will > ever happen, given that TI doesn't care about this code at all. > > If in the future, someone does want to work on this, a simple revert of > the patch that removes the driver will be all that is needed. Let's do > that instead of hoping that sometime, someone, somewhere, will do this > work. Makes sense to me. FYI, it will come back again on newer TI ARM+DSP devices. Those aren't going away, but I'm also not aware of anyone imminently pushing patches. > > thanks, > > greg k-h > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
