sh-sci CTS problem

sh-sci CTS problem

[phil.edworthy]

Hi Yoshii-san, Paul,

Commit 4480a688 is a problem for some devices. For example, on the SH7203 
some serial ports have RTS/CTS, but others don't.

I guess the right thing to do is add an extra field to struct 
plat_sci_port to indicate support for RTS/CTS?

Phil

Re: sh-sci CTS problem

[Paul Mundt]

On Tue, Nov 22, 2011 at 10:32:41AM +0000, phil.edworthy@renesas.com wrote:
> Hi Yoshii-san, Paul,
> 
> Commit 4480a688 is a problem for some devices. For example, on the SH7203 
> some serial ports have RTS/CTS, but others don't.
> 
> I guess the right thing to do is add an extra field to struct 
> plat_sci_port to indicate support for RTS/CTS?
> 
Looking at the data sheets, I think we're probably going to have to do
something like that, as well as overhaul sci_get/set_mctrl(). There are
certainly fewer ports that actually support RTS/CTS in hardware than
those that don't, so the mctrl information is more often than not
completely bogus.

Could you elaborate what precisely you are encountering as a result of
the CTS reporting on SH7203? It was initially added as a correctness
fix to complement the existing RTS reporting, so it would be interesting
to know what your use case is or what ill effects fell out as a result.

Re: sh-sci CTS problem

[phil.edworthy]

Hi Paul,

> > Commit 4480a688 is a problem for some devices. For example, on the 
SH7203 
> > some serial ports have RTS/CTS, but others don't.
> > 
> > I guess the right thing to do is add an extra field to struct 
> > plat_sci_port to indicate support for RTS/CTS?
> > 
> Looking at the data sheets, I think we're probably going to have to do
> something like that, as well as overhaul sci_get/set_mctrl(). There are
> certainly fewer ports that actually support RTS/CTS in hardware than
> those that don't, so the mctrl information is more often than not
> completely bogus.
> 
> Could you elaborate what precisely you are encountering as a result of
> the CTS reporting on SH7203? It was initially added as a correctness
> fix to complement the existing RTS reporting, so it would be interesting
> to know what your use case is or what ill effects fell out as a result.

I am not sure if this actually causing any problems at all, this is 
probably a wild goose chase. I suspect that enabling RTS/CTS on ports that 
don't have these wired up won't change their behaviour.

I am trying to track down an issue with serial that has been around for a 
very long time. Actually this work is on SH7264 but the same issues are on 
at least SH7201 and SH7203 devices. Receiving data over serial often fails 
with framing and overrun errors. I fixed a few things locally, such as the 
multiplexed isr doesn't check that the interrupt source was an overrun, 
and the overrun handling needs some tweaking. However these are just 
addressing the symptoms, not the cause.

Phil

Re: sh-sci CTS problem

[Takashi Yoshii]

Hi,

> I guess the right thing to do is add an extra field to struct 
> plat_sci_port to indicate support for RTS/CTS?

Right. I guess each real pin manipulation will be handled like sci_init_pins().
On the other hand, I don't think there is much things to do here for channels
that does *not* support control lines. get_mctrl() does not provide the function
to tell "not supported" condition anyway.

I think that should be implemented in sci_set_termios().
Currently, it sets SCFCR.MCE regardless of the HW function, and does not
fix any bits in c_flags. We can negate CRTSCTS in termios->c_cflag there,
unless (s->cfg->flags & UPF_xx) or something.
Does anyone know good flags or constant definitions?
/yoshii