Re: newbus questions
On 16.03.2006, at 15:06, Artem 'ZaZooBred' Ignatiev wrote: 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. Okay, now I have got the bus device, the child device. My current trouble is that I want bus driver to provide some methods to child drivers. So I created saa_bus_if.m file, declared some methods there, made implementation in bus driver and added them using DEVICE_METHOD(saa_bus_some_method, saa_some_method_impl), and added the saa_bus_if.c to child driver SRCS. Now, when I do SAA_BUS_SOME_METHOD(card, ...) inside bus driver, it works just as expected. But when I do SAA_BUS_SOME_METHOD(device_get_parent (subdev), ...) inside subdriver, it happens that KOBJLOOKUP(...) returns pointer to generic function (which returns ENXIO) rather than pointer to my implementation. The questions are: Am I going the Right Way(tm) when exporting functions to child drivers like that? If yes, what I must do in order to get the real implementation, not the default one? If no, what is The Right Way(tm)? Thanks in advance. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: newbus questions
Artem Ignatiev wrote this message on Wed, Mar 22, 2006 at 16:47 +0300: On 16.03.2006, at 15:06, Artem 'ZaZooBred' Ignatiev wrote: 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. Okay, now I have got the bus device, the child device. My current trouble is that I want bus driver to provide some methods to child drivers. So I created saa_bus_if.m file, declared some methods there, made implementation in bus driver and added them using DEVICE_METHOD(saa_bus_some_method, saa_some_method_impl), and added the saa_bus_if.c to child driver SRCS. You should only add the saa_bus_if.h to the child driver.. the if.c file is for the part that implementes the bus.. be it one driver, or part of the kernel... I'm surprised you aren't getting duplicate symbols... Now, when I do SAA_BUS_SOME_METHOD(card, ...) inside bus driver, it works just as expected. But when I do SAA_BUS_SOME_METHOD(device_get_parent (subdev), ...) inside subdriver, it happens that KOBJLOOKUP(...) returns pointer to generic function (which returns ENXIO) rather than pointer to my implementation. The questions are: Am I going the Right Way(tm) when exporting functions to child drivers like that? If yes, what I must do in order to get the real implementation, not the default one? If no, what is The Right Way(tm)? Most of the drivers have code in the default, that will reapply the function to the parent, so you don't have to do the device_get_parent in your driver.. They also implement their own lower case wrappers too... This very well could be due to the fact that you're including your interface twice, and that the second time isn't seeing the same cache entry in the KOBJ cache.. Why are you compiling the _if.c twice? If this was to get around undefined symbols at module load time, I found that you need to add a MODULE_DEPEND to the module the provides the symbol... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: newbus questions
On 22.03.2006, at 22:23, John-Mark Gurney wrote: Okay, now I have got the bus device, the child device. My current trouble is that I want bus driver to provide some methods to child drivers. So I created saa_bus_if.m file, declared some methods there, made implementation in bus driver and added them using DEVICE_METHOD(saa_bus_some_method, saa_some_method_impl), and added the saa_bus_if.c to child driver SRCS. You should only add the saa_bus_if.h to the child driver.. the if.c file is for the part that implementes the bus.. be it one driver, or part of the kernel... I'm surprised you aren't getting duplicate symbols... Now, when I do SAA_BUS_SOME_METHOD(card, ...) inside bus driver, it works just as expected. But when I do SAA_BUS_SOME_METHOD(device_get_parent (subdev), ...) inside subdriver, it happens that KOBJLOOKUP(...) returns pointer to generic function (which returns ENXIO) rather than pointer to my implementation. The questions are: Am I going the Right Way(tm) when exporting functions to child drivers like that? If yes, what I must do in order to get the real implementation, not the default one? If no, what is The Right Way(tm)? Most of the drivers have code in the default, that will reapply the function to the parent, so you don't have to do the device_get_parent in your driver.. They also implement their own lower case wrappers too... That's just for sure... I want the method I call to work with the bus' softc, not with the child's one. Right now I am not sure whether I really want to have different softc's for the bridge driver and for tuner. This very well could be due to the fact that you're including your interface twice, and that the second time isn't seeing the same cache entry in the KOBJ cache.. Why are you compiling the _if.c twice? If this was to get around undefined symbols at module load time, I found that you need to add a MODULE_DEPEND to the module the provides the symbol... Yeah, I found that out myself already... I really was missing MODULE_VERSION in a bus driver and MODULE_DEPEND in a child driver. For now, I have all pieces of a puzzle laid out. I'm able to identify Philips IC (bridge), check it's subdevice, and subdriver is able to ask it's parent to do some I2C conversation to test presence of tuner. I know how bus driver can do something with a child device, and vice versa. I think that it's time to try to write an article, as Milan Obuch suggested. I hope it will save someone from bumping into the walls just like I did. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: newbus questions
On Thu, 16/03/2006 at 15:48 +0100, Milan Obuch wrote:
Looks like I'm totally newbie there. I've created small saa_if.m
file,
with CODE section, declaring two small debug functions, and two METHODS,
DEFAULTing to that functions. Now I want to update Makefile so that
typing ``make depend'' will produce .c and .h from the .m file. Looks
like /sys/conf/kmod.mk lists all .m files by name, and deals with them
on one-by-one basis, so I must manually insert all that awk -f ...
invocations for these targets, am I right?
Not necessarily. You should put saa_if.m into kmod.mk, yes, but you should
actually somewhere use it.
Or had I overlooked feature of automated codegeneration just in
Makefile?
Could you show your Makefile? I think you are missing something there - like
saa_if.h and saa_if.c, maybe...
well, I've just added 'saa_if.c saa_if.m' to SRCS, and defined two
targets:
.m.h:
awk -f @/tools/makeobjops.awk ${.ALLSRC} -h
.m.c:
awk -f @tools/makeobjops.awk ${.ALLSRC} -c
and now it works.
I would also like to thank you for tip to call device_add_child
manually, after that my subdriver automatically found the device to
probe.
P.S. I suppose, that it's worth to create some useful doc with skeleton
bus driver, one dummy method, and child driver overriding that method.
(As to me, the latest task is the easiest, at least I know how to do
this, e.g., PCI device overriding probe method).
Any idea how? Maybe manpage patch? You know, every one welcomed :)
I think it will be a small article, with skeleton of bus device driver
and skeleton of driver for device on that bus, since that is really easy
once you know how.
P.P.S Hey, that's my birthday! So I would like a toast to all BSD
developers, core team and hackers
Mnoga ljeta, mnoga ljeta, mnoga ljeta... :)
Thanks!
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
newbus questions
Hello, hackers! I need some help regarding newbus architecture. I'm trying to write driver for budget DVB cards. I have had written driver for one of those card two years ago, but it was very specific regarding tuner that must be present on card. Now these cards are EOL-ed, and they are replaced with more recent version of card with another tuner. As far as I understand, all such cards have the same architecture: there is bridge chip (Philips SAA7146) which interfaces with PC (using PCI) and tuner on the card (using I2C), so in terms of newbus Properly Written (tm) driver must be split in two parts: driver for the SAA7146 itself (which will be a ``bus-device'') and drivers for specific tuners (which will act as a child device on a SAA7146 bus). I had read arch-handbook and googled, but couldn't find an answer to some questions: 1. How to create the bus itself, and properly describe its interfaces? skeletons of bus-driver and frontend-drivers would be a GREAT help. 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. 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? 4. I would like to have driver, acting like sound -- loading one driver loads as dependencies all present sub-drivers for tuners, so after bus-driver identifies card it could try to probe sub-drivers for tuner searching for one to match. How is that done? (I suppose it can be something like no-op driver, that MODULE_DEPEND(9)s on modules it knows about)? Thanks in advance. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: newbus questions
On Thursday 16 March 2006 11:59, Artem 'ZaZooBred' Ignatiev wrote: Hello, hackers! ... As far as I understand, all such cards have the same architecture: there is bridge chip (Philips SAA7146) which interfaces with PC (using PCI) and tuner on the card (using I2C), so in terms of newbus Properly Written (tm) driver must be split in two parts: driver for the SAA7146 itself (which will be a ``bus-device'') and drivers for specific tuners (which will act as a child device on a SAA7146 bus). ... 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. 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. 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. There is maybe much more into this, but I can comment only on what I tried/did. Hopefully you could find some usefull info in my writing :) Regards, Milan -- Please reply only to mailing list. This address is filtered. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: newbus questions
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''. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: newbus questions
On Thu, Mar 16, 2006 at 01:59:52PM +0300, Artem 'ZaZooBred' Ignatiev wrote: I need some help regarding newbus architecture. I'm trying to write driver for budget DVB cards. I think Sami Bahra was going to port Video4Linux, so search archives and check in with him. I had a DVB card but gave it away 2 weeks ago. For IP over DVB info, check out Gorry Fairhurst's papers. BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: newbus questions
On Thursday 16 March 2006 13:06, Artem 'ZaZooBred' Ignatiev wrote: ... 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. i2c subsystem in FreeBSD is somewhat SMBus oriented. Look at iicsmb, smbus and smb manpages. iicbus class implements just basic primitives. 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. There is substantial difference - FreeBSD is modularised, linux (and NetBSD and OpenBSD as well, if I looked there at rught places) somehow makes i2c drivers monolithic, with code duplicated over all drivers. FreeBSD lacks this 'top-level' i2c-exec function. 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''. Look into bus_if.m - child devices are added using device_add_child. And there is device_get_parent... Oh, and maybe pcf device is similar to SAA7146 and may give you an idea on i2c driver implementation... Regards, Milan -- Please reply only to mailing list. This address is filtered. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: newbus questions
On Thu, 16/03/2006 at 15:06 +0300, Artem 'ZaZooBred' Ignatiev wrote: 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. Looks like I'm totally newbie there. I've created small saa_if.m file, with CODE section, declaring two small debug functions, and two METHODS, DEFAULTing to that functions. Now I want to update Makefile so that typing ``make depend'' will produce .c and .h from the .m file. Looks like /sys/conf/kmod.mk lists all .m files by name, and deals with them on one-by-one basis, so I must manually insert all that awk -f ... invocations for these targets, am I right? Or had I overlooked feature of automated codegeneration just in Makefile? P.S. I suppose, that it's worth to create some useful doc with skeleton bus driver, one dummy method, and child driver overriding that method. (As to me, the latest task is the easiest, at least I know how to do this, e.g., PCI device overriding probe method). P.P.S Hey, that's my birthday! So I would like a toast to all BSD developers, core team and hackers ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: newbus questions
On Thursday 16 March 2006 14:57, Artem 'ZaZooBred' Ignatiev wrote: On Thu, 16/03/2006 at 15:06 +0300, Artem 'ZaZooBred' Ignatiev wrote: 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. Looks like I'm totally newbie there. I've created small saa_if.m file, with CODE section, declaring two small debug functions, and two METHODS, DEFAULTing to that functions. Now I want to update Makefile so that typing ``make depend'' will produce .c and .h from the .m file. Looks like /sys/conf/kmod.mk lists all .m files by name, and deals with them on one-by-one basis, so I must manually insert all that awk -f ... invocations for these targets, am I right? Not necessarily. You should put saa_if.m into kmod.mk, yes, but you should actually somewhere use it. Or had I overlooked feature of automated codegeneration just in Makefile? Could you show your Makefile? I think you are missing something there - like saa_if.h and saa_if.c, maybe... P.S. I suppose, that it's worth to create some useful doc with skeleton bus driver, one dummy method, and child driver overriding that method. (As to me, the latest task is the easiest, at least I know how to do this, e.g., PCI device overriding probe method). Any idea how? Maybe manpage patch? You know, every one welcomed :) P.P.S Hey, that's my birthday! So I would like a toast to all BSD developers, core team and hackers Mnoga ljeta, mnoga ljeta, mnoga ljeta... :) Regards, Milan -- Please reply only to mailing list. This address is filtered. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: newbus questions
I maintain a driver for SAA7134 cards which does the same. The driver can be downloaded from. http://download.purpe.com SAA7134 cards interface with the PC using PCI and have an onboard I2C bus to which peripherals and tuners are connected. The tuner control layer is based entirely in userland using the iic(4) interface. rohit -- On Thu, Mar 16, 2006 at 01:59:52PM +0300, Artem 'ZaZooBred' Ignatiev wrote: Hello, hackers! I need some help regarding newbus architecture. I'm trying to write driver for budget DVB cards. I have had written driver for one of those card two years ago, but it was very specific regarding tuner that must be present on card. Now these cards are EOL-ed, and they are replaced with more recent version of card with another tuner. As far as I understand, all such cards have the same architecture: there is bridge chip (Philips SAA7146) which interfaces with PC (using PCI) and tuner on the card (using I2C), so in terms of newbus Properly Written (tm) driver must be split in two parts: driver for the SAA7146 itself (which will be a ``bus-device'') and drivers for specific tuners (which will act as a child device on a SAA7146 bus). I had read arch-handbook and googled, but couldn't find an answer to some questions: 1. How to create the bus itself, and properly describe its interfaces? skeletons of bus-driver and frontend-drivers would be a GREAT help. 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. 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? 4. I would like to have driver, acting like sound -- loading one driver loads as dependencies all present sub-drivers for tuners, so after bus-driver identifies card it could try to probe sub-drivers for tuner searching for one to match. How is that done? (I suppose it can be something like no-op driver, that MODULE_DEPEND(9)s on modules it knows about)? Thanks in advance. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: newbus questions
Artem 'ZaZooBred' Ignatiev wrote this message on Thu, Mar 16, 2006 at 13:59 +0300: As far as I understand, all such cards have the same architecture: there is bridge chip (Philips SAA7146) which interfaces with PC (using PCI) and tuner on the card (using I2C), so in terms of newbus Properly Written (tm) driver must be split in two parts: driver for the SAA7146 itself (which will be a ``bus-device'') and drivers for specific tuners (which will act as a child device on a SAA7146 bus). I'd suggest that we start adopting a method where we don't make device drivers in kernel land for the tuners, and instead make more use of iic device... That's what I did w/ bktrau that supports the DViCO FusionHDTV 5 Lite card... I just wrote a driver to handle DMA from the second function on Bt878 cards, and then compiled the bktr driver w/ SMBUS support, and loaded the iic driver.. Then w/ ioctl's, etc I am able to control the tuner, w/o a specific tuner driver.. Though not as convient as simple ioctl's, it means that this type of support can exist entirely in userland, and is less likely to have bugs, etc... This also means that we don't have to have code in the kernel to handle detection of the different tuner types, and it'll be easier to make fixes to the tuner drivers.. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: newbus questions
In message: [EMAIL PROTECTED] Artem 'ZaZooBred' Ignatiev [EMAIL PROTECTED] writes: : As far as I understand, all such cards have the same architecture: there : is bridge chip (Philips SAA7146) which interfaces with PC (using PCI) : and tuner on the card (using I2C), so in terms of newbus Properly : Written (tm) driver must be split in two parts: driver for the SAA7146 : itself (which will be a ``bus-device'') and drivers for specific tuners : (which will act as a child device on a SAA7146 bus). : : I had read arch-handbook and googled, but couldn't find an answer to : some questions: : : 1. How to create the bus itself, and properly describe its interfaces? : skeletons of bus-driver and frontend-drivers would be a GREAT help. Creating the bus is easy. The driver just adds the 'bus' device. The 'bus' device enumerates the children and adds them. Creating the bus interface can require creating a a foo_if.m interface. You'd wind up with a tree that looks like: pci0 -- your-card-driver0 -- your-bus0 -- child0 + child1 + child2 + child3 + child4 : 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. FreeBSD has a iicbus infrastructure, but I've never used it. : 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? It depends on where you want to put knowledge. If you don't mind the your-bus0 driver knowing, it can ask its parent what the subdevice ID is and then use that to populate the children. : 4. I would like to have driver, acting like sound -- loading one : driver loads as dependencies all present sub-drivers for tuners, so : after bus-driver identifies card it could try to probe sub-drivers for : tuner searching for one to match. How is that done? (I suppose it can be : something like no-op driver, that MODULE_DEPEND(9)s on modules it knows : about)? This is much more complicated. I'd wait until I got the basic driver working before trying to tackle this. I said this because during driver development, you may change your mind on the interrelationships between the different parts of your drivers. It is easy to retrofit functionality like this in later. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: more Newbus questions
None of these are newbus items. Interrupt dispatch is not managed by newbus (due to the costs involved). Instead, interrupts are attached with bus_setup_intr, which forwards the interrupt handler and argument to platform-specific code. The resource mananger is involved (since interrupts are a managed resource), and interrupts must be allocated using bus_alloc_resource before being set up. Could you possibly go over how this works on the i386. Is there a global structure that keeps track of all allocated IRQs and interrupt handling routines? What I really need, is to find out, where this structure is built, so that at this point, I can instead build the structure that xmach needs. Or, alternatively, I can wait until that structure is done, and then make the xmach structure from that... Thanks again, JAn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: more Newbus questions
This is *totally* not how to do interrupts with Mach. You should be creating a thread for each interrupt source, and keeping a worklist of interrupt handlers registered against that source. Unfortunately, I can't help you with Mach-related things, since I work for Apple and that'd put me in a conflict-of-interest situation. 8( None of these are newbus items. Interrupt dispatch is not managed by newbus (due to the costs involved). Instead, interrupts are attached with bus_setup_intr, which forwards the interrupt handler and argument to platform-specific code. The resource mananger is involved (since interrupts are a managed resource), and interrupts must be allocated using bus_alloc_resource before being set up. Could you possibly go over how this works on the i386. Is there a global structure that keeps track of all allocated IRQs and interrupt handling routines? What I really need, is to find out, where this structure is built, so that at this point, I can instead build the structure that xmach needs. Or, alternatively, I can wait until that structure is done, and then make the xmach structure from that... Thanks again, JAn -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: more Newbus questions
On 15-Aug-01 Mike Smith wrote: This is *totally* not how to do interrupts with Mach. You should be creating a thread for each interrupt source, and keeping a worklist of interrupt handlers registered against that source. That's bascially how ithreads work in -current right now.. Could you possibly go over how this works on the i386. Is there a global structure that keeps track of all allocated IRQs and interrupt handling routines? What I really need, is to find out, where this structure is built, so that at this point, I can instead build the structure that xmach needs. Or, alternatively, I can wait until that structure is done, and then make the xmach structure from that... Thanks again, Go read sys/i386/isa/intr_machdep.c (I know, isa/ is a bad place for it..) Also look at sys/kern/kern_intr.c and the ithread manpage to understand the MI ithread portions. JAn -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: more Newbus questions
Thanks, will do JAn Go read sys/i386/isa/intr_machdep.c (I know, isa/ is a bad place for it..) Also look at sys/kern/kern_intr.c and the ithread manpage to understand the MI ithread portions. JAn -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: more Newbus questions
OK, this is helpful, but I have looked at this before. this seems to be where the interrupt vector table is initialized.(correct me if I am wrong..) NOw, where do the devices that newbus finds and probes get inserted into these structures(intr_handler,intr_mptr, etc)? Also, what are fastintr[] and slowintr[] for? I know I am being a pain, but I appreciae the help JAn Go read sys/i386/isa/intr_machdep.c (I know, isa/ is a bad place for it..) Also look at sys/kern/kern_intr.c and the ithread manpage to understand the MI ithread portions. JAn -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: more Newbus questions
On 15-Aug-01 [EMAIL PROTECTED] wrote: OK, this is helpful, but I have looked at this before. this seems to be where the interrupt vector table is initialized.(correct me if I am wrong..) NOw, where do the devices that newbus finds and probes get inserted into these structures(intr_handler,intr_mptr, etc)? Also, what are fastintr[] and slowintr[] for? Look at the nexus driver for i386. That is where bus_setup_intr and bus_teardown_intr() finally end up ending. They end up calling the inthand_add() and inthand_remove() functions. Slow interrupts are threaded interrupts (run in an ithread), fast interrupts are non-threaded (and thus synchronous) and are used for clock and sio interrupts. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
more Newbus questions
First, I would like to thank all of you who answered my first question. I have spent the past couple of days reading through the newbus code, and have a couple more questions. I think I have a pretty good Idea about the device tree by now, but I am a bit confused, as to how the interrupts are handled. Can someone pease explain how the data structure(s) are organized, and used? As far as I can tell, there are several arrays, which are somehow used together, those being intr_handler[], intr_mptr[], intr_mask[], intr_unit[], and intr_countp[]. I find it very difficult to tell by the source code, how these structures are initialized, and how they are used later on. Lastly, there are two arrays, fastintr[] and slowintr[], which also look like some sort of table iwth interrupt handing routine pointers. What are those for, and where is the difference between the two? I admit, I am a bit confused, so I would greatly appreaciate, if someone can clear the whole Newbus IRQ handling stuff for me.. Thanks, JAn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
newbus questions
Hi all, there are two recent articles on newbus on daemonnews, and one at people.freebsd.org/~asmodai by jeroen. Does anyone remember seeing any others? I thought for sure i remembered seeing a article explaining the OO design concepts behind newbus, particularly the use of soft_c, the local data, the global data, and methods for a particular device. jm -- --- Jonathon McKitrick -- [EMAIL PROTECTED] Honk if you hate people too. --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
