Re: [GIT PULL FOR v3.9] videodev2.h fix and em28xx regression fixes
On Sun January 27 2013 10:43:00 Hans Verkuil wrote: Hi Mauro, The first patch moves the DV control IDs from videodev2.h to v4l2-controls.h. I noticed that they weren't moved when the controls were split off from videodev2.h, probably because the patch adding the DV controls and the move to v4l2-controls.h crossed one another. The second and third patch convert tvaudio and mt9v011 to the control framework. These patches were part of my original conversion of em28xx to the control framework, but when Devin based his em28xx work on my tree he forgot to pull them in. Because of that any controls created by the mt9v011 and tvaudio drivers are inaccessible from em28xx. By converting those drivers to the control framework they are seen again. Frank tested the mt9v011 conversion. I have tested the tvaudio conversion somewhat with a bttv card that had a tda9850, but if you have additional tvaudio cards (and especially an em28xx that uses the tvaudio module), then it would be good to do some additional tests. Other than the bttv card I have no other hardware to test tvaudio with. I've removed this pull request and I'll post a new one in a minute. I found another tvaudio fix that had to be included as well. Regards, Hans Regards, Hans The following changes since commit 94a93e5f85040114d6a77c085457b3943b6da889: [media] dvb_frontend: print a msg if a property doesn't exist (2013-01-23 19:10:57 -0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git fixes for you to fetch changes up to 7aa966b3c4135b1745a3c5ac60bdd8f79fead355: mt9v011: convert to the control framework. (2013-01-27 10:22:27 +0100) Hans Verkuil (3): Move DV-class control IDs from videodev2.h to v4l2-controls.h tvaudio: convert to the control framework. mt9v011: convert to the control framework. drivers/media/i2c/mt9v011.c| 223 +-- drivers/media/i2c/tvaudio.c| 224 include/uapi/linux/v4l2-controls.h | 24 include/uapi/linux/videodev2.h | 22 --- 4 files changed, 166 insertions(+), 327 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
[GIT PULL FOR v3.9] videodev2.h fix and em28xx regression fixes
Hi Mauro, This is the second version of this git pull request. While digging through old branches of mine I found another tvaudio fix that I want to include here as well. In addition, the tvaudio control framework conversion in the original pull request also did a fix for balance handling and I have split that fix off into its own patch in this pull request. So effectively the only new thing is a two liner tvaudio/tea6420 fix. The first patch moves the DV control IDs from videodev2.h to v4l2-controls.h. I noticed that they weren't moved when the controls were split off from videodev2.h, probably because the patch adding the DV controls and the move to v4l2-controls.h crossed one another. The second patch converts mt9v011 to the control framework. The third and fourth patches fix two tvaudio bugs and the final patch converts tvaudio to the control framework. These patches were part of my original conversion of em28xx to the control framework (except for the tea6420 fix), but when Devin based his em28xx work on my tree he forgot to pull them in. Because of that any controls created by the mt9v011 and tvaudio drivers are inaccessible from em28xx. By converting those drivers to the control framework they are seen again. Frank tested the mt9v011 conversion. I have tested the tvaudio conversion somewhat with a bttv card that had a tda9850 and tea6420, but if you have additional tvaudio cards (and especially an em28xx that uses the tvaudio module), then it would be good to do some additional tests. Other than the bttv card I have no other hardware to test tvaudio with. Regards, Hans The following changes since commit 94a93e5f85040114d6a77c085457b3943b6da889: [media] dvb_frontend: print a msg if a property doesn't exist (2013-01-23 19:10:57 -0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git fixes2 for you to fetch changes up to 2e984336e5df76226c7ce977d2eeaecd98d625eb: tvaudio: convert to the control framework. (2013-02-02 10:03:36 +0100) Hans Verkuil (5): Move DV-class control IDs from videodev2.h to v4l2-controls.h mt9v011: convert to the control framework. tvaudio: fix broken volume/balance calculations tvaudio: fix two tea6420 errors. tvaudio: convert to the control framework. drivers/media/i2c/mt9v011.c| 223 - drivers/media/i2c/tvaudio.c| 238 ++ include/uapi/linux/v4l2-controls.h | 24 +++ include/uapi/linux/videodev2.h | 22 --- 4 files changed, 179 insertions(+), 328 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: [RFC v2 0/5] Common Display Framework
On Fri, Feb 1, 2013 at 5:42 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Rahul, On Wednesday 09 January 2013 13:53:30 Rahul Sharma wrote: Hi Laurent, CDF will also be helpful in supporting Panels with integrated audio (HDMI/DP) if we can add audio related control operations to display_entity_control_ops. Video controls will be called by crtc in DRM/V4L and audio controls from Alsa. I knew that would come up at some point :-) I agree with you that adding audio support would be a very nice improvement, and I'm totally open to that, but I will concentrate on video, at least to start with. The first reason is that I'm not familiar enough with ALSA, and the second that there's only 24h per day :-) Please feel free, of course, to submit a proposal for audio support. Secondly, if I need to support get_modes operation in hdmi/dp panel, I need to implement edid parser inside the panel driver. It will be meaningful to add get_edid control operation for hdmi/dp. Even if EDID data is parsed in the panel driver, raw EDID will still need to be exported, so a get_edid control operation (or something similar) is definitely needed. There's no disagreement on this, I just haven't included that operation yet because my test hardware is purely panel-based. one of (probably many) places that just keeping CDF (CDH? common display helpers..) inside DRM makes life easier :-P BR, -R -- 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 -- 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: Bug report - em28xx NEW
I tried again with the same machine, but this time with a 3.2.0-29-generik-pae 64bits, instead of previous 32 bits kernel. Same errors when inserting the device. Olivier Le 01. 02. 13 13:35, Futilite a écrit : Well. Compilation is done since last time. But module produced is unusable. I cloned last version of git repository. run ./build once - no compilation of em28xx make menuconfig -select emxx -make result: compilation of em28xx*.ko I attached the result of stderr and stdout. But when I try to modprobe the new modules (or unplug/replug my pctv quatrostick nano (520e), I obtain the following errors: root@mediacenter:~# modprobe em28xx WARNING: Error inserting media (/lib/modules/3.2.0-36-generic-pae/kernel/drivers/media/media.ko): Unknown symbol in module, or unknown parameter (see dmesg) WARNING: Error inserting videodev (/lib/modules/3.2.0-36-generic-pae/kernel/drivers/media/v4l2-core/videodev.ko): Unknown symbol in module, or unknown parameter (see dmesg) WARNING: Error inserting v4l2_common (/lib/modules/3.2.0-36-generic-pae/kernel/drivers/media/v4l2-core/v4l2-common.ko): Unknown symbol in module, or unknown parameter (see dmesg) WARNING: Error inserting videobuf2_core (/lib/modules/3.2.0-36-generic-pae/kernel/drivers/media/v4l2-core/videobuf2-core.ko): Unknown symbol in module, or unknown parameter (see dmesg) FATAL: Error inserting em28xx (/lib/modules/3.2.0-36-generic-pae/kernel/drivers/media/usb/em28xx/em28xx.ko): Unknown symbol in module, or unknown parameter (see dmesg) Some hardware precision: I'm (obviously) trying to make a nice mediacenter with two usb tv decoders. These compiled fine with another computer with kernel 3.2.0-xx-generic-pae. But I need them with my mediacenter, not with my desktop computer... Hardware configuration of my mediacenter: Intel(R) Atom(TM) CPU D525 @ 1.80GHz output of uname -r: 3.2.0-36-generic-pae Any help would be appreciated. Best regards Olivier -- 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-utils: use openat when available
Hello, On 1/22/13 5:37 PM, Riku Voipio wrote: New architectures such as 64-Bit arm build kernels without legacy system calls - Such as the the no-at system calls. Thus, use SYS_openat whenever it is available. +#ifdef SYS_openat +#define SYS_OPEN(file, oflag, mode) \ + syscall(SYS_openat, AT_FDCWD, (const char *)(file), (int)(oflag), (mode_t)(mode)) +#else #define SYS_OPEN(file, oflag, mode) \ syscall(SYS_open, (const char *)(file), (int)(oflag), (mode_t)(mode)) +#endif This would reduce compatibility to Linux = 2.6.16 where openat was introduced. How about testing for absence of SYS_open instead? Or fall back to SYS_open if SYS_openat is not implemented? Thanks, Gregor -- 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: Question about printking
On Sat, 2013-02-02 at 16:30 -0300, Ezequiel Garcia wrote:
ptr = kmalloc(sizeof(foo));
if (!ptr) {
pr_err(Cannot allocate memory for foo\n);
return -ENOMEM;
}
His argue against it was that kmalloc already takes care of
reporting/printking
a good deal of interesting information when this happens.
Can someone expand a bit on this whole idea? (of abuse of printing,
or futility of printing).
k.alloc() takes a GFP_ flag as an arg.
One of those GFP flags is __GFP_NOWARN.
For all failed allocs without GFP_NOWARN
a message is emitted and a dump_stack is
done.
(see: mm/page_alloc.c warn_alloc_failed())
So, most all of these printks after
k.alloc()'s are not necessary.
--
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: [QUERY] V4L async api
On Wed, 30 Jan 2013, Prabhakar Lad wrote: Hi Guennadi, I am working on adding v4l-asyn for capture and display device.. Here is my hw details:-- 1: The capture device has two subdevs tvp514x @0x5c and tvp514x @0x5d. 2: The display device has a one subdev adv7343 @0x2a. Note:- I have added async support for all the subdevices and the capture and display driver too Test Case:- 1: I have v4l2_async_notifier_register() for both capture and display driver, as of now I have built the subdevices as module. when board is up, I insert the tvp514x subdevices and the capture driver gets intialized (/dev/video0 /dev/video1) nodes get created, now I do insmod on the other subdevice adv7343, the bound callback is called in capture driver, but whereas this should have been called in the display driver. This certainly _should_ not happen. Your subdevice driver should call v4l2_async_subdev_bound(), which will walk the notifier list and check, which of them this subdevice matches. I'm afraid you'll have to debug your set up to see why the wrong notifier matches. 2: When I build the subdevices as part of uImage I hit a crash. Attached is the crash log. The crash happens in v4l2_async_notifier_register() when a newly registered notifier walks the list of _already_ successfully probed subdevices. Then I'm not exactly sure where the actual crash happens, one of the possibilities is if the match_i2c() function is called for an invalid or unbound i2c device. You'll have to debug this too. Thanks Guennadi 3: When I just build and use either the capture/display driver and their respective subdevices only every thing works fine. Regards, --Prabhakar --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: WARNINGS
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: Sat Feb 2 19:00:22 CET 2013 git branch: for_v3.9 git hash: 24dec5dabfcc1d424d7bc86d393d31f57ebcc975 gcc version:i686-linux-gcc (GCC) 4.7.2 host hardware: x86_64 host os:3.4.07-marune linux-git-arm-davinci: WARNINGS linux-git-arm-exynos: WARNINGS linux-git-arm-omap: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-rc4-i686: OK linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-rc4-x86_64: OK apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The Media Infrastructure API 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
SDVR 407 S
SDVR 407 S is a single Bt878 chip 16 ch. video, 4ch audio input dvr card. id: 600a:763d board name: SDVR 407 S card=150 Seems to be a Geovision GV-600 clone, video inputs works with card=150 insmod option. Thanks for your work! -- easynet.ro - Best free webmail service hosted by Idilis . Idilis - Internet Provider :: www.idilis.net Inchiriem conexiuni radio si in zone neracordate la coloana - Broadband Wireless Idilis - -- 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: WinTV-HVR-1400: scandvb (and kaffeine) fails to find any channels
On 02/01/13 21:07, Devin Heitmueller wrote: On Fri, Feb 1, 2013 at 4:03 PM, Chris Clayton chris2...@googlemail.com wrote: Yes, I noticed that but even with the tuning timeout set at medium or longest, I doesn't find any channels. However, I've been following the debug messages through the code and ended up at drivers/media/pci/cx23885/cx23885-i2c.c. I've found that by amending I2C_WAIT_DELAY from 32 to 64, I get improved results from scanning. With that delay doubled, scandvb now finds 49 channels over 3 frequencies. That's with all debugging turned off, so no extra delays provided by the production of debug messages. I'll play around more tomorrow and update then. It could be that the cx23885 driver doesn't properly implement I2C clock stretching, which is something you don't encounter on most tuners but is an issue when communicating with the Xceive parts. Well, the action seems to be in drivers/pci/cx23885/cx23885-i2c.c. I answer to your point above, I've had to look up what I2C clock stretching is and I believe that, basically, the driver would wait for the hardware to give the go-ahead to continue. That's what seems to be happening in i2c_wait_done(), but whether that's a good implementation I cannot say. I've noticed that there is some consistency in the failure. For example, if I boot the laptop, activate the dvb-t card and then run a channel scan, no channels will be found. If I then turn on debugging in the cx23885 driver (by writing 1 to /sys/module/cx23885/parameters/i2c_debug), and then run the scan again, some channels will be found. The number found varies from just a few to, on one occasion, all 117 of them. Then, I can turn debugging off again and channels will again be found when I run the scan and continue to be found each time I run the scan. If I reboot, the cycle starts again. I've also added some printks to the cx23885-i2c.c to find out where the return value of -5 (-EIO) comes from. I've found that the call to i2c_wait_done in i2c_sendbytes (line 145) returns 0 and that results in -EIO being returned a few lines later. My debug output also contained the value of the variable cnt, which controls the enclosing for() loop. cnt always has the value 3. I don't know what this might mean in terms of locating the problem, but hopefully someone on the list will. Chris 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: af9035 test needed!
On Fri, Jan 11, 2013 at 6:45 PM, Jose Alberto Reguero
jaregu...@telefonica.net wrote:
On Viernes, 11 de enero de 2013 20:38:01 Antti Palosaari escribió:
Hello Jose and Gianluca
Could you test that (tda18218 mxl5007t):
http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/it9135_tune
r
I wonder if ADC config logic still works for superheterodyne tuners
(tuner having IF). I changed it to adc / 2 always due to IT9135 tuner.
That makes me wonder it possible breaks tuners having IF, as ADC was
clocked just over 20MHz and if it is half then it is 10MHz. For BB that
is enough, but I think that having IF, which is 4MHz at least for 8MHz
BW it is too less.
F*ck I hate to maintain driver without a hardware! Any idea where I can
get AF9035 device having tda18218 or mxl5007t?
regards
Antti
Still pending the changes for mxl5007t. Attached is a patch for that.
Changes to make work Avermedia Twinstar with the af9035 driver.
Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
Jose Alberto
diff -upr linux/drivers/media/tuners/mxl5007t.c
linux.new/drivers/media/tuners/mxl5007t.c
--- linux/drivers/media/tuners/mxl5007t.c 2012-08-14 05:45:22.0
+0200
+++ linux.new/drivers/media/tuners/mxl5007t.c 2013-01-10 19:23:09.247556275
+0100
@@ -374,7 +374,6 @@ static struct reg_pair_t *mxl5007t_calc_
mxl5007t_set_if_freq_bits(state, cfg-if_freq_hz, cfg-invert_if);
mxl5007t_set_xtal_freq_bits(state, cfg-xtal_freq_hz);
- set_reg_bits(state-tab_init, 0x04, 0x01, cfg-loop_thru_enable);
set_reg_bits(state-tab_init, 0x03, 0x08, cfg-clk_out_enable 3);
set_reg_bits(state-tab_init, 0x03, 0x07, cfg-clk_out_amp);
This is a configurable option - it should not be removed, just
configure your glue code to not use that option if you dont want
it unless there's some other reason why you're removing this?
@@ -531,9 +530,12 @@ static int mxl5007t_tuner_init(struct mx
struct reg_pair_t *init_regs;
int ret;
- ret = mxl5007t_soft_reset(state);
- if (mxl_fail(ret))
+ if (!state-config-no_reset) {
+ ret = mxl5007t_soft_reset(state);
+ if (mxl_fail(ret))
goto fail;
+ }
+
this seems wrong to me. why would you want to prevent the driver from
doing a soft reset?
/* calculate initialization reg array */
init_regs = mxl5007t_calc_init_regs(state, mode);
@@ -887,7 +889,12 @@ struct dvb_frontend *mxl5007t_attach(str
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 1);
- ret = mxl5007t_get_chip_id(state);
+ if (!state-config-no_probe)
+ ret = mxl5007t_get_chip_id(state);
+
+ ret = mxl5007t_write_reg(state, 0x04,
+ state-config-loop_thru_enable);
+
Can you explain why this change was made? ^^
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 0);
diff -upr linux/drivers/media/tuners/mxl5007t.h
linux.new/drivers/media/tuners/mxl5007t.h
--- linux/drivers/media/tuners/mxl5007t.h 2012-08-14 05:45:22.0
+0200
+++ linux.new/drivers/media/tuners/mxl5007t.h 2013-01-10 19:19:11.204379581
+0100
@@ -73,8 +73,10 @@ struct mxl5007t_config {
enum mxl5007t_xtal_freq xtal_freq_hz;
enum mxl5007t_if_freq if_freq_hz;
unsigned int invert_if:1;
- unsigned int loop_thru_enable:1;
+ unsigned int loop_thru_enable:3;
Why widen this boolean to three bits?
unsigned int clk_out_enable:1;
+ unsigned int no_probe:1;
+ unsigned int no_reset:1;
};
#if defined(CONFIG_MEDIA_TUNER_MXL5007T) ||
(defined(CONFIG_MEDIA_TUNER_MXL5007T_MODULE) defined(MODULE))
diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.c
linux.new/drivers/media/usb/dvb-usb-v2/af9035.c
--- linux/drivers/media/usb/dvb-usb-v2/af9035.c 2013-01-07 05:45:57.0
+0100
+++ linux.new/drivers/media/usb/dvb-usb-v2/af9035.c 2013-01-12
00:30:57.557310465 +0100
@@ -886,13 +886,17 @@ static struct mxl5007t_config af9035_mxl
.loop_thru_enable = 0,
.clk_out_enable = 0,
.clk_out_amp = MxL_CLKOUT_AMP_0_94V,
+ .no_probe = 1,
+ .no_reset = 1,
}, {
.xtal_freq_hz = MxL_XTAL_24_MHZ,
.if_freq_hz = MxL_IF_4_57_MHZ,
.invert_if = 0,
- .loop_thru_enable = 1,
+ .loop_thru_enable = 3,
.clk_out_enable = 1,
.clk_out_amp = MxL_CLKOUT_AMP_0_94V,
+ .no_probe = 1,
+ .no_reset = 1,
}
};
This patch cannot be merged as-is. I'm sorry. If you could explain
why each change was made, then perhaps I would be able to advise
better how to make this work on your device without breaking others.
-Mike
