On 21 August 2013 01:08, Peter Hurley peter@hurleysoftware.com wrote:
On 08/20/2013 06:52 AM, Viresh Kumar wrote:
That's really Greg's call whether he wants to take up RT-specific patches into the regular tree.
Yeah.. Lets wait for Greg..
One more thing: We are calling tty_flip_buffer_push() with (from interrupt context) and without (from process context) port->lock held. Shouldn't we
make this flat, like don't acquire port->lock while calling tty_flip_buffer_push() as that may cause recursive locking?
When you note that tty_flip_buffer_push() is called from 'process context', I assume you mean kworker threads handling rx DMA. Besides the pty driver and the fwserial staging driver that has loopback mode, I'm not aware of any other drivers that do rx from process context.
Okay.. And so most of the people call it from interrupt context (25+ of them, I am trying to fix for RT and others are already doing the right thing) and all of these must have set port->low_latency to false.
Now my questions is, what exactly we want to protect in this function while calling it from interrupt or process context? For which we need a port->lock to be held by caller?
There are drivers which are sustaining without a lock being held by caller and others shouldn't have any problem doing that... That might be a clean solution for Mainline and that will fix the RT issues we are facing :)
-- viresh