From owner-freebsd-arch@FreeBSD.ORG Wed Apr 9 15:58:02 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BA2E106566B for ; Wed, 9 Apr 2008 15:58:02 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.82]) by mx1.freebsd.org (Postfix) with ESMTP id 5A8C28FC0C for ; Wed, 9 Apr 2008 15:58:01 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp010-s [10.150.69.73]) by smtpoutm.mac.com (Xserve/smtpout019/MantshX 4.0) with ESMTP id m39FaSfu018307; Wed, 9 Apr 2008 08:36:29 -0700 (PDT) Received: from [192.168.1.100] (209-128-86-226.bayarea.net [209.128.86.226]) (authenticated bits=0) by mac.com (Xserve/asmtp010/MantshX 4.0) with ESMTP id m39FaIwS001953 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Apr 2008 08:36:19 -0700 (PDT) Message-Id: From: Marcel Moolenaar To: Poul-Henning Kamp In-Reply-To: <44321.1207738604@critter.freebsd.dk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 9 Apr 2008 08:36:17 -0700 References: <44321.1207738604@critter.freebsd.dk> X-Mailer: Apple Mail (2.919.2) Cc: arch@freebsd.org, John E Hein Subject: sync/async [was: Re: tt_ioctl] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2008 15:58:02 -0000 On Apr 9, 2008, at 3:56 AM, Poul-Henning Kamp wrote: > In message <18428.624.490619.248235@gromit.timing.com>, John E Hein > writes: > >> I guess I'm leaning toward a separate >> uftdi0.ctl minor device despite what the sourceforge >> linux driver does. > > That would be my inclination too. > > We had something slightly similar with a sync/async board at one > point. > > The driver never made it into the tree for a number of reasons, but > the same problem was present: We have one physical connector, and > it can either be a tty or something else. I think the complexity or problems stem from the fact that there's a single driver. With scc(4) the design is such that the driving is left to subordinate drivers like uart(4) and the only thing that scc(4) does is arbitration. The mode the hardware is in corresponds to which sub-ordinate driver is selected. As such, scc(4) presents a time-shared bus onto which multiple drivers can attach -- each of which dealing with a particular mode of the hardware. We currently only have uart(4) for async communication in the tree, but I have some sketches for drivers for bi-sync and hdlc/sdlc in P4. This approach yields logical behaviour in general. Whenever the device special file of uart(4) is being opened, uart(4) will try to activate the resources. If those resources aren't already activated (i.e. the hardware is currently idle), then uart(4) gets to use the resources and the hardware can be put in async mode. Otherwise the open will fail or block. Suppose we have a driver for sdlc/hdlc that presents a network interface. The process above is not triggered by the opening of a device, but by bringing the interface up or configuring it. This succeeds if the hardware is idle (e.g. uart(4) isn't used for async communications). I think this scheme will work well in general and should be applicable in John's case as well. JFYI, -- Marcel Moolenaar xcllnt@mac.com