On 2016-03-07 17:58, Josh Cartwright wrote:
On Mon, Mar 07, 2016 at 05:41:14PM +0100, Sebastian Andrzej Siewior wrote:
On 02/26/2016 08:00 PM, Josh Cartwright wrote:
On Fri, Feb 26, 2016 at 01:26:27PM -0500, Kuba Kicinski wrote:
On 26 February 2016 11:52:28 GMT-05:00, Josh Cartwright <joshc@xxxxxx> wrote:
[..]
Instead, the driver needs to implement it's own oneshot-like
handling at the device-level: in the registered irq handler, capture
triggered interrupt state, squelch/mask, and enqueue the
kthread_work. In the tail-end of the kthread_work, re-enable
interrupts at the device level.
The problem there being IIRC that i2c doesn't provide async writes so
we can't mask from irq callback. The only option would be
disable_irq/enable_irq, right?
Ah, yes, that is a problem. If by disable_irq(), you mean
disable_irq_nosync(), then yes, I think that'd work.
I got lost here. Where do we stand here now?
I understood the comment from Kuba to mean that he would be implementing
the disable_irq()/enable_irq() idea above to fix all the problems with
this driver.
Kuba- did I read that right?
Sean- are you still stuck without this?
The oneshot fix, fixed it for me :-)
We have encountered another problem regarding flow control in this driver.
Flowcontrol simply gets deactivated right after it's activated :-(
My college will submit a patch, hopefully in a couple of days...
And the "sc16is7xx_get_mctrl() is invoked under the uart port spinlock"
problem is still there but with RT patches it's hidden.
/Sean
Thanks for the ping,
Josh
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
