From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16353 invoked by alias); 12 Jun 2012 13:16:15 -0000 Received: (qmail 16335 invoked by uid 22791); 12 Jun 2012 13:16:14 -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; Tue, 12 Jun 2012 13:16:00 +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 0956419F6CF; Tue, 12 Jun 2012 14:15:57 +0100 (BST) Message-ID: <4FD7410D.5060105@calivar.com> Date: Tue, 12 Jun 2012 13:16: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: "" Subject: Re: Handling RTS with an UART that doesn't directly drives the RTS pin References: <4FD7374A.1090602@kuantic.com> In-Reply-To: <4FD7374A.1090602@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/msg00002.txt.bz2 On 12/06/12 13:34, Bernard Fouché wrote: > I'm about to : > > - add definitions for CYGNUM_SERIAL_STATUS_THROTTLE_RX and > CYGNUM_SERIAL_STATUS_RESTART_RX > - add a cdl option to have the line status callback function, which is > user defined, to be called with the corresponding value if > throttle_rx()/restart_rx() are called within serial.c . > - hence the user defined callback can handle RTS (or any other flow > control pin) the way it wants > > Do I break some convention doing this or is it okay? I don't think hacking this into the generic code is the right way to do this. In the past, when I have had to do the same and use GPIO pins for this, I have added it to the underlying serial driver. Of course this was for devices that had no other notion of hardware flow control. But you could define your own variant of the 16x5x driver that did the right thing. However, a better approach is to avoid hacking on either the generic code or the 16x5x driver and make use of the driver stacking mechanism. Create a serial driver that passes all calls through to the underlying driver, except for the throttle and flow config options, which do the right things with the GPIO lines. Take a look at the TTY and TERMIO drivers for how to set this up. Note that while RTS is a simple output level, CTS really needs to be driven by a GPIO line that can interrupt and which will then call the indicate_status() callback in its DSR. That should then drive the generic serial transmit engine. -- 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