On Tue, Feb 16, 2016 at 3:38 PM, Vladimir Murzin
<vladimir.murzin@xxxxxxx> wrote:
> On 16/02/16 13:13, Andy Shevchenko wrote:
>> On Tue, Feb 16, 2016 at 3:09 PM, Vladimir Murzin
>> <vladimir.murzin@xxxxxxx> wrote:
>>> On 16/02/16 10:36, Andy Shevchenko wrote:
>>>> On Tue, Feb 16, 2016 at 12:08 PM, Vladimir Murzin
>>>> <vladimir.murzin@xxxxxxx> wrote:
>>>>> +static void mps2_early_putchar(struct uart_port *port, int ch)
>>>>> +{
>>>>> +
>>>>> + while (readb(port->membase + UARTn_STATE) & UARTn_STATE_TX_FULL)
>>>>> + cpu_relax();
>>>>
>>>> Infinite busy loop?
>>>
>>> In case of broken hw, yes, but I'm quite unsure how we can help to fix
>>> it. Do you have something in mind?
>>
>> Set sane amount of loops like
>>
>> int count = 100;
>> …
>> while (… && --count)
>>
>> Though I have no idea what to do if count == 0. Perhaps it's a TX overrun state.
>
> I thought about counter too, like some of drivers do, but had no idea
> what to do next after counter reaches zero. In case of TX overrun we
> could get it either because of broken hw or because we entered Linux
> with that state already set. In both cases, it looks handy to me to
> attach a debugger and see that we are spinning in this putchar loop.
>
> If you do insist to have a counter I'll add one, but if you are not
> strong about it I'd prefer to leave it as is.
I would wait for Peter Hurley, Alan, or other experienced guys to talk.
>> You may try to recover by flushing TX queue in HW (fifo and / or Tx
>> shift register) if HW supports it.
>>
>
> I'm afraid this is not supported.
Maybe soft reset? Anyway, see above.
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
