search

google-coral / edgetpu

Coral issue tracker (and legacy Edge TPU API source)
https://coral.ai
Apache License 2.0
430 stars 125 forks source link

Plans for Linux kernel driver #346

Open jan-kiszka opened 3 years ago

jan-kiszka commented 3 years ago

Also asking here, in case someone not on CC and not following LKML can contribute to https://lore.kernel.org/lkml/30ee6d6b-9206-acad-b224-591fdeb0dad7@siemens.com: What are the plans now to get the needed driver support into Linux? The current situation is not very handy, specifically for non-Debian users, but also for integrators.

BTW, where are the latest drivers sources and commit history now? I'm probably just blind, any pointer welcome.

Namburger commented 3 years ago

@jan-kiszka that's okay, the mainline drivers was breaking for our HW anyways. You can just get it like this when you need it: https://coral.ai/docs/m2/get-started#2a-on-linux

jan-kiszka commented 3 years ago

Sorry, but that's not OK. We are missing mainline support, specifically when thinking beyond experimental usage. That the upstream driver didn't work anymore was apparently because someone forgot to submit the required updates. That's not a mainline issue.

What was/is missing to finish this? https://coral.googlesource.com/linux-imx/+/refs/heads/release-day/drivers/staging/gasket/TODO or more? Missing time? Or concerns that the kernel community would demand a certain stable interface that makes sync'ing with the Windows driver harder?

Would be great to see a follow up on the LKML thread as well. Greg also asked some concrete questions and would surely help with finding the best way to move forward again. Looking at the history, I see quite a few contributors who tried to improve the driver beyond the staging state. Their work will now also be dumped. IMHO that should happen for discontinued hardware only.

Namburger commented 3 years ago

@jan-kiszka wait, I'm confuse, the mainline driver was never working for our HW in the first place, could you clarify if I'm missing details? From our instruction we mention to disable the mainline kernel and use the one we ship out: https://coral.ai/docs/m2/get-started/#troubleshooting-on-linux

jan-kiszka commented 3 years ago

I have no personal experience with the history of this driver (only started with it 2 days ago) but I would be surprised if nothing worked at all 3 years ago when folks from the Chromium project submitted the code back then to upstream, with your developers on CC and later on even involved. But this doesn't matter.

The point is that your way of supporting the hardware via downstream drivers is suboptimal. For many, many reasons, primarily (from my perspective):

I know that getting things into upstream (including out of staging) can take a while and some effort, depending on where you are coming from. It can also take a while to get the latest extensions (fixes are generally not an issue) into commonly used kernels that distros ship. For that, having a compat out-of-tree driver like yours can be helpful. But only as a bridging solution, not as long-term strategy. And specifically not as the primary place of development. That must be upstream first.

PS: In the meantime, could you mirror that linux-imx tree here on github? Gitiles is rather... limited (also UI-wise), requiring a complete clone in order to get a reproducible package, and that only for those few files. That's why I created the n-th copy of them now in https://github.com/siemens/meta-iot2050/commit/4d18cbc95495e80a01388dea829096a9f24cc8ae. TIA!

Namburger commented 3 years ago

but I would be surprised if nothing worked at all 3 years ago when folks from the Chromium project submitted the code back then to upstream, with your developers on CC and later on even involved.

Sorry if I confused you, but that's not what I meant. Our HW (coral) never worked with the mainstream driver (but it may works with other HW). We have our own separate forks of the driver, the instructions that we advised on our page to get the driver is how you get our. Unfortunately, we are not able to support the mainstream gasket driver, I suggest that you address the kernel maintainers for feedback

DemiMarie commented 1 year ago

but I would be surprised if nothing worked at all 3 years ago when folks from the Chromium project submitted the code back then to upstream, with your developers on CC and later on even involved.

Sorry if I confused you, but that's not what I meant. Our HW (coral) never worked with the mainstream driver (but it may works with other HW). We have our own separate forks of the driver, the instructions that we advised on our page to get the driver is how you get our. Unfortunately, we are not able to support the mainstream gasket driver, I suggest that you address the kernel maintainers for feedback

Why have the changes not been contributed back upstream? This should be under drivers/accel/. For that to happen you will need to make the compiler open source, but that is a good idea anyway.