public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
From: Nick Garnett <nickg@calivar.com>
To: "Bernard Fouché" <bernard.fouche@kuantic.com>
Cc: "<ecos-devel@ecos.sourceware.org>"
	<ecos-devel@ecos.sourceware.org>,
	 stano@meduna.org
Subject: Re: Handling RTS with an UART that doesn't directly drives the RTS pin
Date: Wed, 13 Jun 2012 10:10:00 -0000	[thread overview]
Message-ID: <4FD86705.6080300@calivar.com> (raw)
In-Reply-To: <4FD7748C.1000707@kuantic.com>



On 12/06/12 17:55, Bernard Fouché wrote:
>
> 
> RTS is the real problem: only serial.c knows when it's time to change 
> the pin state because it's related to the use of the RX buffer, which is 
> visible only to serial.c (please correct me if I'm wrong!). AFAIK there 
> is nothing making the RX throttling information to reach higher levels 
> since these higher levels are unaware of the buffering details underneath.

You are right. I was thinking, without looking too closely at the code,
that it might be possible to slip another drive in under the serial
driver. But obviously that is not possible.

But there is still a way to do something similar, I think. In the
board-specific serial configuration package instead of passing
pc_serial_funs to the SERIAL_CHANNEL() macro, pass your own serial
functions structure. Most of the entries can just call straight through
pc_serial_funs to the 16x5x functions, but the set_config entry can be
your function which handles GPIO flow control and calls
pc_serial_funs.set_config() for the rest.

This way all the generic code stays unchanged, and the board-specific
parts are isolated in a board-specific package.

> 
> Another solution would be to add config keys to get/set the pointers of 
> the low level functions of a serial channel which are exposed by a 
> hardware driver and then one could insert any kind of middle level 
> driver (like hooks): this would be more comfortable in the long run, it 
> could help for debug or statistics. The xxx_serial_channelN definition 
> ends in .data so I guess this is possible.

I think if you do what I suggest above you wouldn't need to do this.
Also the serial function tables ought to be declared const and thus be
in read-only memory. At present they are not, but in the future this
might change. These tables should be treated as read-only.



-- 
Nick Garnett                                      eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com      The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.     Tel: +44 1223 245571
Registered in England and Wales:                        Reg No: 4422071

  reply	other threads:[~2012-06-13 10:10 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-12 12:34 Bernard Fouché
2012-06-12 13:12 ` Stanislav Meduna
2012-06-12 13:16 ` Nick Garnett
2012-06-12 16:56   ` Bernard Fouché
2012-06-13 10:10     ` Nick Garnett [this message]
2012-06-13 16:37       ` Bernard Fouché
2012-06-14 15:33         ` Bernard Fouché
     [not found] ` <4FDF355B.2010209@mindspring.com>
2012-06-18 14:34   ` Closing devices Frank Pagliughi
2012-06-19 13:36     ` Bernard Fouché
2012-06-20 13:38       ` Frank Pagliughi
2012-06-20 15:20         ` Bernard Fouché
2012-06-21 18:20           ` Frank Pagliughi
2012-06-22  8:33             ` Bernard Fouché
2012-06-22 14:48               ` Frank Pagliughi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FD86705.6080300@calivar.com \
    --to=nickg@calivar.com \
    --cc=bernard.fouche@kuantic.com \
    --cc=ecos-devel@ecos.sourceware.org \
    --cc=stano@meduna.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).