Re: [PATCH V6 2/5] New control class and features for FM RX
On Tue May 15 2012 00:01:50 manjunatha_ha...@ti.com wrote:
From: Manjunatha Halli x0130...@ti.com
This patch creates new ctrl class for FM RX and adds new CID's for
below FM features,
1) De-Emphasis filter mode
2) RDS Alternate Frequency switch
Also this patch adds a field for band selection in struct v4l2_hw_freq_seek
and adds new capability flags for all below FM bands
1) V4L2_TUNER_CAP_BAND_TYPE_DEFAULT - Default Band
2) V4L2_TUNER_CAP_BAND_TYPE_EUROPE_US - Europe/US Band
3) V4L2_TUNER_CAP_BAND_TYPE_JAPAN - Japan Band
4) V4L2_TUNER_CAP_BAND_TYPE_RUSSIAN - Russian Band
5) V4L2_TUNER_CAP_BAND_TYPE_WEATHER - Weather Band
Signed-off-by: Manjunatha Halli x0130...@ti.com
---
drivers/media/video/v4l2-ctrls.c | 17 ++---
include/linux/videodev2.h| 24 +++-
2 files changed, 37 insertions(+), 4 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index c9c9a46..7b3dd95 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
...
@@ -1819,6 +1827,12 @@ struct v4l2_modulator {
#define V4L2_TUNER_CAP_RDS 0x0080
#define V4L2_TUNER_CAP_RDS_BLOCK_IO 0x0100
#define V4L2_TUNER_CAP_RDS_CONTROLS 0x0200
+#define V4L2_TUNER_CAP_BAND_TYPE_DEFAULT 0x /* Default band
*/
+#define V4L2_TUNER_CAP_BAND_TYPE_EUROPE_US 0x0001 /* Europe/US
band */
+#define V4L2_TUNER_CAP_BAND_TYPE_JAPAN 0x0002 /*
Japan band */
+#define V4L2_TUNER_CAP_BAND_TYPE_RUSSIAN 0x0003 /* Russian band
*/
+#define V4L2_TUNER_CAP_BAND_TYPE_WEATHER 0x0004 /* Weather band
*/
Argh! These capabilities are wrong: these should have been 0x1, 0x2,
0x4 and 0x8! Bits that you can OR together.
Also, I think _TYPE can be dropped here, just as we did for the V4L2_FM_BAND
defines below.
V4L2_TUNER_CAP_BAND_TYPE_DEFAULT is useless as a capability and should be
dropped.
Manju, I would recommend that you split off the frequency band handling from
the other patches. Based on an RFC from Hans de Goede regarding work on the AM
band I believe we need to postpone this part for 3.6. The other patches in this
series not related to frequency bands are fine and you can keep my Acked-by
there.
Mauro, if you intended to merge Manjunatha's patches for 3.5, then please wait
with merging them until he had a chance to split off the frequency band bits.
Regards,
Hans
+
/* Flags for the 'rxsubchans' field */
#define V4L2_TUNER_SUB_MONO 0x0001
@@ -1843,13 +1857,21 @@ struct v4l2_frequency {
__u32 reserved[8];
};
+
+#define V4L2_FM_BAND_DEFAULT 0
+#define V4L2_FM_BAND_EUROPE_US 1 /* 87.5 Mhz - 108 MHz */
+#define V4L2_FM_BAND_JAPAN 2 /* 76 MHz - 90 MHz */
+#define V4L2_FM_BAND_RUSSIAN 3 /* 65.8 MHz - 74 MHz */
+#define V4L2_FM_BAND_WEATHER 4 /* 162.4 MHz - 162.55 MHz */
+
struct v4l2_hw_freq_seek {
__u32 tuner;
enum v4l2_tuner_type type;
__u32 seek_upward;
__u32 wrap_around;
__u32 spacing;
- __u32 reserved[7];
+ __u32 band;
+ __u32 reserved[6];
};
/*
--
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 v5 0/5] support for rtl2832
On 18.05.2012 22:47, Antti Palosaari wrote: Good evening! On 18.05.2012 21:47, Thomas Mair wrote: Good Evening! This is the corrected version of the patch series to support the RTL2832 demodulator. There where no major changes. The majority of the changes consist in fixing style issues and adhering to proper naming conventions. Review done and seems to be OK for my eyes. Thanks Antti! You have been a big help for developing the driver. What are the next steps? I think the fc0012 and fc0013 driver need to be reviewed before the patch may be included in staging. Is that the way it works? The next question for me is how to proceed when including new devices. Poma already sent an extensive list a little while ago (http://patchwork.linuxtv.org/patch/10982/). Should they all be included at once, or should I wait until somone confirms they are working correctly and include them one by one? It has been rule that device is added after known to work. That sounds good to me. In the meantime I will try to set up a page for the driver on the linuxtv.org wiki to keep information about the driver and the devices in one place. Unfortunately DVB USB do not support dynamic USB ID. In order to workaround that I have done some small hackish solution for the dvb_usb_rtl28xxu driver. Currently it works for RTL2831U based devices, but I see it could be easily extended for RTL2832U too by adding module parameter. If I understand it right, the problem is that the tuner/demod combination is also hard coded in the dvb_usb_rtl28xxu driver? regards Antti Regards Thomas -- 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
[no subject]
Unsubscribe
Sent from my BlackBerry®
powered by Sinyal Kuat
INDOSATN‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±™çbj)í…æèw* jg¬±¨ ¶‰šŽŠÝ¢j/�êäz¹Þ–Šà2ŠÞ™¨èÚ¢)ß¡«a¶Úþø ®G«�éh®æj:+v‰¨Šwè†Ù¥
Re: [PATCH v5 0/5] support for rtl2832
On 20.05.2012 12:56, Thomas Mair wrote: On 18.05.2012 22:47, Antti Palosaari wrote: Good evening! On 18.05.2012 21:47, Thomas Mair wrote: Good Evening! This is the corrected version of the patch series to support the RTL2832 demodulator. There where no major changes. The majority of the changes consist in fixing style issues and adhering to proper naming conventions. Review done and seems to be OK for my eyes. Thanks Antti! You have been a big help for developing the driver. What are the next steps? I think the fc0012 and fc0013 driver need to be reviewed before the patch may be included in staging. Is that the way it works? Yes those should be reviewed. At least Mauro will review those when merging drivers to master but it is always better if there is some other reviewers before that as he has million patches to review. The next question for me is how to proceed when including new devices. Poma already sent an extensive list a little while ago (http://patchwork.linuxtv.org/patch/10982/). Should they all be included at once, or should I wait until somone confirms they are working correctly and include them one by one? It has been rule that device is added after known to work. That sounds good to me. In the meantime I will try to set up a page for the driver on the linuxtv.org wiki to keep information about the driver and the devices in one place. Unfortunately DVB USB do not support dynamic USB ID. In order to workaround that I have done some small hackish solution for the dvb_usb_rtl28xxu driver. Currently it works for RTL2831U based devices, but I see it could be easily extended for RTL2832U too by adding module parameter. If I understand it right, the problem is that the tuner/demod combination is also hard coded in the dvb_usb_rtl28xxu driver? Device USB IDs are hard coded to (static struct dvb_usb_device_properties) and that structure is passed to the DVB USB framework by calling dvb_usb_device_init(). DVB USB framework just refuses to register device if USB ID is not found. So I added that hackish solution to replace one USB ID by USB ID got as a dynamic USB ID. Dynamic ID is USB core features. It will load and call some USB driver even given USB ID is not advertised by the driver. regards Antti -- http://palosaari.fi/ -- 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: RFC: V4L2 API and radio devices with multiple tuners
Hi Hans, I'm CC-ing Manjunatha Halli as well as due to his work on adding support for the weather band: http://www.spinics.net/lists/kernel/msg1340986.html The question is whether the weather band and the AM band should be treated the same. The wl128x will implement the weather band as part of the single tuner, the cadet currently implements the AM band as a separate tuner. Given the fact that the wl128x and the radioSHARK both have only one physical tuner (and that's almost certainly the case for the cadet radio as well) I am not so sure whether we should handle this as two tuners. The approach taken for the wl128x seems at first glance a better solution. However, when I have my cadet card I'd like to experiment with it first and see what the best approach is to solve this problem. On Sat May 19 2012 20:20:57 Hans de Goede wrote: Hi Hans et all, Currently the V4L2 API does not allow for radio devices with more then 1 tuner, which is a bit of a historical oversight, since many radio devices have 2 tuners/demodulators 1 for FM and one for AM. Trying to model this as 1 tuner really does not work well, as they have 2 completely separate frequency bands they handle, as well as different properties (the FM part usually is stereo capable, the AM part is not). It is important to realize here that usually the AM/FM tuners are part of 1 chip, and often have only 1 frequency register which is used in both AM/FM modes. IOW it more or less is one tuner, but with 2 modes, and from a V4L2 API pov these modes are best modeled as 2 tuners. This is at least true for the radio-cadet card and the tea575x, which are the only 2 AM capable radio devices we currently know about. Currently the V4L2 spec says the following on this subject: http://linuxtv.org/downloads/v4l-dvb-apis/tuner.html Radio devices have exactly one tuner with index zero, no video inputs. This text can easily be changed into allowing multiple tuners, without any API change from the app pov, existing apps will be limited to accessing just the first tuner though (probably best to always make this the FM one). I agree. This text should change. http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-tuner.html ... call the VIDIOC_S_TUNER ioctl. This will not change the current tuner, which is determined by the current video input. This is a problem, video devices when they have multiple tuners often do so with the purpose of being able to watch/record multiple channels at the same time, and thus multiple tuners are usually connected to different inputs / frame-grabbers, and the input - tuner mapping done for video devices makes sense there. As the spec states, radio devices have no video inputs, so VIDIOC_S_INPUT cannot be used on them. Which means we need another way to get/set the active tuner (the tuner mode) for a radio device. Correct. The spec contradicts itself here for radio devices and that needs to be solved. Lets look at the getting of the active tuner first. We cannot use VIDIOC_G_TUNER for this, since this is used to enumerate tuners, so it should return info on the tuner with the specified index, rather then the active tuner. I agree. VIDEOC_G_FREQUENCY otoh looks like a good candidate to use for this, for radio devices we can simply ignore the passed in tuner field, and instead return the active tuner and the current frequency. This means there will be no way to get the frequency for the non active tuner (mode), this is fine, since the non active tuner does not have a (valid) frequency anyways. This would mean that the spec changes for this ioctl. I'm not certain I like that. If we choose for VIDIOC_G_FREQUENCY to always return info on the active tuner it makes sense to use VIDIOC_S_FREQUENCY to select the active tuner. So for radio devices it will not only change the currently tuned frequency for the indicated tuner, but if the indicated tuner was not the active tuner it will make it the active tuner. Ack. Which leaves the question of what to do with VIDIOC_S_HW_FREQ_SEEK, since VIDIOC_S_HW_FREQ_SEEK needs a valid begin frequency as a pre condition, and the frequency ranges differ between different tuners it makes sense to only allow VIDIOC_S_HW_FREQ_SEEK on the active tuner. I see S_HW_FREQ_SEEK as an extended variation on S_FREQUENCY, so I believe calling S_HW_FREQ_SEEK should also change the current tuner. So this leaves one last problem, what to return from VIDIOC_S_HW_FREQ_SEEK if it tries to seek for a non active tuner. I'm tending towards saying -EBUSY, since some parts of the tuners are shared, so the non active tuner cannot seek because those shared parts are otherwise used. *If* we decide that S_HW_FREQ_SEEK cannot change the current tuner, then -EBUSY would be a good error code. The problem is really that you are trying to use G_FREQUENCY to figure out what the active tuner is. That requires an API change (the tuner field now only contains the
[PATCH] bttv: Use btv-has_radio rather then the card info
I've been spending some time playing with radio receivers under Linux, and I noticed that my bttv's radio reception was not working. The patch in the next message fixes the 1st of 3 problems related to this, can you review this patch please and also let me know if it is ok to send patch though my tree? As said there are 3 problems with the radio on my bttv: 1) The problem fixed by the attached patch 2) The audio_mux function in bttv-driver.c does the wrong thing for my Haupage WinTV + radio + stereo (msp3400) card. Since the radio receiving is part of the same tuner, and not in a separate chip, the same (default ) msp3400 input should be selected when trying to listen to radio, as when watching TV. I could special case my card in audio_mux, but in general it seems to me that if their is a combined radio/tv tuner, rather then a separate radio chip (ie the tea5757), the msp3400 input should stay connected to the default / tuner1 input. I guess we should go with special casing for now, to avoid regressions, although I wonder how many people try to use the radio part of any tvcards they may have. 3) The automatic selection of radio versus tv-mode goes astray pretty quickly, if I start the radio program from xawtv, which I've patched in git to do digital loopback of the audio through alsa, so as that I can actual hear what the radio is doing :) And with a quick hack to fix 2), and then after that start gtk-v4l to look at the radio controls (only the mute one actually), then bttv automatically switches from radio to tv mode, not good (tm). IMHO it would be better to defer the switching to tv mode until something relevant is actually done to the /dev/video# node (set operations or start streaming), likewise it would probably be best to defer switching to radio mode until something relevant (any set operations) is actually done on /dev/radio#. If you agree I can try to write a patch for this. Regards, Hans -- 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
[PATCH] bttv: Use btv-has_radio rather then the card info when registering the tuner
bttv_init_card2() sets btv-has_audio to a *default* value from the tvcards array and then may update it by reading a card specific eeprom or gpio detection. After bttv_init_card2(), bttv_init_tuner(), and it should clearly use the updated, dynamic has_radio value from btv-has_radio, rather then the const value in the tvcards array. This fixes the radio not working on my Hauppauge WinTV. Signed-off-by: Hans de Goede hdego...@redhat.com --- drivers/media/video/bt8xx/bttv-cards.c |4 ++-- drivers/media/video/bt8xx/bttv-driver.c |5 + 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/bt8xx/bttv-cards.c b/drivers/media/video/bt8xx/bttv-cards.c index ff2933a..1c030fe 100644 --- a/drivers/media/video/bt8xx/bttv-cards.c +++ b/drivers/media/video/bt8xx/bttv-cards.c @@ -3649,7 +3649,7 @@ void __devinit bttv_init_tuner(struct bttv *btv) struct tuner_setup tun_setup; /* Load tuner module before issuing tuner config call! */ - if (bttv_tvcards[btv-c.type].has_radio) + if (btv-has_radio) v4l2_i2c_new_subdev(btv-c.v4l2_dev, btv-c.i2c_adap, tuner, 0, v4l2_i2c_tuner_addrs(ADDRS_RADIO)); @@ -3664,7 +3664,7 @@ void __devinit bttv_init_tuner(struct bttv *btv) tun_setup.type = btv-tuner_type; tun_setup.addr = addr; - if (bttv_tvcards[btv-c.type].has_radio) + if (btv-has_radio) tun_setup.mode_mask |= T_RADIO; bttv_call_all(btv, tuner, s_type_addr, tun_setup); diff --git a/drivers/media/video/bt8xx/bttv-driver.c b/drivers/media/video/bt8xx/bttv-driver.c index a9cfb0f..7ce3aac 100644 --- a/drivers/media/video/bt8xx/bttv-driver.c +++ b/drivers/media/video/bt8xx/bttv-driver.c @@ -1181,6 +1181,8 @@ audio_mux(struct bttv *btv, int input, int mute) btv-mute = mute; btv-audio = input; + + printk(input: %d, mute: %d\n, input, mute); /* automute */ mute = mute || (btv-opt_automute !signal !btv-radio_user); @@ -1220,6 +1222,9 @@ audio_mux(struct bttv *btv, int input, int mute) case TVAUDIO_INPUT_RADIO: in = MSP_INPUT(MSP_IN_SCART2, MSP_IN_TUNER1, MSP_DSP_IN_SCART, MSP_DSP_IN_SCART); + in = MSP_INPUT(MSP_IN_SCART1, MSP_IN_TUNER2, \ + MSP_DSP_IN_TUNER, MSP_DSP_IN_TUNER); + in = MSP_INPUT_DEFAULT; break; case TVAUDIO_INPUT_EXTERN: in = MSP_INPUT(MSP_IN_SCART1, MSP_IN_TUNER1, -- 1.7.10 -- 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: RFC: V4L2 API and radio devices with multiple tuners
Hi, On 05/20/2012 12:23 PM, Hans Verkuil wrote: Hi Hans, I'm CC-ing Manjunatha Halli as well as due to his work on adding support for the weather band: http://www.spinics.net/lists/kernel/msg1340986.html The question is whether the weather band and the AM band should be treated the same. The wl128x will implement the weather band as part of the single tuner, the cadet currently implements the AM band as a separate tuner. Given the fact that the wl128x and the radioSHARK both have only one physical tuner (and that's almost certainly the case for the cadet radio as well) I am not so sure whether we should handle this as two tuners. The approach taken for the wl128x seems at first glance a better solution. However, when I have my cadet card I'd like to experiment with it first and see what the best approach is to solve this problem. I agree that since it is a single tuner, it makes sense to treat is as such :) The problem is that it has very distinctive properties depending on whether it is operating in AM or FM mode, ie the bands are: 87.5 - 108 Mhz and 530 - 1710 kHz. Now we can just represent that as the tuner being capable to tune from 530 kHz - 108 Mhz but that won't result in a good UI experience in userspace at all. I still agree that since it is a single tuner, it makes sense to treat is as such, and since there are no overlapping frequencies, treating it as one tuner is not a problem for most of the API, the only trouble some part really is G_TUNER, since it cannot deal with having multiple frequency ranges, nor with different properties per frequency range. We could introduce a subidx concept, and a related tuner capability. Add if that capability is present, then userspace can query different frequency ranges and there separate properties by calling g_tuner with the same index but a different subidx until it returns -EINVAL. We can use one of the reserved fields for the subidx, or ... We could store the subidx in the higher 16 bits of index, since index is way larger then we need anyways, and this also avoids the theoretical problems with apps not clearing the reserved fields we could use for a proper subidx again. I personally prefer just using a separate field for it. On Sat May 19 2012 20:20:57 Hans de Goede wrote: Hi Hans et all, Currently the V4L2 API does not allow for radio devices with more then 1 tuner, which is a bit of a historical oversight, since many radio devices have 2 tuners/demodulators 1 for FM and one for AM. Trying to model this as 1 tuner really does not work well, as they have 2 completely separate frequency bands they handle, as well as different properties (the FM part usually is stereo capable, the AM part is not). It is important to realize here that usually the AM/FM tuners are part of 1 chip, and often have only 1 frequency register which is used in both AM/FM modes. IOW it more or less is one tuner, but with 2 modes, and from a V4L2 API pov these modes are best modeled as 2 tuners. This is at least true for the radio-cadet card and the tea575x, which are the only 2 AM capable radio devices we currently know about. Currently the V4L2 spec says the following on this subject: http://linuxtv.org/downloads/v4l-dvb-apis/tuner.html Radio devices have exactly one tuner with index zero, no video inputs. This text can easily be changed into allowing multiple tuners, without any API change from the app pov, existing apps will be limited to accessing just the first tuner though (probably best to always make this the FM one). I agree. This text should change. Well if we go with the actually it is a single tuner concept above it does not need to change, and we avoid the problems below... http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-tuner.html ... call the VIDIOC_S_TUNER ioctl. This will not change the current tuner, which is determined by the current video input. This is a problem, video devices when they have multiple tuners often do so with the purpose of being able to watch/record multiple channels at the same time, and thus multiple tuners are usually connected to different inputs / frame-grabbers, and the input- tuner mapping done for video devices makes sense there. As the spec states, radio devices have no video inputs, so VIDIOC_S_INPUT cannot be used on them. Which means we need another way to get/set the active tuner (the tuner mode) for a radio device. Correct. The spec contradicts itself here for radio devices and that needs to be solved. Only if we assume there can be more then 1 tuner on a radio dev. Lets look at the getting of the active tuner first. We cannot use VIDIOC_G_TUNER for this, since this is used to enumerate tuners, so it should return info on the tuner with the specified index, rather then the active tuner. I agree. VIDEOC_G_FREQUENCY otoh looks like a good candidate to use for this, for radio devices we can simply ignore the passed in tuner field, and instead return the active tuner and the current
Scan file fr-Rennes
Hi All, I managed to get a working scan file for this location (France - Rennes) and the one provided is a bit outdated. I've checked in the tree and it has simply been deleted for exactly the same reason. I successfully used the following replacement of /usr/share/dvb/dvb-t/fr-Rennes : # Rennes - France # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 47400 8MHz AUTO NONE QAM64 8k AUTO NONE T 62600 8MHz AUTO NONE QAM64 8k AUTO NONE T 52200 8MHz AUTO NONE QAM64 8k AUTO NONE T 69800 8MHz AUTO NONE QAM64 8k AUTO NONE T 60200 8MHz AUTO NONE QAM64 8k AUTO NONE T 49800 8MHz AUTO NONE QAM64 8k AUTO NONE Multiplexes have changed since a few years when all the country felt into full DVB-T. Previous file was using transitory multiplexes. Could it be possible to update this file on the tree ? Thanks in advance for your help. Best regards, Christophe -- 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: [GIT PULL FOR 3.5] s5p-fimc driver updates
Em 14-05-2012 18:39, Sylwester Nawrocki escreveu: On 05/10/2012 10:48 AM, Sylwester Nawrocki wrote: On 05/04/2012 05:31 PM, Sylwester Nawrocki wrote: Hi Mauro, The following changes since commit 34b2debaa62bfa384ef91b61cf2c40c48e86a5e2: s5p-fimc: Correct memory allocation for VIDIOC_CREATE_BUFS (2012-05-04 17:07:24 +0200) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-samsung v4l-fimc-exynos4x12 for you to fetch changes up to bab96b068afa07105139be09d3830cc9ed580382: s5p-fimc: Use selection API in place of crop operations (2012-05-04 17:18:38 +0200) Mauro, I've found a few issues in this series afterwards and re-edited 3 commits there. Here is an updated pull request: The following changes since commit ae45d3e9aea0ab951dbbca2238fbfbf3993f1e7f: s5p-fimc: Correct memory allocation for VIDIOC_CREATE_BUFS (2012-05-09 16:07:49 +0200) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-samsung v4l-fimc-exynos4x12 for you to fetch changes up to 5feefe6656583de6fd4ef1d53b19031dd5efeec1: s5p-fimc: Use selection API in place of crop operations (2012-05-09 16:11:29 +0200) Sylwester Nawrocki (14): V4L: Extend V4L2_CID_COLORFX with more image effects s5p-fimc: Avoid crash with null platform_data s5p-fimc: Move m2m node driver into separate file It seems there is a conflict now with this patch: http://git.linuxtv.org/media_tree.git/commit/5126f2590bee412e3053de851cb07f531e4be36a Attached are updated versions of the two conflicting patches, the others don't need touching. I could provide rebased version of the whole change set tomorrow - if needed. Please do that, as this patch doesn't apply as-is. Regards, Mauro $ quilt push Applying patch patches/lmml_11243_git_pull_for_3_5_s5p_fimc_driver_updates.patch patching file drivers/media/video/s5p-fimc/fimc-capture.c Hunk #1 FAILED at 993. Hunk #2 FAILED at 1489. Hunk #3 FAILED at 1554. Hunk #4 FAILED at 1572. Hunk #5 FAILED at 1580. Hunk #6 FAILED at 1616. Hunk #7 FAILED at 1636. 7 out of 7 hunks FAILED -- rejects in file drivers/media/video/s5p-fimc/fimc-capture.c patching file drivers/media/video/s5p-fimc/fimc-core.c Hunk #1 FAILED at 842. Hunk #2 FAILED at 851. Hunk #3 FAILED at 866. Hunk #4 FAILED at 953. 4 out of 4 hunks FAILED -- rejects in file drivers/media/video/s5p-fimc/fimc-core.c patching file drivers/media/video/s5p-fimc/fimc-core.h Hunk #1 FAILED at 331. Hunk #2 FAILED at 737. 2 out of 2 hunks FAILED -- rejects in file drivers/media/video/s5p-fimc/fimc-core.h patching file drivers/media/video/s5p-fimc/fimc-m2m.c Hunk #1 FAILED at 777. Hunk #2 FAILED at 789. 2 out of 2 hunks FAILED -- rejects in file drivers/media/video/s5p-fimc/fimc-m2m.c patching file drivers/media/video/s5p-fimc/fimc-mdevice.c Hunk #1 FAILED at 304. Hunk #2 FAILED at 313. Hunk #3 FAILED at 401. Hunk #4 FAILED at 420. Hunk #5 FAILED at 479. Hunk #6 FAILED at 588. Hunk #7 FAILED at 817. 7 out of 7 hunks FAILED -- rejects in file drivers/media/video/s5p-fimc/fimc-mdevice.c patching file drivers/media/video/s5p-fimc/fimc-mdevice.h Hunk #1 FAILED at 24. 1 out of 1 hunk FAILED -- rejects in file drivers/media/video/s5p-fimc/fimc-mdevice.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
[PATCH 01/10] string: introduce memweight
memweight() is the function that counts the total number of bits set
in memory area. The memory area doesn't need to be aligned to
long-word boundary unlike bitmap_weight().
Signed-off-by: Akinobu Mita akinobu.m...@gmail.com
Cc: Anders Larsen a...@alarsen.net
Cc: Alasdair Kergon a...@redhat.com
Cc: dm-de...@redhat.com
Cc: linux-fsde...@vger.kernel.org
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: linux-media@vger.kernel.org
Cc: Mark Fasheh mfas...@suse.com
Cc: Joel Becker jl...@evilplan.org
Cc: ocfs2-de...@oss.oracle.com
Cc: Jan Kara j...@suse.cz
Cc: linux-e...@vger.kernel.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Andreas Dilger adilger.ker...@dilger.ca
Cc: Theodore Ts'o ty...@mit.edu
---
include/linux/string.h |3 +++
lib/string.c | 37 +
2 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/include/linux/string.h b/include/linux/string.h
index e033564..ffe0442 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -145,4 +145,7 @@ static inline bool strstarts(const char *str, const char
*prefix)
return strncmp(str, prefix, strlen(prefix)) == 0;
}
#endif
+
+extern size_t memweight(const void *ptr, size_t bytes);
+
#endif /* _LINUX_STRING_H_ */
diff --git a/lib/string.c b/lib/string.c
index e5878de..c8b92a0 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -26,6 +26,7 @@
#include linux/export.h
#include linux/bug.h
#include linux/errno.h
+#include linux/bitmap.h
#ifndef __HAVE_ARCH_STRNICMP
/**
@@ -824,3 +825,39 @@ void *memchr_inv(const void *start, int c, size_t bytes)
return check_bytes8(start, value, bytes % 8);
}
EXPORT_SYMBOL(memchr_inv);
+
+/**
+ * memweight - count the total number of bits set in memory area
+ * @ptr: pointer to the start of the area
+ * @bytes: the size of the area
+ */
+size_t memweight(const void *ptr, size_t bytes)
+{
+ size_t w = 0;
+ size_t longs;
+ union {
+ const void *ptr;
+ const unsigned char *b;
+ unsigned long address;
+ } bitmap;
+
+ for (bitmap.ptr = ptr; bytes 0 bitmap.address % sizeof(long);
+ bytes--, bitmap.address++)
+ w += hweight8(*bitmap.b);
+
+ for (longs = bytes / sizeof(long); longs 0; ) {
+ size_t bits = min_t(size_t, INT_MAX ~(BITS_PER_LONG - 1),
+ longs * BITS_PER_LONG);
+
+ w += bitmap_weight(bitmap.ptr, bits);
+ bytes -= bits / BITS_PER_BYTE;
+ bitmap.address += bits / BITS_PER_BYTE;
+ longs -= bits / BITS_PER_LONG;
+ }
+
+ for (; bytes 0; bytes--, bitmap.address++)
+ w += hweight8(*bitmap.b);
+
+ return w;
+}
+EXPORT_SYMBOL(memweight);
--
1.7.7.6
--
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
[PATCH 06/10] video/uvc: use memweight()
Use memweight() to count the total number of bits set in memory area.
Signed-off-by: Akinobu Mita akinobu.m...@gmail.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: linux-media@vger.kernel.org
---
drivers/media/video/uvc/uvc_ctrl.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_ctrl.c
b/drivers/media/video/uvc/uvc_ctrl.c
index 0efd3b1..8683be0 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -1851,7 +1851,7 @@ int uvc_ctrl_init_device(struct uvc_device *dev)
/* Walk the entities list and instantiate controls */
list_for_each_entry(entity, dev-entities, list) {
struct uvc_control *ctrl;
- unsigned int bControlSize = 0, ncontrols = 0;
+ unsigned int bControlSize = 0, ncontrols;
__u8 *bmControls = NULL;
if (UVC_ENTITY_TYPE(entity) == UVC_VC_EXTENSION_UNIT) {
@@ -1869,8 +1869,7 @@ int uvc_ctrl_init_device(struct uvc_device *dev)
uvc_ctrl_prune_entity(dev, entity);
/* Count supported controls and allocate the controls array */
- for (i = 0; i bControlSize; ++i)
- ncontrols += hweight8(bmControls[i]);
+ ncontrols = memweight(bmControls, bControlSize);
if (ncontrols == 0)
continue;
--
1.7.7.6
--
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 2/2] au0828: Move under dvb
Em 12-05-2012 07:21, Devin Heitmueller escreveu: On Fri, May 11, 2012 at 11:08 PM, Ismael Luceno ismael.luc...@gmail.com wrote: On Fri, 11 May 2012 08:04:59 -0400 Devin Heitmueller dheitmuel...@kernellabs.com wrote: ... What is the motivation for moving these files? Well, the device was on the wrong Kconfig section, and while thinking about changing that, I just thought to move it under DVB. The au0828 is a hybrid bridge, and every other hybrid bridge is under video? Sorry, the devices I got don't support analog, so I didn't thought about it that much... I guess it's arbitrary... isn't it? wouldn't it be better to have an hybrid section? (just thinking out loud) Yeah, in this case it's largely historical (a product from before the V4L and DVB subsystems were merged). At this point I don't see any real advantage to arbitrarily moving the stuff around. And in fact in some areas it's even more ambiguous because some drivers are hybrid drivers but support both hybrid chips as well as analog-only (the em28xx driver is one such example). Anyway, Mauro is welcome to offer his opinion if it differs, but as far as I'm concerned this patch shouldn't get applied. I won't apply this patch. If the Kconfig menus are confusing, then we should fix it, instead of moving things from one place to another ;) Cheers, Devin -- 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 2/2] au0828: Move under dvb
Em 20-05-2012 10:32, Mauro Carvalho Chehab escreveu: Em 12-05-2012 07:21, Devin Heitmueller escreveu: On Fri, May 11, 2012 at 11:08 PM, Ismael Luceno ismael.luc...@gmail.com wrote: On Fri, 11 May 2012 08:04:59 -0400 Devin Heitmueller dheitmuel...@kernellabs.com wrote: ... What is the motivation for moving these files? Well, the device was on the wrong Kconfig section, and while thinking about changing that, I just thought to move it under DVB. The au0828 is a hybrid bridge, and every other hybrid bridge is under video? Sorry, the devices I got don't support analog, so I didn't thought about it that much... I guess it's arbitrary... isn't it? wouldn't it be better to have an hybrid section? (just thinking out loud) Yeah, in this case it's largely historical (a product from before the V4L and DVB subsystems were merged). At this point I don't see any real advantage to arbitrarily moving the stuff around. And in fact in some areas it's even more ambiguous because some drivers are hybrid drivers but support both hybrid chips as well as analog-only (the em28xx driver is one such example). Anyway, Mauro is welcome to offer his opinion if it differs, but as far as I'm concerned this patch shouldn't get applied. I won't apply this patch. If the Kconfig menus are confusing, then we should fix it, instead of moving things from one place to another ;) Hmm... menuconfig VIDEO_CAPTURE_DRIVERS bool Video capture adapters depends on VIDEO_V4L2 default y ---help--- Say Y here to enable selecting the video adapters for webcams, analog TV, and hybrid analog/digital TV. Some of those devices also supports FM radio. The help explanation is OK. Maybe we could change the description: comment at the bool description. What about the change below? Regards, Mauro - [media] video: Improve Kconfig menu description The menu description can mislead to indicate that only capture devices are there. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/media/dvb/Kconfig b/drivers/media/dvb/Kconfig index f6e40b3..8efa494 100644 --- a/drivers/media/dvb/Kconfig +++ b/drivers/media/dvb/Kconfig @@ -29,11 +29,12 @@ config DVB_DYNAMIC_MINORS If you are unsure about this, say N here. menuconfig DVB_CAPTURE_DRIVERS - bool DVB/ATSC adapters + bool Digital TV adapters depends on DVB_CORE default y ---help--- - Say Y to select Digital TV adapters + Say Y to select Digital TV adapters. Hybrid devices + with both analog TV and digital TVs are not there. if DVB_CAPTURE_DRIVERS DVB_CORE diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 268b36d..a5a0ef2 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -71,12 +71,13 @@ config VIDEOBUF2_DMA_SG # menuconfig VIDEO_CAPTURE_DRIVERS - bool Video capture adapters + bool Video adapters (capture, webcams, analog TV, hybrid TV) depends on VIDEO_V4L2 default y ---help--- Say Y here to enable selecting the video adapters for - webcams, analog TV, and hybrid analog/digital TV. + webcams, video capture, analog TV, and hybrid + analog/digital TV. Some of those devices also supports FM radio. if VIDEO_CAPTURE_DRIVERS VIDEO_V4L2 -- 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: [GIT PULL FOR 3.5] s5p-fimc driver updates
On 05/20/2012 02:39 PM, Mauro Carvalho Chehab wrote: Em 14-05-2012 18:39, Sylwester Nawrocki escreveu: On 05/10/2012 10:48 AM, Sylwester Nawrocki wrote: On 05/04/2012 05:31 PM, Sylwester Nawrocki wrote: ... The following changes since commit ae45d3e9aea0ab951dbbca2238fbfbf3993f1e7f: s5p-fimc: Correct memory allocation for VIDIOC_CREATE_BUFS (2012-05-09 16:07:49 +0200) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-samsung v4l-fimc-exynos4x12 for you to fetch changes up to 5feefe6656583de6fd4ef1d53b19031dd5efeec1: s5p-fimc: Use selection API in place of crop operations (2012-05-09 16:11:29 +0200) Sylwester Nawrocki (14): V4L: Extend V4L2_CID_COLORFX with more image effects s5p-fimc: Avoid crash with null platform_data s5p-fimc: Move m2m node driver into separate file It seems there is a conflict now with this patch: http://git.linuxtv.org/media_tree.git/commit/5126f2590bee412e3053de851cb07f531e4be36a Attached are updated versions of the two conflicting patches, the others don't need touching. I could provide rebased version of the whole change set tomorrow - if needed. Please do that, as this patch doesn't apply as-is. I guess there is no intervention from my side needed, since you already applied those updated patches to the media tree (since I pushed the rebased patch to git.infradead.org a few days ago already) ? However, there is going to be conflicts now with my patch from Sakari's pull request: http://patchwork.linuxtv.org/patch/11336. As we talked in #v4l IRC, even if the API is experimental, any changes to it must not cause build breaks. I didn't discuss that yet with Sakari. I have now reworked the renaming patch, so it now includes backward compatibility definitions like this: #define V4L2_SEL_TGT_CROP_ACTIVEV4L2_SEL_TGT_CROP #define V4L2_SEL_TGT_COMPOSE_ACTIVE V4L2_SEL_TGT_COMPOSE I would then make a patch for Documentation/feature-removal-schedule.txt to indicate those aliases will be removed after two kernel releases. Does it sound like a right thing to do ? Regards, Sylwester -- 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
[PATCH] V4L: Remove _ACTIVE from the selection target name definitions
This patch drops the _ACTIVE part from the selection target names as a prerequisite to unify the selection target names across the subdev and regular video node API. The meaning of V4L2_SEL_TGT_*_ACTIVE and V4L2_SUBDEV_SEL_TGT_*_ACTUAL selection targets is logically the same. Different names add to confusion where both APIs are used in a single driver or an application. For some system configurations different names may lead to interoperability issues. For backwards compatibility V4L2_SEL_TGT_CROP_ACTIVE and V4L2_SEL_TGT_COMPOSE_ACTIVE are defined as aliases to V4L2_SEL_TGT_CROP and V4L2_SEL_TGT_COMPOSE. These aliases will be removed after deprecation period, according to Documentation/feature-removal-schedule.txt. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- This a replacement for this patch: http://patchwork.linuxtv.org/patch/11226 Changes include an adition of backward compatibility alias definitions and the required bits for FIMC-LITE driver. Sakari, do you think you could update you pull request with this patch ? I assumed the Acks still apply, if not, please let me know. Thanks, Sylwester Documentation/DocBook/media/v4l/selection-api.xml | 24 ++-- .../DocBook/media/v4l/vidioc-g-selection.xml | 15 ++- drivers/media/video/s5p-fimc/fimc-capture.c| 14 +- drivers/media/video/s5p-fimc/fimc-lite.c |4 +- drivers/media/video/s5p-jpeg/jpeg-core.c |4 +- drivers/media/video/s5p-tv/mixer_video.c |8 +++--- drivers/media/video/v4l2-ioctl.c |8 +++--- include/linux/videodev2.h |8 +- 8 files changed, 45 insertions(+), 40 deletions(-) diff --git a/Documentation/DocBook/media/v4l/selection-api.xml b/Documentation/DocBook/media/v4l/selection-api.xml index b299e47..ac013e5 100644 --- a/Documentation/DocBook/media/v4l/selection-api.xml +++ b/Documentation/DocBook/media/v4l/selection-api.xml @@ -91,7 +91,7 @@ top/left corner at position constant (0,0) /constant. The rectangle's coordinates are expressed in pixels./para paraThe top left corner, width and height of the source rectangle, that is -the area actually sampled, is given by the constant V4L2_SEL_TGT_CROP_ACTIVE +the area actually sampled, is given by the constant V4L2_SEL_TGT_CROP /constant target. It uses the same coordinate system as constant V4L2_SEL_TGT_CROP_BOUNDS /constant. The active cropping area must lie completely inside the capture boundaries. The driver may further adjust the @@ -111,7 +111,7 @@ height are equal to the image size set by constant VIDIOC_S_FMT /constant. /para paraThe part of a buffer into which the image is inserted by the hardware is -controlled by the constant V4L2_SEL_TGT_COMPOSE_ACTIVE /constant target. +controlled by the constant V4L2_SEL_TGT_COMPOSE /constant target. The rectangle's coordinates are also expressed in the same coordinate system as the bounds rectangle. The composing rectangle must lie completely inside bounds rectangle. The driver must adjust the composing rectangle to fit to the @@ -125,7 +125,7 @@ bounding rectangle./para paraThe part of a buffer that is modified by the hardware is given by constant V4L2_SEL_TGT_COMPOSE_PADDED /constant. It contains all pixels -defined using constant V4L2_SEL_TGT_COMPOSE_ACTIVE /constant plus all +defined using constant V4L2_SEL_TGT_COMPOSE /constant plus all padding data modified by hardware during insertion process. All pixels outside this rectangle emphasismust not/emphasis be changed by the hardware. The content of pixels that lie inside the padded area but outside active area is @@ -153,7 +153,7 @@ specified using constant VIDIOC_S_FMT /constant ioctl./para paraThe top left corner, width and height of the source rectangle, that is the area from which image date are processed by the hardware, is given by the -constant V4L2_SEL_TGT_CROP_ACTIVE /constant. Its coordinates are expressed +constant V4L2_SEL_TGT_CROP /constant. Its coordinates are expressed in in the same coordinate system as the bounds rectangle. The active cropping area must lie completely inside the crop boundaries and the driver may further adjust the requested size and/or position according to hardware @@ -165,7 +165,7 @@ bounding rectangle./para paraThe part of a video signal or graphics display where the image is inserted by the hardware is controlled by constant -V4L2_SEL_TGT_COMPOSE_ACTIVE /constant target. The rectangle's coordinates +V4L2_SEL_TGT_COMPOSE /constant target. The rectangle's coordinates are expressed in pixels. The composing rectangle must lie completely inside the bounds rectangle. The driver must adjust the area to fit to the bounding limits. Moreover, the driver can perform other adjustments according to @@
Re: [PATCH] bttv: Use btv-has_radio rather then the card info
On Sun May 20 2012 13:28:11 Hans de Goede wrote: I've been spending some time playing with radio receivers under Linux, and I noticed that my bttv's radio reception was not working. The patch in the next message fixes the 1st of 3 problems related to this, can you review this patch please and also let me know if it is ok to send patch though my tree? As said there are 3 problems with the radio on my bttv: 1) The problem fixed by the attached patch 2) The audio_mux function in bttv-driver.c does the wrong thing for my Haupage WinTV + radio + stereo (msp3400) card. Since the radio receiving is part of the same tuner, and not in a separate chip, the same (default ) msp3400 input should be selected when trying to listen to radio, as when watching TV. I could special case my card in audio_mux, but in general it seems to me that if their is a combined radio/tv tuner, rather then a separate radio chip (ie the tea5757), the msp3400 input should stay connected to the default / tuner1 input. I guess we should go with special casing for now, to avoid regressions, although I wonder how many people try to use the radio part of any tvcards they may have. 3) The automatic selection of radio versus tv-mode goes astray pretty quickly, if I start the radio program from xawtv, which I've patched in git to do digital loopback of the audio through alsa, so as that I can actual hear what the radio is doing :) And with a quick hack to fix 2), and then after that start gtk-v4l to look at the radio controls (only the mute one actually), then bttv automatically switches from radio to tv mode, not good (tm). This was the behavior for a long time: opening the radio node was sufficient to switch to radio mode, and opening a video node would switch to video. That behavior has been marked obsolete and in the feature-removal document it is slated for removal. Unfortunately I haven't had time to do any of that work. The only time you should switch between radio and tv tuner is with S_TUNER, S_FREQUENCY or S_HW_FREQ_SEEK, issued from the corresponding radio or video node. Trying to switch to radio mode if streaming is in progress should obviously result in EBUSY. IMHO it would be better to defer the switching to tv mode until something relevant is actually done to the /dev/video# node (set operations or start streaming), likewise it would probably be best to defer switching to radio mode until something relevant (any set operations) is actually done on /dev/radio#. If you agree I can try to write a patch for this. It would be nice if bttv was fixed. There are loads more issues with bttv, that's going to be a big project at one time. Regards, Hans -- 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: RFC: V4L2 API and radio devices with multiple tuners
I propose that once I have received my radio-cadet card and I have had some time to test it that we talk it over on irc. It seems we are close to a result. BTW, multiple tuners for a radio device should definitely be possible and we do need to clarify the spec in that respect. There isn't actually any board with multiple tuners, although the Hauppauge PVR-500 (ivtv based) comes close as it has separate TV and radio tuners instead of the usual 'one tuner fits all' approach. Regards, Hans On Sun May 20 2012 13:50:52 Hans de Goede wrote: Hi, On 05/20/2012 12:23 PM, Hans Verkuil wrote: Hi Hans, I'm CC-ing Manjunatha Halli as well as due to his work on adding support for the weather band: http://www.spinics.net/lists/kernel/msg1340986.html The question is whether the weather band and the AM band should be treated the same. The wl128x will implement the weather band as part of the single tuner, the cadet currently implements the AM band as a separate tuner. Given the fact that the wl128x and the radioSHARK both have only one physical tuner (and that's almost certainly the case for the cadet radio as well) I am not so sure whether we should handle this as two tuners. The approach taken for the wl128x seems at first glance a better solution. However, when I have my cadet card I'd like to experiment with it first and see what the best approach is to solve this problem. I agree that since it is a single tuner, it makes sense to treat is as such :) The problem is that it has very distinctive properties depending on whether it is operating in AM or FM mode, ie the bands are: 87.5 - 108 Mhz and 530 - 1710 kHz. Now we can just represent that as the tuner being capable to tune from 530 kHz - 108 Mhz but that won't result in a good UI experience in userspace at all. I still agree that since it is a single tuner, it makes sense to treat is as such, and since there are no overlapping frequencies, treating it as one tuner is not a problem for most of the API, the only trouble some part really is G_TUNER, since it cannot deal with having multiple frequency ranges, nor with different properties per frequency range. We could introduce a subidx concept, and a related tuner capability. Add if that capability is present, then userspace can query different frequency ranges and there separate properties by calling g_tuner with the same index but a different subidx until it returns -EINVAL. We can use one of the reserved fields for the subidx, or ... We could store the subidx in the higher 16 bits of index, since index is way larger then we need anyways, and this also avoids the theoretical problems with apps not clearing the reserved fields we could use for a proper subidx again. I personally prefer just using a separate field for it. On Sat May 19 2012 20:20:57 Hans de Goede wrote: Hi Hans et all, Currently the V4L2 API does not allow for radio devices with more then 1 tuner, which is a bit of a historical oversight, since many radio devices have 2 tuners/demodulators 1 for FM and one for AM. Trying to model this as 1 tuner really does not work well, as they have 2 completely separate frequency bands they handle, as well as different properties (the FM part usually is stereo capable, the AM part is not). It is important to realize here that usually the AM/FM tuners are part of 1 chip, and often have only 1 frequency register which is used in both AM/FM modes. IOW it more or less is one tuner, but with 2 modes, and from a V4L2 API pov these modes are best modeled as 2 tuners. This is at least true for the radio-cadet card and the tea575x, which are the only 2 AM capable radio devices we currently know about. Currently the V4L2 spec says the following on this subject: http://linuxtv.org/downloads/v4l-dvb-apis/tuner.html Radio devices have exactly one tuner with index zero, no video inputs. This text can easily be changed into allowing multiple tuners, without any API change from the app pov, existing apps will be limited to accessing just the first tuner though (probably best to always make this the FM one). I agree. This text should change. Well if we go with the actually it is a single tuner concept above it does not need to change, and we avoid the problems below... http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-tuner.html ... call the VIDIOC_S_TUNER ioctl. This will not change the current tuner, which is determined by the current video input. This is a problem, video devices when they have multiple tuners often do so with the purpose of being able to watch/record multiple channels at the same time, and thus multiple tuners are usually connected to different inputs / frame-grabbers, and the input- tuner mapping done for video devices makes sense there. As the spec states, radio devices have no video inputs, so VIDIOC_S_INPUT cannot be
Re: [PATCH] mmp-camera: specify XO-1.75 clock speed
Em 16-05-2012 18:15, Daniel Drake escreveu: On Wed, May 16, 2012 at 3:12 PM, Jonathan Corbet cor...@lwn.net wrote: On Tue, 15 May 2012 20:43:31 +0100 (BST) Daniel Drake d...@laptop.org wrote: Jon, is it OK to assume that XO-1.75 is the only mmp-camera user? It's the only one I know of at the moment, certainly. Even so, I think it would be a lot better to put this parameter into the mmp_camera_platform_data structure instead of wiring it into the driver source; it could then be set in olpc-xo-1-75.c with the other relevant parameters. I won't oppose the inclusion of this patch, but...any chance it could be done that way? I'll look into it. Please put this patch on pause for now. I've marked this patch as changes requested at patchwork: http://patchwork.linuxtv.org/patch/11270/ I agree with Jon: adding such config stuff at platform data is better. Regards, Mauro -- 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 1/3] adv7180: add support to user controls
Hi Frederico!
On Thu April 12 2012 18:39:36 Federico Vaga wrote:
Video user controls such as brightness, contrast, saturation, and
hue are now handled.
I just saw this patch series being merged, and I wonder if you could make a
follow-up patch for 3.6 where you implement the control framework for adv7180
and sta2x11. See Documentation/video4linux/v4l2-controls.txt and the many
drivers that use it now.
I missed this patch series or I would have requested it at the time.
Unfortunately
I had to deal with other things in March and April so I was for the most part
absent from the list during those months.
My goal is to convert all subdevice drivers like adv7180 and as many bridge and
platform drivers as is possible to the control framework. I try to prevent new
drivers from getting in that do not use that framework to prevent double work,
but I didn't catch this one.
If you could do that work, then that would be much appreciated. You have the
hardware, after all, so that makes it easier for you.
Regards,
Hans
Signed-off-by: Federico Vaga federico.v...@gmail.com
Acked-by: Giancarlo Asnaghi giancarlo.asna...@st.com
Cc: Alan Cox a...@linux.intel.com
---
drivers/media/video/adv7180.c | 417
++---
1 files changed, 350 insertions(+), 67 deletions(-)
diff --git a/drivers/media/video/adv7180.c b/drivers/media/video/adv7180.c
index b8b6c4b..174bffa 100644
--- a/drivers/media/video/adv7180.c
+++ b/drivers/media/video/adv7180.c
@@ -48,6 +48,7 @@
#define ADV7180_INPUT_CONTROL_PAL_COMB_N_PED 0xd0
#define ADV7180_INPUT_CONTROL_PAL_SECAM 0xe0
#define ADV7180_INPUT_CONTROL_PAL_SECAM_PED 0xf0
+#define ADV7180_INPUT_CONTROL_INSEL_MASK 0x0f
#define ADV7180_EXTENDED_OUTPUT_CONTROL_REG 0x04
#define ADV7180_EXTENDED_OUTPUT_CONTROL_NTSCDIS 0xC5
@@ -55,9 +56,29 @@
#define ADV7180_AUTODETECT_ENABLE_REG0x07
#define ADV7180_AUTODETECT_DEFAULT 0x7f
+#define ADV7180_CON_REG 0x08/*Unsigned */
+#define CON_REG_MIN 0
+#define CON_REG_DEF 128
+#define CON_REG_MAX 255
+
+#define ADV7180_BRI_REG 0x0a/*Signed */
+#define BRI_REG_MIN -128
+#define BRI_REG_DEF 0
+#define BRI_REG_MAX 127
+
+#define ADV7180_HUE_REG 0x0b/*Signed, inverted */
+#define HUE_REG_MIN -127
+#define HUE_REG_DEF 0
+#define HUE_REG_MAX 128
+
#define ADV7180_ADI_CTRL_REG 0x0e
#define ADV7180_ADI_CTRL_IRQ_SPACE 0x20
+#define ADV7180_PWR_MAN_REG 0x0f
+#define ADV7180_PWR_MAN_ON 0x04
+#define ADV7180_PWR_MAN_OFF 0x24
+#define ADV7180_PWR_MAN_RES 0x80
+
#define ADV7180_STATUS1_REG 0x10
#define ADV7180_STATUS1_IN_LOCK 0x01
#define ADV7180_STATUS1_AUTOD_MASK 0x70
@@ -78,6 +99,12 @@
#define ADV7180_ICONF1_PSYNC_ONLY0x10
#define ADV7180_ICONF1_ACTIVE_TO_CLR 0xC0
+#define ADV7180_SD_SAT_CB_REG0xe3/*Unsigned */
+#define ADV7180_SD_SAT_CR_REG0xe4/*Unsigned */
+#define SAT_REG_MIN 0
+#define SAT_REG_DEF 128
+#define SAT_REG_MAX 255
+
#define ADV7180_IRQ1_LOCK0x01
#define ADV7180_IRQ1_UNLOCK 0x02
#define ADV7180_ISR1_ADI 0x42
@@ -90,6 +117,9 @@
#define ADV7180_IMR3_ADI 0x4C
#define ADV7180_IMR4_ADI 0x50
+#define ADV7180_NTSC_V_BIT_END_REG 0xE6
+#define ADV7180_NTSC_V_BIT_END_MANUAL_NVEND 0x4F
+
struct adv7180_state {
struct v4l2_subdev sd;
struct work_struct work;
@@ -97,6 +127,11 @@ struct adv7180_state {
int irq;
v4l2_std_id curr_norm;
boolautodetect;
+ s8 brightness;
+ s16 hue;
+ u8 contrast;
+ u8 saturation;
+ u8 input;
};
static v4l2_std_id adv7180_std_to_v4l2(u8 status1)
@@ -155,7 +190,7 @@ static u32 adv7180_status_to_v4l2(u8 status1)
}
static int __adv7180_status(struct i2c_client *client, u32 *status,
- v4l2_std_id *std)
+ v4l2_std_id *std)
{
int status1 = i2c_smbus_read_byte_data(client, ADV7180_STATUS1_REG);
@@ -192,6 +227,36 @@ static int adv7180_querystd(struct v4l2_subdev *sd,
v4l2_std_id *std)
return err;
}
+static int adv7180_s_routing(struct v4l2_subdev *sd, u32 input,
+ u32 output, u32 config)
+{
+ struct adv7180_state *state = to_state(sd);
+ int ret = mutex_lock_interruptible(state-mutex);
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+ if (ret)
+ return ret;
+
+ /*We cannot discriminate between LQFP and
Re: [GIT PULL FOR 3.5] s5p-fimc driver updates
Em 20-05-2012 11:05, Sylwester Nawrocki escreveu: On 05/20/2012 02:39 PM, Mauro Carvalho Chehab wrote: Em 14-05-2012 18:39, Sylwester Nawrocki escreveu: On 05/10/2012 10:48 AM, Sylwester Nawrocki wrote: On 05/04/2012 05:31 PM, Sylwester Nawrocki wrote: ... The following changes since commit ae45d3e9aea0ab951dbbca2238fbfbf3993f1e7f: s5p-fimc: Correct memory allocation for VIDIOC_CREATE_BUFS (2012-05-09 16:07:49 +0200) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-samsung v4l-fimc-exynos4x12 for you to fetch changes up to 5feefe6656583de6fd4ef1d53b19031dd5efeec1: s5p-fimc: Use selection API in place of crop operations (2012-05-09 16:11:29 +0200) Sylwester Nawrocki (14): V4L: Extend V4L2_CID_COLORFX with more image effects s5p-fimc: Avoid crash with null platform_data s5p-fimc: Move m2m node driver into separate file It seems there is a conflict now with this patch: http://git.linuxtv.org/media_tree.git/commit/5126f2590bee412e3053de851cb07f531e4be36a Attached are updated versions of the two conflicting patches, the others don't need touching. I could provide rebased version of the whole change set tomorrow - if needed. Please do that, as this patch doesn't apply as-is. I guess there is no intervention from my side needed, since you already applied those updated patches to the media tree (since I pushed the rebased patch to git.infradead.org a few days ago already) ? However, there is going to be conflicts now with my patch from Sakari's pull request: http://patchwork.linuxtv.org/patch/11336. Yes. I didn't apply that patch. It needs rework. As we talked in #v4l IRC, even if the API is experimental, any changes to it must not cause build breaks. I didn't discuss that yet with Sakari. I have now reworked the renaming patch, so it now includes backward compatibility definitions like this: #define V4L2_SEL_TGT_CROP_ACTIVE V4L2_SEL_TGT_CROP #define V4L2_SEL_TGT_COMPOSE_ACTIVE V4L2_SEL_TGT_COMPOSE I would then make a patch for Documentation/feature-removal-schedule.txt to indicate those aliases will be removed after two kernel releases. Does it sound like a right thing to do ? _If_ 3.5 is the first kernel with the selection API, we can fix it without a backward compat, but I think that the selection API went into 3.4 kernel series. Regards, Mauro -- 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 3/3] STA2X11 VIP: new V4L2 driver
Hi Federico, This driver is now merged, but I'm not happy with this. The main criticism is that it doesn't use videobuf2, but still uses the old videobuf framework. You really, really should upgrade. There is also no reason to return -EBUSY if someone opens the device node a second time. That's a perfectly valid thing to do. And please run the v4l2-compliance tool for your driver (found in the v4l-utils.git repository). It will find quite a few issues, I'm sure. I see that there was no review of this code at the time you posted it. Normally I would have reviewed it, but as I mentioned earlier, I was temporarily absent from the list at the time. It's too bad that I'm finding these issues so late. I hope you can spend some time upgrading the driver for 3.6. Regards, Hans On Thu April 12 2012 18:39:38 Federico Vaga wrote: V4L2 driver for the Video Input Port within STA2X11 board Signed-off-by: Federico Vaga federico.v...@gmail.com Acked-by: Giancarlo Asnaghi giancarlo.asna...@st.com Cc: Alan Cox a...@linux.intel.com --- drivers/media/video/Kconfig | 13 + drivers/media/video/Makefile |1 + drivers/media/video/sta2x11_vip.c | 1550 + drivers/media/video/sta2x11_vip.h | 40 + 4 files changed, 1604 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/sta2x11_vip.c create mode 100644 drivers/media/video/sta2x11_vip.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index f2479c5..32c6c0e 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -794,6 +794,19 @@ source drivers/media/video/saa7164/Kconfig source drivers/media/video/zoran/Kconfig +config STA2X11_VIP + tristate STA2X11 VIP Video For Linux + depends on STA2X11 + select VIDEO_ADV7180 if VIDEO_HELPER_CHIPS_AUTO + select VIDEOBUF_DMA_CONTIG + depends on PCI VIDEO_V4L2 VIRT_TO_BUS + help + Say Y for support for STA2X11 VIP (Video Input Port) capture + device. + + To compile this driver as a module, choose M here: the + module will be called sta2x11_vip. + endif # V4L_PCI_DRIVERS # diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index a6282a3..2a05b9a 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -120,6 +120,7 @@ obj-$(CONFIG_VIDEO_TM6000) += tm6000/ obj-$(CONFIG_VIDEO_MXB) += mxb.o obj-$(CONFIG_VIDEO_HEXIUM_ORION) += hexium_orion.o obj-$(CONFIG_VIDEO_HEXIUM_GEMINI) += hexium_gemini.o +obj-$(CONFIG_STA2X11_VIP) += sta2x11_vip.o obj-$(CONFIG_VIDEO_TIMBERDALE) += timblogiw.o obj-$(CONFIG_VIDEOBUF_GEN) += videobuf-core.o diff --git a/drivers/media/video/sta2x11_vip.c b/drivers/media/video/sta2x11_vip.c new file mode 100644 index 000..636643f --- /dev/null +++ b/drivers/media/video/sta2x11_vip.c @@ -0,0 +1,1550 @@ +/* + * This is the driver for the STA2x11 Video Input Port. + * + * Copyright (C) 2010 WindRiver Systems, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms and conditions of the GNU General Public License, + * version 2, as published by the Free Software Foundation. + * + * This program is distributed in the hope it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + * more details. + * + * You should have received a copy of the GNU General Public License along with + * this program; if not, write to the Free Software Foundation, Inc., + * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA. + * + * The full GNU General Public License is included in this distribution in + * the file called COPYING. + * + * Author: Andreas Kies andreas.k...@windriver.com + * Vlad Lungu vlad.lu...@windriver.com + * + */ + +#include linux/types.h +#include linux/kernel.h +#include linux/module.h +#include linux/init.h +#include linux/vmalloc.h + +#include linux/videodev2.h + +#include linux/kmod.h + +#include linux/pci.h +#include linux/interrupt.h +#include linux/mutex.h +#include linux/io.h +#include linux/gpio.h +#include linux/i2c.h +#include linux/delay.h +#include media/v4l2-common.h +#include media/v4l2-device.h +#include media/v4l2-ioctl.h +#include media/videobuf-dma-contig.h + +#include sta2x11_vip.h + +#define DRV_NAME sta2x11_vip +#define DRV_VERSION 1.3 + +#ifndef PCI_DEVICE_ID_STMICRO_VIP +#define PCI_DEVICE_ID_STMICRO_VIP 0xCC0D +#endif + +#define MAX_FRAMES 4 + +/*Register offsets*/ +#define DVP_CTL 0x00 +#define DVP_TFO 0x04 +#define DVP_TFS 0x08 +#define DVP_BFO 0x0C +#define DVP_BFS 0x10 +#define DVP_VTP 0x14 +#define DVP_VBP 0x18 +#define DVP_VMP 0x1C +#define
rtl28xxu - rtl2832 frontend attach
Heigh ho, heigh ho To make your troubles go Just keep on singing All day long, heigh ho Heigh ho! After hard/cold boot: […] usb 1-1: new high-speed USB device number 2 using ehci_hcd usb 1-1: New USB device found, idVendor=1f4d, idProduct=b803 usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1: Product: RTL2838UHIDIR usb 1-1: Manufacturer: Realtek usb 1-1: SerialNumber: 0041 rtl28xxu_module_init: rtl28xxu_probe: interface=0 check for warm bda 2831 check for warm 14aa 160 check for warm 14aa 161 something went very wrong, device was not found in current device list - let's see what comes next. check for warm ccd a9 check for warm 1f4d b803 dvb-usb: found a 'G-Tek Electronics Group Lifeview LV5TDLX DVB-T' in warm state. power control: 1 rtl2832u_power_ctrl: onoff=1 dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. all in all I will use 24576 bytes for streaming DVB: registering new adapter (G-Tek Electronics Group Lifeview LV5TDLX DVB-T) DVB: register adapter0/demux0 @ minor: 0 (0x00) DVB: register adapter0/dvr0 @ minor: 1 (0x01) DVB: register adapter0/net0 @ minor: 2 (0x02) rtl2832u_frontend_attach: rtl28xxu: rtl2832u_frontend_attach: FC0012 tuner found dvb_register_frontend DVB: registering adapter 0 frontend 0 (Realtek RTL2832 (DVB-T))... DVB: register adapter0/frontend0 @ minor: 3 (0x03) dvb_frontend_clear_cache() Clearing cache for delivery system 3 rtl2832u_tuner_attach: fc0012: Fitipower FC0012 successfully attached. Registered IR keymap rc-empty input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:02.1/usb1/1-1/rc/rc0/input5 rc0: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:02.1/usb1/1-1/rc/rc0 dvb-usb: schedule remote query interval to 400 msecs. power control: 0 rtl2832u_power_ctrl: onoff=0 dvb-usb: G-Tek Electronics Group Lifeview LV5TDLX DVB-T successfully initialized and connected. rtl28xxu_probe: interface=1 usbcore: registered new interface driver dvb_usb_rtl28xxu […] Seems OK. After soft/warm re(boot): […] usb 1-1: new high-speed USB device number 2 using ehci_hcd usb 1-1: New USB device found, idVendor=1f4d, idProduct=b803 usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1: Product: RTL2838UHIDIR usb 1-1: Manufacturer: Realtek usb 1-1: SerialNumber: 0041 rtl28xxu_module_init: rtl28xxu_probe: interface=0 check for warm bda 2831 check for warm 14aa 160 check for warm 14aa 161 something went very wrong, device was not found in current device list - let's see what comes next. check for warm ccd a9 check for warm 1f4d b803 dvb-usb: found a 'G-Tek Electronics Group Lifeview LV5TDLX DVB-T' in warm state. power control: 1 rtl2832u_power_ctrl: onoff=1 dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. all in all I will use 24576 bytes for streaming DVB: registering new adapter (G-Tek Electronics Group Lifeview LV5TDLX DVB-T) DVB: register adapter0/demux0 @ minor: 0 (0x00) DVB: register adapter0/dvr0 @ minor: 1 (0x01) DVB: register adapter0/net0 @ minor: 2 (0x02) rtl2832u_frontend_attach: rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 No compatible tuner found dvb-usb: no frontend was attached by 'G-Tek Electronics Group Lifeview LV5TDLX DVB-T' Registered IR keymap rc-empty input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:02.1/usb1/1-1/rc/rc0/input5 rc0: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:02.1/usb1/1-1/rc/rc0 dvb-usb: schedule remote query interval to 400 msecs. power control: 0 rtl2832u_power_ctrl: onoff=0 dvb-usb: G-Tek Electronics Group Lifeview LV5TDLX DVB-T successfully initialized and connected. rtl28xxu_probe: interface=1 usbcore: registered new interface driver dvb_usb_rtl28xxu […] D'oh! Difference - cold vs warm boot: rtl28xxu: rtl2832u_frontend_attach: FC0012 tuner found dvb_register_frontend DVB: registering adapter 0 frontend 0 (Realtek RTL2832 (DVB-T))... DVB: register adapter0/frontend0 @ minor: 3 (0x03) dvb_frontend_clear_cache() Clearing cache for delivery system 3 rtl2832u_tuner_attach: fc0012: Fitipower FC0012 successfully attached. --- rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 No compatible tuner found dvb-usb: no frontend was attached by 'G-Tek Electronics Group Lifeview LV5TDLX DVB-T' Any tip or trick? cheers, poma -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to
Re: [GIT PULL FOR 3.5] s5p-fimc driver updates
On 05/20/2012 05:30 PM, Mauro Carvalho Chehab wrote: Em 20-05-2012 11:05, Sylwester Nawrocki escreveu: On 05/20/2012 02:39 PM, Mauro Carvalho Chehab wrote: Em 14-05-2012 18:39, Sylwester Nawrocki escreveu: On 05/10/2012 10:48 AM, Sylwester Nawrocki wrote: On 05/04/2012 05:31 PM, Sylwester Nawrocki wrote: ... The following changes since commit ae45d3e9aea0ab951dbbca2238fbfbf3993f1e7f: s5p-fimc: Correct memory allocation for VIDIOC_CREATE_BUFS (2012-05-09 16:07:49 +0200) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-samsung v4l-fimc-exynos4x12 for you to fetch changes up to 5feefe6656583de6fd4ef1d53b19031dd5efeec1: s5p-fimc: Use selection API in place of crop operations (2012-05-09 16:11:29 +0200) Sylwester Nawrocki (14): V4L: Extend V4L2_CID_COLORFX with more image effects s5p-fimc: Avoid crash with null platform_data s5p-fimc: Move m2m node driver into separate file It seems there is a conflict now with this patch: http://git.linuxtv.org/media_tree.git/commit/5126f2590bee412e3053de851cb07f531e4be36a Attached are updated versions of the two conflicting patches, the others don't need touching. I could provide rebased version of the whole change set tomorrow - if needed. Please do that, as this patch doesn't apply as-is. I guess there is no intervention from my side needed, since you already applied those updated patches to the media tree (since I pushed the rebased patch to git.infradead.org a few days ago already) ? However, there is going to be conflicts now with my patch from Sakari's pull request: http://patchwork.linuxtv.org/patch/11336. Yes. I didn't apply that patch. It needs rework. As we talked in #v4l IRC, even if the API is experimental, any changes to it must not cause build breaks. I didn't discuss that yet with Sakari. I have now reworked the renaming patch, so it now includes backward compatibility definitions like this: #define V4L2_SEL_TGT_CROP_ACTIVE V4L2_SEL_TGT_CROP #define V4L2_SEL_TGT_COMPOSE_ACTIVE V4L2_SEL_TGT_COMPOSE I would then make a patch for Documentation/feature-removal-schedule.txt to indicate those aliases will be removed after two kernel releases. Does it sound like a right thing to do ? _If_ 3.5 is the first kernel with the selection API, we can fix it without a backward compat, but I think that the selection API went into 3.4 kernel series. Yeah, only the selection API for subdevs is first appearing in kernel 3.5, and it's been already two stable kernel releases since the selection API was introduced: $ git log --oneline v3.0..v3.3 -- Documentation/DocBook/media/v4l/vidioc-g-selection.xml 8af4922 [media] doc: v4l: add documentation for selection API So some backward compatibility code seems to be needed. It's not really a big deal and would saved users headaches. -- Regards, Sylwester -- 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
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Sun May 20 19:00:24 CEST 2012 git hash:711e1bfb5b7e77e5317b25fc5a2faf3d47cf5d7b gcc version: i686-linux-gcc (GCC) 4.6.3 host hardware:x86_64 host os: 3.3-5.slh.3-amd64 linux-git-arm-eabi-exynos: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: ERRORS linux-2.6.38.2-i686: ERRORS linux-2.6.39.1-i686: ERRORS linux-3.0-i686: ERRORS linux-3.1-i686: ERRORS linux-3.2.1-i686: ERRORS linux-3.3-i686: ERRORS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS linux-2.6.36-x86_64: ERRORS linux-2.6.37-x86_64: ERRORS linux-2.6.38.2-x86_64: ERRORS linux-2.6.39.1-x86_64: ERRORS linux-3.0-x86_64: ERRORS linux-3.1-x86_64: ERRORS linux-3.2.1-x86_64: ERRORS linux-3.3-x86_64: ERRORS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.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: [PATCH 2/3] fc001x: tuner driver for FC0012, version 0.5
Hmm,
Mauro just merged those FC0012 and FC0013 drivers via my RTL2831U
tree... It was not my meaning to do that like this.
Anyhow, I will now review those FC0012 and FC0013.
On 06.05.2012 23:56, Hans-Frieder Vogt wrote:
Support for tuner Fitipower FC0012
Signed-off-by: Hans-Frieder Vogthfv...@gmx.net
drivers/media/common/tuners/Kconfig |7
drivers/media/common/tuners/Makefile |1
drivers/media/common/tuners/fc0012-priv.h | 43 +++
drivers/media/common/tuners/fc0012.c | 397
++
drivers/media/common/tuners/fc0012.h | 44 +++
5 files changed, 492 insertions(+)
diff -up --new-file --recursive a/drivers/media/common/tuners/Kconfig
b/drivers/media/common/tuners/Kconfig
--- a/drivers/media/common/tuners/Kconfig 2012-04-10 05:45:26.0
+0200
+++ b/drivers/media/common/tuners/Kconfig 2012-05-06 22:20:10.167088333
+0200
@@ -211,6 +211,13 @@ config MEDIA_TUNER_FC0011
help
Fitipower FC0011 silicon tuner driver.
+config MEDIA_TUNER_FC0012
+ tristate Fitipower FC0012 silicon tuner
+ depends on VIDEO_MEDIA I2C
+ default m if MEDIA_TUNER_CUSTOMISE
+ help
+ Fitipower FC0012 silicon tuner driver.
+
config MEDIA_TUNER_TDA18212
tristate NXP TDA18212 silicon tuner
depends on VIDEO_MEDIA I2C
diff -up --new-file --recursive a/drivers/media/common/tuners/Makefile
b/drivers/media/common/tuners/Makefile.half
--- a/drivers/media/common/tuners/Makefile 2012-04-10 05:45:26.0
+0200
+++ b/drivers/media/common/tuners/Makefile 2012-05-06 22:20:25.270299615
+0200
@@ -30,6 +30,7 @@ obj-$(CONFIG_MEDIA_TUNER_TDA18218) += td
obj-$(CONFIG_MEDIA_TUNER_TDA18212) += tda18212.o
obj-$(CONFIG_MEDIA_TUNER_TUA9001) += tua9001.o
obj-$(CONFIG_MEDIA_TUNER_FC0011) += fc0011.o
+obj-$(CONFIG_MEDIA_TUNER_FC0012) += fc0012.o
ccflags-y += -I$(srctree)/drivers/media/dvb/dvb-core
ccflags-y += -I$(srctree)/drivers/media/dvb/frontends
diff -up --new-file --recursive a/drivers/media/common/tuners/fc0012.c
b/drivers/media/common/tuners/fc0012.c
--- a/drivers/media/common/tuners/fc0012.c 1970-01-01 01:00:00.0
+0100
+++ b/drivers/media/common/tuners/fc0012.c 2012-05-06 19:38:03.731130289
+0200
@@ -0,0 +1,397 @@
+/*
+ * Fitipower FC0012 tuner driver
+ *
+ * Copyright (C) 2012 Hans-Frieder Vogthfv...@gmx.net
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include fc0012.h
+#include fc0012-priv.h
+
+static int fc0012_writereg(struct fc0012_priv *priv, u8 reg, u8 val)
+{
+ u8 buf[2] = {reg, val};
+ struct i2c_msg msg = {
+ .addr = priv-addr, .flags = 0, .buf = buf, .len = 2
+ };
+
+ if (i2c_transfer(priv-i2c,msg, 1) != 1) {
+ err(I2C write reg failed, reg: %02x, val: %02x, reg, val);
+ return -EREMOTEIO;
+ }
+ return 0;
+}
+
+static int fc0012_readreg(struct fc0012_priv *priv, u8 reg, u8 *val)
+{
+ struct i2c_msg msg[2] = {
+ { .addr = priv-addr, .flags = 0, .buf =reg, .len = 1 },
+ { .addr = priv-addr, .flags = I2C_M_RD, .buf = val, .len = 1 },
+ };
+
+ if (i2c_transfer(priv-i2c, msg, 2) != 2) {
+ err(I2C read reg failed, reg: %02x, reg);
+ return -EREMOTEIO;
+ }
+ return 0;
+}
+
+static int fc0012_release(struct dvb_frontend *fe)
+{
+ kfree(fe-tuner_priv);
+ fe-tuner_priv = NULL;
+ return 0;
+}
+
+static int fc0012_init(struct dvb_frontend *fe)
+{
+ struct fc0012_priv *priv = fe-tuner_priv;
+ int i, ret = 0;
ret = 0 is unneeded initialization in that case.
+ unsigned char reg[] = {
We use generally u8 instead of unsigned char. But just only style
issue... I don't see requirement to change.
+ 0x00, /* dummy reg. 0 */
+ 0x05, /* reg. 0x01 */
+ 0x10, /* reg. 0x02 */
+ 0x00, /* reg. 0x03 */
+ 0x00, /* reg. 0x04 */
+ 0x0f, /* reg. 0x05: may also be 0x0a */
+ 0x00, /* reg. 0x06: divider 2, VCO slow */
+ 0x00, /* reg. 0x07: may also be 0x0f */
+ 0xff, /* reg. 0x08: AGC Clock divide by 256, AGC gain 1/256,
+ Loop Bw 1/8 */
+
Re: [PATCH 3/3] fc001x: tuner driver for FC0013
On 06.05.2012 23:57, Hans-Frieder Vogt wrote:
Support for tuner Fitipower FC0013
Signed-off-by: Hans-Frieder Vogthfv...@gmx.net
drivers/media/common/tuners/Kconfig |7
drivers/media/common/tuners/Makefile |1
drivers/media/common/tuners/fc0013-priv.h | 44 ++
drivers/media/common/tuners/fc0013.c | 562
++
drivers/media/common/tuners/fc0013.h | 57 +++
5 files changed, 671 insertions(+)
diff -up --new-file --recursive a/drivers/media/common/tuners/Kconfig
b/drivers/media/common/tuners/Kconfig
--- a/drivers/media/common/tuners/Kconfig 2012-05-06 22:20:10.167088333
+0200
+++ b/drivers/media/common/tuners/Kconfig 2012-05-05 12:00:43.769785450
+0200
@@ -218,6 +218,13 @@ config MEDIA_TUNER_FC0012
help
Fitipower FC0012 silicon tuner driver.
+config MEDIA_TUNER_FC0013
+ tristate Fitipower FC0013 silicon tuner
+ depends on VIDEO_MEDIA I2C
+ default m if MEDIA_TUNER_CUSTOMISE
+ help
+ Fitipower FC0013 silicon tuner driver.
+
config MEDIA_TUNER_TDA18212
tristate NXP TDA18212 silicon tuner
depends on VIDEO_MEDIA I2C
diff -up --new-file --recursive a/drivers/media/common/tuners/Makefile
b/drivers/media/common/tuners/Makefile
--- a/drivers/media/common/tuners/Makefile 2012-05-06 22:20:25.270299615
+0200
+++ b/drivers/media/common/tuners/Makefile 2012-05-06 19:13:08.974524215
+0200
@@ -31,6 +31,7 @@ obj-$(CONFIG_MEDIA_TUNER_TDA18212) += td
obj-$(CONFIG_MEDIA_TUNER_TUA9001) += tua9001.o
obj-$(CONFIG_MEDIA_TUNER_FC0011) += fc0011.o
obj-$(CONFIG_MEDIA_TUNER_FC0012) += fc0012.o
+obj-$(CONFIG_MEDIA_TUNER_FC0013) += fc0013.o
ccflags-y += -I$(srctree)/drivers/media/dvb/dvb-core
ccflags-y += -I$(srctree)/drivers/media/dvb/frontends
diff -up --new-file --recursive a/drivers/media/common/tuners/fc0013.c
b/drivers/media/common/tuners/fc0013.c
--- a/drivers/media/common/tuners/fc0013.c 1970-01-01 01:00:00.0
+0100
+++ b/drivers/media/common/tuners/fc0013.c 2012-05-06 19:40:15.506368324
+0200
@@ -0,0 +1,562 @@
+/*
+ * Fitipower FC0013 tuner driver
+ *
+ * Copyright (C) 2012 Hans-Frieder Vogthfv...@gmx.net
+ * partially based on driver code from Fitipower
+ * Copyright (C) 2010 Fitipower Integrated Technology Inc
+ *
+ *This program is free software; you can redistribute it and/or modify
+ *it under the terms of the GNU General Public License as published by
+ *the Free Software Foundation; either version 2 of the License, or
+ *(at your option) any later version.
+ *
+ *This program is distributed in the hope that it will be useful,
+ *but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ *GNU General Public License for more details.
+ *
+ *You should have received a copy of the GNU General Public License
+ *along with this program; if not, write to the Free Software
+ *Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ */
+
+#include fc0013.h
+#include fc0013-priv.h
+
+static int fc0013_writereg(struct fc0013_priv *priv, u8 reg, u8 val)
+{
+ u8 buf[2] = {reg, val};
+ struct i2c_msg msg = {
+ .addr = priv-addr, .flags = 0, .buf = buf, .len = 2
+ };
+
+ if (i2c_transfer(priv-i2c,msg, 1) != 1) {
+ err(I2C write reg failed, reg: %02x, val: %02x, reg, val);
+ return -EREMOTEIO;
+ }
+ return 0;
+}
+
+static int fc0013_readreg(struct fc0013_priv *priv, u8 reg, u8 *val)
+{
+ struct i2c_msg msg[2] = {
+ { .addr = priv-addr, .flags = 0, .buf =reg, .len = 1 },
+ { .addr = priv-addr, .flags = I2C_M_RD, .buf = val, .len = 1 },
+ };
+
+ if (i2c_transfer(priv-i2c, msg, 2) != 2) {
+ err(I2C read reg failed, reg: %02x, reg);
+ return -EREMOTEIO;
+ }
+ return 0;
+}
+
+static int fc0013_release(struct dvb_frontend *fe)
+{
+ kfree(fe-tuner_priv);
+ fe-tuner_priv = NULL;
+ return 0;
+}
+
+static int fc0013_init(struct dvb_frontend *fe)
+{
+ struct fc0013_priv *priv = fe-tuner_priv;
+ int i, ret = 0;
+ unsigned char reg[] = {
+ 0x00, /* reg. 0x00: dummy */
+ 0x09, /* reg. 0x01 */
+ 0x16, /* reg. 0x02 */
+ 0x00, /* reg. 0x03 */
+ 0x00, /* reg. 0x04 */
+ 0x17, /* reg. 0x05 */
+ 0x02, /* reg. 0x06 */
+ 0x0a, /* reg. 0x07: CHECK */
+ 0xff, /* reg. 0x08: AGC Clock divide by 256, AGC gain 1/256,
+ Loop Bw 1/8 */
+ 0x6f, /* reg. 0x09: enable LoopThrough */
+ 0xb8, /* reg. 0x0a: Disable LO Test Buffer */
+ 0x82, /* reg. 0x0b: CHECK */
+ 0xfc, /* reg. 0x0c: depending on AGC Up-Down mode, may need
0xf8 */
Re: [PATCH] V4L: Remove _ACTIVE from the selection target name definitions
Hi Sylwester, Sylwester Nawrocki wrote: This patch drops the _ACTIVE part from the selection target names as a prerequisite to unify the selection target names across the subdev and regular video node API. The meaning of V4L2_SEL_TGT_*_ACTIVE and V4L2_SUBDEV_SEL_TGT_*_ACTUAL selection targets is logically the same. Different names add to confusion where both APIs are used in a single driver or an application. For some system configurations different names may lead to interoperability issues. For backwards compatibility V4L2_SEL_TGT_CROP_ACTIVE and V4L2_SEL_TGT_COMPOSE_ACTIVE are defined as aliases to V4L2_SEL_TGT_CROP and V4L2_SEL_TGT_COMPOSE. These aliases will be removed after deprecation period, according to Documentation/feature-removal-schedule.txt. Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com Acked-by: Laurent Pinchartlaurent.pinch...@ideasonboard.com Signed-off-by: Sakari Ailussakari.ai...@iki.fi --- This a replacement for this patch: http://patchwork.linuxtv.org/patch/11226 Changes include an adition of backward compatibility alias definitions and the required bits for FIMC-LITE driver. Sakari, do you think you could update you pull request with this patch ? I assumed the Acks still apply, if not, please let me know. I'll send a new pull req with the new patch tomorrow, during early morning unless something unexpected happens. Cheers, -- Sakari Ailus sakari.ai...@iki.fi -- 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: rtl28xxu - rtl2832 frontend attach
On 20.05.2012 20:04, poma wrote: After hard/cold boot: DVB: register adapter0/net0 @ minor: 2 (0x02) rtl2832u_frontend_attach: rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 No compatible tuner found These errors are coming from tuner probe. As it still goes to probing and did not jump out earlier when gate is opened it means that demod is answering commands but tuner are not. My guess is that tuner is still on the reset or not powered at all. It is almost 100% sure error is wrong tuner GPIO. regards Antti -- http://palosaari.fi/ -- 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 06/10] video/uvc: use memweight()
Hi Akinobu,
Thank you for the patch.
On Sunday 20 May 2012 22:23:19 Akinobu Mita wrote:
Use memweight() to count the total number of bits set in memory area.
Signed-off-by: Akinobu Mita akinobu.m...@gmail.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: linux-media@vger.kernel.org
Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/uvc/uvc_ctrl.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_ctrl.c
b/drivers/media/video/uvc/uvc_ctrl.c index 0efd3b1..8683be0 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -1851,7 +1851,7 @@ int uvc_ctrl_init_device(struct uvc_device *dev)
/* Walk the entities list and instantiate controls */
list_for_each_entry(entity, dev-entities, list) {
struct uvc_control *ctrl;
- unsigned int bControlSize = 0, ncontrols = 0;
+ unsigned int bControlSize = 0, ncontrols;
__u8 *bmControls = NULL;
if (UVC_ENTITY_TYPE(entity) == UVC_VC_EXTENSION_UNIT) {
@@ -1869,8 +1869,7 @@ int uvc_ctrl_init_device(struct uvc_device *dev)
uvc_ctrl_prune_entity(dev, entity);
/* Count supported controls and allocate the controls array */
- for (i = 0; i bControlSize; ++i)
- ncontrols += hweight8(bmControls[i]);
+ ncontrols = memweight(bmControls, bControlSize);
if (ncontrols == 0)
continue;
--
Regards,
Laurent Pinchart
--
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
[RFCv1] DVB-USB improvements [alternative 2]
I did some more planning and made alternative RFC.
As the earlier alternative was more like changing old functionality that
new one goes much more deeper.
As a basic rule I designed it to reduce stuff from the current struct
dvb_usb_device_properties. Currently there is many nested structs
introducing same callbacks. For that one I dropped all frontend and
adapter level callbacks to device level. Currently struct contains 2
adapters and 3 frontends - which means we have 2 * 3 = 6 similar
callbacks and only 1 is used. It wastes some space since devices having
more than one adapter or frontend are rather rare. Making callback
selection inside individual driver is very trivial even without a
designated callback. Here is common example from the use of
.frontend_attach() callback in case of only one callback used:
static int frontend_attach(struct dvb_usb_adapter *adap)
{
if (adap-id == 0)
return frontend_attach_1();
else
return frontend_attach_2();
}
Functionality enhancement mentioned earlier RFC are valid too:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg46352.html
As I was a little bit lazy I wrote only quick skeleton code to represent
new simplified struct dvb_usb_device_properties:
struct dvb_usb_device_properties = {
/* download_firmware() success return values to signal what happens
next */
#define RECONNECTS_USB (1 0)
#define RECONNECTS_USB_USING_NEW_ID (1 1)
.size_of_priv = sizeof(struct 'state'),
/* firmware download */
.identify_state(struct dvb_usb_device *d, int *cold),
.get_firmware_name(struct dvb_usb_device *d, char *firmware_name),
.download_firmware(struct dvb_usb_device *d, const struct firmware *fw),
.allow_dynamic_id = true,
.power_ctrl(struct dvb_usb_device *d, int onoff),
.read_config(struct dvb_usb_device *d, u8 mac[6]),
.get_adapter_count(struct dvb_usb_device *d, int *count),
.frontend_attach(struct dvb_usb_adapter *adap),
.tuner_attach(struct dvb_usb_adapter *adap),
.init(struct dvb_usb_device *d),
.get_rc(struct dvb_rc *),
.i2c_algo = (struct i2c_algorithm),
.frontend_ctrl(struct dvb_frontend *fe, int onoff),
.get_stream_props(struct usb_data_stream_properties *),
.streaming_ctrl(struct dvb_usb_adapter *adap, int onoff),
.generic_bulk_ctrl_endpoint = (int),
.generic_bulk_ctrl_endpoint_response = (int),
.devices = (struct dvb_usb_device)[],
};
struct dvb_usb_device dvb_usb_devices {
char *name = name,
.rc_map = RC_MAP_EMPTY,
.device_id = (struct usb_device_id),
}
It is likely Wednesday I am going to start implementing that one unless
some big issues are raised. Making simple test code as a
proof-of-concept should not be very many days of work.
regards
Antti
--
http://palosaari.fi/
--
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: rtl28xxu - rtl2832 frontend attach
On 20.05.2012 22:08, Antti Palosaari wrote: On 20.05.2012 20:04, poma wrote: After hard/cold boot: DVB: register adapter0/net0 @ minor: 2 (0x02) rtl2832u_frontend_attach: rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 No compatible tuner found These errors are coming from tuner probe. As it still goes to probing and did not jump out earlier when gate is opened it means that demod is answering commands but tuner are not. My guess is that tuner is still on the reset or not powered at all. It is almost 100% sure error is wrong tuner GPIO. There is an issue with GPIO, as FC0012 tuner callback will set the value of one of the GPIO outputs. However fixing that, will not resolve the issue. So I need to debug the problem further. Thanks for the bug report. Regards Thomas -- 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: [RFCv1] DVB-USB improvements [alternative 2]
On Sun, May 20, 2012 at 1:55 PM, Antti Palosaari cr...@iki.fi wrote: I did some more planning and made alternative RFC. As the earlier alternative was more like changing old functionality that new one goes much more deeper. Functionality enhancement mentioned earlier RFC are valid too: http://www.mail-archive.com/linux-media@vger.kernel.org/msg46352.html One thing I didn't see mentioned in your post or the one your linked is the rc dependency for _all_ usb devices, whether they even have rc capability or not. It makes sense that is dvb usb is going to get overhauled, that rc functionality be at the very least optional rather than forced it on all usb devices. -- 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
[PATCH] media: Use pr_info not homegrown pr_reg macro
No need to duplicate normal kernel logging capabilities.
Add pr_fmt and convert pr_reg to pr_info.
Remove pr_reg macros.
Signed-off-by: Joe Perches j...@perches.com
---
drivers/media/rc/fintek-cir.c | 32 +
drivers/media/rc/nuvoton-cir.c | 145
2 files changed, 90 insertions(+), 87 deletions(-)
diff --git a/drivers/media/rc/fintek-cir.c b/drivers/media/rc/fintek-cir.c
index 4a3a238..01764a3 100644
--- a/drivers/media/rc/fintek-cir.c
+++ b/drivers/media/rc/fintek-cir.c
@@ -23,6 +23,8 @@
* USA
*/
+#define pr_fmt(fmt) KBUILD_MODNAME : fmt
+
#include linux/kernel.h
#include linux/module.h
#include linux/pnp.h
@@ -110,30 +112,32 @@ static u8 fintek_cir_reg_read(struct fintek_dev *fintek,
u8 offset)
return val;
}
-#define pr_reg(text, ...) \
- printk(KERN_INFO KBUILD_MODNAME : text, ## __VA_ARGS__)
-
/* dump current cir register contents */
static void cir_dump_regs(struct fintek_dev *fintek)
{
fintek_config_mode_enable(fintek);
fintek_select_logical_dev(fintek, fintek-logical_dev_cir);
- pr_reg(%s: Dump CIR logical device registers:\n, FINTEK_DRIVER_NAME);
- pr_reg( * CR CIR BASE ADDR: 0x%x\n,
- (fintek_cr_read(fintek, CIR_CR_BASE_ADDR_HI) 8) |
+ pr_info(%s: Dump CIR logical device registers:\n, FINTEK_DRIVER_NAME);
+ pr_info( * CR CIR BASE ADDR: 0x%x\n,
+ (fintek_cr_read(fintek, CIR_CR_BASE_ADDR_HI) 8) |
fintek_cr_read(fintek, CIR_CR_BASE_ADDR_LO));
- pr_reg( * CR CIR IRQ NUM: 0x%x\n,
- fintek_cr_read(fintek, CIR_CR_IRQ_SEL));
+ pr_info( * CR CIR IRQ NUM: 0x%x\n,
+ fintek_cr_read(fintek, CIR_CR_IRQ_SEL));
fintek_config_mode_disable(fintek);
- pr_reg(%s: Dump CIR registers:\n, FINTEK_DRIVER_NAME);
- pr_reg( * STATUS: 0x%x\n, fintek_cir_reg_read(fintek,
CIR_STATUS));
- pr_reg( * CONTROL:0x%x\n, fintek_cir_reg_read(fintek,
CIR_CONTROL));
- pr_reg( * RX_DATA:0x%x\n, fintek_cir_reg_read(fintek,
CIR_RX_DATA));
- pr_reg( * TX_CONTROL: 0x%x\n, fintek_cir_reg_read(fintek,
CIR_TX_CONTROL));
- pr_reg( * TX_DATA:0x%x\n, fintek_cir_reg_read(fintek,
CIR_TX_DATA));
+ pr_info(%s: Dump CIR registers:\n, FINTEK_DRIVER_NAME);
+ pr_info( * STATUS: 0x%x\n,
+ fintek_cir_reg_read(fintek, CIR_STATUS));
+ pr_info( * CONTROL:0x%x\n,
+ fintek_cir_reg_read(fintek, CIR_CONTROL));
+ pr_info( * RX_DATA:0x%x\n,
+ fintek_cir_reg_read(fintek, CIR_RX_DATA));
+ pr_info( * TX_CONTROL: 0x%x\n,
+ fintek_cir_reg_read(fintek, CIR_TX_CONTROL));
+ pr_info( * TX_DATA:0x%x\n,
+ fintek_cir_reg_read(fintek, CIR_TX_DATA));
}
/* detect hardware features */
diff --git a/drivers/media/rc/nuvoton-cir.c b/drivers/media/rc/nuvoton-cir.c
index 8b2c071..f7b064f 100644
--- a/drivers/media/rc/nuvoton-cir.c
+++ b/drivers/media/rc/nuvoton-cir.c
@@ -25,6 +25,8 @@
* USA
*/
+#define pr_fmt(fmt) KBUILD_MODNAME : fmt
+
#include linux/kernel.h
#include linux/module.h
#include linux/pnp.h
@@ -123,43 +125,40 @@ static u8 nvt_cir_wake_reg_read(struct nvt_dev *nvt, u8
offset)
return val;
}
-#define pr_reg(text, ...) \
- printk(KERN_INFO KBUILD_MODNAME : text, ## __VA_ARGS__)
-
/* dump current cir register contents */
static void cir_dump_regs(struct nvt_dev *nvt)
{
nvt_efm_enable(nvt);
nvt_select_logical_dev(nvt, LOGICAL_DEV_CIR);
- pr_reg(%s: Dump CIR logical device registers:\n, NVT_DRIVER_NAME);
- pr_reg( * CR CIR ACTIVE : 0x%x\n,
- nvt_cr_read(nvt, CR_LOGICAL_DEV_EN));
- pr_reg( * CR CIR BASE ADDR: 0x%x\n,
- (nvt_cr_read(nvt, CR_CIR_BASE_ADDR_HI) 8) |
+ pr_info(%s: Dump CIR logical device registers:\n, NVT_DRIVER_NAME);
+ pr_info( * CR CIR ACTIVE : 0x%x\n,
+ nvt_cr_read(nvt, CR_LOGICAL_DEV_EN));
+ pr_info( * CR CIR BASE ADDR: 0x%x\n,
+ (nvt_cr_read(nvt, CR_CIR_BASE_ADDR_HI) 8) |
nvt_cr_read(nvt, CR_CIR_BASE_ADDR_LO));
- pr_reg( * CR CIR IRQ NUM: 0x%x\n,
- nvt_cr_read(nvt, CR_CIR_IRQ_RSRC));
+ pr_info( * CR CIR IRQ NUM: 0x%x\n,
+ nvt_cr_read(nvt, CR_CIR_IRQ_RSRC));
nvt_efm_disable(nvt);
- pr_reg(%s: Dump CIR registers:\n, NVT_DRIVER_NAME);
- pr_reg( * IRCON: 0x%x\n, nvt_cir_reg_read(nvt, CIR_IRCON));
- pr_reg( * IRSTS: 0x%x\n, nvt_cir_reg_read(nvt, CIR_IRSTS));
- pr_reg( * IREN: 0x%x\n, nvt_cir_reg_read(nvt, CIR_IREN));
- pr_reg( * RXFCONT: 0x%x\n, nvt_cir_reg_read(nvt, CIR_RXFCONT));
- pr_reg( * CP:0x%x\n, nvt_cir_reg_read(nvt, CIR_CP));
- pr_reg( * CC:0x%x\n, nvt_cir_reg_read(nvt, CIR_CC));
- pr_reg( * SLCH: 0x%x\n, nvt_cir_reg_read(nvt, CIR_SLCH));
- pr_reg( *
Re: [RFCv1] DVB-USB improvements [alternative 2]
On Sun, May 20, 2012 at 6:30 PM, VDR User user@gmail.com wrote: On Sun, May 20, 2012 at 1:55 PM, Antti Palosaari cr...@iki.fi wrote: I did some more planning and made alternative RFC. As the earlier alternative was more like changing old functionality that new one goes much more deeper. Functionality enhancement mentioned earlier RFC are valid too: http://www.mail-archive.com/linux-media@vger.kernel.org/msg46352.html One thing I didn't see mentioned in your post or the one your linked is the rc dependency for _all_ usb devices, whether they even have rc capability or not. It makes sense that is dvb usb is going to get overhauled, that rc functionality be at the very least optional rather than forced it on all usb devices. If you think this is important, then you should feel free to submit patches to Antti's tree. Otherwise, this is the sort of optimization that brings so little value as to not really be worth the engineering effort. The time is better spent working on problems that *actually* have a visible effect to users (and a few extra modules being loaded does not fall into this category). I think you'll find after spending a few hours trying to abstract out the logic and the ugly solution that results that it *really* isn't worth it. Regards, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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: [RFCv1] DVB-USB improvements [alternative 2]
On Sun, May 20, 2012 at 4:10 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: If you think this is important, then you should feel free to submit patches to Antti's tree. Otherwise, this is the sort of optimization that brings so little value as to not really be worth the engineering effort. The time is better spent working on problems that *actually* have a visible effect to users (and a few extra modules being loaded does not fall into this category). I think you'll find after spending a few hours trying to abstract out the logic and the ugly solution that results that it *really* isn't worth it. So you think that it makes more sense to ignore existing issues rather than fix them. Isn't fixing issues flaws the whole point of an overhaul/redesign? Yes, it is. I do get the point you're trying to make -- there are bigger fish to fry. But this is not an urgent project and I disagree with the attitude to just disregard whatever you deem unimportant. If you're going to do it, do it right. -- 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] V4L: sh-mobile-ceu-camera: restore the bus-width test
Hi Guennadi Would be nice if the below patch could be tested with a 16-bit set up. But it should be tested negatively. This means: I think, also now 16-bit set ups work. The only problem is, that even if your board only connects 8 data lines, an attempt to set a 16-bit format wouldn't fail and would, probably, deliver corrupt data. So, the test would be: - take a 16-bit set up and choose a 16-bit format - it should work - remove the 16-bit flag from the platform data - it would, presumably, still work, which is a bug - apply the patch - now verify that 16-bits formats can only be used, if the board specifies the respective flag in platform data Thank you about this patch, but we are busy now. Sorry. We would like to test this, but 16bit camera is using v3.0 kernel now. And it is difficult to update kernel because of time issue. (The board itself is not upstreamed) Of course we will test when we have free time in the future. Best regards --- Kuninori Morimoto -- 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: [RFCv1] DVB-USB improvements [alternative 2]
On 21.05.2012 03:36, VDR User wrote: On Sun, May 20, 2012 at 4:10 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: If you think this is important, then you should feel free to submit patches to Antti's tree. Otherwise, this is the sort of optimization that brings so little value as to not really be worth the engineering effort. The time is better spent working on problems that *actually* have a visible effect to users (and a few extra modules being loaded does not fall into this category). I think you'll find after spending a few hours trying to abstract out the logic and the ugly solution that results that it *really* isn't worth it. So you think that it makes more sense to ignore existing issues rather than fix them. Isn't fixing issues flaws the whole point of an overhaul/redesign? Yes, it is. I do get the point you're trying to make -- there are bigger fish to fry. But this is not an urgent project and I disagree with the attitude to just disregard whatever you deem unimportant. If you're going to do it, do it right. I am not sure what you trying to say. Do you mean I should try to get remote controller totally optional module which can be left out? How much memory will be saved if remote can be left out as unloaded? regards Antti -- http://palosaari.fi/ -- 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 2/3] fc001x: tuner driver for FC0012, version 0.5
Em 20-05-2012 13:56, Antti Palosaari escreveu: Hmm, Mauro just merged those FC0012 and FC0013 drivers via my RTL2831U tree... It was not my meaning to do that like this. This was due to a pull request that you sent me on May, 18, requesting to pull from: git://linuxtv.org/anttip/media_tree.git rtl2831u Regards, Mauro -- 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: [RFCv1] DVB-USB improvements [alternative 2]
On Sun, May 20, 2012 at 7:22 PM, Antti Palosaari cr...@iki.fi wrote: So you think that it makes more sense to ignore existing issues rather than fix them. Isn't fixing issues flaws the whole point of an overhaul/redesign? Yes, it is. I do get the point you're trying to make -- there are bigger fish to fry. But this is not an urgent project and I disagree with the attitude to just disregard whatever you deem unimportant. If you're going to do it, do it right. I am not sure what you trying to say. Do you mean I should try to get remote controller totally optional module which can be left out? I am saying it's a dependency that is currently forced onto every usb device whether the device even supports rc or not. This is clearly poor design. For that matter, the whole usb handling must be poor design if it needs to be overhauled. How much memory will be saved if remote can be left out as unloaded? I don't know. I'm merely pointing out just one of the issues that should be resolved if the idea is to fix things that are wrong with usb handling. If nobody cares, doesn't think it matters, or simply doesn't want to bother, so be it. I guess I'm crazy but when I'm facing an overhaul, especially when there's no rush, I compile a list of _everything_ that's wrong and make sure the overhaul fixes it all. I guess there's quite a difference between my idea of what an overhaul should be, and other peoples. If you really want, there's probably people who deal with embedded systems where every wasted byte counts, that would agree cleaning up the waste is a good idea. Since nobody thinks it should be fixed, just pretend I didn't even bring it up. Problem solved. -- 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
[GIT PULL FOR 3.5 v2] V4L2 and V4L2 subdev selection target rename
Hi Mauro, Compared to the last pull req, I've rebased the request on top of more recent media_tree.git and replaced Sylwester's patch with a newer version of it. --- This pull request contains just two patches; one for the V4L2 and one for the V4L2 subdev interfaces. The patches rename the effective selection targets by removing the _ACTUAL (V4L2 subdev) or _ACTIVE (V4L2) part of the target name, thus making the target names the same on both interfaces except for the _SUBDEV string in the names. We later will to remove that as well but to do that properly requires non-trivial changes to the documentation. The users are already encouraged to use the V4L2 selection targets on subdevs; the documentation will be changed for 3.6. These patches should be applied already now since that decreases the number of required changes for selection API users in the future, and 3.5 is also the first kernel version where the subdev selection API is present. The following changes since commit abed623ca59a7d1abed6c4e7459be03e25a90a1e: [media] radio-sf16fmi: add support for SF16-FMD (2012-05-20 16:10:05 -0300) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git media-for-3.5-selections Sakari Ailus (1): v4l: Remove _ACTUAL from subdev selection API target definition names Sylwester Nawrocki (1): V4L: Remove _ACTIVE from the selection target name definitions Documentation/DocBook/media/v4l/dev-subdev.xml | 25 +-- Documentation/DocBook/media/v4l/selection-api.xml | 24 +- .../DocBook/media/v4l/vidioc-g-selection.xml | 15 ++- .../media/v4l/vidioc-subdev-g-selection.xml| 12 drivers/media/video/omap3isp/ispccdc.c |4 +- drivers/media/video/omap3isp/isppreview.c |4 +- drivers/media/video/omap3isp/ispresizer.c |4 +- drivers/media/video/s5p-fimc/fimc-capture.c| 14 +- drivers/media/video/s5p-fimc/fimc-lite.c |4 +- drivers/media/video/s5p-jpeg/jpeg-core.c |4 +- drivers/media/video/s5p-tv/mixer_video.c |8 +++--- drivers/media/video/smiapp/smiapp-core.c | 22 drivers/media/video/v4l2-ioctl.c |8 +++--- drivers/media/video/v4l2-subdev.c |4 +- include/linux/v4l2-subdev.h|4 +- include/linux/videodev2.h |8 - 16 files changed, 84 insertions(+), 80 deletions(-) Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- 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 2/3] fc001x: tuner driver for FC0012, version 0.5
ma 21.5.2012 5:25 Mauro Carvalho Chehab kirjoitti: Em 20-05-2012 13:56, Antti Palosaari escreveu: Hmm, Mauro just merged those FC0012 and FC0013 drivers via my RTL2831U tree... It was not my meaning to do that like this. This was due to a pull request that you sent me on May, 18, requesting to pull from: git://linuxtv.org/anttip/media_tree.git rtl2831u http://www.spinics.net/lists/linux-media/msg47992.html I asked to pull last 6 patches. There was few other patches bottom of that due to fact it is always some extra work to jump from tree to other, sync and resolve compilation issues. Those tuner patches were there because I tested and reviewed rtl2832 driver multiple times and tuners were needed for the rtl2832. regards Antti -- 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: [RFCv1] DVB-USB improvements [alternative 2]
ma 21.5.2012 5:42 VDR User kirjoitti: On Sun, May 20, 2012 at 7:22 PM, Antti Palosaari cr...@iki.fi wrote: So you think that it makes more sense to ignore existing issues rather than fix them. Isn't fixing issues flaws the whole point of an overhaul/redesign? Yes, it is. I do get the point you're trying to make -- there are bigger fish to fry. But this is not an urgent project and I disagree with the attitude to just disregard whatever you deem unimportant. If you're going to do it, do it right. I am not sure what you trying to say. Do you mean I should try to get remote controller totally optional module which can be left out? I am saying it's a dependency that is currently forced onto every usb device whether the device even supports rc or not. This is clearly poor design. For that matter, the whole usb handling must be poor design if it needs to be overhauled. How much memory will be saved if remote can be left out as unloaded? I don't know. I'm merely pointing out just one of the issues that should be resolved if the idea is to fix things that are wrong with usb handling. If nobody cares, doesn't think it matters, or simply doesn't want to bother, so be it. I guess I'm crazy but when I'm facing an overhaul, especially when there's no rush, I compile a list of _everything_ that's wrong and make sure the overhaul fixes it all. I guess there's quite a difference between my idea of what an overhaul should be, and other peoples. If you really want, there's probably people who deal with embedded systems where every wasted byte counts, that would agree cleaning up the waste is a good idea. Since nobody thinks it should be fixed, just pretend I didn't even bring it up. Problem solved. There is quite few devices that are shipped without remote. I agree that it could be better and more modular. And it is asked multiple times during these years. But my main motivation is to fix problems first and then do enhancements. I will look if I can found some time for that too. regards Antti -- 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: [RFCv1] DVB-USB improvements [alternative 2]
Em 21-05-2012 00:20, Antti Palosaari escreveu: ma 21.5.2012 5:42 VDR User kirjoitti: On Sun, May 20, 2012 at 7:22 PM, Antti Palosaari cr...@iki.fi wrote: So you think that it makes more sense to ignore existing issues rather than fix them. Isn't fixing issues flaws the whole point of an overhaul/redesign? Yes, it is. I do get the point you're trying to make -- there are bigger fish to fry. But this is not an urgent project and I disagree with the attitude to just disregard whatever you deem unimportant. If you're going to do it, do it right. I am not sure what you trying to say. Do you mean I should try to get remote controller totally optional module which can be left out? I am saying it's a dependency that is currently forced onto every usb device whether the device even supports rc or not. This is clearly poor design. For that matter, the whole usb handling must be poor design if it needs to be overhauled. How much memory will be saved if remote can be left out as unloaded? I don't know. I'm merely pointing out just one of the issues that should be resolved if the idea is to fix things that are wrong with usb handling. If nobody cares, doesn't think it matters, or simply doesn't want to bother, so be it. I guess I'm crazy but when I'm facing an overhaul, especially when there's no rush, I compile a list of _everything_ that's wrong and make sure the overhaul fixes it all. I guess there's quite a difference between my idea of what an overhaul should be, and other peoples. If you really want, there's probably people who deal with embedded systems where every wasted byte counts, that would agree cleaning up the waste is a good idea. Since nobody thinks it should be fixed, just pretend I didn't even bring it up. Problem solved. There is quite few devices that are shipped without remote. I agree that it could be better and more modular. And it is asked multiple times during these years. But my main motivation is to fix problems first and then do enhancements. I will look if I can found some time for that too. I see two separate issues here: 1) the dvb_usb properties struct needs to point if the device has RC or not. It could be possible to optimize it if the remote code is not enabled, but provided that the structure is properly designed, the only per-device information is the RC keytable. Optimizing it when IR is not compiled will save just a few bytes per card. Not worth, IMHO. 2) Remove the RC dependency from dvb-usb, and making the dvb-usb-remote code as a module. This can bring some savings, as the RC core and IR decoders won't be loaded. I think (2) is valuable to do, but this can be done latter with a likely simple patch, and won't require any changes at the DVB structures. Regards, Mauro -- 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: [RFCv1] DVB-USB improvements [alternative 2]
Em 20-05-2012 17:55, Antti Palosaari escreveu:
I did some more planning and made alternative RFC.
As the earlier alternative was more like changing old functionality that new
one goes much more deeper.
As a basic rule I designed it to reduce stuff from the current struct
dvb_usb_device_properties. Currently there is many nested structs introducing
same callbacks. For that one I dropped all frontend and adapter level
callbacks to device level. Currently struct contains 2 adapters and 3
frontends - which means we have 2 * 3 = 6 similar callbacks and only 1 is
used. It wastes some space since devices having more than one adapter or
frontend are rather rare. Making callback selection inside individual driver
is very trivial even without a designated callback. Here is common example
from the use of .frontend_attach() callback in case of only one callback used:
static int frontend_attach(struct dvb_usb_adapter *adap)
{
if (adap-id == 0)
return frontend_attach_1();
else
return frontend_attach_2();
}
Functionality enhancement mentioned earlier RFC are valid too:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg46352.html
As I was a little bit lazy I wrote only quick skeleton code to represent new
simplified struct dvb_usb_device_properties:
struct dvb_usb_device_properties = {
/* download_firmware() success return values to signal what happens next */
#define RECONNECTS_USB (1 0)
#define RECONNECTS_USB_USING_NEW_ID (1 1)
.size_of_priv = sizeof(struct 'state'),
/* firmware download */
.identify_state(struct dvb_usb_device *d, int *cold),
.get_firmware_name(struct dvb_usb_device *d, char *firmware_name),
.download_firmware(struct dvb_usb_device *d, const struct firmware *fw),
.allow_dynamic_id = true,
.power_ctrl(struct dvb_usb_device *d, int onoff),
.read_config(struct dvb_usb_device *d, u8 mac[6]),
.get_adapter_count(struct dvb_usb_device *d, int *count),
.frontend_attach(struct dvb_usb_adapter *adap),
.tuner_attach(struct dvb_usb_adapter *adap),
.init(struct dvb_usb_device *d),
.get_rc(struct dvb_rc *),
.i2c_algo = (struct i2c_algorithm),
.frontend_ctrl(struct dvb_frontend *fe, int onoff),
.get_stream_props(struct usb_data_stream_properties *),
.streaming_ctrl(struct dvb_usb_adapter *adap, int onoff),
.generic_bulk_ctrl_endpoint = (int),
.generic_bulk_ctrl_endpoint_response = (int),
.devices = (struct dvb_usb_device)[],
};
struct dvb_usb_device dvb_usb_devices {
char *name = name,
.rc_map = RC_MAP_EMPTY,
.device_id = (struct usb_device_id),
}
It looks OK to me. It may make sense to add an optional
per-device field, to allow drivers to add more board-specific
information, if they need, in order to avoid duplicating
things there.
Another option would be for the drivers to do:
struct dvb_usb_drive_foo dvb_usb_driver_foo {
struct dvb_usb_device dvb_usb_devices dvb_usb_dev;
int foo;
long bar;
...
}
And, inside the core, use the container_of() macro to go from
the device-specific table to struct dvb_usb_device.
This way, simple drivers can do just:
struct dvb_usb_drive_foo dvb_usb_driver_foo {
struct dvb_usb_device dvb_usb_devices dvb_usb_dev;
}
And complex drivers can add more stuff there.
Regards,
Mauro
--
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
