From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9637 invoked by alias); 13 Jun 2012 10:10:31 -0000 Received: (qmail 9628 invoked by uid 22791); 13 Jun 2012 10:10:30 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from calivar.demon.co.uk (HELO calivar.com) (83.104.54.243) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 13 Jun 2012 10:10:16 +0000 Received: from [192.168.7.22] (fugu.barn.ecoscentric.com [192.168.7.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by calivar.com (Postfix) with ESMTPS id 7947619F811; Wed, 13 Jun 2012 11:10:14 +0100 (BST) Message-ID: <4FD86705.6080300@calivar.com> Date: Wed, 13 Jun 2012 10:10:00 -0000 From: Nick Garnett User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120421 Thunderbird/12.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bernard_Fouch=E9?= CC: "" , stano@meduna.org Subject: Re: Handling RTS with an UART that doesn't directly drives the RTS pin References: <4FD7374A.1090602@kuantic.com> <4FD7410D.5060105@calivar.com> <4FD7748C.1000707@kuantic.com> In-Reply-To: <4FD7748C.1000707@kuantic.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2012-06/txt/msg00004.txt.bz2 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