Date: Thu, 16 Mar 2006 15:06:25 +0300 From: Artem 'ZaZooBred' Ignatiev <zazubrik@mail.ru> To: freebsd-hackers@freebsd.org Subject: Re: newbus questions Message-ID: <1142510785.36931.43.camel@timon> In-Reply-To: <200603161235.24124.hackers@dino.sk> References: <1142506792.36931.25.camel@timon> <200603161235.24124.hackers@dino.sk>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <something>_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''.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1142510785.36931.43.camel>