From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 16 12:06:31 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 506EA16A41F for ; Thu, 16 Mar 2006 12:06:31 +0000 (UTC) (envelope-from zazubrik@mail.ru) Received: from mx6.mail.ru (mx6.mail.ru [194.67.23.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAC9243D49 for ; Thu, 16 Mar 2006 12:06:30 +0000 (GMT) (envelope-from zazubrik@mail.ru) Received: from [85.141.213.186] (port=11798 helo=timon) by mx6.mail.ru with esmtp id 1FJrFN-0009jr-00 for freebsd-hackers@freebsd.org; Thu, 16 Mar 2006 15:06:29 +0300 From: Artem 'ZaZooBred' Ignatiev To: freebsd-hackers@freebsd.org In-Reply-To: <200603161235.24124.hackers@dino.sk> References: <1142506792.36931.25.camel@timon> <200603161235.24124.hackers@dino.sk> Content-Type: text/plain Date: Thu, 16 Mar 2006 15:06:25 +0300 Message-Id: <1142510785.36931.43.camel@timon> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Re: newbus questions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2006 12:06:31 -0000 On Thu, 16/03/2006 12:35 +0100, Milan Obuch wrote: > .... > > > 1. How to create the bus itself, and properly describe its interfaces? > > skeletons of bus-driver and frontend-drivers would be a GREAT help. > > Being far from everything knowing hacker, I just can help with what I found > when working on something totally unrelated. > First you need to write .m file describing your methods - they are class > description, kind of. There are couple of them - maybe PCI analogy (pci_if.m > and pcib_if.m) could help a little to understand their role. Then you can use > these methods in your device_method_t array describing your device. Actually, > these definitions are something like software bus between parent and child > device. And maybe you could get some clue looking at bktr driver, which could > be somehow related to your are of interest. Yes, I've got some clearance in how that _if.m files are written, but bktr driver is too complex for me to understand how the things are done right now. I'll look at it again, though, maybe I could understand the logic of how such things are done, when I could clearly separate generic logic from implementation of particular hardware driver. > > 2. SAA7146 uses I2C to communicate with tuners, and I know that there > > are some I2C-related peaces already in kernel. I would like to reuse > > that code, if possible, but can't figure out where to look and how to > > link it in. > > There is some basis for i2c, look in /usr/src/sys/dev/iicbus directory. There > are two kinds of i2c controllers - bit banged and full hardware controlled. > The former is easily usable, you need just set and query methods > implementation (look into iicbb_if.m), even if this has not the full i2c > potential, the latter is (at least for me) somewhat hard to understand. I > tried to implement such driver with Geode's Access.BUS controller, but so far > no luck. And no description, google does not help me either. > If SAA7146 uses bit banging interface or can be forced into such mode, you can > do it in small amount of time. I had looked at both iicbb_if.m and iicbus_if.m. SAA has internal logic to handle IIC, so iicbb was of no interest to me. As to iicbus_if.m, it way closer to what I want. It looks like linux is one layer of abstraction higher, so they have "send N i2c messages" kind of functions, and in case of these cards, logic is like that: get array of messages, pack them into dwords, transfer that dwords using DMA to card, read that dwords back and decode them into response. All START/STOP conditions are handled by SAA chip itself, and I hoped that there was something similar in other drivers, so there's no need to reinvent the wheel for me. Therefore, I suppose that this peace of code I had written couple of years ago will be left unchanged... > > > 3. Card vendors use different PCI_SUBDEVICE on SAA7146 to indicate which > > tuner is (possibly) used. So, I suppose that "bus"-driver shall provide > > some way to tuner-driver to get this information. How that can be done? > > This is not that easy to understand at first, but bus 'ivars' are intended for > this purpose. man device_get_ivars would be first step as it was for me to > understand this. Yeah, that told me to look into BUS_READ_IVAR(9), and it looks like something I can use, so now my question is reformed to ``how can I from child driver get the bus device_t''.