Hi
On Wed, Apr 18, 2018 at 11:59 AM, Russell King - ARM Linux
<linux@xxxxxxxxxxxxxxx> wrote:
> On Wed, Apr 18, 2018 at 02:41:43PM +0530, Vignesh R wrote:
>>
>>
>> On Tuesday 17 April 2018 02:50 PM, Vignesh R wrote:
>> >
>> >
>> > On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
>> >> * Russell King - ARM Linux <linux@xxxxxxxxxxxxxxx> [180416 15:19]:
>> >>> Hi,
>> >>>
>> >>> I'm not entirely sure what's going on, but I see corrupted characters
>> >>> with the serial console on the OMAP4430 SDP board. During boot,
>> >>> everything seems fine, the problem appears to be userspace output.
>> >>>
>> >>> For example, if I edit a file, then quit vi:
>> >>>
>> >>> :q■■%■■B■■Z■root@omap-4430sdp:~#
>> >>
>> >> I don't think I've seen that one. What I've seen few times is
>> >> typing a key on the serial console echoing back the previous
>> >> character typed while the new character won't get displayed
>> >> until hitting keyboard again. Only rebooting the device seems
>> >> to solve this. This is with 4430 ES2.3 revision.
>> >>
>> >> I wonder if we're missing some parts of errata i202 handling
>> >> in omap_8250_mdr1_errataset()?
>> >>
>>
>> I wonder if the extra read of MDR1 register at the beginning of
>> omap_8250_mdr1_errataset() compared to omap-serial is the issue.
>> errata i202 says access to MDR1 can cause data corruption.
>> Assuming both reads and writes can cause glitch then, that read
>> is not following advisory:
>>
>> I don't have SDP board so, could you verify if below diff helps:
>>
>>
>> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
>> index 6aaa84355fd1..8ab9d0a1b1eb 100644
>> --- a/drivers/tty/serial/8250/8250_omap.c
>> +++ b/drivers/tty/serial/8250/8250_omap.c
>> @@ -163,11 +163,6 @@ static void omap_8250_mdr1_errataset(struct uart_8250_port *up,
>> struct omap8250_priv *priv)
>> {
>> u8 timeout = 255;
>> - u8 old_mdr1;
>> -
>> - old_mdr1 = serial_in(up, UART_OMAP_MDR1);
>> - if (old_mdr1 == priv->mdr1)
>> - return;
>>
>> serial_out(up, UART_OMAP_MDR1, priv->mdr1);
>> udelay(2);
>
> That doesn't appear to help.
>
> Looking at the bitstream and comparing what should have been sent with
> what was sent, there appears to be some correlation between the two.
> It looks like the FTDI is not properly synchronised to the bitstream
> coming from the OMAP4430.
>
> Setting two stop bits on both ends (OMAP4430 and FTDI) appears to
> improve the issue, but not completely solve it.
Are you sure about clock error above some tollerance?
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
> According to speedtest.net: 8.21Mbps down 510kbps up
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
