[PATCH 10/16] serial: sh: Add RZ/G2L SCIF support

[Paul Barker]

On Sat, Oct 07, 2023 at 11:14:06PM +0200, Marek Vasut wrote:
> On 10/5/23 14:08, Paul Barker wrote:
> > The case we're interested in here is the Receive Error (ER) & Break
> > Detect (BRK) conditions. I've done some further datasheet digging...
> > 
> > RZ/G2L datasheet says these are cleared by writing zero to the
> > appropriate bits of the FSR register.
> > 
> > RZ/G2{H,M,N,E} datasheet says the same (pages 50-18 & 50-19 of
> > R01UH0808EJ0111 Rev.1.11).
> > 
> > The R-Car Gen3 Hardware Manual says the same (pages 55-18 & 55-19 of
> > R19UH0105EJ0230 Rev.2.30).
> > 
> > For R-Car S4, there is an Excel spreadsheet attached to page 105-5 of
> > the datasheet (R19UH0161EJ0100 Rev.1.00) which again says the same.
> > 
> > For R-Car V4H, the relevant info is on pages 105-16 & 105-18 of the
> > datasheet (R19UH0172EJ0081 Rev.0.81) and says the same.
> > 
> > On the RZ/G2L I was able to reproduce a break condition by changing
> > pinmux settings after the SCIF interface has been configured. You could
> > try this out on an R-Car system, but I don't think it's guaranteed to
> > cause a break condition, it may depend on how the port input is
> > implemented in those SoCs. From my reading, the only guaranteed way to
> > cause a break condition is to hold the Rx signal low, and you might need
> > to solder on some extra wires on to a board to be able to do that.
> 
> Can't you simply send a BREAK from terminal program ?
> In minicom, I think that's meta-F B .
> 
> > We should still fix the error handling here, even if the boards we have
> > don't easily cause Receive Errors or Break conditions, other folks may
> > have their own boards based on these SoCs.
> > 
> > If you're happy I'll go ahead and check IS_ENABLED(CONFIG_RCAR_64) here
> > instead of IS_ENABLED(CONFIG_RZG2L).
> 
> Based on the input I am getting from you here, it seems to me we should just
> use the G2L case as the common case for all systems, without any special
> casing, right ?

I assumed that the code that's in place here was correct for some older
SoC when it was added to u-boot. But I've just looked at the SH7751
datasheet this morning and guess what? It requires writing zeros to
clear the errors.

As long as SCIF_ERRORS is correctly defined for each SoC, then yes, it
looks like we can drop the conditional.

I'll include this in v2.

Thanks,
Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20231009/68048ee6/attachment.sig>