On 27-04-26, 11:21, Bertrand Marquis wrote:
As said during the meeting, I encountered a lot of issues related to:
I end up missing things during the meeting sometimes and hence try to get more discussion over email (so I can read again and again to understand clearly).
- blocking in code that cannot sleep
We can have a spin-lock implementation for that ? How does the current code solve that ? Some sort of blocking needs to be done if the caller expects the response in the same thread.
I hope that can be done with a simple change over the current code.
- dma handling issues
- timings and concurrency during probe or runtime
Can we please discuss these in detail here ? I think we can make the current code work and solve all these issues easily. If not, I am okay with making a change in design and adapt a new strategy. But starting with completely new code at this point doesn't look right. We have already invested so much time with the current code.
There are a lot of examples in kernel where similar (simple) design was adapted, one of them is Greybus (For Google's ARA modular phone and I did work on that earlier). We can adapt parts from that to solve our current problems if required.
Maybe lets start with the problems one by one, with exact use-case to see what we are lacking right now. I am still not able to see the full picture (in sense of the problems we have).