Description
Is your enhancement proposal related to a problem? Please describe.
The current Bluetooth host depends on it's thread having specific cooperative priorities.
The values seem to be pulled out of thin air, ie, the rationale for deriving them are not described anywhere.
This is okay-ish if the controller runs on the same chip (but still not nice), but this really breaks down when using an off-chip controller with a slow transport. The TX thread will call into the transport's driver, and will block all other threads until the driver returns control.
This means that the amount of time with all other threads blocked on the CPU is highly dependent on the driver's implementation.
Describe the solution you'd like
The Bluetooth stack shouldn't block all other threads from running while it is shuffling data around.
It should be possible to run the TX thread with a pre-emptible priority, so that other threads that may have soft real-time constraints are able to run.
Describe alternatives you've considered
An 'easy win' would be to have yet another thread/wq that sits at a pre-empt prio to do the talking with the HAL, but that will eat a lot of memory and will create a priority inversion.
The real solution is fixing the stack so that it doesn't depend on specific priority levels to function correctly.
Additional context
This issue describes the problem quite well: #50658