Hi,
On 04/12/2016 10:33 PM, Sebastian Andrzej Siewior wrote:
> On 04/11/2016 10:10 PM, Peter Hurley wrote:
>> On 04/11/2016 11:31 AM, Sebastian Andrzej Siewior wrote:
>>> On 04/11/2016 07:53 PM, Peter Hurley wrote:
On 04/11/2016 01:18 AM, John Ogness wrote:
> On 2016-04-05, Peter Hurley
On 04/14/2016 08:07 AM, One Thousand Gnomes wrote:
3. Handling XON/XOFF transmit is mandatory; I don't see a way to do that
without pause/resume.
>>>
>>> Yes, not doing XON/XOFF with DMA is not good. Using hardware flow
>>> control is one workaround but the user has no chance of know
On 04/12/2016 11:42 AM, Peter Hurley wrote:
> On 04/12/2016 10:03 AM, Sebastian Andrzej Siewior wrote:
>> On 04/11/2016 10:10 PM, Peter Hurley wrote:
>>> On 04/11/2016 11:31 AM, Sebastian Andrzej Siewior wrote:
On 04/11/2016 07:53 PM, Peter Hurley wrote:
> On 04/11/2016 01:18 AM, John Ogne
> >> 3. Handling XON/XOFF transmit is mandatory; I don't see a way to do that
> >>without pause/resume.
> >
> > Yes, not doing XON/XOFF with DMA is not good. Using hardware flow
> > control is one workaround but the user has no chance of knowing that
> > XON/XOFF has been silently disabled.
On 04/13/2016 04:11 AM, Sekhar Nori wrote:
> On Wednesday 13 April 2016 05:30 AM, Peter Hurley wrote:
>
- generates spurious uart interrupt for every rx dma transaction
(ie., necessitates acking every UART interrupt, even UART_IIR_NO_INT)
_Even with this workaround_, it still ge
On Wednesday 13 April 2016 05:30 AM, Peter Hurley wrote:
>>> - generates spurious uart interrupt for every rx dma transaction
>>> (ie., necessitates acking every UART interrupt, even UART_IIR_NO_INT)
>>> _Even with this workaround_, it still generates spurious interrupt warning
>>> which shu
On 04/12/2016 10:03 AM, Sebastian Andrzej Siewior wrote:
> On 04/11/2016 10:10 PM, Peter Hurley wrote:
>> On 04/11/2016 11:31 AM, Sebastian Andrzej Siewior wrote:
>>> On 04/11/2016 07:53 PM, Peter Hurley wrote:
On 04/11/2016 01:18 AM, John Ogness wrote:
> On 2016-04-05, Peter Hurley wrote
[ +to Heikki, Andy ]
On 04/12/2016 10:03 AM, Sebastian Andrzej Siewior wrote:
> On 04/11/2016 10:10 PM, Peter Hurley wrote:
>> On 04/11/2016 11:31 AM, Sebastian Andrzej Siewior wrote:
>>> On 04/11/2016 07:53 PM, Peter Hurley wrote:
[ elided parts not relevant to shared 8250 dma discussion ]
>> 2
On 04/12/2016 10:03 AM, Sebastian Andrzej Siewior wrote:
> On 04/11/2016 10:10 PM, Peter Hurley wrote:
>> On 04/11/2016 11:31 AM, Sebastian Andrzej Siewior wrote:
>>> On 04/11/2016 07:53 PM, Peter Hurley wrote:
On 04/11/2016 01:18 AM, John Ogness wrote:
> On 2016-04-05, Peter Hurley wrote
On 04/11/2016 10:10 PM, Peter Hurley wrote:
> On 04/11/2016 11:31 AM, Sebastian Andrzej Siewior wrote:
>> On 04/11/2016 07:53 PM, Peter Hurley wrote:
>>> On 04/11/2016 01:18 AM, John Ogness wrote:
On 2016-04-05, Peter Hurley wrote:
> On 03/31/2016 01:41 AM, John Ogness wrote:
>> It ha
On 04/11/2016 11:31 AM, Sebastian Andrzej Siewior wrote:
> On 04/11/2016 07:53 PM, Peter Hurley wrote:
>> On 04/11/2016 01:18 AM, John Ogness wrote:
>>> On 2016-04-05, Peter Hurley wrote:
On 03/31/2016 01:41 AM, John Ogness wrote:
> It has been observed that the TX-DMA can stall
On 04/11/2016 07:53 PM, Peter Hurley wrote:
> On 04/11/2016 01:18 AM, John Ogness wrote:
>> On 2016-04-05, Peter Hurley wrote:
>>> On 03/31/2016 01:41 AM, John Ogness wrote:
It has been observed that the TX-DMA can stall
>>>
>>> Does this happen on any other OMAP part besides am335x?
>>> I lo
On 04/11/2016 01:18 AM, John Ogness wrote:
> On 2016-04-05, Peter Hurley wrote:
>> On 03/31/2016 01:41 AM, John Ogness wrote:
>>> It has been observed that the TX-DMA can stall
>>
>> Does this happen on any other OMAP part besides am335x?
>> I looked back over the LKML history of this and didn't s
On 2016-04-05, Peter Hurley wrote:
> On 03/31/2016 01:41 AM, John Ogness wrote:
>> It has been observed that the TX-DMA can stall
>
> Does this happen on any other OMAP part besides am335x?
> I looked back over the LKML history of this and didn't see
> any other design implicated in this problem.
On 03/31/2016 01:41 AM, John Ogness wrote:
> From: Sebastian Andrzej Siewior
>
> It has been observed that the TX-DMA can stall
Does this happen on any other OMAP part besides am335x?
I looked back over the LKML history of this and didn't see any other
design implicated in this problem.
> if te
> + * TCSANOW requests the change to occur immediately, however
> + * if we have a TX-DMA operation in progress then it has been
> + * observed that it might stall and never complete. Therefore
> + * we wait until DMA completes to prevent this han
On 2016-03-31, John Ogness wrote:
> diff --git a/drivers/tty/serial/8250/8250_omap.c
> b/drivers/tty/serial/8250/8250_omap.c
> index 6f76051..9459b4d 100644
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
> @@ -460,6 +451,24 @@ static void omap_8250_set_ter
From: Sebastian Andrzej Siewior
It has been observed that the TX-DMA can stall if termios changes
occur while a TX-DMA operation is in progress. Previously this was
handled by allowing set_termios to return immediately and deferring
the change until the operation is completed. Now set_termios wil
18 matches
Mail list logo
