Re: [PATCH] pxa serial auto flow control

[Uli Luckas <u.luckas@xxxxxxx>]

On Wednesday, 3. September 2008, Robert Jarzmik wrote:
> Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> writes:
> > On Wed, Sep 03, 2008 at 06:17:49PM +0200, Robert Jarzmik wrote:
> >> But if a termio is done to activate a hardware CTS/RTS management, I
> >> understand that the userland application is aware the state of RTS
> >> signal will change. So even if RTS is unfortunatelly set that way on
> >> pxa25x uarts, the user asked for it (in fact he asked to loose control
> >> over RTS), didn't he ?
> >
> > No, and if that's how you regard it, it's broken.
> >
> > Why?  Lets say you enable this mode.  It's great when you don't read
> > the FIFO - when the FIFO reaches a certain point, RTS is deasserted.
> >
> > The driver eventually gets around to reading the FIFO, and places
> > characters into the tty buffer.  The tty buffer then starts to become
> > full, and the tty layer decides it needs to throttle the remote end.
> > How does the tty layer achieve this?  It asks the driver to deassert
> > RTS.
>
> Ah, I understand now the misunderstaning in my patch.
>
> You've been always talking about CTS/RTS flow control, but fully controlled
> from software (from the kernel). I was talking about hardware flow control
> fully controlled from hardware, based on FIFO filling.
>
> In your example, I aggree that tty layer action on RTS won't work. But what
> will come next :
>  - tty layer won't read from the FIFO
>  - the FIFO will get filled up
>  - hardware flow control will deassert RTS
>  - time will pass ...
>  - tty layer will eventually read from the FIFO
>  - hardware flow control will reassert RTS
>  - ... life goes on ...
>
> > So, unless the RTS bit being deasserted takes priority over the UARTs
> > AFE bit, merely enabling AFE will result in hardware flow control
> > basically being broken; you'll be far better off leaving the AFE bit
> > clear.
>
> Well, the actual implementation doesn't work for bluetooth uart at
> 921kbps. While hardware based auto-flow works ...
>
How about your patch minus setting the RTS bit? Does that work? 

If not, you should find out why it does not work because it should.

Actually as long as the tty layer does not overflow RTS should be asserted by 
the tty layer giving the same result as your original patch. 
Now if the tty layer overflows why should it be wrong to deassert RTS?
By the way, you only assert RTS once, that does not prevent the tty layer from 
re-deaserting RTS at a later time anyway.

> I suppose there's no  special termio to notify the driver to use the
> hardware implemented CTSRTS flow control ...
>
> I suppose also you won't consider use of hardware CTS/RTS handling instead
> of kernel controlled CTS/RTS for pxa serial driver acceptable, will you ?
> With a module parameter perhaps ?
>
Your thinko is the 'instead' in the above paragraph.
If your rip the RTS modification out of your original patch you should get 
both, hardware CTS/RTS handling plus kernel controlled CTS/RTS.
Read the auto-flow part of the pxa manaual again and figure out what happens 
if AFE is set and the tty layer manipulates RTS as it thinks suits..

regards,
Uli

-- 

------- ROAD ...the handyPC Company - - -  ) ) )

Uli Luckas
Software Development

ROAD GmbH
Bennigsenstr. 14 | 12159 Berlin | Germany
fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69
url: www.road.de

Amtsgericht Charlottenburg: HRB 96688 B
Managing directors: Hans-Peter Constien, Hubertus von Streit

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php