Re: [PATCH 0/3] gspca: kinect cleanup, ov534 port to control framework
On Wed, 16 May 2012 23:42:43 +0200 Antonio Ospite osp...@studenti.unina.it wrote: The second patch removes the dependency between auto gain and auto white balance, I'd like to hear Jean-Francois on this, the webcam (the ov772x sensor) is able to set the two parameters independently and the user can see the difference of either, is there a reason why we were preventing the user from doing so before? Hi Antonio, I added this dependency by the git commit 2d19a2c1186d86e3 on Thu, 12 Nov 2009 (the original patch was done under mercurial). Looking in my archives, I retrieved this mail I have sent to you, Max Thrun, kaswy, baptiste_lemarie, Martin Drake and Jim Paris: On Thu, 12 Nov 2009 13:24:43 +0100 I wrote: On Thu, 12 Nov 2009 11:13:32 +0100 Antonio Ospite osp...@studenti.unina.it wrote: On Wed, 11 Nov 2009 19:13:51 -0500 Max Thrun bear2...@gmail.com wrote: *I get a weird effect, something like a mosaic effect caused by a picture shift, at such high frame rates (also at 640x480@60), I need to verify if it is my usb host which is weak.* [snip] Maybe the End Of Frame detection logic is still imperfect, but I have to admit I haven't looked at it lately. You are heading to face/object tracking, aren't you? Very interesting. When adding the ov965x, I removed the check of the image size. May you try to set it back? (sorry, I have no patch - the check must be done at 2 places, just before adding the LAST_PACKET - the 2nd is enclosed in #if 0) * * Brightness control in guvcview doesn't seem to work.* Confirmed. Easy fix though: [snip] Thanks, please send patches, they are so easy to create from Mercurial that I don't think you have many excuses for not doing so :) Thanks also from me. I already did and uploaded the fix. * * AWB doesn't have any effect?* I notice its effect if i start uvcview, enable auto gain, then enable awb. If there is a strict dependency between these two settings, shouldn't the driver enforce it? [snip] It should! This asks for a change in the main gspca. I will try to do it quickly. Otherwise, you are right, the ov7670 and ov7729 datasheets do not talk about a possible AGC and AWB dependency... -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] gspca: kinect cleanup, ov534 port to control framework
On Fri, 18 May 2012 09:08:29 +0200 Jean-Francois Moine moin...@free.fr wrote: On Wed, 16 May 2012 23:42:43 +0200 Antonio Ospite osp...@studenti.unina.it wrote: The second patch removes the dependency between auto gain and auto white balance, I'd like to hear Jean-Francois on this, the webcam (the ov772x sensor) is able to set the two parameters independently and the user can see the difference of either, is there a reason why we were preventing the user from doing so before? Hi Antonio, I added this dependency by the git commit 2d19a2c1186d86e3 on Thu, 12 Nov 2009 (the original patch was done under mercurial). Looking in my archives, I retrieved this mail I have sent to you, Max Thrun, kaswy, baptiste_lemarie, Martin Drake and Jim Paris: [...] * * AWB doesn't have any effect?* I notice its effect if i start uvcview, enable auto gain, then enable awb. If there is a strict dependency between these two settings, shouldn't the driver enforce it? Here I made a wrong assumption at the time, the bug must have been somewhere else, forgive the younger me in that email :) Otherwise, you are right, the ov7670 and ov7729 datasheets do not talk about a possible AGC and AWB dependency... OK, thanks. Regards, Antonio -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? -- 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 v3.5] Fix gspca compile error if CONFIG_PM is not set
The field 'frozen' is only there if CONFIG_PM is set, so don't use it directly, always check for CONFIG_PM first. Regards, Hans The following changes since commit 61282daf505f3c8def09332ca337ac257b792029: [media] V4L2: mt9t112: fixup JPEG initialization workaround (2012-05-15 16:15:35 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git frozenfix for you to fetch changes up to 4ba342204948e9df49dc1f639ffdbfe49579e626: gspca: the field 'frozen' is under CONFIG_PM (2012-05-18 13:40:42 +0200) Hans Verkuil (1): gspca: the field 'frozen' is under CONFIG_PM drivers/media/video/gspca/finepix.c | 20 +++- drivers/media/video/gspca/jl2005bcd.c |6 +- drivers/media/video/gspca/sq905.c |6 +- drivers/media/video/gspca/sq905c.c|6 +- drivers/media/video/gspca/vicam.c |6 +- drivers/media/video/gspca/zc3xx.c |7 +-- 6 files changed, 40 insertions(+), 11 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] media_build: fix compilation on old kernels (2.6.34)
On Wed May 16 2012 12:44:08 Gianluca Gennari wrote: This patches fix compilation of the media_build tree on kernels older than 2.6.34. Tested on kernel 2.6.32 (Ubuntu 10.04). Applied the patches, thanks! Regards, Hans Gianluca Gennari (2): media_build: add SET_SYSTEM_SLEEP_PM_OPS definition to compat.h media_build: disable VIDEO_SMIAPP driver on kernels older than 2.6.34 v4l/compat.h | 14 ++ v4l/scripts/make_config_compat.pl |1 + v4l/versions.txt |2 ++ 3 files changed, 17 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] gspca: kinect cleanup, ov534 port to control framework
Hi, Thanks for the patches. I've added them all to my tree, so they will be included in my next pull-req. In the mean time you can find them (unmodified) here: http://git.linuxtv.org/hgoede/gspca.git/shortlog/refs/heads/media-for_v3.5-wip On 05/16/2012 11:42 PM, Antonio Ospite wrote: Hi, the first patch just removes traces of the gspca control handling mechanism from the kinect driver; this driver does not have any controls. The change is trivial and can be applied right away, or postponed to when the gspca_main code is removed, you decide. The second patch removes the dependency between auto gain and auto white balance, I'd like to hear Jean-Francois on this, the webcam (the ov772x sensor) is able to set the two parameters independently and the user can see the difference of either, is there a reason why we were preventing the user from doing so before? The third patch is the conversion of the ov534 subdriver to the v4l2 control framework, I tested the code with a PS3 Eye (ov772x sensor) and it works fine (now disabling automatic exposure works too, yay), maybe someone else can give it a run on a webcam with OV767x. NOTE: in patch 3, in sd_init_controls(), I left multiple checks if (sd-sensor == SENSOR_OV772x) just to preserve the order the controls were declared in struct sd, if you feel the order is not that important I can aggregate the checks, just let me know, it just looked neater to me this way. From a purely aesthetic point of view maybe the gspca mechanism of defining controls was prettier, more declarative, but the control framework really looks more correct even from userspace, qv4l2 can now display labels of control classes in tabs automatically while before we had empty labels, disabled controls in clusters work beautifully, and disabled controls with associated automatic settings can show the value calculated by the hardware on every update, very instructive if not super-useful. I'm glad to hear you like the control framework. Regards, Hans Thanks, Antonio Antonio Ospite (3): gspca - kinect: remove traces of gspca control handling gspca - ov534: make AGC and AWB controls independent gspca - ov534: convert to v4l2 control framework drivers/media/video/gspca/kinect.c |9 - drivers/media/video/gspca/ov534.c | 590 2 files changed, 261 insertions(+), 338 deletions(-) -- 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 v4 1/5] rtl2832 ver. 0.4: removed signal statistics
On 18.05.2012 13:38, poma wrote: […] printk(KERN_ERR LOG_PREFIX: f \n , ## arg) pr_err(LOG_PREFIX: f \n , ## arg) printk(KERN_INFO LOG_PREFIX: f \n , ## arg) pr_info(LOG_PREFIX: f \n , ## arg) printk(KERN_WARNING LOG_PREFIX: f \n , ## arg) pr_warn(LOG_PREFIX: f \n , ## arg) Besides what 'checkpatch' suggest/output - Antti, is it a correct conversions? I haven't looked those pr_err/pr_info/pr_warn, but what I did for af9035/af9033 was I used pr_debug as a debug writings since it seems to be choice of today. I still suspect those pr_* functions should be used instead own macros. Currently documentation mentions only pr_debug and pr_info. regards Antit -- 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: PCTV 290e with DVB-C on Fedora 16?
On 18.05.2012 11:38, Niklas Brunlid wrote: That whole issues is related of MFE (multi-frontend) = SFE (single-frontend) change. And there is still known issues like only one frontend parameters, as we still have three different delivery systems Due to that currently applications should not trust parameters frontend is advertising. Only valid parameter is supported delivery systems. Needless to say it took about one week for me to fix all cxd2820r bugs after that... As seen in mythtv-users (http://www.gossamer-threads.com/lists/mythtv/users/514948?search_string=290e;#514948) and mythtv-dev (http://www.gossamer-threads.com/lists/mythtv/dev/514946?search_string=290e;#514946), I'm trying to figure out why my PCTV 290e (which I use for DVB-C only) stopped working when I upgraded to Fedora 16. It was most likely with the switch to the new API (5.x)? Some highlights from the thread(s): begin cut $ w_scan -A2 -fc -cSE -G -X |tee .czap/channels.conf w_scan version 20120112 (compiled for DVB API 5.3) w_scan version 20120112 (compiled for DVB API 5.3) using settings for SWEDEN DVB cable DVB-C scan type CABLE, channellist 7 output format czap/tzap/szap/xine WARNING: could not guess your codepage. Falling back to 'UTF-8' output charset 'UTF-8', use -Ccharset to override Info: using DVB adapter auto detection. /dev/dvb/adapter0/frontend0 - CABLE Sony CXD2820R: very good :-)) Using CABLE frontend (adapter /dev/dvb/adapter0/frontend0) -_-_-_-_ Getting frontend capabilities-_-_-_-_ Using DVB API 5.5 frontend 'Sony CXD2820R' supports DVB-C2 INVERSION_AUTO QAM_AUTO FEC_AUTO FREQ (45.00MHz ... 864.00MHz) This dvb driver is *buggy*: the symbol rate limits are undefined - please report to linuxtv.org -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ 73000: sr6900 (time: 00:00) sr6875 (time: 00:05) w_scan works? At least for me. After trying dvb-fe-tool to force the card to DVB-C: begin cut Didn't help, unfortunately - mythtvsetup still complains: 2012-05-13 17:25:32.385665 E FE_GET_INFO ioctl failed (/dev/dvb/adapter0/frontend0) eno: No such device (19) I looked frontend code and I do not see where that error is coming. Maybe there is no such file at all? 2012-05-13 17:25:33.865334 E FE_GET_INFO ioctl failed (/dev/dvb/adapter_290e/frontend0) eno: No such device (19) /adapter_290e/ something unusual. The backend says: 2012-05-13 17:33:23.922804 I [9042/9059] TVRecEvent tv_rec.cpp:1014 (HandleStateChange) - TVRec(24): Changing from None to WatchingLiveTV 2012-05-13 17:33:23.926627 I [9042/9059] TVRecEvent tv_rec.cpp:3456 (TuningCheckForHWChange) - TVRec(24): HW Tuner: 24-24 2012-05-13 17:33:23.960061 N [9042/9042] CoreContext autoexpire.cpp:263 (CalcParams) - AutoExpire: CalcParams(): Max required Free Space: 2.0 GB w/freq: 14 min 2012-05-13 17:33:24.171394 E [9042/9164] DVBRead dvbstreamhandler.cpp:626 (Open) - PIDInfo(/dev/dvb/adapter_290e/frontend0): Failed to set TS filter (pid 0x0) dvb-fe-tol says: # dvb-fe-tool Device Sony CXD2820R (/dev/dvb/adapter0/frontend0) capabilities: CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_32 CAN_QAM_64 CAN_QAM_128 CAN_QAM_256 CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO DVB API Version 5.5, Current v5 delivery system: DVBC/ANNEX_A Supported delivery systems: DVBT DVBT2 [DVBC/ANNEX_A] ...so the card should be set to DVB-C already, or at least a variant of DVB-C. Is it possible that the kernel module simply doesn't understand the v3 API? Or is v5 backwards compatible? end cut I am using Fedora 16 and latest development Kernel. VLC, czap, w_scan, etc. are working fine. 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: How fix driver for this USB camera (MT9T031 sensor and Cypress FX2LP USB bridge)
Jean-Francois Moine moinejf at free.fr writes: The FX2 is a processor, and, in ov519, used as a bridge, it has been programmed by OmniVision for their sensors. It is quite sure that its firmware is different in your webcam. To know more, you should examine USB traces done with some other driver You're right, protocol was completely different, for instance, we can't read/write to I2C registers of our own choice. Got it working in user space now, including all settings available in their windows software (except software-only settings like gamma etc). Not sure if it's appropriate with a kernel driver, but since the amount of code needed would be so small, we might just as well add it. It would probably add support for these Chinese industrial cameras: DLC130/130L, DLC131/131L, DLC200, DLC300, Whitehawk, Goldenhawk, and GoldenEagle. The Windows software lets you choose between those cameras at start up, and my camera produces images for all those choices. For some choices, the images are cropped, and/or in gray scale with visible bayer pattern (suggesting those cameras would be monochrome). Have a list of bad things below, would appreciate feedback on these. May amount to question whether there should be a kernel driver, in which case I'll just fix up the user space code, and host it somewhere. 1a) This FX2 bridge can't be used for auto-detection, since I didn't snoop anything indicating we could read/write to any sensor registers of our own choice. Additionally, the Windows software don't choose camera based on VID:PID (you have the same choice of cameras even without a camera plugged in), so I assume we need a module parameter for selecting which camera to use. 1b) I only have one of these cameras, so I can only verify against this one, and since mine support the highest resolution, I can't try auto detection methods of requesting higher resolutions then the camera supports (hoping it fails), so module parameters would be needed here to begin with. 2) I guess the video format won't be supported by many apps (raw byer, specifically V4L2_PIX_FMT_SRGGB8). Would it be OK with a module parameter switching on kernel space conversion to something universally useful? (would happen in a workqueueue of course). 3) The windows software (or FX2 bridge) don't handle selecting lower resolutions correctly (it always crops the image, and we get the upper-left portion of the image). This may be appropriate in many industrial applications. But I still feel that users won't know why the driver sucks, so I would spontaneously think we should always emit a couple of KERN_ERR messages describing the possible problems, and possibly even require the user to configure the camera type module parameter before opening the device. Alternatively, we could provide all resolutions, and all combinations of color/monochrome all the time, but then only one out of 14 choices would give the expected image for a normal user, but industrial users would think seven of those 14 modes would be OK. This is a big usability point, I would go for an additional module parameter, allow_crop, which industrial users could set to get access to cropped images, so regular users won't have to set more then a max_resolution or camera_type parameter. But on the bright side, one can have a lot of fun with cheap Chinese industrial cameras, like reverse engineering, and writing kernel drivers :) BR /Simon -- 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 v4 1/5] rtl2832 ver. 0.4: removed signal statistics
On 05/18/2012 02:38 PM, Antti Palosaari wrote: On 18.05.2012 13:38, poma wrote: […] printk(KERN_ERR LOG_PREFIX: f \n , ## arg) pr_err(LOG_PREFIX: f \n , ## arg) printk(KERN_INFO LOG_PREFIX: f \n , ## arg) pr_info(LOG_PREFIX: f \n , ## arg) printk(KERN_WARNING LOG_PREFIX: f \n , ## arg) pr_warn(LOG_PREFIX: f \n , ## arg) Besides what 'checkpatch' suggest/output - Antti, is it a correct conversions? I haven't looked those pr_err/pr_info/pr_warn, but what I did for af9035/af9033 was I used pr_debug as a debug writings since it seems to be choice of today. I still suspect those pr_* functions should be used instead own macros. Currently documentation mentions only pr_debug and pr_info. regards Antit OK, thanks Antti! Thomas, dropping 'rtl2832_priv.h.diff' 'rtl2832_priv.h-v2.diff' Please leave 'rtl2832_priv.h' as it is. And there you go… cheers, poma -- 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 1/1] rc-loopback: remove duplicate line
This patch just removes the second assignment rc-priv = loopdev; that happens a fews lines after the first one. Signed-off-by: Michel Machado mic...@digirati.com.br CC: Mauro Carvalho Chehab mche...@infradead.org CC: David Härdeman da...@hardeman.nu --- diff --git a/drivers/media/rc/rc-loopback.c b/drivers/media/rc/rc-loopback.c index efc6a51..fae1615 100644 --- a/drivers/media/rc/rc-loopback.c +++ b/drivers/media/rc/rc-loopback.c @@ -221,7 +221,6 @@ static int __init loop_init(void) rc-s_idle = loop_set_idle; rc-s_learning_mode = loop_set_learning_mode; rc-s_carrier_report= loop_set_carrier_report; - rc-priv= loopdev; loopdev.txmask = RXMASK_REGULAR; loopdev.txcarrier = 36000; -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How I must report that a driver has been broken?
Hi
Thank you all for your responses.
Devin, I appreciate the time and labor you do to revise the code.
My previous letters maybe I can help you see where the problem and the
date you began.
I thought of a patch of this type:
if (card != mycard) {
bad code for my card}
but unfortunately not so easy for me.
I will be patient.
Thank you.
Alfredo
El 14/05/12 01:51, Devin Heitmueller escribió:
On Sun, May 13, 2012 at 1:50 AM, Hans de Goedehdego...@redhat.com wrote:
Hi,
On 05/12/2012 09:26 PM, Alfredo Jesús Delaiti wrote:
Hi
Thanks for your response Hans and Patrick
Maybe I doing wrong this, because it reports twice:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg45199.html
http://www.mail-archive.com/linux-media@vger.kernel.org/msg44846.html
In your last message you indicate that you've found the patch causing it,
and that you were looking into figuring which bit of the patch actually
breaks things, so I guess people reading the thread were / are
waiting for you to follow up on it with the results of your attempts
to further isolate the cause.
What I were do if I were you is send a mail directly to the author
of the patch causing the problems, with what you've discovered
about the problem sofar in there, and put the list in the CC.
Regards,
Hans
Steven loaned me his HVR-1850 board last week, and I'm hoping to debug
the regression this week (I have an HVR-1800 that is also effected).
I suspect the problem is related to a codepath for the cx23888's
onboard DIF being executed for 885 based boards. Steven did a whole
series of patches to make the cx23888 work properly and I think a
regression snuck in there. Simply backing out the change isn't the
correct fix.
I've got all the boards and the datasheets - I just need to find a bit
of time to get the current tree installed onto a machine and plug in
the various boards...
In short, it's in my queue so please be patient.
Devin
--
Dona tu voz
http://www.voxforge.org/es
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How I must report that a driver has been broken?
On Fri, May 18, 2012 at 10:15 AM, Alfredo Jesús Delaiti
alfredodela...@netscape.net wrote:
Hi
Thank you all for your responses.
Devin, I appreciate the time and labor you do to revise the code.
My previous letters maybe I can help you see where the problem and the date
you began.
I thought of a patch of this type:
if (card != mycard) {
bad code for my card}
but unfortunately not so easy for me.
Some initial analysis of the driver code I did last night suggests
it's much more complicated than that (in addition to the HVR-1850
support there was a bunch of refactoring done to the both the cx23885
and cx25840 drivers).
You can keep an eye on http://www.kernellabs.com/blog for updates.
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: [PATCH v3 07/10] arm: omap4430sdp: Add support for omap4iss camera
Hi Sakari,
On Sun, May 13, 2012 at 7:24 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
Hi Sergio,
On Thu, May 03, 2012 at 10:20:47PM -0500, Aguirre, Sergio wrote:
Hi Sakari,
On Thu, May 3, 2012 at 7:03 AM, Aguirre, Sergio saagui...@ti.com wrote:
Hi Sakari,
Thanks for reviewing.
On Wed, May 2, 2012 at 2:47 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
Hi Sergio,
Thanks for the patches!!
On Wed, May 02, 2012 at 10:15:46AM -0500, Sergio Aguirre wrote:
...
+static int sdp4430_ov_cam1_power(struct v4l2_subdev *subdev, int on)
+{
+ struct device *dev = subdev-v4l2_dev-dev;
+ int ret;
+
+ if (on) {
+ if (!regulator_is_enabled(sdp4430_cam2pwr_reg)) {
+ ret = regulator_enable(sdp4430_cam2pwr_reg);
+ if (ret) {
+ dev_err(dev,
+ Error in enabling sensor power
regulator 'cam2pwr'\n);
+ return ret;
+ }
+
+ msleep(50);
+ }
+
+ gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 1);
+ msleep(10);
+ ret = clk_enable(sdp4430_cam1_aux_clk); /* Enable XCLK */
+ if (ret) {
+ dev_err(dev,
+ Error in clk_enable() in %s(%d)\n,
+ __func__, on);
+ gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 0);
+ return ret;
+ }
+ msleep(10);
+ } else {
+ clk_disable(sdp4430_cam1_aux_clk);
+ msleep(1);
+ gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 0);
+ if (regulator_is_enabled(sdp4430_cam2pwr_reg)) {
+ ret = regulator_disable(sdp4430_cam2pwr_reg);
+ if (ret) {
+ dev_err(dev,
+ Error in disabling sensor power
regulator 'cam2pwr'\n);
+ return ret;
+ }
+ }
+ }
+
+ return 0;
+}
Isn't this something that should be part of the sensor driver? There's
nothing in the above code that would be board specific, except the names
of
the clocks, regulators and GPIOs. The sensor driver could hold the names
instead; this would be also compatible with the device tree.
Agreed. I see what you mean...
I'll take care of that.
Can you please check out these patches?
1.
http://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera/commit/cb6c10d58053180364461e6bc8d30d1ec87e6e22
Ideally we should really get rid of the board code callbacks. What do you
need to do there?
Well, in a OMAP44xx Blaze:
http://svtronics.com/products/27-blaze-mdp
The CSI2-A interface has 2 possible sensor inputs:
- Sony IMX060 12 MP
- OmniVision OV5650 5MP
Which are muxed with a High speed differential selector.
(Analog devices part: ADG936, found here:
http://www.analog.com/static/imported-files/data_sheets/ADG936_936R.pdf)
And to make it more fun, you switch that with a GPIO in an Audio IC (TWL6040) !
Quite a mess, but leaves me with few options, so that's why I need
that to be board
specific, and that by providing these function that can be used to
take care of such
creative designs :P
Have better ideas?
2.
http://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera/commit/6732e0db25c6647b34ef8f01c244a49a1fd6b45d
Isn't reset voltage level (high or low) a property of the sensor rather than
the board?
Well, I know sometimes the people who typically design the hardware can be
quite inventive. ;)
Unfortunately, that's exactly the case!
Again, in this creative design in Blaze platform I mentioned above,
they also have a
level inverter just before the RESET pin in the sensor. So that makes
it active high, from
the GPIO driver point of view :/
Not sure if there's a better way of handling this...
Thanks for the comments!
Regards,
Sergio
3.
http://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera/commit/d61c4e3142dc9cae972f9128fe73d986838c0ca1
4.
http://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera/commit/e83f36001c7f7cbe184ad094d9b0c95c39e5028f
Cheers,
--
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
--
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 v4 1/5] rtl2832 ver. 0.4: removed signal statistics
On 18.05.2012 20:46, Thomas Mair wrote:
On 18.05.2012 15:26, poma wrote:
On 05/18/2012 02:38 PM, Antti Palosaari wrote:
On 18.05.2012 13:38, poma wrote:
[…]
printk(KERN_ERR LOG_PREFIX: f \n , ## arg)
pr_err(LOG_PREFIX: f \n , ## arg)
printk(KERN_INFO LOG_PREFIX: f \n , ## arg)
pr_info(LOG_PREFIX: f \n , ## arg)
printk(KERN_WARNING LOG_PREFIX: f \n , ## arg)
pr_warn(LOG_PREFIX: f \n , ## arg)
Besides what 'checkpatch' suggest/output - Antti, is it a correct
conversions?
I haven't looked those pr_err/pr_info/pr_warn, but what I did for
af9035/af9033 was I used pr_debug as a debug writings since it seems to
be choice of today.
I still suspect those pr_* functions should be used instead own macros.
Currently documentation mentions only pr_debug and pr_info.
regards
Antit
OK, thanks Antti!
Thomas, dropping 'rtl2832_priv.h.diff' 'rtl2832_priv.h-v2.diff'
Please leave 'rtl2832_priv.h' as it is.
And there you go…
cheers,
poma
Alright. One last question though.
I seem incapable of removing the checkpatch error with the parentheses.
How should that be done properly? Should do something like do { ... } while(0)
or is there a more elegant solution?
I have seen that do { ... } while(0) many times in Kernel sources so it
is likely the proper solution.
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
[PATCH v5 0/5] support for rtl2832
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. 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? Regards Thomas Thomas Mair (5): rtl2832 ver. 0.5: support for RTL2832 demod rtl28xxu: support for the rtl2832 demod driver rtl28xxu: renamed rtl2831_rd/rtl2831_wr to rtl28xx_rd/rtl28xx_wr rtl28xxu: support Delock USB 2.0 DVB-T rtl28xxu: support Terratec Noxon DAB/DAB+ stick drivers/media/dvb/dvb-usb/Kconfig |3 + drivers/media/dvb/dvb-usb/dvb-usb-ids.h|3 + drivers/media/dvb/dvb-usb/rtl28xxu.c | 516 -- drivers/media/dvb/frontends/Kconfig|7 + drivers/media/dvb/frontends/Makefile |1 + drivers/media/dvb/frontends/rtl2832.c | 823 drivers/media/dvb/frontends/rtl2832.h | 74 +++ drivers/media/dvb/frontends/rtl2832_priv.h | 260 + 8 files changed, 1638 insertions(+), 49 deletions(-) create mode 100644 drivers/media/dvb/frontends/rtl2832.c create mode 100644 drivers/media/dvb/frontends/rtl2832.h create mode 100644 drivers/media/dvb/frontends/rtl2832_priv.h -- 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 v5 1/5] rtl2832 ver. 0.5: support for RTL2832 demod
Changelog for ver. 0.5:
- fixed code style and naming errors
Changelog for ver. 0.4:
- removed statistics as their calculation was wrong
- fixed bug in Makefile
- indentation and code style improvements
Signed-off-by: Thomas Mair thomas.mai...@googlemail.com
---
drivers/media/dvb/frontends/Kconfig|7 +
drivers/media/dvb/frontends/Makefile |1 +
drivers/media/dvb/frontends/rtl2832.c | 823
drivers/media/dvb/frontends/rtl2832.h | 74 +++
drivers/media/dvb/frontends/rtl2832_priv.h | 260 +
5 files changed, 1165 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/dvb/frontends/rtl2832.c
create mode 100644 drivers/media/dvb/frontends/rtl2832.h
create mode 100644 drivers/media/dvb/frontends/rtl2832_priv.h
diff --git a/drivers/media/dvb/frontends/Kconfig
b/drivers/media/dvb/frontends/Kconfig
index f479834..f7d67d7 100644
--- a/drivers/media/dvb/frontends/Kconfig
+++ b/drivers/media/dvb/frontends/Kconfig
@@ -432,6 +432,13 @@ config DVB_RTL2830
help
Say Y when you want to support this frontend.
+config DVB_RTL2832
+ tristate Realtek RTL2832 DVB-T
+ depends on DVB_CORE I2C
+ default m if DVB_FE_CUSTOMISE
+ help
+ Say Y when you want to support this frontend.
+
comment DVB-C (cable) frontends
depends on DVB_CORE
diff --git a/drivers/media/dvb/frontends/Makefile
b/drivers/media/dvb/frontends/Makefile
index b0381dc..2279c5d 100644
--- a/drivers/media/dvb/frontends/Makefile
+++ b/drivers/media/dvb/frontends/Makefile
@@ -98,6 +98,7 @@ obj-$(CONFIG_DVB_IT913X_FE) += it913x-fe.o
obj-$(CONFIG_DVB_A8293) += a8293.o
obj-$(CONFIG_DVB_TDA10071) += tda10071.o
obj-$(CONFIG_DVB_RTL2830) += rtl2830.o
+obj-$(CONFIG_DVB_RTL2832) += rtl2832.o
obj-$(CONFIG_DVB_M88RS2000) += m88rs2000.o
obj-$(CONFIG_DVB_AF9033) += af9033.o
diff --git a/drivers/media/dvb/frontends/rtl2832.c
b/drivers/media/dvb/frontends/rtl2832.c
new file mode 100644
index 000..d0cbe27
--- /dev/null
+++ b/drivers/media/dvb/frontends/rtl2832.c
@@ -0,0 +1,823 @@
+/*
+ * Realtek RTL2832 DVB-T demodulator driver
+ *
+ * Copyright (C) 2012 Thomas Mair thomas.mai...@gmail.com
+ *
+ * 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.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include rtl2832_priv.h
+
+
+int rtl2832_debug;
+module_param_named(debug, rtl2832_debug, int, 0644);
+MODULE_PARM_DESC(debug, Turn on/off frontend debugging (default:off).);
+
+
+static const int reg_mask[32] = {
+ 0x0001,
+ 0x0003,
+ 0x0007,
+ 0x000f,
+ 0x001f,
+ 0x003f,
+ 0x007f,
+ 0x00ff,
+ 0x01ff,
+ 0x03ff,
+ 0x07ff,
+ 0x0fff,
+ 0x1fff,
+ 0x3fff,
+ 0x7fff,
+ 0x,
+ 0x0001,
+ 0x0003,
+ 0x0007,
+ 0x000f,
+ 0x001f,
+ 0x003f,
+ 0x007f,
+ 0x00ff,
+ 0x01ff,
+ 0x03ff,
+ 0x07ff,
+ 0x0fff,
+ 0x1fff,
+ 0x3fff,
+ 0x7fff,
+ 0x
+};
+
+static const struct rtl2832_reg_entry registers[] = {
+ [DVBT_SOFT_RST] = {0x1, 0x1, 2, 2},
+ [DVBT_IIC_REPEAT] = {0x1, 0x1, 3, 3},
+ [DVBT_TR_WAIT_MIN_8K] = {0x1, 0x88, 11, 2},
+ [DVBT_RSD_BER_FAIL_VAL] = {0x1, 0x8f, 15, 0},
+ [DVBT_EN_BK_TRK]= {0x1, 0xa6, 7, 7},
+ [DVBT_AD_EN_REG]= {0x0, 0x8, 7, 7},
+ [DVBT_AD_EN_REG1] = {0x0, 0x8, 6, 6},
+ [DVBT_EN_BBIN] = {0x1, 0xb1, 0, 0},
+ [DVBT_MGD_THD0] = {0x1, 0x95, 7, 0},
+ [DVBT_MGD_THD1] = {0x1, 0x96, 7, 0},
+ [DVBT_MGD_THD2] = {0x1, 0x97, 7, 0},
+ [DVBT_MGD_THD3] = {0x1, 0x98, 7, 0},
+ [DVBT_MGD_THD4] = {0x1, 0x99, 7, 0},
+ [DVBT_MGD_THD5] = {0x1, 0x9a, 7, 0},
+ [DVBT_MGD_THD6] = {0x1, 0x9b, 7, 0},
+ [DVBT_MGD_THD7] = {0x1, 0x9c, 7, 0},
+ [DVBT_EN_CACQ_NOTCH]= {0x1, 0x61, 4, 4},
+ [DVBT_AD_AV_REF]= {0x0, 0x9, 6, 0},
+ [DVBT_REG_PI] = {0x0, 0xa, 2, 0},
+ [DVBT_PIP_ON] = {0x0, 0x21, 3, 3},
+
[PATCH v5 2/5] rtl28xxu: support for the rtl2832 demod driver
This only adds support for the Terratec Cinergy T Stick Black device.
Changes from previous patches:
- fixed compiler warnings
- added fc0013 tuner handling to this patch
Signed-off-by: Thomas Mair thomas.mai...@googlemail.com
---
drivers/media/dvb/dvb-usb/Kconfig |3 +
drivers/media/dvb/dvb-usb/dvb-usb-ids.h |1 +
drivers/media/dvb/dvb-usb/rtl28xxu.c| 450 +--
3 files changed, 429 insertions(+), 25 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/Kconfig
b/drivers/media/dvb/dvb-usb/Kconfig
index be1db75..98dd0d8 100644
--- a/drivers/media/dvb/dvb-usb/Kconfig
+++ b/drivers/media/dvb/dvb-usb/Kconfig
@@ -417,9 +417,12 @@ config DVB_USB_RTL28XXU
tristate Realtek RTL28xxU DVB USB support
depends on DVB_USB EXPERIMENTAL
select DVB_RTL2830
+ select DVB_RTL2832
select MEDIA_TUNER_QT1010 if !MEDIA_TUNER_CUSTOMISE
select MEDIA_TUNER_MT2060 if !MEDIA_TUNER_CUSTOMISE
select MEDIA_TUNER_MXL5005S if !MEDIA_TUNER_CUSTOMISE
+ select MEDIA_TUNER_FC0012 if !MEDIA_TUNER_CUSTOMISE
+ select MEDIA_TUNER_FC0013 if !MEDIA_TUNER_CUSTOMISE
help
Say Y here to support the Realtek RTL28xxU DVB USB receiver.
diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
b/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
index 7a6160b..cd9254c 100644
--- a/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
+++ b/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
@@ -160,6 +160,7 @@
#define USB_PID_TERRATEC_CINERGY_T_STICK 0x0093
#define USB_PID_TERRATEC_CINERGY_T_STICK_RC0x0097
#define USB_PID_TERRATEC_CINERGY_T_STICK_DUAL_RC 0x0099
+#define USB_PID_TERRATEC_CINERGY_T_STICK_BLACK_REV10x00a9
#define USB_PID_TWINHAN_VP7041_COLD0x3201
#define USB_PID_TWINHAN_VP7041_WARM0x3202
#define USB_PID_TWINHAN_VP7020_COLD0x3203
diff --git a/drivers/media/dvb/dvb-usb/rtl28xxu.c
b/drivers/media/dvb/dvb-usb/rtl28xxu.c
index 4e69e9d..5285f3d 100644
--- a/drivers/media/dvb/dvb-usb/rtl28xxu.c
+++ b/drivers/media/dvb/dvb-usb/rtl28xxu.c
@@ -3,6 +3,7 @@
*
* Copyright (C) 2009 Antti Palosaari cr...@iki.fi
* Copyright (C) 2011 Antti Palosaari cr...@iki.fi
+ * Copyright (C) 2012 Thomas Mair thomas.mai...@googlemail.com
*
*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
@@ -22,10 +23,13 @@
#include rtl28xxu.h
#include rtl2830.h
+#include rtl2832.h
#include qt1010.h
#include mt2060.h
#include mxl5005s.h
+#include fc0012.h
+#include fc0013.h
/* debug */
static int dvb_usb_rtl28xxu_debug;
@@ -378,34 +382,159 @@ err:
return ret;
}
+static struct rtl2832_config rtl28xxu_rtl2832_fc0012_config = {
+ .i2c_addr = 0x10, /* 0x20 */
+ .xtal = 2880,
+ .if_dvbt = 0,
+ .tuner = TUNER_RTL2832_FC0012
+};
+
+static struct rtl2832_config rtl28xxu_rtl2832_fc0013_config = {
+ .i2c_addr = 0x10, /* 0x20 */
+ .xtal = 2880,
+ .if_dvbt = 0,
+ .tuner = TUNER_RTL2832_FC0013
+};
+
+static int rtl2832u_fc0012_tuner_callback(struct dvb_usb_device *d,
+ int cmd, int arg)
+{
+ int ret;
+ u8 val;
+
+ deb_info(%s cmd=%d arg=%d\n, __func__, cmd, arg);
+ switch (cmd) {
+ case FC_FE_CALLBACK_VHF_ENABLE:
+ /* set output values */
+ ret = rtl2831_rd_reg(d, SYS_GPIO_OUT_VAL, val);
+ if (ret)
+ goto err;
+
+ if (arg)
+ val = 0xbf; /* set GPIO6 low */
+ else
+ val |= 0x40; /* set GPIO6 high */
+
+
+ ret = rtl2831_wr_reg(d, SYS_GPIO_OUT_VAL, val);
+ if (ret)
+ goto err;
+ break;
+ default:
+ ret = -EINVAL;
+ goto err;
+ }
+ return 0;
+
+err:
+ err(%s: failed=%d\n, __func__, ret);
+
+ return ret;
+}
+
+
+static int rtl2832u_fc0013_tuner_callback(struct dvb_usb_device *d,
+ int cmd, int arg)
+{
+ /* TODO implement*/
+ return 0;
+}
+
+static int rtl2832u_tuner_callback(struct dvb_usb_device *d, int cmd, int arg)
+{
+ struct rtl28xxu_priv *priv = d-priv;
+
+ switch (priv-tuner) {
+ case TUNER_RTL2832_FC0012:
+ return rtl2832u_fc0012_tuner_callback(d, cmd, arg);
+
+ case TUNER_RTL2832_FC0013:
+ return rtl2832u_fc0013_tuner_callback(d, cmd, arg);
+ default:
+ break;
+ }
+
+ return -ENODEV;
+}
+
+static int rtl2832u_frontend_callback(void *adapter_priv, int component,
+ int cmd, int arg)
+{
+ struct i2c_adapter *adap = adapter_priv;
+ struct dvb_usb_device *d = i2c_get_adapdata(adap);
+
+ switch (component) {
+ case DVB_FRONTEND_COMPONENT_TUNER:
+
[PATCH v5 3/5] rtl28xxu: renamed rtl2831_rd/rtl2831_wr to rtl28xx_rd/rtl28xx_wr
Signed-off-by: Thomas Mair thomas.mai...@googlemail.com
---
drivers/media/dvb/dvb-usb/rtl28xxu.c | 102 +-
1 files changed, 51 insertions(+), 51 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/rtl28xxu.c
b/drivers/media/dvb/dvb-usb/rtl28xxu.c
index 5285f3d..5586715 100644
--- a/drivers/media/dvb/dvb-usb/rtl28xxu.c
+++ b/drivers/media/dvb/dvb-usb/rtl28xxu.c
@@ -84,7 +84,7 @@ err:
return ret;
}
-static int rtl2831_wr_regs(struct dvb_usb_device *d, u16 reg, u8 *val, int len)
+static int rtl28xx_wr_regs(struct dvb_usb_device *d, u16 reg, u8 *val, int len)
{
struct rtl28xxu_req req;
@@ -120,12 +120,12 @@ static int rtl2831_rd_regs(struct dvb_usb_device *d, u16
reg, u8 *val, int len)
return rtl28xxu_ctrl_msg(d, req);
}
-static int rtl2831_wr_reg(struct dvb_usb_device *d, u16 reg, u8 val)
+static int rtl28xx_wr_reg(struct dvb_usb_device *d, u16 reg, u8 val)
{
- return rtl2831_wr_regs(d, reg, val, 1);
+ return rtl28xx_wr_regs(d, reg, val, 1);
}
-static int rtl2831_rd_reg(struct dvb_usb_device *d, u16 reg, u8 *val)
+static int rtl28xx_rd_reg(struct dvb_usb_device *d, u16 reg, u8 *val)
{
return rtl2831_rd_regs(d, reg, val, 1);
}
@@ -312,12 +312,12 @@ static int rtl2831u_frontend_attach(struct
dvb_usb_adapter *adap)
*/
/* GPIO direction */
- ret = rtl2831_wr_reg(adap-dev, SYS_GPIO_DIR, 0x0a);
+ ret = rtl28xx_wr_reg(adap-dev, SYS_GPIO_DIR, 0x0a);
if (ret)
goto err;
/* enable as output GPIO0, GPIO2, GPIO4 */
- ret = rtl2831_wr_reg(adap-dev, SYS_GPIO_OUT_EN, 0x15);
+ ret = rtl28xx_wr_reg(adap-dev, SYS_GPIO_OUT_EN, 0x15);
if (ret)
goto err;
@@ -406,7 +406,7 @@ static int rtl2832u_fc0012_tuner_callback(struct
dvb_usb_device *d,
switch (cmd) {
case FC_FE_CALLBACK_VHF_ENABLE:
/* set output values */
- ret = rtl2831_rd_reg(d, SYS_GPIO_OUT_VAL, val);
+ ret = rtl28xx_rd_reg(d, SYS_GPIO_OUT_VAL, val);
if (ret)
goto err;
@@ -416,7 +416,7 @@ static int rtl2832u_fc0012_tuner_callback(struct
dvb_usb_device *d,
val |= 0x40; /* set GPIO6 high */
- ret = rtl2831_wr_reg(d, SYS_GPIO_OUT_VAL, val);
+ ret = rtl28xx_wr_reg(d, SYS_GPIO_OUT_VAL, val);
if (ret)
goto err;
break;
@@ -511,25 +511,25 @@ static int rtl2832u_frontend_attach(struct
dvb_usb_adapter *adap)
deb_info(%s:\n, __func__);
- ret = rtl2831_rd_reg(adap-dev, SYS_GPIO_DIR, val);
+ ret = rtl28xx_rd_reg(adap-dev, SYS_GPIO_DIR, val);
if (ret)
goto err;
val = 0xbf;
- ret = rtl2831_wr_reg(adap-dev, SYS_GPIO_DIR, val);
+ ret = rtl28xx_wr_reg(adap-dev, SYS_GPIO_DIR, val);
if (ret)
goto err;
/* enable as output GPIO3 and GPIO6*/
- ret = rtl2831_rd_reg(adap-dev, SYS_GPIO_OUT_EN, val);
+ ret = rtl28xx_rd_reg(adap-dev, SYS_GPIO_OUT_EN, val);
if (ret)
goto err;
val |= 0x48;
- ret = rtl2831_wr_reg(adap-dev, SYS_GPIO_OUT_EN, val);
+ ret = rtl28xx_wr_reg(adap-dev, SYS_GPIO_OUT_EN, val);
if (ret)
goto err;
@@ -790,7 +790,7 @@ static int rtl2831u_streaming_ctrl(struct dvb_usb_adapter
*adap , int onoff)
deb_info(%s: onoff=%d\n, __func__, onoff);
- ret = rtl2831_rd_reg(adap-dev, SYS_GPIO_OUT_VAL, gpio);
+ ret = rtl28xx_rd_reg(adap-dev, SYS_GPIO_OUT_VAL, gpio);
if (ret)
goto err;
@@ -804,11 +804,11 @@ static int rtl2831u_streaming_ctrl(struct dvb_usb_adapter
*adap , int onoff)
gpio = (~0x04); /* LED off */
}
- ret = rtl2831_wr_reg(adap-dev, SYS_GPIO_OUT_VAL, gpio);
+ ret = rtl28xx_wr_reg(adap-dev, SYS_GPIO_OUT_VAL, gpio);
if (ret)
goto err;
- ret = rtl2831_wr_regs(adap-dev, USB_EPA_CTL, buf, 2);
+ ret = rtl28xx_wr_regs(adap-dev, USB_EPA_CTL, buf, 2);
if (ret)
goto err;
@@ -834,7 +834,7 @@ static int rtl2832u_streaming_ctrl(struct dvb_usb_adapter
*adap , int onoff)
buf[1] = 0x02; /* reset EPA */
}
- ret = rtl2831_wr_regs(adap-dev, USB_EPA_CTL, buf, 2);
+ ret = rtl28xx_wr_regs(adap-dev, USB_EPA_CTL, buf, 2);
if (ret)
goto err;
@@ -852,12 +852,12 @@ static int rtl2831u_power_ctrl(struct dvb_usb_device *d,
int onoff)
deb_info(%s: onoff=%d\n, __func__, onoff);
/* demod adc */
- ret = rtl2831_rd_reg(d, SYS_SYS0, sys0);
+ ret = rtl28xx_rd_reg(d, SYS_SYS0, sys0);
if (ret)
goto err;
/* tuner power, read GPIOs */
- ret = rtl2831_rd_reg(d, SYS_GPIO_OUT_VAL, gpio);
+ ret = rtl28xx_rd_reg(d, SYS_GPIO_OUT_VAL, gpio);
[PATCH v5 4/5] rtl28xxu: support Delock USB 2.0 DVB-T
Signed-off-by: Thomas Mair thomas.mai...@googlemail.com
---
drivers/media/dvb/dvb-usb/dvb-usb-ids.h |1 +
drivers/media/dvb/dvb-usb/rtl28xxu.c| 11 ++-
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
b/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
index cd9254c..360f6b7 100644
--- a/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
+++ b/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
@@ -100,6 +100,7 @@
#define USB_PID_CONCEPTRONIC_CTVDIGRCU 0xe397
#define USB_PID_CONEXANT_D680_DMB 0x86d6
#define USB_PID_CREATIX_CTX19210x1921
+#define USB_PID_DELOCK_USB2_DVBT 0xb803
#define USB_PID_DIBCOM_HOOK_DEFAULT0x0064
#define USB_PID_DIBCOM_HOOK_DEFAULT_REENUM 0x0065
#define USB_PID_DIBCOM_MOD3000_COLD0x0bb8
diff --git a/drivers/media/dvb/dvb-usb/rtl28xxu.c
b/drivers/media/dvb/dvb-usb/rtl28xxu.c
index 5586715..b2c8f67 100644
--- a/drivers/media/dvb/dvb-usb/rtl28xxu.c
+++ b/drivers/media/dvb/dvb-usb/rtl28xxu.c
@@ -1152,6 +1152,7 @@ enum rtl28xxu_usb_table_entry {
RTL2831U_14AA_0160,
RTL2831U_14AA_0161,
RTL2832U_0CCD_00A9,
+ RTL2832U_1F4D_B803,
};
static struct usb_device_id rtl28xxu_table[] = {
@@ -1166,6 +1167,8 @@ static struct usb_device_id rtl28xxu_table[] = {
/* RTL2832U */
[RTL2832U_0CCD_00A9] = {
USB_DEVICE(USB_VID_TERRATEC,
USB_PID_TERRATEC_CINERGY_T_STICK_BLACK_REV1)},
+ [RTL2832U_1F4D_B803] = {
+ USB_DEVICE(USB_VID_GTEK, USB_PID_DELOCK_USB2_DVBT)},
{} /* terminating entry */
};
@@ -1279,7 +1282,7 @@ static struct dvb_usb_device_properties
rtl28xxu_properties[] = {
.i2c_algo = rtl28xxu_i2c_algo,
- .num_device_descs = 1,
+ .num_device_descs = 2,
.devices = {
{
.name = Terratec Cinergy T Stick Black,
@@ -1287,6 +1290,12 @@ static struct dvb_usb_device_properties
rtl28xxu_properties[] = {
rtl28xxu_table[RTL2832U_0CCD_00A9],
},
},
+ {
+ .name = G-Tek Electronics Group Lifeview
LV5TDLX DVB-T,
+ .warm_ids = {
+ rtl28xxu_table[RTL2832U_1F4D_B803],
+ },
+ },
}
},
--
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 v5 5/5] rtl28xxu: support Terratec Noxon DAB/DAB+ stick
Signed-off-by: Hans-Frieder Vogt hfv...@gmx.net
Signed-off-by: Thomas Mair thomas.mai...@googlemail.com
---
drivers/media/dvb/dvb-usb/dvb-usb-ids.h |1 +
drivers/media/dvb/dvb-usb/rtl28xxu.c| 11 ++-
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
b/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
index 360f6b7..26c4481 100644
--- a/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
+++ b/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
@@ -247,6 +247,7 @@
#define USB_PID_TERRATEC_H7_2 0x10a3
#define USB_PID_TERRATEC_T30x10a0
#define USB_PID_TERRATEC_T50x10a1
+#define USB_PID_NOXON_DAB_STICK0x00b3
#define USB_PID_PINNACLE_EXPRESSCARD_320CX 0x022e
#define USB_PID_PINNACLE_PCTV2000E 0x022c
#define USB_PID_PINNACLE_PCTV_DVB_T_FLASH 0x0228
diff --git a/drivers/media/dvb/dvb-usb/rtl28xxu.c
b/drivers/media/dvb/dvb-usb/rtl28xxu.c
index b2c8f67..0cac6fb 100644
--- a/drivers/media/dvb/dvb-usb/rtl28xxu.c
+++ b/drivers/media/dvb/dvb-usb/rtl28xxu.c
@@ -1153,6 +1153,7 @@ enum rtl28xxu_usb_table_entry {
RTL2831U_14AA_0161,
RTL2832U_0CCD_00A9,
RTL2832U_1F4D_B803,
+ RTL2832U_0CCD_00B3,
};
static struct usb_device_id rtl28xxu_table[] = {
@@ -1169,6 +1170,8 @@ static struct usb_device_id rtl28xxu_table[] = {
USB_DEVICE(USB_VID_TERRATEC,
USB_PID_TERRATEC_CINERGY_T_STICK_BLACK_REV1)},
[RTL2832U_1F4D_B803] = {
USB_DEVICE(USB_VID_GTEK, USB_PID_DELOCK_USB2_DVBT)},
+ [RTL2832U_0CCD_00B3] = {
+ USB_DEVICE(USB_VID_TERRATEC, USB_PID_NOXON_DAB_STICK)},
{} /* terminating entry */
};
@@ -1282,7 +1285,7 @@ static struct dvb_usb_device_properties
rtl28xxu_properties[] = {
.i2c_algo = rtl28xxu_i2c_algo,
- .num_device_descs = 2,
+ .num_device_descs = 3,
.devices = {
{
.name = Terratec Cinergy T Stick Black,
@@ -1296,6 +1299,12 @@ static struct dvb_usb_device_properties
rtl28xxu_properties[] = {
rtl28xxu_table[RTL2832U_1F4D_B803],
},
},
+ {
+ .name = NOXON DAB/DAB+ USB dongle,
+ .warm_ids = {
+ rtl28xxu_table[RTL2832U_0CCD_00B3],
+ },
+ },
}
},
--
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
[GIT PULL FOR 3.5] RTL2831U changes
Moikka Mauro, PULL these for 3.5. The following changes since commit a73d06b082bdf3eccfa910de75242798ff272a4e: em28xx: disable LNA - PCTV QuatroStick nano (520e) (2012-05-18 21:23:05 +0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git rtl2831u Antti Palosaari (6): rtl2830: implement .read_snr() rtl2830: implement .read_ber() rtl2830: implement .read_signal_strength() rtl2830: implement .get_frontend() rtl2830: prevent hw access when sleeping rtl28xxu: add small sleep for rtl2830 demod attach drivers/media/dvb/dvb-usb/rtl28xxu.c |3 + drivers/media/dvb/frontends/rtl2830.c | 201 +++- drivers/media/dvb/frontends/rtl2830_priv.h |1 + 3 files changed, 202 insertions(+), 3 deletions(-) -- 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 1/5] rtl2832 ver 0.3: suport for RTL2832 demodulator revised version
On 14.05.2012 04:37, Antti Palosaari wrote:
+else {
+/* if_agc is read as a 10bit binary */
+ret = rtl2832_rd_demod_reg(priv, DVBT_IF_AGC_VAL,if_agc_raw);
+if (ret)
+goto err;
+
+if (if_agc_raw (1 9))
+if_agc = if_agc_raw;
+else
+if_agc = -(~(if_agc_raw-1) 0x1ff);
+
+*strength = 55 - if_agc / 182;
+*strength |= *strength 8;
That calculation shows doubtful. Why not to scale directly to the
counter. Now you divide it by 182 and after that multiply 256 ( 8
means same as multiply by 256). It is stupid calculation.
I was playing with RTL2830 statistics and thus it is quite similar I
ended up looking that again. It is not so wrong as I commented. The idea
of whole calculation is to underflow unsigned 8 bit value to the
*strength. But it goes wrong here because you don't cast it as unsigned
char (this should be *strength = (u8) (55 - if_agc / 182);.
I implemented that rather similarly for the RTL2830. But it is very poor
resolution for some reason... :-(
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] rtl2830: implement .read_snr()
On 16.05.2012 01:32, Antti Palosaari wrote: Reports value as a 0.1 dB. Drop this patch. I just PULL requested new one. 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: [GIT PULL FOR v3.5] Fix gspca compile error if CONFIG_PM is not set
Hi Hans,
On 05/18/2012 01:43 PM, Hans Verkuil wrote:
The field 'frozen' is only there if CONFIG_PM is set, so don't use it
directly, always check for CONFIG_PM first.
If it is safe to assume that for !CONFIG_PM the field 'frozen' is always
zero, wouldn't it be better to create a macro in a header file, something
like:
#ifdef CONFIG_PM
#define gspca_pm_frozen(__dev) ((__dev)-frozen)
#else
#define gspca_pm_frozen(__dev) (0)
#endif
and use it instead ?
diff --git a/drivers/media/video/gspca/sq905.c
b/drivers/media/video/gspca/sq905.c
index a144ce7..04f5465 100644 (file)
--- a/drivers/media/video/gspca/sq905.c
+++ b/drivers/media/video/gspca/sq905.c
@@ -232,7 +232,11 @@ static void sq905_dostream(struct work_struct *work)
frame_sz = gspca_dev-cam.cam_mode[gspca_dev-curr_mode].sizeimage
+ FRAME_HEADER_LEN;
- while (!gspca_dev-frozen gspca_dev-dev gspca_dev-streaming) {
+ while (!gspca_pm_frozen(gspca_dev) gspca_dev-dev
gspca_dev-streaming) {
I really hate #ifdefs ... :-)
--
Regards,
Sylwester
Regards,
Hans
The following changes since commit 61282daf505f3c8def09332ca337ac257b792029:
[media] V4L2: mt9t112: fixup JPEG initialization workaround (2012-05-15
16:15:35 -0300)
are available in the git repository at:
git://linuxtv.org/hverkuil/media_tree.git frozenfix
for you to fetch changes up to 4ba342204948e9df49dc1f639ffdbfe49579e626:
gspca: the field 'frozen' is under CONFIG_PM (2012-05-18 13:40:42 +0200)
Hans Verkuil (1):
gspca: the field 'frozen' is under CONFIG_PM
drivers/media/video/gspca/finepix.c | 20 +++-
drivers/media/video/gspca/jl2005bcd.c |6 +-
drivers/media/video/gspca/sq905.c |6 +-
drivers/media/video/gspca/sq905c.c|6 +-
drivers/media/video/gspca/vicam.c |6 +-
drivers/media/video/gspca/zc3xx.c |7 +--
6 files changed, 40 insertions(+), 11 deletions(-)
--
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 1/5] rtl2832 ver. 0.5: support for RTL2832 demod
On 18.05.2012 21:47, Thomas Mair wrote: Changelog for ver. 0.5: - fixed code style and naming errors Changelog for ver. 0.4: - removed statistics as their calculation was wrong - fixed bug in Makefile - indentation and code style improvements Signed-off-by: Thomas Mairthomas.mai...@googlemail.com Reviewed-by: Antti Palosaari cr...@iki.fi Seems to be correct! 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: PCTV 290e with DVB-C on Fedora 16?
On 18 May 2012 15:01, Antti Palosaari cr...@iki.fi wrote:
On 18.05.2012 11:38, Niklas Brunlid wrote:
That whole issues is related of MFE (multi-frontend) = SFE
(single-frontend) change.
Yes, that I have understood. But from the threads on the MythTV lists
below, it seems at least one user has one or more 290e sticks running
fine in DVB-T (or T2) mode. Although that was on Ubuntu IIRC.
And there is still known issues like only one frontend parameters, as we
still have three different delivery systems Due to that currently
applications should not trust parameters frontend is advertising. Only valid
parameter is supported delivery systems.
Needless to say it took about one week for me to fix all cxd2820r bugs after
that...
As seen in mythtv-users
(http://www.gossamer-threads.com/lists/mythtv/users/514948?search_string=290e;#514948)
and mythtv-dev
(http://www.gossamer-threads.com/lists/mythtv/dev/514946?search_string=290e;#514946),
I'm trying to figure out why my PCTV 290e (which I use for DVB-C only)
stopped working when I upgraded to Fedora 16. It was most likely with
the switch to the new API (5.x)?
Some highlights from the thread(s):
begin cut
$ w_scan -A2 -fc -cSE -G -X |tee .czap/channels.conf
w_scan version 20120112 (compiled for DVB API 5.3)
w_scan version 20120112 (compiled for DVB API 5.3)
using settings for SWEDEN
DVB cable
DVB-C
scan type CABLE, channellist 7
output format czap/tzap/szap/xine
WARNING: could not guess your codepage. Falling back to 'UTF-8'
output charset 'UTF-8', use -Ccharset to override
Info: using DVB adapter auto detection.
/dev/dvb/adapter0/frontend0 - CABLE Sony CXD2820R: very good :-))
Using CABLE frontend (adapter /dev/dvb/adapter0/frontend0)
-_-_-_-_ Getting frontend capabilities-_-_-_-_
Using DVB API 5.5
frontend 'Sony CXD2820R' supports
DVB-C2
INVERSION_AUTO
QAM_AUTO
FEC_AUTO
FREQ (45.00MHz ... 864.00MHz)
This dvb driver is *buggy*: the symbol rate limits are undefined - please
report to linuxtv.org
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
73000: sr6900 (time: 00:00) sr6875 (time: 00:05)
w_scan works? At least for me.
It was some time since I actually ran it. I'll have to try again
tomorrow as the backend is currently recording, and MythTV seems to
tie up the device even though it is not connected with any input in
mythtvsetup...
After trying dvb-fe-tool to force the card to DVB-C:
begin cut
Didn't help, unfortunately - mythtvsetup still complains:
2012-05-13 17:25:32.385665 E FE_GET_INFO ioctl failed
(/dev/dvb/adapter0/frontend0)
eno: No such device (19)
I looked frontend code and I do not see where that error is coming.
Maybe there is no such file at all?
The file is there, as seen in the ls output I posted. And dvb-fe-tool
complains when mythbackend is running:
# dvb-fe-tool
Device or resource busy while opening /dev/dvb/adapter0/frontend0
# lsusb
...
Bus 006 Device 002: ID 2013:024f Unknown (Pinnacle?)
...
# dmesg:
...
[1.996623] usb 6-1: Product: PCTV 290e
[1.996625] usb 6-1: Manufacturer: PCTV Systems
[1.996627] usb 6-1: SerialNumber: 0006LG6C
...
[3.130872] Linux video capture interface: v2.00
...
[3.136301] em28xx: New device PCTV Systems PCTV 290e @ 480 Mbps
(2013:024f, interface 0, class 0)
[3.136304] em28xx: DVB interface 0 found
[3.137792] em28xx #0: chip ID is em28174
...
[3.436262] em28xx #0: Identified as PCTV nanoStick T2 290e (card=78)
...
[3.460535] Registered IR keymap rc-pinnacle-pctv-hd
[3.460579] input: em28xx IR (em28xx #0) as
/devices/pci:00/:00:1c.4/:03:00.0/usb6/6-1/rc/rc0/input13
[3.460613] rc0: em28xx IR (em28xx #0) as
/devices/pci:00/:00:1c.4/:03:00.0/usb6/6-1/rc/rc0
[3.461994] em28xx #0: v4l2 driver version 0.1.3
...
[3.477657] em28xx #0: V4L2 video device registered as video0
[3.478407] usbcore: registered new interface driver em28xx
[3.480313] tea5767 1-0060: type set to Philips TEA5767HN FM Radio
...
[3.772161] DVB: registering new adapter (em28xx #0)
[3.772165] DVB: registering adapter 0 frontend 0 (Sony CXD2820R)...
[3.772623] em28xx #0: Successfully loaded em28xx-dvb
[3.772627] Em28xx: Initialized (Em28xx dvb Extension) extension
[3.987489] dvb-usb: will pass the complete MPEG2 transport stream
to the software demuxer.
...
The system also has a Hauppauhe PVR350 and a Hauppage Nova-T 500, in
case that's relevant. The Nova works fine, although the reception is
poor (70%) which is why I got the 290e for DVB-C. :)
BTW, I see firmware being loaded for the Hauppauge devices. Is the
same needed for the PCTV 290e?
2012-05-13 17:25:33.865334 E FE_GET_INFO ioctl failed
(/dev/dvb/adapter_290e/frontend0) eno: No such device (19)
/adapter_290e/ something unusual.
It's created by my udev rules:
# Create a symlink to the DVB-C tuners of the PCTV 290e
SUBSYSTEM==dvb, ATTRS{manufacturer}==PCTV Systems,
Re: [PATCH v5 3/5] rtl28xxu: renamed rtl2831_rd/rtl2831_wr to rtl28xx_rd/rtl28xx_wr
On 18.05.2012 21:47, Thomas Mair wrote: Signed-off-by: Thomas Mairthomas.mai...@googlemail.com Acked-by: Antti Palosaari cr...@iki.fi Reviewed-by: Antti Palosaari cr...@iki.fi 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 v5 4/5] rtl28xxu: support Delock USB 2.0 DVB-T
On 18.05.2012 21:47, Thomas Mair wrote: Signed-off-by: Thomas Mairthomas.mai...@googlemail.com Acked-by: Antti Palosaari cr...@iki.fi Reviewed-by: Antti Palosaari cr...@iki.fi 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 v5 2/5] rtl28xxu: support for the rtl2832 demod driver
On 18.05.2012 21:47, Thomas Mair wrote: This only adds support for the Terratec Cinergy T Stick Black device. Changes from previous patches: - fixed compiler warnings - added fc0013 tuner handling to this patch Signed-off-by: Thomas Mairthomas.mai...@googlemail.com Acked-by: Antti Palosaari cr...@iki.fi Reviewed-by: Antti Palosaari cr...@iki.fi 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 v5 5/5] rtl28xxu: support Terratec Noxon DAB/DAB+ stick
On 18.05.2012 21:47, Thomas Mair wrote: Signed-off-by: Hans-Frieder Vogthfv...@gmx.net Signed-off-by: Thomas Mairthomas.mai...@googlemail.com Acked-by: Antti Palosaari cr...@iki.fi Reviewed-by: Antti Palosaari cr...@iki.fi 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: PCTV 290e with DVB-C on Fedora 16?
On 18.05.2012 23:27, Niklas Brunlid wrote: On 18 May 2012 15:01, Antti Palosaaricr...@iki.fi wrote: On 18.05.2012 11:38, Niklas Brunlid wrote: That whole issues is related of MFE (multi-frontend) = SFE (single-frontend) change. Yes, that I have understood. But from the threads on the MythTV lists below, it seems at least one user has one or more 290e sticks running fine in DVB-T (or T2) mode. Although that was on Ubuntu IIRC. w_scan works? At least for me. It was some time since I actually ran it. I'll have to try again tomorrow as the backend is currently recording, and MythTV seems to tie up the device even though it is not connected with any input in mythtvsetup... 2012-05-13 17:25:32.385665 E FE_GET_INFO ioctl failed (/dev/dvb/adapter0/frontend0) eno: No such device (19) I looked frontend code and I do not see where that error is coming. Maybe there is no such file at all? The file is there, as seen in the ls output I posted. And dvb-fe-tool complains when mythbackend is running: The system also has a Hauppauhe PVR350 and a Hauppage Nova-T 500, in case that's relevant. The Nova works fine, although the reception is poor (70%) which is why I got the 290e for DVB-C. :) BTW, I see firmware being loaded for the Hauppauge devices. Is the same needed for the PCTV 290e? No firmware needed for that device. All used chips are firmware free. DVB-C is not officially supported by that device but it seems to work rather well. Biggest problem is hard coded LNA but I think I am going to resolve LNA and GPIO issues later this summer when enhancing DVB-CORE frontend issues. My plan is to add internal API, GPIO callbacks for the demod and tuner in order to allow use of LNA etc. And of course some param to API which sets LNA AUTO/ON/OFF, maybe numeric value for gain also? 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 v5 0/5] support for rtl2832
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. 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. 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. 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
[PATCH] libdvbv5: constify and hide dvb_sat_lnb
Signed-off-by: Gregor Jasny gja...@googlemail.com
---
lib/include/dvb-fe.h |2 +-
lib/include/libsat.h |2 +-
lib/libdvbv5/libsat.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/include/dvb-fe.h b/lib/include/dvb-fe.h
index 872a558..062edd8 100644
--- a/lib/include/dvb-fe.h
+++ b/lib/include/dvb-fe.h
@@ -76,7 +76,7 @@ struct dvb_v5_fe_parms {
struct dvb_v5_stats stats;
/* Satellite specific stuff, specified by the library client */
- struct dvb_sat_lnb *lnb;
+ const struct dvb_sat_lnb*lnb;
int sat_number;
unsignedfreq_bpf;
diff --git a/lib/include/libsat.h b/lib/include/libsat.h
index 2e74a11..57e5511 100644
--- a/lib/include/libsat.h
+++ b/lib/include/libsat.h
@@ -47,7 +47,7 @@ extern C {
int dvb_sat_search_lnb(const char *name);
int print_lnb(int i);
void print_all_lnb(void);
-struct dvb_sat_lnb *dvb_sat_get_lnb(int i);
+const struct dvb_sat_lnb *dvb_sat_get_lnb(int i);
int dvb_sat_set_parms(struct dvb_v5_fe_parms *parms);
int dvb_sat_get_parms(struct dvb_v5_fe_parms *parms);
diff --git a/lib/libdvbv5/libsat.c b/lib/libdvbv5/libsat.c
index 126dc4e..5f8cbdd 100644
--- a/lib/libdvbv5/libsat.c
+++ b/lib/libdvbv5/libsat.c
@@ -25,7 +25,7 @@
#include dvb-fe.h
#include dvb-v5-std.h
-struct dvb_sat_lnb lnb[] = {
+static const struct dvb_sat_lnb lnb[] = {
{
.name = Europe,
.alias = UNIVERSAL,
--
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
[Fixed PATCH] libdvbv5: constify and hide dvb_sat_lnb
Signed-off-by: Gregor Jasny gja...@googlemail.com
---
lib/include/dvb-fe.h |2 +-
lib/include/libsat.h |2 +-
lib/libdvbv5/libsat.c |4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/include/dvb-fe.h b/lib/include/dvb-fe.h
index 872a558..062edd8 100644
--- a/lib/include/dvb-fe.h
+++ b/lib/include/dvb-fe.h
@@ -76,7 +76,7 @@ struct dvb_v5_fe_parms {
struct dvb_v5_stats stats;
/* Satellite specific stuff, specified by the library client */
- struct dvb_sat_lnb *lnb;
+ const struct dvb_sat_lnb*lnb;
int sat_number;
unsignedfreq_bpf;
diff --git a/lib/include/libsat.h b/lib/include/libsat.h
index 2e74a11..57e5511 100644
--- a/lib/include/libsat.h
+++ b/lib/include/libsat.h
@@ -47,7 +47,7 @@ extern C {
int dvb_sat_search_lnb(const char *name);
int print_lnb(int i);
void print_all_lnb(void);
-struct dvb_sat_lnb *dvb_sat_get_lnb(int i);
+const struct dvb_sat_lnb *dvb_sat_get_lnb(int i);
int dvb_sat_set_parms(struct dvb_v5_fe_parms *parms);
int dvb_sat_get_parms(struct dvb_v5_fe_parms *parms);
diff --git a/lib/libdvbv5/libsat.c b/lib/libdvbv5/libsat.c
index 126dc4e..34268c2 100644
--- a/lib/libdvbv5/libsat.c
+++ b/lib/libdvbv5/libsat.c
@@ -25,7 +25,7 @@
#include dvb-fe.h
#include dvb-v5-std.h
-struct dvb_sat_lnb lnb[] = {
+static const struct dvb_sat_lnb lnb[] = {
{
.name = Europe,
.alias = UNIVERSAL,
@@ -347,7 +347,7 @@ static int dvbsat_diseqc_set_input(struct dvb_v5_fe_parms
*parms, uint16_t t)
int dvb_sat_set_parms(struct dvb_v5_fe_parms *parms)
{
- struct dvb_sat_lnb *lnb = parms-lnb;
+ const struct dvb_sat_lnb *lnb = parms-lnb;
enum dvb_sat_polarization pol;
dvb_fe_retrieve_parm(parms, DTV_POLARIZATION, pol);
uint32_t freq;
--
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: [PATCH v5 0/5] support for rtl2832
On 05/18/2012 10:47 PM, 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. 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. I second that. 'rtl28xxu-v2-rtl2832-fc0012.patch' is referencetemplate. 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. regards Antti regards, poma -- 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 05/18/2012 08:47 PM, 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. 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? Regards Thomas Thomas Mair (5): rtl2832 ver. 0.5: support for RTL2832 demod rtl28xxu: support for the rtl2832 demod driver rtl28xxu: renamed rtl2831_rd/rtl2831_wr to rtl28xx_rd/rtl28xx_wr rtl28xxu: support Delock USB 2.0 DVB-T rtl28xxu: support Terratec Noxon DAB/DAB+ stick drivers/media/dvb/dvb-usb/Kconfig |3 + drivers/media/dvb/dvb-usb/dvb-usb-ids.h|3 + drivers/media/dvb/dvb-usb/rtl28xxu.c | 516 -- drivers/media/dvb/frontends/Kconfig|7 + drivers/media/dvb/frontends/Makefile |1 + drivers/media/dvb/frontends/rtl2832.c | 823 drivers/media/dvb/frontends/rtl2832.h | 74 +++ drivers/media/dvb/frontends/rtl2832_priv.h | 260 + 8 files changed, 1638 insertions(+), 49 deletions(-) create mode 100644 drivers/media/dvb/frontends/rtl2832.c create mode 100644 drivers/media/dvb/frontends/rtl2832.h create mode 100644 drivers/media/dvb/frontends/rtl2832_priv.h Compliment! regards, poma -- 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
