Re: [PATCH 0/3] FM Transmitter driver
Hello again, On Fri, Apr 03, 2009 at 01:48:21PM +0200, Valentin Eduardo (Nokia-D/Helsinki) wrote: On Fri, Apr 03, 2009 at 01:29:27PM +0200, ext Hans Verkuil wrote: On Friday 03 April 2009 12:48:19 Eduardo Valentin wrote: Hi, On Fri, Apr 03, 2009 at 12:36:53PM +0200, ext Hans Verkuil wrote: On Friday 03 April 2009 12:12:30 Eduardo Valentin wrote: On Thu, Apr 02, 2009 at 06:36:37PM +0200, ext Hans Verkuil wrote: On Thursday 02 April 2009 14:02:11 Eduardo Valentin wrote: Hi Hans, On Thu, Apr 02, 2009 at 09:47:11AM +0200, ext Hans Verkuil wrote: On Wednesday 01 April 2009 11:43:28 Eduardo Valentin wrote: Hello Mauro and v4l guys, This series contains a v4l2 radio driver which adds support for Silabs si4713 devices. That is a FM transmitter device. As you should know, v4l2 does not contain representation of FM Transmitters (at least that I know). So this driver was written highly based on FM receivers API, which can cover most of basic functionality. However, as expected, there are some properties which were not covered. For those properties, sysfs nodes were added in order to get user interactions. Comments are wellcome. Can you explain in reasonable detail the extra properties needed for a device like this? You will need to document that anyway :-) Rather than implementing a private API it would be much more interesting to turn this into a public V4L2 API that everyone can use. Yes, here is a little description of them: Pilot is an audible tone sent by the device. pilot_frequency - Configures the frequency of the stereo pilot tone. pilot_deviation - Configures pilot tone frequency deviation level. pilot_enabled - Enables or disables the pilot tone feature. The si4713 device is capable of applying audio compression to the transmitted signal. acomp_enabled - Enables or disables the audio dynamic range control feature. acomp_gain - Sets the gain for audio dynamic range control. acomp_threshold - Sets the threshold level for audio dynamic range control. acomp_attack_time - Sets the attack time for audio dynamic range control. acomp_release_time - Sets the release time for audio dynamic range control. Limiter setups audio deviation limiter feature. Once a over deviation occurs, it is possible to adjust the front-end gain of the audio input and always prevent over deviation. limiter_enabled - Enables or disables the limiter feature. limiter_deviation - Configures audio frequency deviation level. limiter_release_time - Sets the limiter release time. power_level - Sets the output power level for signal transmission. Hmm, there are two ways to implement these: either make a bunch of VIDIOC's for each of these categories, or use extended controls to set all these values. I'm hardly an expert on FM transmitters, but it all seems reasonable to me (i.e., not too specific for this chip). I am leaning towards extended controls, since that's so easy to extend if needed in the future. And I still intend to add sysfs support to controls in the future. On the other hand, it's a bit harder to use compared to normal VIDIOCs. Could you please explain more about extended controls vs. VIDIOC's? Pointing drivers which uses one of those also would be worth. But yes, looks like moving this properties to some sort of v4l2 control looks better implementation. The spec explains it pretty well. The most up to date version of the spec is available here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html. Basically the extended controls API is more flexible than the older VIDIOC_S/G_CTRL ioctls, allowing to set controls atomically (either all are applied or none) and allowing for a wider range of types, although currently that feature isn't used. It's used by uvcvideo and by MPEG encoders (e.g. cx18, ivtv and others). Using VIDIOCs is easier, but much harder to make future-proof. One disadvantage of using extended controls is that it is harder to implement in drivers, although I plan on creating a much better solution for that in the coming months. With the new v4l framework it should be possible to move much of the control handling into the framework and so simplifying the drivers. RDS related rds_enabled - Enables or disables the RDS feature. rds_ps_name - Sets the RDS ps name field for transmission. rds_radio_text - Sets the RDS radio text for transmission. rds_pi - Sets the RDS PI field for
Re: [PATCH 0/3] FM Transmitter driver
Hello again, On Fri, Apr 03, 2009 at 01:48:21PM +0200, Valentin Eduardo (Nokia-D/Helsinki) wrote: On Fri, Apr 03, 2009 at 01:29:27PM +0200, ext Hans Verkuil wrote: 2. Split driver into i2c driver (common/tunner?) and media/radio Not common/tuner, I think it can just go into media/radio. As long as it is a stand-alone i2c driver that can be reused. Ok. right. One question about this split. AFAIU, the split should go as: - one i2c driver under media/radio, which handles the i2c device itself and also registers itself as a v4l2_subdev_tuner of v4l2_subdevice api. - another driver under media/radio, which actually registers the v4l2_device as VFL_TYPE_RADIO and uses the i2c driver through the v4l2_subdev api (v4l2_subdev_call ??). In this case, I see this second driver as platform driver. Is that correct ? Yes, that's correct. Any good example of driver which does this? We do not currently have platform drivers that do that, but you can take a look at usbvision, which is probably the simplest of the lot when it comes to this. A more complicated example would be saa7134. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: [PATCH 0/3] FM Transmitter driver
Hello, Am Freitag, 3. April 2009 12:12 schrieb Eduardo Valentin: On Thu, Apr 02, 2009 at 06:36:37PM +0200, ext Hans Verkuil wrote: On Thursday 02 April 2009 14:02:11 Eduardo Valentin wrote: Hi Hans, On Thu, Apr 02, 2009 at 09:47:11AM +0200, ext Hans Verkuil wrote: On Wednesday 01 April 2009 11:43:28 Eduardo Valentin wrote: Hello Mauro and v4l guys, This series contains a v4l2 radio driver which adds support for Silabs si4713 devices. That is a FM transmitter device. As you should know, v4l2 does not contain representation of FM Transmitters (at least that I know). So this driver was written highly based on FM receivers API, which can cover most of basic functionality. However, as expected, there are some properties which were not covered. For those properties, sysfs nodes were added in order to get user interactions. Comments are wellcome. Can you explain in reasonable detail the extra properties needed for a device like this? You will need to document that anyway :-) Rather than implementing a private API it would be much more interesting to turn this into a public V4L2 API that everyone can use. Yes, here is a little description of them: Pilot is an audible tone sent by the device. pilot_frequency - Configures the frequency of the stereo pilot tone. pilot_deviation - Configures pilot tone frequency deviation level. pilot_enabled - Enables or disables the pilot tone feature. The si4713 device is capable of applying audio compression to the transmitted signal. acomp_enabled - Enables or disables the audio dynamic range control feature. acomp_gain - Sets the gain for audio dynamic range control. acomp_threshold - Sets the threshold level for audio dynamic range control. acomp_attack_time - Sets the attack time for audio dynamic range control. acomp_release_time - Sets the release time for audio dynamic range control. Limiter setups audio deviation limiter feature. Once a over deviation occurs, it is possible to adjust the front-end gain of the audio input and always prevent over deviation. limiter_enabled - Enables or disables the limiter feature. limiter_deviation - Configures audio frequency deviation level. limiter_release_time - Sets the limiter release time. power_level - Sets the output power level for signal transmission. Hmm, there are two ways to implement these: either make a bunch of VIDIOC's for each of these categories, or use extended controls to set all these values. I'm hardly an expert on FM transmitters, but it all seems reasonable to me (i.e., not too specific for this chip). I am leaning towards extended controls, since that's so easy to extend if needed in the future. And I still intend to add sysfs support to controls in the future. On the other hand, it's a bit harder to use compared to normal VIDIOCs. Could you please explain more about extended controls vs. VIDIOC's? Pointing drivers which uses one of those also would be worth. But yes, looks like moving this properties to some sort of v4l2 control looks better implementation. RDS related rds_enabled - Enables or disables the RDS feature. rds_ps_name - Sets the RDS ps name field for transmission. rds_radio_text - Sets the RDS radio text for transmission. rds_pi - Sets the RDS PI field for transmission. rds_pty - Sets the RDS PTY field for transmission. So you set the fields and the RDS encoder will just start using them? Once you have rds_enabled set, yes, it will transmit them. This too can be done with controls (needs some work, though, to support string controls). Yes, true. Region related Setting region will affect other region properties. region_bottom_frequency region_channel_spacing region_preemphasis region_top_frequency I do not know enough about FM transmissions to judge this. Are these region properties something that is regulated by some standards commision? Do they also apply when you modulate this over a TV/radio cable system? Do you have some documentation or links that I can look at to learn more about this? stereo_enabled - Enables or disables stereo mode. How does one pass the audio and rds data to the driver? Note that for 2.6.31 we will finalize the V4L2 RDS decoder API (I recently posted an RFC for that, but I haven't had the time to implement the few changes needed). It would be nice if rds modulator support would be modeled after this demodulator API if possible. I see. This is good. I think the best way is to have a rds modulator interface. This driver have implemented it as sys properties, as described above. I don't think there is that much overlap, though. The similarities are probably limited to some flags. Does region information really belong in the driver? Perhaps
Re: [PATCH 0/3] FM Transmitter driver
On Thu, Apr 02, 2009 at 06:36:37PM +0200, ext Hans Verkuil wrote: On Thursday 02 April 2009 14:02:11 Eduardo Valentin wrote: Hi Hans, On Thu, Apr 02, 2009 at 09:47:11AM +0200, ext Hans Verkuil wrote: On Wednesday 01 April 2009 11:43:28 Eduardo Valentin wrote: Hello Mauro and v4l guys, This series contains a v4l2 radio driver which adds support for Silabs si4713 devices. That is a FM transmitter device. As you should know, v4l2 does not contain representation of FM Transmitters (at least that I know). So this driver was written highly based on FM receivers API, which can cover most of basic functionality. However, as expected, there are some properties which were not covered. For those properties, sysfs nodes were added in order to get user interactions. Comments are wellcome. Can you explain in reasonable detail the extra properties needed for a device like this? You will need to document that anyway :-) Rather than implementing a private API it would be much more interesting to turn this into a public V4L2 API that everyone can use. Yes, here is a little description of them: Pilot is an audible tone sent by the device. pilot_frequency - Configures the frequency of the stereo pilot tone. pilot_deviation - Configures pilot tone frequency deviation level. pilot_enabled - Enables or disables the pilot tone feature. The si4713 device is capable of applying audio compression to the transmitted signal. acomp_enabled - Enables or disables the audio dynamic range control feature. acomp_gain - Sets the gain for audio dynamic range control. acomp_threshold - Sets the threshold level for audio dynamic range control. acomp_attack_time - Sets the attack time for audio dynamic range control. acomp_release_time - Sets the release time for audio dynamic range control. Limiter setups audio deviation limiter feature. Once a over deviation occurs, it is possible to adjust the front-end gain of the audio input and always prevent over deviation. limiter_enabled - Enables or disables the limiter feature. limiter_deviation - Configures audio frequency deviation level. limiter_release_time - Sets the limiter release time. power_level - Sets the output power level for signal transmission. Hmm, there are two ways to implement these: either make a bunch of VIDIOC's for each of these categories, or use extended controls to set all these values. I'm hardly an expert on FM transmitters, but it all seems reasonable to me (i.e., not too specific for this chip). I am leaning towards extended controls, since that's so easy to extend if needed in the future. And I still intend to add sysfs support to controls in the future. On the other hand, it's a bit harder to use compared to normal VIDIOCs. Could you please explain more about extended controls vs. VIDIOC's? Pointing drivers which uses one of those also would be worth. But yes, looks like moving this properties to some sort of v4l2 control looks better implementation. RDS related rds_enabled - Enables or disables the RDS feature. rds_ps_name - Sets the RDS ps name field for transmission. rds_radio_text - Sets the RDS radio text for transmission. rds_pi - Sets the RDS PI field for transmission. rds_pty - Sets the RDS PTY field for transmission. So you set the fields and the RDS encoder will just start using them? Once you have rds_enabled set, yes, it will transmit them. This too can be done with controls (needs some work, though, to support string controls). Yes, true. Region related Setting region will affect other region properties. region_bottom_frequency region_channel_spacing region_preemphasis region_top_frequency I do not know enough about FM transmissions to judge this. Are these region properties something that is regulated by some standards commision? Do they also apply when you modulate this over a TV/radio cable system? Do you have some documentation or links that I can look at to learn more about this? stereo_enabled - Enables or disables stereo mode. How does one pass the audio and rds data to the driver? Note that for 2.6.31 we will finalize the V4L2 RDS decoder API (I recently posted an RFC for that, but I haven't had the time to implement the few changes needed). It would be nice if rds modulator support would be modeled after this demodulator API if possible. I see. This is good. I think the best way is to have a rds modulator interface. This driver have implemented it as sys properties, as described above. I don't think there is that much overlap, though. The similarities are probably limited to some flags. Does region information really belong in the driver? Perhaps this should be in a user-space library? (just a suggestion, I'm not sure at this stage). Ok. Yes, this
Re: [PATCH 0/3] FM Transmitter driver
On Friday 03 April 2009 12:12:30 Eduardo Valentin wrote: On Thu, Apr 02, 2009 at 06:36:37PM +0200, ext Hans Verkuil wrote: On Thursday 02 April 2009 14:02:11 Eduardo Valentin wrote: Hi Hans, On Thu, Apr 02, 2009 at 09:47:11AM +0200, ext Hans Verkuil wrote: On Wednesday 01 April 2009 11:43:28 Eduardo Valentin wrote: Hello Mauro and v4l guys, This series contains a v4l2 radio driver which adds support for Silabs si4713 devices. That is a FM transmitter device. As you should know, v4l2 does not contain representation of FM Transmitters (at least that I know). So this driver was written highly based on FM receivers API, which can cover most of basic functionality. However, as expected, there are some properties which were not covered. For those properties, sysfs nodes were added in order to get user interactions. Comments are wellcome. Can you explain in reasonable detail the extra properties needed for a device like this? You will need to document that anyway :-) Rather than implementing a private API it would be much more interesting to turn this into a public V4L2 API that everyone can use. Yes, here is a little description of them: Pilot is an audible tone sent by the device. pilot_frequency - Configures the frequency of the stereo pilot tone. pilot_deviation - Configures pilot tone frequency deviation level. pilot_enabled - Enables or disables the pilot tone feature. The si4713 device is capable of applying audio compression to the transmitted signal. acomp_enabled - Enables or disables the audio dynamic range control feature. acomp_gain - Sets the gain for audio dynamic range control. acomp_threshold - Sets the threshold level for audio dynamic range control. acomp_attack_time - Sets the attack time for audio dynamic range control. acomp_release_time - Sets the release time for audio dynamic range control. Limiter setups audio deviation limiter feature. Once a over deviation occurs, it is possible to adjust the front-end gain of the audio input and always prevent over deviation. limiter_enabled - Enables or disables the limiter feature. limiter_deviation - Configures audio frequency deviation level. limiter_release_time - Sets the limiter release time. power_level - Sets the output power level for signal transmission. Hmm, there are two ways to implement these: either make a bunch of VIDIOC's for each of these categories, or use extended controls to set all these values. I'm hardly an expert on FM transmitters, but it all seems reasonable to me (i.e., not too specific for this chip). I am leaning towards extended controls, since that's so easy to extend if needed in the future. And I still intend to add sysfs support to controls in the future. On the other hand, it's a bit harder to use compared to normal VIDIOCs. Could you please explain more about extended controls vs. VIDIOC's? Pointing drivers which uses one of those also would be worth. But yes, looks like moving this properties to some sort of v4l2 control looks better implementation. The spec explains it pretty well. The most up to date version of the spec is available here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html. Basically the extended controls API is more flexible than the older VIDIOC_S/G_CTRL ioctls, allowing to set controls atomically (either all are applied or none) and allowing for a wider range of types, although currently that feature isn't used. It's used by uvcvideo and by MPEG encoders (e.g. cx18, ivtv and others). Using VIDIOCs is easier, but much harder to make future-proof. One disadvantage of using extended controls is that it is harder to implement in drivers, although I plan on creating a much better solution for that in the coming months. With the new v4l framework it should be possible to move much of the control handling into the framework and so simplifying the drivers. RDS related rds_enabled - Enables or disables the RDS feature. rds_ps_name - Sets the RDS ps name field for transmission. rds_radio_text - Sets the RDS radio text for transmission. rds_pi - Sets the RDS PI field for transmission. rds_pty - Sets the RDS PTY field for transmission. So you set the fields and the RDS encoder will just start using them? Once you have rds_enabled set, yes, it will transmit them. This too can be done with controls (needs some work, though, to support string controls). Yes, true. Region related Setting region will affect other region properties. region_bottom_frequency region_channel_spacing region_preemphasis region_top_frequency I do not know enough about FM transmissions to judge this. Are these region properties something that is regulated by some standards commision? Do they also apply when you modulate this over a
Re: [PATCH 0/3] FM Transmitter driver
Hi, On Fri, Apr 03, 2009 at 12:36:53PM +0200, ext Hans Verkuil wrote: On Friday 03 April 2009 12:12:30 Eduardo Valentin wrote: On Thu, Apr 02, 2009 at 06:36:37PM +0200, ext Hans Verkuil wrote: On Thursday 02 April 2009 14:02:11 Eduardo Valentin wrote: Hi Hans, On Thu, Apr 02, 2009 at 09:47:11AM +0200, ext Hans Verkuil wrote: On Wednesday 01 April 2009 11:43:28 Eduardo Valentin wrote: Hello Mauro and v4l guys, This series contains a v4l2 radio driver which adds support for Silabs si4713 devices. That is a FM transmitter device. As you should know, v4l2 does not contain representation of FM Transmitters (at least that I know). So this driver was written highly based on FM receivers API, which can cover most of basic functionality. However, as expected, there are some properties which were not covered. For those properties, sysfs nodes were added in order to get user interactions. Comments are wellcome. Can you explain in reasonable detail the extra properties needed for a device like this? You will need to document that anyway :-) Rather than implementing a private API it would be much more interesting to turn this into a public V4L2 API that everyone can use. Yes, here is a little description of them: Pilot is an audible tone sent by the device. pilot_frequency - Configures the frequency of the stereo pilot tone. pilot_deviation - Configures pilot tone frequency deviation level. pilot_enabled - Enables or disables the pilot tone feature. The si4713 device is capable of applying audio compression to the transmitted signal. acomp_enabled - Enables or disables the audio dynamic range control feature. acomp_gain - Sets the gain for audio dynamic range control. acomp_threshold - Sets the threshold level for audio dynamic range control. acomp_attack_time - Sets the attack time for audio dynamic range control. acomp_release_time - Sets the release time for audio dynamic range control. Limiter setups audio deviation limiter feature. Once a over deviation occurs, it is possible to adjust the front-end gain of the audio input and always prevent over deviation. limiter_enabled - Enables or disables the limiter feature. limiter_deviation - Configures audio frequency deviation level. limiter_release_time - Sets the limiter release time. power_level - Sets the output power level for signal transmission. Hmm, there are two ways to implement these: either make a bunch of VIDIOC's for each of these categories, or use extended controls to set all these values. I'm hardly an expert on FM transmitters, but it all seems reasonable to me (i.e., not too specific for this chip). I am leaning towards extended controls, since that's so easy to extend if needed in the future. And I still intend to add sysfs support to controls in the future. On the other hand, it's a bit harder to use compared to normal VIDIOCs. Could you please explain more about extended controls vs. VIDIOC's? Pointing drivers which uses one of those also would be worth. But yes, looks like moving this properties to some sort of v4l2 control looks better implementation. The spec explains it pretty well. The most up to date version of the spec is available here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html. Basically the extended controls API is more flexible than the older VIDIOC_S/G_CTRL ioctls, allowing to set controls atomically (either all are applied or none) and allowing for a wider range of types, although currently that feature isn't used. It's used by uvcvideo and by MPEG encoders (e.g. cx18, ivtv and others). Using VIDIOCs is easier, but much harder to make future-proof. One disadvantage of using extended controls is that it is harder to implement in drivers, although I plan on creating a much better solution for that in the coming months. With the new v4l framework it should be possible to move much of the control handling into the framework and so simplifying the drivers. RDS related rds_enabled - Enables or disables the RDS feature. rds_ps_name - Sets the RDS ps name field for transmission. rds_radio_text - Sets the RDS radio text for transmission. rds_pi - Sets the RDS PI field for transmission. rds_pty - Sets the RDS PTY field for transmission. So you set the fields and the RDS encoder will just start using them? Once you have rds_enabled set, yes, it will transmit them. This too can be done with controls (needs some work, though, to support string controls). Yes, true. Region related Setting region will affect other region properties. region_bottom_frequency region_channel_spacing region_preemphasis region_top_frequency I do not know
Re: [PATCH 0/3] FM Transmitter driver
On Wednesday 01 April 2009 11:43:28 Eduardo Valentin wrote: Hello Mauro and v4l guys, This series contains a v4l2 radio driver which adds support for Silabs si4713 devices. That is a FM transmitter device. As you should know, v4l2 does not contain representation of FM Transmitters (at least that I know). So this driver was written highly based on FM receivers API, which can cover most of basic functionality. However, as expected, there are some properties which were not covered. For those properties, sysfs nodes were added in order to get user interactions. Comments are wellcome. Can you explain in reasonable detail the extra properties needed for a device like this? You will need to document that anyway :-) Rather than implementing a private API it would be much more interesting to turn this into a public V4L2 API that everyone can use. How does one pass the audio and rds data to the driver? Note that for 2.6.31 we will finalize the V4L2 RDS decoder API (I recently posted an RFC for that, but I haven't had the time to implement the few changes needed). It would be nice if rds modulator support would be modeled after this demodulator API if possible. Does region information really belong in the driver? Perhaps this should be in a user-space library? (just a suggestion, I'm not sure at this stage). A general comment: the si4713 driver should be a stand-alone i2c driver. That way it can be reused by other drivers/platforms that use this chip. The v4l2_subdev framework should be used for this. Always interesting to see new functionality arrive in V4L2 :-) Regards, Hans Eduardo Valentin (3): FMTx: si4713: Add files to handle si4713 device FMTx: si4713: Add files to add radio interface for si4713 FMTx: si4713: Add Kconfig and Makefile entries drivers/media/radio/Kconfig| 12 + drivers/media/radio/Makefile |2 + drivers/media/radio/radio-si4713.c | 834 ++ drivers/media/radio/radio-si4713.h | 32 + drivers/media/radio/si4713.c | 2238 drivers/media/radio/si4713.h | 294 + 6 files changed, 3412 insertions(+), 0 deletions(-) create mode 100644 drivers/media/radio/radio-si4713.c create mode 100644 drivers/media/radio/radio-si4713.h create mode 100644 drivers/media/radio/si4713.c create mode 100644 drivers/media/radio/si4713.h -- 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 -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: [PATCH 0/3] FM Transmitter driver
Hi Hans, On Thu, Apr 02, 2009 at 09:47:11AM +0200, ext Hans Verkuil wrote: On Wednesday 01 April 2009 11:43:28 Eduardo Valentin wrote: Hello Mauro and v4l guys, This series contains a v4l2 radio driver which adds support for Silabs si4713 devices. That is a FM transmitter device. As you should know, v4l2 does not contain representation of FM Transmitters (at least that I know). So this driver was written highly based on FM receivers API, which can cover most of basic functionality. However, as expected, there are some properties which were not covered. For those properties, sysfs nodes were added in order to get user interactions. Comments are wellcome. Can you explain in reasonable detail the extra properties needed for a device like this? You will need to document that anyway :-) Rather than implementing a private API it would be much more interesting to turn this into a public V4L2 API that everyone can use. Yes, here is a little description of them: Pilot is an audible tone sent by the device. pilot_frequency - Configures the frequency of the stereo pilot tone. pilot_deviation - Configures pilot tone frequency deviation level. pilot_enabled - Enables or disables the pilot tone feature. The si4713 device is capable of applying audio compression to the transmitted signal. acomp_enabled - Enables or disables the audio dynamic range control feature. acomp_gain - Sets the gain for audio dynamic range control. acomp_threshold - Sets the threshold level for audio dynamic range control. acomp_attack_time - Sets the attack time for audio dynamic range control. acomp_release_time - Sets the release time for audio dynamic range control. Limiter setups audio deviation limiter feature. Once a over deviation occurs, it is possible to adjust the front-end gain of the audio input and always prevent over deviation. limiter_enabled - Enables or disables the limiter feature. limiter_deviation - Configures audio frequency deviation level. limiter_release_time - Sets the limiter release time. power_level - Sets the output power level for signal transmission. RDS related rds_enabled - Enables or disables the RDS feature. rds_ps_name - Sets the RDS ps name field for transmission. rds_radio_text - Sets the RDS radio text for transmission. rds_pi - Sets the RDS PI field for transmission. rds_pty - Sets the RDS PTY field for transmission. Region related Setting region will affect other region properties. region_bottom_frequency region_channel_spacing region_preemphasis region_top_frequency stereo_enabled - Enables or disables stereo mode. How does one pass the audio and rds data to the driver? Note that for 2.6.31 we will finalize the V4L2 RDS decoder API (I recently posted an RFC for that, but I haven't had the time to implement the few changes needed). It would be nice if rds modulator support would be modeled after this demodulator API if possible. I see. This is good. I think the best way is to have a rds modulator interface. This driver have implemented it as sys properties, as described above. Does region information really belong in the driver? Perhaps this should be in a user-space library? (just a suggestion, I'm not sure at this stage). Ok. Yes, this could be better to implement in user land. However, depending on region that would restrict other properties as well. So, letting user space control that, would allow device operate in wrong intervals for frequencies for instance. A general comment: the si4713 driver should be a stand-alone i2c driver. That way it can be reused by other drivers/platforms that use this chip. The v4l2_subdev framework should be used for this. Right. I'll take a look at the v4l2_subdev framework. Always interesting to see new functionality arrive in V4L2 :-) Regards, Hans Eduardo Valentin (3): FMTx: si4713: Add files to handle si4713 device FMTx: si4713: Add files to add radio interface for si4713 FMTx: si4713: Add Kconfig and Makefile entries drivers/media/radio/Kconfig| 12 + drivers/media/radio/Makefile |2 + drivers/media/radio/radio-si4713.c | 834 ++ drivers/media/radio/radio-si4713.h | 32 + drivers/media/radio/si4713.c | 2238 drivers/media/radio/si4713.h | 294 + 6 files changed, 3412 insertions(+), 0 deletions(-) create mode 100644 drivers/media/radio/radio-si4713.c create mode 100644 drivers/media/radio/radio-si4713.h create mode 100644 drivers/media/radio/si4713.c create mode 100644 drivers/media/radio/si4713.h -- 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 -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- Eduardo Valentin -- To unsubscribe from this list: send the
Re: [PATCH 0/3] FM Transmitter driver
On Thursday 02 April 2009 14:02:11 Eduardo Valentin wrote: Hi Hans, On Thu, Apr 02, 2009 at 09:47:11AM +0200, ext Hans Verkuil wrote: On Wednesday 01 April 2009 11:43:28 Eduardo Valentin wrote: Hello Mauro and v4l guys, This series contains a v4l2 radio driver which adds support for Silabs si4713 devices. That is a FM transmitter device. As you should know, v4l2 does not contain representation of FM Transmitters (at least that I know). So this driver was written highly based on FM receivers API, which can cover most of basic functionality. However, as expected, there are some properties which were not covered. For those properties, sysfs nodes were added in order to get user interactions. Comments are wellcome. Can you explain in reasonable detail the extra properties needed for a device like this? You will need to document that anyway :-) Rather than implementing a private API it would be much more interesting to turn this into a public V4L2 API that everyone can use. Yes, here is a little description of them: Pilot is an audible tone sent by the device. pilot_frequency - Configures the frequency of the stereo pilot tone. pilot_deviation - Configures pilot tone frequency deviation level. pilot_enabled - Enables or disables the pilot tone feature. The si4713 device is capable of applying audio compression to the transmitted signal. acomp_enabled - Enables or disables the audio dynamic range control feature. acomp_gain - Sets the gain for audio dynamic range control. acomp_threshold - Sets the threshold level for audio dynamic range control. acomp_attack_time - Sets the attack time for audio dynamic range control. acomp_release_time - Sets the release time for audio dynamic range control. Limiter setups audio deviation limiter feature. Once a over deviation occurs, it is possible to adjust the front-end gain of the audio input and always prevent over deviation. limiter_enabled - Enables or disables the limiter feature. limiter_deviation - Configures audio frequency deviation level. limiter_release_time - Sets the limiter release time. power_level - Sets the output power level for signal transmission. Hmm, there are two ways to implement these: either make a bunch of VIDIOC's for each of these categories, or use extended controls to set all these values. I'm hardly an expert on FM transmitters, but it all seems reasonable to me (i.e., not too specific for this chip). I am leaning towards extended controls, since that's so easy to extend if needed in the future. And I still intend to add sysfs support to controls in the future. On the other hand, it's a bit harder to use compared to normal VIDIOCs. RDS related rds_enabled - Enables or disables the RDS feature. rds_ps_name - Sets the RDS ps name field for transmission. rds_radio_text - Sets the RDS radio text for transmission. rds_pi - Sets the RDS PI field for transmission. rds_pty - Sets the RDS PTY field for transmission. So you set the fields and the RDS encoder will just start using them? This too can be done with controls (needs some work, though, to support string controls). Region related Setting region will affect other region properties. region_bottom_frequency region_channel_spacing region_preemphasis region_top_frequency I do not know enough about FM transmissions to judge this. Are these region properties something that is regulated by some standards commision? Do they also apply when you modulate this over a TV/radio cable system? Do you have some documentation or links that I can look at to learn more about this? stereo_enabled - Enables or disables stereo mode. How does one pass the audio and rds data to the driver? Note that for 2.6.31 we will finalize the V4L2 RDS decoder API (I recently posted an RFC for that, but I haven't had the time to implement the few changes needed). It would be nice if rds modulator support would be modeled after this demodulator API if possible. I see. This is good. I think the best way is to have a rds modulator interface. This driver have implemented it as sys properties, as described above. I don't think there is that much overlap, though. The similarities are probably limited to some flags. Does region information really belong in the driver? Perhaps this should be in a user-space library? (just a suggestion, I'm not sure at this stage). Ok. Yes, this could be better to implement in user land. However, depending on region that would restrict other properties as well. So, letting user space control that, would allow device operate in wrong intervals for frequencies for instance. But if you are in region A and you setup the device for region B, then it's wrong as well, right? I also wonder if there are legal requirements that have to be followed here? Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by
[PATCH 0/3] FM Transmitter driver
Hello Mauro and v4l guys, This series contains a v4l2 radio driver which adds support for Silabs si4713 devices. That is a FM transmitter device. As you should know, v4l2 does not contain representation of FM Transmitters (at least that I know). So this driver was written highly based on FM receivers API, which can cover most of basic functionality. However, as expected, there are some properties which were not covered. For those properties, sysfs nodes were added in order to get user interactions. Comments are wellcome. Eduardo Valentin (3): FMTx: si4713: Add files to handle si4713 device FMTx: si4713: Add files to add radio interface for si4713 FMTx: si4713: Add Kconfig and Makefile entries drivers/media/radio/Kconfig| 12 + drivers/media/radio/Makefile |2 + drivers/media/radio/radio-si4713.c | 834 ++ drivers/media/radio/radio-si4713.h | 32 + drivers/media/radio/si4713.c | 2238 drivers/media/radio/si4713.h | 294 + 6 files changed, 3412 insertions(+), 0 deletions(-) create mode 100644 drivers/media/radio/radio-si4713.c create mode 100644 drivers/media/radio/radio-si4713.h create mode 100644 drivers/media/radio/si4713.c create mode 100644 drivers/media/radio/si4713.h -- 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
