Re: RE: How to use saa7134 gpio via gpio-sysfs?
On Mon, Jan 18, 2010 at 5:01 PM, hermann pitton hermann-pit...@arcor.de wrote: Hello, Am Montag, den 18.01.2010, 18:11 -0500 schrieb Will Tate: I'm not sure why access in userspace would be required. I checked the schematic today and all the GPIO pins are used to communicate with the SAA6752HS on board for compression. We do not bring the GPIO off the board anywhere. thank you very much. I was still expecting that and did not get Gordon's point, but must admit to have been totally unaware about the DI/O features. RTD did all the hardware implementations themselves. Very nice job that time. Gordon and I have spoken previously about the RTD software for digital I/O breaking with the migration of pcf8574 driver to the pcf857x. So, perhaps he intended to use GPIO until I can fix the digital I/O software. Ah, good to know. BTW, we had the mpeg encoder broken unnoticed for some kernels, but due to fixes by Dmitri Belimov and extensions by Hans Verkuil, we are much better on it these days. Enjoy. Always let us know, if we can do anything or at least make it public for those interested to work on it. Thanks, Hermann Hello Hermann, good to hear from you again. It looks like I was off track regarding GPIO. In 2.6.30 the pcf8574 module that was used for digital I/O earlier was no longer available and something I read lead me to believe I should use gpio-sysfs instead. I'm sorry for the noise. - Gordon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RE: How to use saa7134 gpio via gpio-sysfs?
Hello Gordon, Am Dienstag, den 19.01.2010, 10:24 -0700 schrieb Gordon Smith: On Mon, Jan 18, 2010 at 5:01 PM, hermann pitton hermann-pit...@arcor.de wrote: Hello, Am Montag, den 18.01.2010, 18:11 -0500 schrieb Will Tate: I'm not sure why access in userspace would be required. I checked the schematic today and all the GPIO pins are used to communicate with the SAA6752HS on board for compression. We do not bring the GPIO off the board anywhere. thank you very much. I was still expecting that and did not get Gordon's point, but must admit to have been totally unaware about the DI/O features. RTD did all the hardware implementations themselves. Very nice job that time. Gordon and I have spoken previously about the RTD software for digital I/O breaking with the migration of pcf8574 driver to the pcf857x. So, perhaps he intended to use GPIO until I can fix the digital I/O software. Ah, good to know. BTW, we had the mpeg encoder broken unnoticed for some kernels, but due to fixes by Dmitri Belimov and extensions by Hans Verkuil, we are much better on it these days. Enjoy. Always let us know, if we can do anything or at least make it public for those interested to work on it. Thanks, Hermann Hello Hermann, good to hear from you again. It looks like I was off track regarding GPIO. In 2.6.30 the pcf8574 module that was used for digital I/O earlier was no longer available and something I read lead me to believe I should use gpio-sysfs instead. I'm sorry for the noise. - Gordon no problem at all. It was quite interesting to think about such gpio use. If such a card appears in the future, we can point to the thread you started here and have already, thanks to Trent, a collection of good ideas and comments. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: How to use saa7134 gpio via gpio-sysfs?
Gentlemen, I may be able to assist here. Specifically what information/photographs are you looking for? Regards, William Tate RTD Embedded Technologies, Inc. -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of hermann pitton Sent: Sunday, January 17, 2010 6:02 PM To: Trent Piepho Cc: Gordon Smith; linux-media@vger.kernel.org Subject: Re: How to use saa7134 gpio via gpio-sysfs? [snip] Damned, seems the opto-isolated I/Os might be in question. For the RTD stuff we don't have any high resolution photographs or anything else ... Gordon, we should wait for, if RTD and Philips/NXP do have a agreement on such. I doubt it, given how it came in. Else, you can of course still do what you ever want on that driver. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: How to use saa7134 gpio via gpio-sysfs?
Hi, Am Montag, den 18.01.2010, 09:13 -0500 schrieb William Tate: Gentlemen, I may be able to assist here. Specifically what information/photographs are you looking for? Regards, William Tate RTD Embedded Technologies, Inc. Gordon, please explain, why you would like to have access to some of the saa713x gpios on that device from userspace. Unknown to me previously, it seems RTD already provides software for their customers to use the digital I/Os, but restricted to owners of such devices. For an example of how to use VFG73xx digital I/O, please see the Software Product SWP-700010065 “Linux Software (VFG73xx)” available from the RTD web site William, is there a desire to have such gpio access from userspace on your side? Trent kindly outlined some details. Please give us some brief explanations in that case. Thanks for offering your help. Hermann -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of hermann pitton Sent: Sunday, January 17, 2010 6:02 PM To: Trent Piepho Cc: Gordon Smith; linux-media@vger.kernel.org Subject: Re: How to use saa7134 gpio via gpio-sysfs? [snip] Damned, seems the opto-isolated I/Os might be in question. For the RTD stuff we don't have any high resolution photographs or anything else ... Gordon, we should wait for, if RTD and Philips/NXP do have a agreement on such. I doubt it, given how it came in. Else, you can of course still do what you ever want on that driver. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RE: How to use saa7134 gpio via gpio-sysfs?
Hello, Am Montag, den 18.01.2010, 18:11 -0500 schrieb Will Tate: I'm not sure why access in userspace would be required. I checked the schematic today and all the GPIO pins are used to communicate with the SAA6752HS on board for compression. We do not bring the GPIO off the board anywhere. thank you very much. I was still expecting that and did not get Gordon's point, but must admit to have been totally unaware about the DI/O features. RTD did all the hardware implementations themselves. Very nice job that time. Gordon and I have spoken previously about the RTD software for digital I/O breaking with the migration of pcf8574 driver to the pcf857x. So, perhaps he intended to use GPIO until I can fix the digital I/O software. Ah, good to know. BTW, we had the mpeg encoder broken unnoticed for some kernels, but due to fixes by Dmitri Belimov and extensions by Hans Verkuil, we are much better on it these days. Enjoy. Always let us know, if we can do anything or at least make it public for those interested to work on it. Thanks, Hermann On Jan 18, 2010 5:43 PM, hermann pitton hermann-pit...@arcor.de wrote: Hi, Am Montag, den 18.01.2010, 09:13 -0500 schrieb William Tate: Gentlemen, I may be able to assist here. Specifically what information/photographs are you l... Gordon, please explain, why you would like to have access to some of the saa713x gpios on that device from userspace. Unknown to me previously, it seems RTD already provides software for their customers to use the digital I/Os, but restricted to owners of such devices. For an example of how to use VFG73xx digital I/O, please see the Software Product SWP-700010065 “Linux Software (VFG73xx)” available from the RTD web site William, is there a desire to have such gpio access from userspace on your side? Trent kindly outlined some details. Please give us some brief explanations in that case. Thanks for offering your help. Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to use saa7134 gpio via gpio-sysfs?
[snip] Damned, seems the opto-isolated I/Os might be in question. For the RTD stuff we don't have any high resolution photographs or anything else ... Gordon, we should wait for, if RTD and Philips/NXP do have a agreement on such. I doubt it, given how it came in. Else, you can of course still do what you ever want on that driver. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to use saa7134 gpio via gpio-sysfs?
On Sat, 16 Jan 2010, hermann pitton wrote: Am Freitag, den 15.01.2010, 17:27 -0800 schrieb Trent Piepho: On Sat, 16 Jan 2010, hermann pitton wrote: Am Dienstag, den 12.01.2010, 04:13 +0100 schrieb hermann pitton: gpio-sysfs creates /sys/class/gpio/export /sys/class/gpio/import but no gpion entries so far. The saa713x driver predates the generic gpio layer by years and years, so it doesn't use it. It also doesn't need to use it. Since the gpios are managed by the saa713x driver, and they also used by the saa713x driver, there is no need to interface two different drivers together. There are tons of drivers for devices that have gpios like this, but they don't use the gpio layer. But with gpio access via sysfs for generic gpios, there is something useful about having the saa713x driver support generic gpios. IIRC, somehow wrote a gpio only bt848 driver that didn't do anything but export gpios. In order to do this, you'll have to write code for the saa7134 driver to have it register with the gpio layer. I think you could still have the saa7134 driver itself use its gpio directly. That would avoid a performance penalty in the driver. Thanks for more details, but I'm still wondering what pins ever could be interesting in userland, given that they are all treated such different per device, and we count up to 200 different boards these days. There are some cards for intended for survilence or embedded applications that have headers on them to connect things to the GPIOs. Like alarms or camera controllers and stuff like that. The GPIO only bttv driver was created by someone who just soldered a bunch of wires on a cheap bt848 card, you can get them for just a few dollars, as it was a cheap and easy way to get a bunch of gpios in a pc. See his page here http://www.bu3sch.de/joomla/index.php/bt8xx-based-gpio-card There are cards you can get that just have GPIOs, but they end up being rather expensive. Here's one: http://www.acromag.com/parts.cfm?Model_ID=317Product_Function_ID=4Category_ID=18Group_ID=1 Way fancier than a tv card, but it's $600. I think if I was doing the coding, I'd add a field in the card description for what GPIOs should be exported. I.e., which ones have an external header. Maybe in addition to, or instead of, I'd have a module option that would cause GPIOs to be exported. A bitmask of which to export would be enough. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to use saa7134 gpio via gpio-sysfs?
Am Samstag, den 16.01.2010, 04:15 -0800 schrieb Trent Piepho: On Sat, 16 Jan 2010, hermann pitton wrote: Am Freitag, den 15.01.2010, 17:27 -0800 schrieb Trent Piepho: On Sat, 16 Jan 2010, hermann pitton wrote: Am Dienstag, den 12.01.2010, 04:13 +0100 schrieb hermann pitton: gpio-sysfs creates /sys/class/gpio/export /sys/class/gpio/import but no gpion entries so far. The saa713x driver predates the generic gpio layer by years and years, so it doesn't use it. It also doesn't need to use it. Since the gpios are managed by the saa713x driver, and they also used by the saa713x driver, there is no need to interface two different drivers together. There are tons of drivers for devices that have gpios like this, but they don't use the gpio layer. But with gpio access via sysfs for generic gpios, there is something useful about having the saa713x driver support generic gpios. IIRC, somehow wrote a gpio only bt848 driver that didn't do anything but export gpios. In order to do this, you'll have to write code for the saa7134 driver to have it register with the gpio layer. I think you could still have the saa7134 driver itself use its gpio directly. That would avoid a performance penalty in the driver. Thanks for more details, but I'm still wondering what pins ever could be interesting in userland, given that they are all treated such different per device, and we count up to 200 different boards these days. There are some cards for intended for survilence or embedded applications that have headers on them to connect things to the GPIOs. Like alarms or camera controllers and stuff like that. The GPIO only bttv driver was created by someone who just soldered a bunch of wires on a cheap bt848 card, you can get them for just a few dollars, as it was a cheap and easy way to get a bunch of gpios in a pc. See his page here http://www.bu3sch.de/joomla/index.php/bt8xx-based-gpio-card There are cards you can get that just have GPIOs, but they end up being rather expensive. Here's one: http://www.acromag.com/parts.cfm?Model_ID=317Product_Function_ID=4Category_ID=18Group_ID=1 Way fancier than a tv card, but it's $600. I think if I was doing the coding, I'd add a field in the card description for what GPIOs should be exported. I.e., which ones have an external header. Maybe in addition to, or instead of, I'd have a module option that would cause GPIOs to be exported. A bitmask of which to export would be enough. Cool stuff! Are we aware of boards under mass production connecting unused gpios to a panel already, providing external gpio functionality? The RTD one in question seems not to do so yet. http://www.rtd.com/pc104/UM/video/VFG7350ER.htm Thanks, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to use saa7134 gpio via gpio-sysfs?
Am Sonntag, den 17.01.2010, 01:08 +0100 schrieb hermann pitton: Am Samstag, den 16.01.2010, 04:15 -0800 schrieb Trent Piepho: On Sat, 16 Jan 2010, hermann pitton wrote: Am Freitag, den 15.01.2010, 17:27 -0800 schrieb Trent Piepho: On Sat, 16 Jan 2010, hermann pitton wrote: Am Dienstag, den 12.01.2010, 04:13 +0100 schrieb hermann pitton: gpio-sysfs creates /sys/class/gpio/export /sys/class/gpio/import but no gpion entries so far. The saa713x driver predates the generic gpio layer by years and years, so it doesn't use it. It also doesn't need to use it. Since the gpios are managed by the saa713x driver, and they also used by the saa713x driver, there is no need to interface two different drivers together. There are tons of drivers for devices that have gpios like this, but they don't use the gpio layer. But with gpio access via sysfs for generic gpios, there is something useful about having the saa713x driver support generic gpios. IIRC, somehow wrote a gpio only bt848 driver that didn't do anything but export gpios. In order to do this, you'll have to write code for the saa7134 driver to have it register with the gpio layer. I think you could still have the saa7134 driver itself use its gpio directly. That would avoid a performance penalty in the driver. Thanks for more details, but I'm still wondering what pins ever could be interesting in userland, given that they are all treated such different per device, and we count up to 200 different boards these days. There are some cards for intended for survilence or embedded applications that have headers on them to connect things to the GPIOs. Like alarms or camera controllers and stuff like that. The GPIO only bttv driver was created by someone who just soldered a bunch of wires on a cheap bt848 card, you can get them for just a few dollars, as it was a cheap and easy way to get a bunch of gpios in a pc. See his page here http://www.bu3sch.de/joomla/index.php/bt8xx-based-gpio-card There are cards you can get that just have GPIOs, but they end up being rather expensive. Here's one: http://www.acromag.com/parts.cfm?Model_ID=317Product_Function_ID=4Category_ID=18Group_ID=1 Way fancier than a tv card, but it's $600. I think if I was doing the coding, I'd add a field in the card description for what GPIOs should be exported. I.e., which ones have an external header. Maybe in addition to, or instead of, I'd have a module option that would cause GPIOs to be exported. A bitmask of which to export would be enough. Cool stuff! Are we aware of boards under mass production connecting unused gpios to a panel already, providing external gpio functionality? The RTD one in question seems not to do so yet. http://www.rtd.com/pc104/UM/video/VFG7350ER.htm Damned, seems the opto-isolated I/Os might be in question. For the RTD stuff we don't have any high resolution photographs or anything else ... -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to use saa7134 gpio via gpio-sysfs?
Am Dienstag, den 12.01.2010, 04:13 +0100 schrieb hermann pitton: Hi! Am Montag, den 11.01.2010, 11:59 -0700 schrieb Gordon Smith: I need to bit twiddle saa7134 gpio pins from userspace. To use gpio-sysfs, I need a GPIO number to export each pin, but I do not know how to find such a number. Card is RTD Embedded Technologies VFG7350 [card=72,autodetected]. GPIO uses pcf8574 chip. Kernel is 2.6.30. gpio-sysfs creates /sys/class/gpio/export /sys/class/gpio/import but no gpion entries so far. From dmesg (gpiotracking=1) saa7133[0]: board init: gpio is 1 saa7133[0]: gpio: mode=0x000 in=0x4011000 out=0x000 [pre-init] saa7133[1]: board init: gpio is 1 saa7133[1]: gpio: mode=0x000 in=0x4010f00 out=0x000 [pre-init] How may I find each GPIO number for this board? Thanks in advance for any help. There are 28 (0-27) gpio pins on each saa713x chip. Documentation about possible use cases is publicly available via nxp.com. You can do what ever you want with them, but to export them to userland seems to be a very bad idea to me. Likely soon some advanced hackers will damage ;) all kind of hardware around and others will claim it as being a GNU/Linux problem within the same time such stuff appears, and of course it will. In fact these days, only one to three users are involved hacking on a board. It is much cheaper for all involved to give the serial number of those than to imagine every day, what all could happen. For all others not yet active, avoiding any worst case through contributing is the way to go. For the rest, we likely should have some fund, for worst cases, payed by themselves. Cheers, Hermann Hi Trent, thought there would be straight PROs too, but no reply so far. If you ever want, could you elaborate a little, what for userspace gpios can be useful at all and why people eventually also can run into problems with such pins, since they are somehow also under control of manufacturers. Means they do use them all different within _some_ rules. Given all the different use cases of gpio pins, for example on the saa7134 driver, which ones should we eventually export to gpio-sysfs to try to understand that approach better? Do we have such pins at all? Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to use saa7134 gpio via gpio-sysfs?
On Sat, 16 Jan 2010, hermann pitton wrote: Am Dienstag, den 12.01.2010, 04:13 +0100 schrieb hermann pitton: gpio-sysfs creates /sys/class/gpio/export /sys/class/gpio/import but no gpion entries so far. You have to explictly export the GPIO lines to get them to appear. Either in the kernel with gpio_export() or from sysfs. You also can't export GPIOs that something in the kernel is using. My original design didn't have this restriction. I felt there were valid debug and development reasons for doing so, having used them myself for debug and development of embedded systems, but David Brownell felt otherwise. I didn't even have the concept of export originally, all the gpios would show up. After all, all your PCI and USB devices, I2C chips or busses, etc. show up in sysfs. Nothing else does this must be exported to show up business. You can memory map the saa7133 PCI address space and modify the gpios, and anything else, with direct register access from userspace, and that's just fine. But being able to observe and modify the gpios with a gpio-only interface is just way too dangerous. Doesn't make sense. But I'm digressing. This sysfs interface only works with the gpio using the generic gpio layer. This was designed for generic gpios on SoCs that would be providing by some kind of platform driver or I2C gpio extenders. The gpios get and used by various other drivers. Like say write protects on memory cards, or system LEDs. I wrote a JTAG driver that used it. The point of the gpio layer is to interface drivers the provide gpios with other, different, drivers that use the gpio. It was introduced in the mid 2.6.20s IIRC. The saa713x driver predates the generic gpio layer by years and years, so it doesn't use it. It also doesn't need to use it. Since the gpios are managed by the saa713x driver, and they also used by the saa713x driver, there is no need to interface two different drivers together. There are tons of drivers for devices that have gpios like this, but they don't use the gpio layer. But with gpio access via sysfs for generic gpios, there is something useful about having the saa713x driver support generic gpios. IIRC, somehow wrote a gpio only bt848 driver that didn't do anything but export gpios. In order to do this, you'll have to write code for the saa7134 driver to have it register with the gpio layer. I think you could still have the saa7134 driver itself use its gpio directly. That would avoid a performance penalty in the driver. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to use saa7134 gpio via gpio-sysfs?
Am Freitag, den 15.01.2010, 17:27 -0800 schrieb Trent Piepho: On Sat, 16 Jan 2010, hermann pitton wrote: Am Dienstag, den 12.01.2010, 04:13 +0100 schrieb hermann pitton: gpio-sysfs creates /sys/class/gpio/export /sys/class/gpio/import but no gpion entries so far. You have to explictly export the GPIO lines to get them to appear. Either in the kernel with gpio_export() or from sysfs. You also can't export GPIOs that something in the kernel is using. My original design didn't have this restriction. I felt there were valid debug and development reasons for doing so, having used them myself for debug and development of embedded systems, but David Brownell felt otherwise. I didn't even have the concept of export originally, all the gpios would show up. After all, all your PCI and USB devices, I2C chips or busses, etc. show up in sysfs. Nothing else does this must be exported to show up business. You can memory map the saa7133 PCI address space and modify the gpios, and anything else, with direct register access from userspace, and that's just fine. But being able to observe and modify the gpios with a gpio-only interface is just way too dangerous. Doesn't make sense. But I'm digressing. This sysfs interface only works with the gpio using the generic gpio layer. This was designed for generic gpios on SoCs that would be providing by some kind of platform driver or I2C gpio extenders. The gpios get and used by various other drivers. Like say write protects on memory cards, or system LEDs. I wrote a JTAG driver that used it. The point of the gpio layer is to interface drivers the provide gpios with other, different, drivers that use the gpio. It was introduced in the mid 2.6.20s IIRC. The saa713x driver predates the generic gpio layer by years and years, so it doesn't use it. It also doesn't need to use it. Since the gpios are managed by the saa713x driver, and they also used by the saa713x driver, there is no need to interface two different drivers together. There are tons of drivers for devices that have gpios like this, but they don't use the gpio layer. But with gpio access via sysfs for generic gpios, there is something useful about having the saa713x driver support generic gpios. IIRC, somehow wrote a gpio only bt848 driver that didn't do anything but export gpios. In order to do this, you'll have to write code for the saa7134 driver to have it register with the gpio layer. I think you could still have the saa7134 driver itself use its gpio directly. That would avoid a performance penalty in the driver. Thanks for more details, but I'm still wondering what pins ever could be interesting in userland, given that they are all treated such different per device, and we count up to 200 different boards these days. For now, we should only allow user control over such pins above any count from 0 to 27, what the m$ driver does rounding up nothing ;) Or is there one single pin, potentially useful in userland? They can all be ambiguous, multi purpose per device, for what I can see. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to use saa7134 gpio via gpio-sysfs?
Hi! Am Montag, den 11.01.2010, 11:59 -0700 schrieb Gordon Smith: I need to bit twiddle saa7134 gpio pins from userspace. To use gpio-sysfs, I need a GPIO number to export each pin, but I do not know how to find such a number. Card is RTD Embedded Technologies VFG7350 [card=72,autodetected]. GPIO uses pcf8574 chip. Kernel is 2.6.30. gpio-sysfs creates /sys/class/gpio/export /sys/class/gpio/import but no gpion entries so far. From dmesg (gpiotracking=1) saa7133[0]: board init: gpio is 1 saa7133[0]: gpio: mode=0x000 in=0x4011000 out=0x000 [pre-init] saa7133[1]: board init: gpio is 1 saa7133[1]: gpio: mode=0x000 in=0x4010f00 out=0x000 [pre-init] How may I find each GPIO number for this board? Thanks in advance for any help. There are 28 (0-27) gpio pins on each saa713x chip. Documentation about possible use cases is publicly available via nxp.com. You can do what ever you want with them, but to export them to userland seems to be a very bad idea to me. Likely soon some advanced hackers will damage ;) all kind of hardware around and others will claim it as being a GNU/Linux problem within the same time such stuff appears, and of course it will. In fact these days, only one to three users are involved hacking on a board. It is much cheaper for all involved to give the serial number of those than to imagine every day, what all could happen. For all others not yet active, avoiding any worst case through contributing is the way to go. For the rest, we likely should have some fund, for worst cases, payed by themselves. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
