newbus questions

[Artem 'ZaZooBred' Ignatiev]

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''.