Anybody working on tidspbridge?
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 13 lines · Greg KH
Quoted 12 lines · Kristina Martšenko
Quoted 10 lines · Kristina Martšenko
Hi Omar,
I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving tidspbridge out of staging in over a year. Are there any plans to clean it up and move it out soon? Because otherwise we're going to have to delete the driver, as we don't want staging to become a permanent place for unfinished code.
Thanks,
Kristina
Quoted 8 lines
Quoted 2 lines
Omar's email address in tidspbridge's TODO file seems to be outdated. Resending to more recent addresses which hopefully won't bounce.
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.
Kristina
Hello,
Quoted 9 lines
Quoted 5 lines
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
regards, p.
Signature · 2 lines
Peter Meerwald +43-664-2444418 (mobile)
Quoted 8 lines · Peter Meerwald
Hello,
Quoted 6 lines
Quoted 5 lines
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.
Quoted 6 lines
Quoted 3 lines
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.
greg k-h
Hi Peter,
Quoted 16 lines · Greg KH
Quoted 8 lines · Peter Meerwald
Hello,
Quoted 6 lines
Quoted 5 lines
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 7 lines
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.
regards
Suman
Quoted 27 lines · Suman Anna
Hi Peter,
Quoted 16 lines · Greg KH
Quoted 8 lines · Peter Meerwald
Hello,
Quoted 6 lines
Quoted 5 lines
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 7 lines
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.
Quoted 8 lines
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
Quoted 37 lines · Tony Lindgren
Quoted 27 lines · Suman Anna
Hi Peter,
Quoted 16 lines · Greg KH
Quoted 8 lines · Peter Meerwald
Hello,
Quoted 6 lines
Quoted 5 lines
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 7 lines
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.
Quoted 8 lines
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.
Quoted 6 lines
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.
Regards,
Ivo
[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/staging/tidspbridge?id=559c71fe5dc3bf2ecc55afb336145db7f0abf810
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/staging/tidspbridge?id=a3b22220a48bd14c9ba4ca8d051b0c92d5bc3866
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/staging/tidspbridge?id=d30555853052bbec8497260ba888b7d696bed9b8
Quoted 47 lines · Ivaylo Dimitrov
Quoted 37 lines · Tony Lindgren
Quoted 27 lines · Suman Anna
Hi Peter,
Quoted 16 lines · Greg KH
Quoted 8 lines · Peter Meerwald
Hello,
Quoted 6 lines
Quoted 5 lines
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 7 lines
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.
Quoted 8 lines
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.
Quoted 6 lines
I agree, not much has improved with this driver since it got added into staging except just compile fixes.
Regards,
Tony
Quoted 9 lines
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.
thanks,
greg k-h
Quoted 64 lines · Greg KH
Quoted 47 lines · Ivaylo Dimitrov
Quoted 37 lines · Tony Lindgren
Quoted 27 lines · Suman Anna
Hi Peter,
Quoted 16 lines · Greg KH
Quoted 8 lines · Peter Meerwald
Hello,
Quoted 6 lines
Quoted 5 lines
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 7 lines
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.
Quoted 8 lines
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.
Quoted 6 lines
I agree, not much has improved with this driver since it got added into staging except just compile fixes.
Regards,
Tony
Quoted 9 lines
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.
Quoted 4 lines
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.
Quoted 8 lines
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html