[PATCH] staging: ion: remove from the tree
The ION android code has long been marked to be removed, now that we dma-buf support merged into the real part of the kernel. It was thought that we could wait to remove the ion kernel at a later time, but as the out-of-tree Android fork of the ion code has diverged quite a bit, and any Android device using the ion interface uses that forked version and not this in-tree version, the in-tree copy of the code is abandonded and not used by anyone. Combine this abandoned codebase with the need to make changes to it in order to keep the kernel building properly, which then causes merge issues when merging those changes into the out-of-tree Android code, and you end up with two different groups of people (the in-kernel-tree developers, and the Android kernel developers) who are both annoyed at the current situation. Because of this problem, just drop the in-kernel copy of the ion code now, as it's not used, and is only causing problems for everyone involved. Cc: "Arve Hjønnevåg" Cc: "Christian König" Cc: Christian Brauner Cc: Christoph Hellwig Cc: Hridya Valsaraju Cc: Joel Fernandes Cc: John Stultz Cc: Laura Abbott Cc: Martijn Coenen Cc: Shuah Khan Cc: Sumit Semwal Cc: Suren Baghdasaryan Cc: Todd Kjos Cc: de...@driverdev.osuosl.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-...@lists.linaro.org Signed-off-by: Greg Kroah-Hartman --- MAINTAINERS | 10 - drivers/staging/android/Kconfig | 2 - drivers/staging/android/Makefile | 2 - drivers/staging/android/TODO | 5 - drivers/staging/android/ion/Kconfig | 27 - drivers/staging/android/ion/Makefile | 4 - drivers/staging/android/ion/ion.c | 649 -- drivers/staging/android/ion/ion.h | 302 drivers/staging/android/ion/ion_cma_heap.c| 138 drivers/staging/android/ion/ion_heap.c| 286 drivers/staging/android/ion/ion_page_pool.c | 155 - drivers/staging/android/ion/ion_system_heap.c | 377 -- drivers/staging/android/uapi/ion.h| 127 tools/testing/selftests/Makefile | 3 +- tools/testing/selftests/android/Makefile | 39 -- tools/testing/selftests/android/config| 5 - .../testing/selftests/android/ion/.gitignore | 4 - tools/testing/selftests/android/ion/Makefile | 20 - tools/testing/selftests/android/ion/README| 101 --- tools/testing/selftests/android/ion/ion.h | 134 .../testing/selftests/android/ion/ion_test.sh | 58 -- .../selftests/android/ion/ionapp_export.c | 127 .../selftests/android/ion/ionapp_import.c | 79 --- .../selftests/android/ion/ionmap_test.c | 136 .../testing/selftests/android/ion/ionutils.c | 253 --- .../testing/selftests/android/ion/ionutils.h | 55 -- .../testing/selftests/android/ion/ipcsocket.c | 227 -- .../testing/selftests/android/ion/ipcsocket.h | 35 - tools/testing/selftests/android/run.sh| 3 - 29 files changed, 1 insertion(+), 3362 deletions(-) delete mode 100644 drivers/staging/android/ion/Kconfig delete mode 100644 drivers/staging/android/ion/Makefile delete mode 100644 drivers/staging/android/ion/ion.c delete mode 100644 drivers/staging/android/ion/ion.h delete mode 100644 drivers/staging/android/ion/ion_cma_heap.c delete mode 100644 drivers/staging/android/ion/ion_heap.c delete mode 100644 drivers/staging/android/ion/ion_page_pool.c delete mode 100644 drivers/staging/android/ion/ion_system_heap.c delete mode 100644 drivers/staging/android/uapi/ion.h delete mode 100644 tools/testing/selftests/android/Makefile delete mode 100644 tools/testing/selftests/android/config delete mode 100644 tools/testing/selftests/android/ion/.gitignore delete mode 100644 tools/testing/selftests/android/ion/Makefile delete mode 100644 tools/testing/selftests/android/ion/README delete mode 100644 tools/testing/selftests/android/ion/ion.h delete mode 100755 tools/testing/selftests/android/ion/ion_test.sh delete mode 100644 tools/testing/selftests/android/ion/ionapp_export.c delete mode 100644 tools/testing/selftests/android/ion/ionapp_import.c delete mode 100644 tools/testing/selftests/android/ion/ionmap_test.c delete mode 100644 tools/testing/selftests/android/ion/ionutils.c delete mode 100644 tools/testing/selftests/android/ion/ionutils.h delete mode 100644 tools/testing/selftests/android/ion/ipcsocket.c delete mode 100644 tools/testing/selftests/android/ion/ipcsocket.h delete mode 100755 tools/testing/selftests/android/run.sh diff --git a/MAINTAINERS b/MAINTAINERS index 0edac88f4a84..5df6fb4403fb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1200,16 +1200,6 @@ S: Supported F: Documentation/devicetree/bindings/rtc/google,goldfish-rtc.txt F: drivers/rtc/rtc-goldfish.c -ANDROID ION DRIVER -M: Laura Abbott -M: Sumit Semwal -L: de...@driverdev.osuosl.org -L: dri-devel@li
Re: [PATCH] staging: ion: remove from the tree
On Thu, Aug 27, 2020 at 09:31:27AM -0400, Laura Abbott wrote: > On 8/27/20 8:36 AM, Greg Kroah-Hartman wrote: > > The ION android code has long been marked to be removed, now that we > > dma-buf support merged into the real part of the kernel. > > > > It was thought that we could wait to remove the ion kernel at a later > > time, but as the out-of-tree Android fork of the ion code has diverged > > quite a bit, and any Android device using the ion interface uses that > > forked version and not this in-tree version, the in-tree copy of the > > code is abandonded and not used by anyone. > > > > Combine this abandoned codebase with the need to make changes to it in > > order to keep the kernel building properly, which then causes merge > > issues when merging those changes into the out-of-tree Android code, and > > you end up with two different groups of people (the in-kernel-tree > > developers, and the Android kernel developers) who are both annoyed at > > the current situation. Because of this problem, just drop the in-kernel > > copy of the ion code now, as it's not used, and is only causing problems > > for everyone involved. > > > > Cc: "Arve Hjønnevåg" > > Cc: "Christian König" > > Cc: Christian Brauner > > Cc: Christoph Hellwig > > Cc: Hridya Valsaraju > > Cc: Joel Fernandes > > Cc: John Stultz > > Cc: Laura Abbott > > Cc: Martijn Coenen > > Cc: Shuah Khan > > Cc: Sumit Semwal > > Cc: Suren Baghdasaryan > > Cc: Todd Kjos > > Cc: de...@driverdev.osuosl.org > > Cc: dri-devel@lists.freedesktop.org > > Cc: linaro-mm-...@lists.linaro.org > > Signed-off-by: Greg Kroah-Hartman > > We discussed this at the Android MC on Monday and the plan was to > remove it after the next LTS release. As 5.10 will be the next LTS release, I have now merged it to my "testing" branch to go into 5.11-rc1. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: ion: remove from the tree
On Fri, Oct 16, 2020 at 1:29 AM Greg Kroah-Hartman wrote: > > On Thu, Aug 27, 2020 at 09:31:27AM -0400, Laura Abbott wrote: > > On 8/27/20 8:36 AM, Greg Kroah-Hartman wrote: > > > The ION android code has long been marked to be removed, now that we > > > dma-buf support merged into the real part of the kernel. > > > > > > It was thought that we could wait to remove the ion kernel at a later > > > time, but as the out-of-tree Android fork of the ion code has diverged > > > quite a bit, and any Android device using the ion interface uses that > > > forked version and not this in-tree version, the in-tree copy of the > > > code is abandonded and not used by anyone. > > > > > > Combine this abandoned codebase with the need to make changes to it in > > > order to keep the kernel building properly, which then causes merge > > > issues when merging those changes into the out-of-tree Android code, and > > > you end up with two different groups of people (the in-kernel-tree > > > developers, and the Android kernel developers) who are both annoyed at > > > the current situation. Because of this problem, just drop the in-kernel > > > copy of the ion code now, as it's not used, and is only causing problems > > > for everyone involved. > > > > > > Cc: "Arve Hjønnevåg" > > > Cc: "Christian König" > > > Cc: Christian Brauner > > > Cc: Christoph Hellwig > > > Cc: Hridya Valsaraju > > > Cc: Joel Fernandes > > > Cc: John Stultz > > > Cc: Laura Abbott > > > Cc: Martijn Coenen > > > Cc: Shuah Khan > > > Cc: Sumit Semwal > > > Cc: Suren Baghdasaryan > > > Cc: Todd Kjos > > > Cc: de...@driverdev.osuosl.org > > > Cc: dri-devel@lists.freedesktop.org > > > Cc: linaro-mm-...@lists.linaro.org > > > Signed-off-by: Greg Kroah-Hartman > > > > We discussed this at the Android MC on Monday and the plan was to > > remove it after the next LTS release. > > As 5.10 will be the next LTS release, I have now merged it to my > "testing" branch to go into 5.11-rc1. Sounds great! Thanks so much for waiting a bit on this, I really appreciate it! -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: ion: remove from the tree
On Thu, Aug 27, 2020 at 09:31:27AM -0400, Laura Abbott wrote: > On 8/27/20 8:36 AM, Greg Kroah-Hartman wrote: > > The ION android code has long been marked to be removed, now that we > > dma-buf support merged into the real part of the kernel. > > > > It was thought that we could wait to remove the ion kernel at a later > > time, but as the out-of-tree Android fork of the ion code has diverged > > quite a bit, and any Android device using the ion interface uses that > > forked version and not this in-tree version, the in-tree copy of the > > code is abandonded and not used by anyone. > > > > Combine this abandoned codebase with the need to make changes to it in > > order to keep the kernel building properly, which then causes merge > > issues when merging those changes into the out-of-tree Android code, and > > you end up with two different groups of people (the in-kernel-tree > > developers, and the Android kernel developers) who are both annoyed at > > the current situation. Because of this problem, just drop the in-kernel > > copy of the ion code now, as it's not used, and is only causing problems > > for everyone involved. > > > > Cc: "Arve Hjønnevåg" > > Cc: "Christian König" > > Cc: Christian Brauner > > Cc: Christoph Hellwig > > Cc: Hridya Valsaraju > > Cc: Joel Fernandes > > Cc: John Stultz > > Cc: Laura Abbott > > Cc: Martijn Coenen > > Cc: Shuah Khan > > Cc: Sumit Semwal > > Cc: Suren Baghdasaryan > > Cc: Todd Kjos > > Cc: de...@driverdev.osuosl.org > > Cc: dri-devel@lists.freedesktop.org > > Cc: linaro-mm-...@lists.linaro.org > > Signed-off-by: Greg Kroah-Hartman > > We discussed this at the Android MC on Monday and the plan was to > remove it after the next LTS release. I know it was discussed, my point is that it is actually causing problems now (with developers who want to change the internal kernel api hitting issues, and newbies trying to clean up code in ways that isn't exactly optimal wasting maintainer cycles), and that anyone who uses this code, is not actually using this version of the code. Everyone who relies on ion right now, is using the version that is in the Android common kernel tree, which has diverged from this in-kernel way quite a bit now for the reason that we didn't want to take any of those new features in the in-kernel version. So this is a problem that we have caused by just wanting to wait, no one is using this code, combined with it causing problems for the upstream developers. There is nothing "magic" about the last kernel of the year that requires this code to sit here until then. At that point in time, all users will, again, be using the forked Android kernel version, and if we delete this now here, that fork can remain just fine, with the added benifit of it reducing developer workloads here in-kernel. So why wait? thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: ion: remove from the tree
On Thu, Aug 27, 2020 at 10:31:41PM +0530, Amit Pundir wrote: > On Thu, 27 Aug 2020 at 21:34, Greg Kroah-Hartman > wrote: > > > > On Thu, Aug 27, 2020 at 09:31:27AM -0400, Laura Abbott wrote: > > > On 8/27/20 8:36 AM, Greg Kroah-Hartman wrote: > > > > The ION android code has long been marked to be removed, now that we > > > > dma-buf support merged into the real part of the kernel. > > > > > > > > It was thought that we could wait to remove the ion kernel at a later > > > > time, but as the out-of-tree Android fork of the ion code has diverged > > > > quite a bit, and any Android device using the ion interface uses that > > > > forked version and not this in-tree version, the in-tree copy of the > > > > code is abandonded and not used by anyone. > > > > > > > > Combine this abandoned codebase with the need to make changes to it in > > > > order to keep the kernel building properly, which then causes merge > > > > issues when merging those changes into the out-of-tree Android code, and > > > > you end up with two different groups of people (the in-kernel-tree > > > > developers, and the Android kernel developers) who are both annoyed at > > > > the current situation. Because of this problem, just drop the in-kernel > > > > copy of the ion code now, as it's not used, and is only causing problems > > > > for everyone involved. > > > > > > > > Cc: "Arve Hjønnevåg" > > > > Cc: "Christian König" > > > > Cc: Christian Brauner > > > > Cc: Christoph Hellwig > > > > Cc: Hridya Valsaraju > > > > Cc: Joel Fernandes > > > > Cc: John Stultz > > > > Cc: Laura Abbott > > > > Cc: Martijn Coenen > > > > Cc: Shuah Khan > > > > Cc: Sumit Semwal > > > > Cc: Suren Baghdasaryan > > > > Cc: Todd Kjos > > > > Cc: de...@driverdev.osuosl.org > > > > Cc: dri-devel@lists.freedesktop.org > > > > Cc: linaro-mm-...@lists.linaro.org > > > > Signed-off-by: Greg Kroah-Hartman > > > > > > We discussed this at the Android MC on Monday and the plan was to > > > remove it after the next LTS release. > > > > I know it was discussed, my point is that it is actually causing > > problems now (with developers who want to change the internal kernel api > > hitting issues, and newbies trying to clean up code in ways that isn't > > exactly optimal wasting maintainer cycles), and that anyone who uses > > this code, is not actually using this version of the code. Everyone who > > relies on ion right now, is using the version that is in the Android > > common kernel tree, which has diverged from this in-kernel way quite a > > bit now for the reason that we didn't want to take any of those new > > features in the in-kernel version. > > > > So this is a problem that we have caused by just wanting to wait, no one > > is using this code, combined with it causing problems for the upstream > > developers. > > > > There is nothing "magic" about the last kernel of the year that requires > > this code to sit here until then. At that point in time, all users > > will, again, be using the forked Android kernel version, and if we > > delete this now here, that fork can remain just fine, with the added > > benifit of it reducing developer workloads here in-kernel. > > > > So why wait? > > Hi, > > I don't know what is the right thing to do here. I just want to > highlight that AOSP's audio (codec2) HAL depends on the ION system > heap and it will break AOSP for people who boot mainline on their > devices, even for just testing purpose like we do in Linaro. Right now > we need only 1 (Android specific out-of-tree) patch to boot AOSP with > mainline and Sumit is already trying to upstream that vma naming > patch. Removal of in-kernel ION, will just add more to that delta. As AOSP will continue to rely on ION after December of this year, all you are doing is postponing the inevitable a few more months. Push back on the Android team to fix up the code to not use ION, they know this needs to happen. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: ion: remove from the tree
On Thu, Aug 27, 2020 at 10:17 AM Greg Kroah-Hartman wrote: > On Thu, Aug 27, 2020 at 10:31:41PM +0530, Amit Pundir wrote: > > I don't know what is the right thing to do here. I just want to > > highlight that AOSP's audio (codec2) HAL depends on the ION system > > heap and it will break AOSP for people who boot mainline on their > > devices, even for just testing purpose like we do in Linaro. Right now > > we need only 1 (Android specific out-of-tree) patch to boot AOSP with > > mainline and Sumit is already trying to upstream that vma naming > > patch. Removal of in-kernel ION, will just add more to that delta. > > As AOSP will continue to rely on ION after December of this year, all > you are doing is postponing the inevitable a few more months. > > Push back on the Android team to fix up the code to not use ION, they > know this needs to happen. The point though, is your main premise that no one is using this isn't true. I'm actively working with Hridya and folks on the codec2 HAL side to transition this on the userland side: https://android-review.googlesource.com/c/platform/frameworks/av/+/1368918/3 I'd like AOSP to not use ION after September (though being external I can't promise anything), much less continuing after December. I want this migration to happen as much as anyone. But I'd prefer to keep ION in staging until after the LTS is announced. Having both around helps development for the transition, which helps us have a reliable solution, which helps vendors to migrate and be able to do comparative performance testing. I do appreciate that keeping it isn't free, but I also don't feel the chaos-monkey approach here is really motivational in the way you intend. thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: ion: remove from the tree
On Thu, 27 Aug 2020 at 21:34, Greg Kroah-Hartman wrote: > > On Thu, Aug 27, 2020 at 09:31:27AM -0400, Laura Abbott wrote: > > On 8/27/20 8:36 AM, Greg Kroah-Hartman wrote: > > > The ION android code has long been marked to be removed, now that we > > > dma-buf support merged into the real part of the kernel. > > > > > > It was thought that we could wait to remove the ion kernel at a later > > > time, but as the out-of-tree Android fork of the ion code has diverged > > > quite a bit, and any Android device using the ion interface uses that > > > forked version and not this in-tree version, the in-tree copy of the > > > code is abandonded and not used by anyone. > > > > > > Combine this abandoned codebase with the need to make changes to it in > > > order to keep the kernel building properly, which then causes merge > > > issues when merging those changes into the out-of-tree Android code, and > > > you end up with two different groups of people (the in-kernel-tree > > > developers, and the Android kernel developers) who are both annoyed at > > > the current situation. Because of this problem, just drop the in-kernel > > > copy of the ion code now, as it's not used, and is only causing problems > > > for everyone involved. > > > > > > Cc: "Arve Hjønnevåg" > > > Cc: "Christian König" > > > Cc: Christian Brauner > > > Cc: Christoph Hellwig > > > Cc: Hridya Valsaraju > > > Cc: Joel Fernandes > > > Cc: John Stultz > > > Cc: Laura Abbott > > > Cc: Martijn Coenen > > > Cc: Shuah Khan > > > Cc: Sumit Semwal > > > Cc: Suren Baghdasaryan > > > Cc: Todd Kjos > > > Cc: de...@driverdev.osuosl.org > > > Cc: dri-devel@lists.freedesktop.org > > > Cc: linaro-mm-...@lists.linaro.org > > > Signed-off-by: Greg Kroah-Hartman > > > > We discussed this at the Android MC on Monday and the plan was to > > remove it after the next LTS release. > > I know it was discussed, my point is that it is actually causing > problems now (with developers who want to change the internal kernel api > hitting issues, and newbies trying to clean up code in ways that isn't > exactly optimal wasting maintainer cycles), and that anyone who uses > this code, is not actually using this version of the code. Everyone who > relies on ion right now, is using the version that is in the Android > common kernel tree, which has diverged from this in-kernel way quite a > bit now for the reason that we didn't want to take any of those new > features in the in-kernel version. > > So this is a problem that we have caused by just wanting to wait, no one > is using this code, combined with it causing problems for the upstream > developers. > > There is nothing "magic" about the last kernel of the year that requires > this code to sit here until then. At that point in time, all users > will, again, be using the forked Android kernel version, and if we > delete this now here, that fork can remain just fine, with the added > benifit of it reducing developer workloads here in-kernel. > > So why wait? Hi, I don't know what is the right thing to do here. I just want to highlight that AOSP's audio (codec2) HAL depends on the ION system heap and it will break AOSP for people who boot mainline on their devices, even for just testing purpose like we do in Linaro. Right now we need only 1 (Android specific out-of-tree) patch to boot AOSP with mainline and Sumit is already trying to upstream that vma naming patch. Removal of in-kernel ION, will just add more to that delta. Regards, Amit Pundir > > thanks, > > greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: ion: remove from the tree
On 8/27/20 8:36 AM, Greg Kroah-Hartman wrote: The ION android code has long been marked to be removed, now that we dma-buf support merged into the real part of the kernel. It was thought that we could wait to remove the ion kernel at a later time, but as the out-of-tree Android fork of the ion code has diverged quite a bit, and any Android device using the ion interface uses that forked version and not this in-tree version, the in-tree copy of the code is abandonded and not used by anyone. Combine this abandoned codebase with the need to make changes to it in order to keep the kernel building properly, which then causes merge issues when merging those changes into the out-of-tree Android code, and you end up with two different groups of people (the in-kernel-tree developers, and the Android kernel developers) who are both annoyed at the current situation. Because of this problem, just drop the in-kernel copy of the ion code now, as it's not used, and is only causing problems for everyone involved. Cc: "Arve Hjønnevåg" Cc: "Christian König" Cc: Christian Brauner Cc: Christoph Hellwig Cc: Hridya Valsaraju Cc: Joel Fernandes Cc: John Stultz Cc: Laura Abbott Cc: Martijn Coenen Cc: Shuah Khan Cc: Sumit Semwal Cc: Suren Baghdasaryan Cc: Todd Kjos Cc: de...@driverdev.osuosl.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-...@lists.linaro.org Signed-off-by: Greg Kroah-Hartman We discussed this at the Android MC on Monday and the plan was to remove it after the next LTS release. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: ion: remove from the tree
On 8/27/20 6:36 AM, Greg Kroah-Hartman wrote: The ION android code has long been marked to be removed, now that we dma-buf support merged into the real part of the kernel. It was thought that we could wait to remove the ion kernel at a later time, but as the out-of-tree Android fork of the ion code has diverged quite a bit, and any Android device using the ion interface uses that forked version and not this in-tree version, the in-tree copy of the code is abandonded and not used by anyone. Combine this abandoned codebase with the need to make changes to it in order to keep the kernel building properly, which then causes merge issues when merging those changes into the out-of-tree Android code, and you end up with two different groups of people (the in-kernel-tree developers, and the Android kernel developers) who are both annoyed at the current situation. Because of this problem, just drop the in-kernel copy of the ion code now, as it's not used, and is only causing problems for everyone involved. Cc: "Arve Hjønnevåg" Cc: "Christian König" Cc: Christian Brauner Cc: Christoph Hellwig Cc: Hridya Valsaraju Cc: Joel Fernandes Cc: John Stultz Cc: Laura Abbott Cc: Martijn Coenen Cc: Shuah Khan Cc: Sumit Semwal Cc: Suren Baghdasaryan Cc: Todd Kjos Cc: de...@driverdev.osuosl.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-...@lists.linaro.org Signed-off-by: Greg Kroah-Hartman --- MAINTAINERS | 10 - drivers/staging/android/Kconfig | 2 - drivers/staging/android/Makefile | 2 - drivers/staging/android/TODO | 5 - drivers/staging/android/ion/Kconfig | 27 - drivers/staging/android/ion/Makefile | 4 - drivers/staging/android/ion/ion.c | 649 -- drivers/staging/android/ion/ion.h | 302 drivers/staging/android/ion/ion_cma_heap.c| 138 drivers/staging/android/ion/ion_heap.c| 286 drivers/staging/android/ion/ion_page_pool.c | 155 - drivers/staging/android/ion/ion_system_heap.c | 377 -- drivers/staging/android/uapi/ion.h| 127 tools/testing/selftests/Makefile | 3 +- tools/testing/selftests/android/Makefile | 39 -- tools/testing/selftests/android/config| 5 - .../testing/selftests/android/ion/.gitignore | 4 - tools/testing/selftests/android/ion/Makefile | 20 - tools/testing/selftests/android/ion/README| 101 --- tools/testing/selftests/android/ion/ion.h | 134 .../testing/selftests/android/ion/ion_test.sh | 58 -- .../selftests/android/ion/ionapp_export.c | 127 .../selftests/android/ion/ionapp_import.c | 79 --- .../selftests/android/ion/ionmap_test.c | 136 .../testing/selftests/android/ion/ionutils.c | 253 --- .../testing/selftests/android/ion/ionutils.h | 55 -- .../testing/selftests/android/ion/ipcsocket.c | 227 -- .../testing/selftests/android/ion/ipcsocket.h | 35 - tools/testing/selftests/android/run.sh| 3 - 29 files changed, 1 insertion(+), 3362 deletions(-) delete mode 100644 drivers/staging/android/ion/Kconfig delete mode 100644 drivers/staging/android/ion/Makefile delete mode 100644 drivers/staging/android/ion/ion.c delete mode 100644 drivers/staging/android/ion/ion.h delete mode 100644 drivers/staging/android/ion/ion_cma_heap.c delete mode 100644 drivers/staging/android/ion/ion_heap.c delete mode 100644 drivers/staging/android/ion/ion_page_pool.c delete mode 100644 drivers/staging/android/ion/ion_system_heap.c delete mode 100644 drivers/staging/android/uapi/ion.h delete mode 100644 tools/testing/selftests/android/Makefile delete mode 100644 tools/testing/selftests/android/config delete mode 100644 tools/testing/selftests/android/ion/.gitignore delete mode 100644 tools/testing/selftests/android/ion/Makefile delete mode 100644 tools/testing/selftests/android/ion/README delete mode 100644 tools/testing/selftests/android/ion/ion.h delete mode 100755 tools/testing/selftests/android/ion/ion_test.sh delete mode 100644 tools/testing/selftests/android/ion/ionapp_export.c delete mode 100644 tools/testing/selftests/android/ion/ionapp_import.c delete mode 100644 tools/testing/selftests/android/ion/ionmap_test.c delete mode 100644 tools/testing/selftests/android/ion/ionutils.c delete mode 100644 tools/testing/selftests/android/ion/ionutils.h delete mode 100644 tools/testing/selftests/android/ion/ipcsocket.c delete mode 100644 tools/testing/selftests/android/ion/ipcsocket.h delete mode 100755 tools/testing/selftests/android/run.sh For selftest changes in this patch: Acked-by: Shuah Khan thanks, -- Shuah ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: ion: remove from the tree
On Thu, Aug 27, 2020 at 10:31:41PM +0530, Amit Pundir wrote: > On Thu, 27 Aug 2020 at 21:34, Greg Kroah-Hartman > wrote: > > > > On Thu, Aug 27, 2020 at 09:31:27AM -0400, Laura Abbott wrote: > > > On 8/27/20 8:36 AM, Greg Kroah-Hartman wrote: > > > > The ION android code has long been marked to be removed, now that we > > > > dma-buf support merged into the real part of the kernel. > > > > > > > > It was thought that we could wait to remove the ion kernel at a later > > > > time, but as the out-of-tree Android fork of the ion code has diverged > > > > quite a bit, and any Android device using the ion interface uses that > > > > forked version and not this in-tree version, the in-tree copy of the > > > > code is abandonded and not used by anyone. > > > > > > > > Combine this abandoned codebase with the need to make changes to it in > > > > order to keep the kernel building properly, which then causes merge > > > > issues when merging those changes into the out-of-tree Android code, and > > > > you end up with two different groups of people (the in-kernel-tree > > > > developers, and the Android kernel developers) who are both annoyed at > > > > the current situation. Because of this problem, just drop the in-kernel > > > > copy of the ion code now, as it's not used, and is only causing problems > > > > for everyone involved. > > > > > > > > Cc: "Arve Hjønnevåg" > > > > Cc: "Christian König" > > > > Cc: Christian Brauner > > > > Cc: Christoph Hellwig > > > > Cc: Hridya Valsaraju > > > > Cc: Joel Fernandes > > > > Cc: John Stultz > > > > Cc: Laura Abbott > > > > Cc: Martijn Coenen > > > > Cc: Shuah Khan > > > > Cc: Sumit Semwal > > > > Cc: Suren Baghdasaryan > > > > Cc: Todd Kjos > > > > Cc: de...@driverdev.osuosl.org > > > > Cc: dri-devel@lists.freedesktop.org > > > > Cc: linaro-mm-...@lists.linaro.org > > > > Signed-off-by: Greg Kroah-Hartman > > > > > > We discussed this at the Android MC on Monday and the plan was to > > > remove it after the next LTS release. > > > > I know it was discussed, my point is that it is actually causing > > problems now (with developers who want to change the internal kernel api > > hitting issues, and newbies trying to clean up code in ways that isn't > > exactly optimal wasting maintainer cycles), and that anyone who uses > > this code, is not actually using this version of the code. Everyone who > > relies on ion right now, is using the version that is in the Android > > common kernel tree, which has diverged from this in-kernel way quite a > > bit now for the reason that we didn't want to take any of those new > > features in the in-kernel version. > > > > So this is a problem that we have caused by just wanting to wait, no one > > is using this code, combined with it causing problems for the upstream > > developers. > > > > There is nothing "magic" about the last kernel of the year that requires > > this code to sit here until then. At that point in time, all users > > will, again, be using the forked Android kernel version, and if we > > delete this now here, that fork can remain just fine, with the added > > benifit of it reducing developer workloads here in-kernel. > > > > So why wait? > > Hi, > > I don't know what is the right thing to do here. I just want to > highlight that AOSP's audio (codec2) HAL depends on the ION system > heap and it will break AOSP for people who boot mainline on their > devices, even for just testing purpose like we do in Linaro. Right now > we need only 1 (Android specific out-of-tree) patch to boot AOSP with > mainline and Sumit is already trying to upstream that vma naming > patch. Removal of in-kernel ION, will just add more to that delta. So that means you now have to carry 2 patches instead of 1, right? That's not that bad :-D. BTW, why doesn't your mainline testing use dmabuf already? AFAIK, upstream has inertia catching up to products etc, so sooner its removed the better if it is mostly dead (Before it turns into ashmem which nobody can remove). My 2c. thanks, - Joel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: ion: remove from the tree
On Thu, Aug 27, 2020 at 11:54:12AM -0700, John Stultz wrote: > On Thu, Aug 27, 2020 at 10:17 AM Greg Kroah-Hartman > wrote: > > On Thu, Aug 27, 2020 at 10:31:41PM +0530, Amit Pundir wrote: > > > I don't know what is the right thing to do here. I just want to > > > highlight that AOSP's audio (codec2) HAL depends on the ION system > > > heap and it will break AOSP for people who boot mainline on their > > > devices, even for just testing purpose like we do in Linaro. Right now > > > we need only 1 (Android specific out-of-tree) patch to boot AOSP with > > > mainline and Sumit is already trying to upstream that vma naming > > > patch. Removal of in-kernel ION, will just add more to that delta. > > > > As AOSP will continue to rely on ION after December of this year, all > > you are doing is postponing the inevitable a few more months. > > > > Push back on the Android team to fix up the code to not use ION, they > > know this needs to happen. > > The point though, is your main premise that no one is using this isn't true. They are using the version of ion in the Android kernel tree, yes, as it has new features that many people are relying on. The version that is currently in the kernel tree is crippled, and maybe works for some use cases, but not the majority, right? > I'm actively working with Hridya and folks on the codec2 HAL side to > transition this on the userland side: > https://android-review.googlesource.com/c/platform/frameworks/av/+/1368918/3 > > I'd like AOSP to not use ION after September (though being external I > can't promise anything), much less continuing after December. The android team has said they will be dropping ION use for the "next" Android release, which is sometime next year from what I recall. December is probably not going to happen :) > I want this migration to happen as much as anyone. But I'd prefer to > keep ION in staging until after the LTS is announced. Having both > around helps development for the transition, which helps us have a > reliable solution, which helps vendors to migrate and be able to do > comparative performance testing. I don't understand what having this in the "next" kernel helps us with here. And I would really really prefer to NOT have an outdated version of this code in a kernel tree that I am going to have to support for the next X number of years, when no one is using that version of the driver. What is this LTS fixation to keep this code around for? Who does it help? > I do appreciate that keeping it isn't free, but I also don't feel the > chaos-monkey approach here is really motivational in the way you > intend. I don't see it helping anyone to leave this around, except to cause merge issues for me, and development issues for other developers. Anyone who really wants this code, can easily revert the deletion and move on and grab the AOSP copy of the code. That's what they did when we deleted other Android features that are still relied on. Given that the "isn't free" is causing _me_ real pain, and not the actual users of this code, I am leaning toward wanting to move that pain/cost to those users, for obvious reasons. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: ion: remove from the tree
On Thu, Aug 27, 2020 at 10:17 AM Greg Kroah-Hartman wrote: > > On Thu, Aug 27, 2020 at 10:31:41PM +0530, Amit Pundir wrote: > > On Thu, 27 Aug 2020 at 21:34, Greg Kroah-Hartman > > wrote: > > > > > > On Thu, Aug 27, 2020 at 09:31:27AM -0400, Laura Abbott wrote: > > > > On 8/27/20 8:36 AM, Greg Kroah-Hartman wrote: > > > > > The ION android code has long been marked to be removed, now that we > > > > > dma-buf support merged into the real part of the kernel. > > > > > > > > > > It was thought that we could wait to remove the ion kernel at a later > > > > > time, but as the out-of-tree Android fork of the ion code has diverged > > > > > quite a bit, and any Android device using the ion interface uses that > > > > > forked version and not this in-tree version, the in-tree copy of the > > > > > code is abandonded and not used by anyone. > > > > > > > > > > Combine this abandoned codebase with the need to make changes to it in > > > > > order to keep the kernel building properly, which then causes merge > > > > > issues when merging those changes into the out-of-tree Android code, > > > > > and > > > > > you end up with two different groups of people (the in-kernel-tree > > > > > developers, and the Android kernel developers) who are both annoyed at > > > > > the current situation. Because of this problem, just drop the > > > > > in-kernel > > > > > copy of the ion code now, as it's not used, and is only causing > > > > > problems > > > > > for everyone involved. > > > > > > > > > > Cc: "Arve Hjønnevåg" > > > > > Cc: "Christian König" > > > > > Cc: Christian Brauner > > > > > Cc: Christoph Hellwig > > > > > Cc: Hridya Valsaraju > > > > > Cc: Joel Fernandes > > > > > Cc: John Stultz > > > > > Cc: Laura Abbott > > > > > Cc: Martijn Coenen > > > > > Cc: Shuah Khan > > > > > Cc: Sumit Semwal > > > > > Cc: Suren Baghdasaryan > > > > > Cc: Todd Kjos > > > > > Cc: de...@driverdev.osuosl.org > > > > > Cc: dri-devel@lists.freedesktop.org > > > > > Cc: linaro-mm-...@lists.linaro.org > > > > > Signed-off-by: Greg Kroah-Hartman > > > > > > > > We discussed this at the Android MC on Monday and the plan was to > > > > remove it after the next LTS release. > > > > > > I know it was discussed, my point is that it is actually causing > > > problems now (with developers who want to change the internal kernel api > > > hitting issues, and newbies trying to clean up code in ways that isn't > > > exactly optimal wasting maintainer cycles), and that anyone who uses > > > this code, is not actually using this version of the code. Everyone who > > > relies on ion right now, is using the version that is in the Android > > > common kernel tree, which has diverged from this in-kernel way quite a > > > bit now for the reason that we didn't want to take any of those new > > > features in the in-kernel version. > > > > > > So this is a problem that we have caused by just wanting to wait, no one > > > is using this code, combined with it causing problems for the upstream > > > developers. > > > > > > There is nothing "magic" about the last kernel of the year that requires > > > this code to sit here until then. At that point in time, all users > > > will, again, be using the forked Android kernel version, and if we > > > delete this now here, that fork can remain just fine, with the added > > > benifit of it reducing developer workloads here in-kernel. > > > > > > So why wait? > > > > Hi, > > > > I don't know what is the right thing to do here. I just want to > > highlight that AOSP's audio (codec2) HAL depends on the ION system > > heap and it will break AOSP for people who boot mainline on their > > devices, even for just testing purpose like we do in Linaro. Right now > > we need only 1 (Android specific out-of-tree) patch to boot AOSP with > > mainline and Sumit is already trying to upstream that vma naming > > patch. Removal of in-kernel ION, will just add more to that delta. > > As AOSP will continue to rely on ION after December of this year, all > you are doing is postponing the inevitable a few more months. > > Push back on the Android team to fix up the code to not use ION, they > know this needs to happen. > Hi all, We are currently working with the codec2 team to transition codec2 to use libdmabufheap instead of libion. It will definitely happen during the Android S timeframe. Thanks, Hridya > thanks, > > greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: ion: remove from the tree
On Fri, Aug 28, 2020 at 1:05 AM Greg Kroah-Hartman wrote: > > On Thu, Aug 27, 2020 at 11:54:12AM -0700, John Stultz wrote: > > On Thu, Aug 27, 2020 at 10:17 AM Greg Kroah-Hartman > > wrote: > > > On Thu, Aug 27, 2020 at 10:31:41PM +0530, Amit Pundir wrote: > > > > I don't know what is the right thing to do here. I just want to > > > > highlight that AOSP's audio (codec2) HAL depends on the ION system > > > > heap and it will break AOSP for people who boot mainline on their > > > > devices, even for just testing purpose like we do in Linaro. Right now > > > > we need only 1 (Android specific out-of-tree) patch to boot AOSP with > > > > mainline and Sumit is already trying to upstream that vma naming > > > > patch. Removal of in-kernel ION, will just add more to that delta. > > > > > > As AOSP will continue to rely on ION after December of this year, all > > > you are doing is postponing the inevitable a few more months. > > > > > > Push back on the Android team to fix up the code to not use ION, they > > > know this needs to happen. > > > > The point though, is your main premise that no one is using this isn't true. > > They are using the version of ion in the Android kernel tree, yes, as it > has new features that many people are relying on. > > The version that is currently in the kernel tree is crippled, and maybe > works for some use cases, but not the majority, right? So my understanding is the Android Common Kernel tree version was mostly reworked to allow heaps as modules, and allowed heaps to have their own exporter logic (not unlike how dmabuf heaps do it). The main allocation interface is maybe slightly tweaked for out-of-tree vendor heaps, but doesn't affect the in-staging heaps. There's also a few optimizations we have skipped taking upstream. So yes, there are differences, but I don't feel your characterization is quite accurate. > > I'm actively working with Hridya and folks on the codec2 HAL side to > > transition this on the userland side: > > > > https://android-review.googlesource.com/c/platform/frameworks/av/+/1368918/3 > > > > I'd like AOSP to not use ION after September (though being external I > > can't promise anything), much less continuing after December. > > The android team has said they will be dropping ION use for the "next" > Android release, which is sometime next year from what I recall. > December is probably not going to happen :) AOSP is what the next Android release forks off of, so it needs to be fixed first. > > I want this migration to happen as much as anyone. But I'd prefer to > > keep ION in staging until after the LTS is announced. Having both > > around helps development for the transition, which helps us have a > > reliable solution, which helps vendors to migrate and be able to do > > comparative performance testing. > > I don't understand what having this in the "next" kernel helps us with > here. And I would really really prefer to NOT have an outdated version > of this code in a kernel tree that I am going to have to support for the > next X number of years, when no one is using that version of the driver. > > What is this LTS fixation to keep this code around for? Who does it > help? Vendors usually target LTS releases for their hardware bringups. Having a LTS release with both ION and DMA BUF Heaps helps them validate their old ION solution as performant, and then migrate to DMA BUF Heaps and be able to do performance comparisons holding all other things equal. > > I do appreciate that keeping it isn't free, but I also don't feel the > > chaos-monkey approach here is really motivational in the way you > > intend. > > I don't see it helping anyone to leave this around, except to cause > merge issues for me, and development issues for other developers. > > Anyone who really wants this code, can easily revert the deletion and > move on and grab the AOSP copy of the code. That's what they did when > we deleted other Android features that are still relied on. > > Given that the "isn't free" is causing _me_ real pain, and not the > actual users of this code, I am leaning toward wanting to move that > pain/cost to those users, for obvious reasons. Sure. Again, I do understand the desire to remove it, and it's your right to do so. Keeping the code for an extra year in LTS (over 5.4) is a cost, so I understand if you drop it. But I'll ask that you make that judgement clear as the main motivator/rationale of the commit message, rather than flippantly pretending it's not being used, and that everyone agrees it has no usefulness to keep around (especially after we've had this conversation a few times already this year). thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
