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: Thu 31 Jul 08:04:29 CEST 2014 git branch: test git hash: 27dcb00d0dc1d532b0da940e35a6d020ee33bd47 gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-16-g1db35d0 host hardware: x86_64 host os:3.15-5.slh.2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16-rc1-i686: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16-rc1-x86_64: OK apps: WARNINGS spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.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
Re: ddbridge -- kernel 3.15.6
On 07/30/2014 11:03 PM, Rudy Zijlstra wrote: On 19-07-14 19:49, Thomas Kaiser wrote: Hello Rudy I use a similar card from Digital Devices with Ubuntu 14.04 and kernel 3.13.0-32-generic. Support for this card was not build into the kernel and I had to compile it myself. I had to use media_build_experimental from Mr. Endriss. http://linuxtv.org/hg/~endriss/media_build_experimental Your card should be supported with this version. Regards, Thomas Hi Thomas, thank you for the information. Is there a preferred kernel for the experimental? Cheers Rudy Hello Rudy I don't know! I use it with Ubuntu 14.04 and kernel 3.13.0, right know. But I used it with older Ubuntu Versions (13.10, 13.04) and there kernels, too. I think it should compile with the newest kernel also. 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
[PATCH] videobuf2-core: simplify and unify the kernel api
Making the kernel api more simplified and unified. Signed-off-by: panpan liu panpan1@samsung.com --- drivers/media/v4l2-core/videobuf2-core.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) mode change 100644 = 100755 drivers/media/v4l2-core/videobuf2-core.c diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c old mode 100644 new mode 100755 index 9abb15e..71ba92c --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -1194,7 +1194,7 @@ static void __enqueue_in_driver(struct vb2_buffer *vb) for (plane = 0; plane vb-num_planes; ++plane) call_memop(q, prepare, vb-planes[plane].mem_priv); - q-ops-buf_queue(vb); + call_qop(q, buf_queue, vb); } static int __buf_prepare(struct vb2_buffer *vb, const struct v4l2_buffer *b) -- 1.7.9.5 -- 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: Problems with the omap3isp
Am 31.07.2014 01:10, schrieb Laurent Pinchart:
On Tuesday 15 July 2014 12:04:09 Stefan Herbrechtsmeier wrote:
Hi Laurent,
I have some problems with the omap3isp driver. At the moment I use a
linux-stable 3.14.5 with your fixes for omap3xxx-clocks.dtsi.
1. If I change the clock rate to 24 MHz in my camera driver the whole
system freeze at the clk_prepare_enable. The first enable and disable
works without any problem. The system freeze during a systemd / udev
call of media-ctl.
I've never seen that before. Where does your sensor get its clock from ? Is it
connected to the ISP XCLKA or XCLKB output ?
XCLKA
What happens if you don't change
the clock rate to 24 MHz ? What rate is it set to in that case ?
It works if I use a clock rate of 12 MHz or 36 MHz.
I use the following lines during power enable in the driver:
clk_set_rate(ov5647-clk, 2400);
clk_prepare_enable(ov5647-clk);
This works during probe, but the second time I try to power up the
device the system stall after clk_prepare_enable.
I see the following dump:
[ 392.148620] INFO: rcu_preempt self-detected stall on CPU { 0} (t=2100
jiffies g=1819 c=1818 q=16)
[ 392.158142] CPU: 0 PID: 1853 Comm: v4l2-ctl Tainted: G W
3.14.5-yocto-standard #131
[ 392.167144] [c001518c] (unwind_backtrace) from [c00125a0]
(show_stack+0x20/0x24)
[ 392.175323] [c00125a0] (show_stack) from [c069bdcc]
(dump_stack+0x20/0x28)
[ 392.182922] [c069bdcc] (dump_stack) from [c0086974]
(rcu_check_callbacks+0x210/0x694)
[ 392.191558] [c0086974] (rcu_check_callbacks) from [c0045684]
(update_process_times+0x4c/0x6c)
[ 392.200897] [c0045684] (update_process_times) from [c00906b0]
(tick_sched_handle.isra.14+0x58/0x64)
[ 392.210784] [c00906b0] (tick_sched_handle.isra.14) from
[c009070c] (tick_sched_timer+0x50/0x80)
[ 392.220306] [c009070c] (tick_sched_timer) from [c005b8b0]
(__run_hrtimer+0x190/0x2d0)
[ 392.228912] [c005b8b0] (__run_hrtimer) from [c005c20c]
(hrtimer_interrupt+0x118/0x260)
[ 392.237640] [c005c20c] (hrtimer_interrupt) from [c0022e34]
(omap2_gp_timer_interrupt+0x30/0x40)
[ 392.247161] [c0022e34] (omap2_gp_timer_interrupt) from [c007db60]
(handle_irq_event_percpu+0xb4/0x2d0)
[ 392.257324] [c007db60] (handle_irq_event_percpu) from [c007ddc8]
(handle_irq_event+0x4c/0x6c)
[ 392.22] [c007ddc8] (handle_irq_event) from [c0080668]
(handle_level_irq+0xe0/0xf8)
[ 392.275360] [c0080668] (handle_level_irq) from [c007d314]
(generic_handle_irq+0x30/0x40)
[ 392.284271] [c007d314] (generic_handle_irq) from [c000f32c]
(handle_IRQ+0x70/0x90)
[ 392.292602] [c000f32c] (handle_IRQ) from [c00085f4]
(omap3_intc_handle_irq+0x68/0x90)
[ 392.301208] [c00085f4] (omap3_intc_handle_irq) from [c06a2f44]
(__irq_svc+0x44/0x78)
[ 392.309722] Exception stack(0xdda299f8 to 0xdda29a40)
[ 392.315032]
99e0: 0001
0110
[ 392.323638] 9a00: de604600 dda28000 0202 dda28000
c0a73800 de554cc0 de554cc8
[ 392.332244] 9a20: 000a dda29a8c dda299d8 dda29a40 c00724fc
c003d1b8 60070113
[ 392.340881] [c06a2f44] (__irq_svc) from [c003d1b8]
(__do_softirq+0xd0/0x370)
[ 392.348663] [c003d1b8] (__do_softirq) from [c003d758]
(irq_exit+0x94/0x104)
[ 392.356353] [c003d758] (irq_exit) from [c000f330]
(handle_IRQ+0x74/0x90)
[ 392.363769] [c000f330] (handle_IRQ) from [c00085f4]
(omap3_intc_handle_irq+0x68/0x90)
[ 392.372406] [c00085f4] (omap3_intc_handle_irq) from [c06a2f44]
(__irq_svc+0x44/0x78)
[ 392.380889] Exception stack(0xdda29ae8 to 0xdda29b30)
[ 392.386230] 9ae0: 0001 0110
de604600 60070013 c0a5eb08
[ 392.394836] 9b00: 60070013 fdfd de554cc0 de554cc8 de62b400
dda29b44 dda29ac8 dda29b30
[ 392.403442] 9b20: c00724fc c06a21b8 20070013
[ 392.408752] [c06a2f44] (__irq_svc) from [c06a21b8]
(_raw_spin_unlock_irqrestore+0x50/0x84)
[ 392.417846] [c06a21b8] (_raw_spin_unlock_irqrestore) from
[c056750c] (clk_enable_unlock+0xb4/0xc8)
[ 392.427642] [c056750c] (clk_enable_unlock) from [c0567bdc]
(clk_enable+0x34/0x3c)
[ 392.435913] [c0567bdc] (clk_enable) from [bf255f50]
(ov5647_set_power.part.2+0x68/0xc4 [ov5647])
[ 392.445800] [bf255f50] (ov5647_set_power.part.2 [ov5647]) from
[bf255568] (ov5647_set_power+0x24/0x58 [ov5647])
[ 392.456787] [bf255568] (ov5647_set_power [ov5647]) from
[bf255604] (ov5647_s_power+0x68/0xb4 [ov5647])
[ 392.467041] [bf255604] (ov5647_s_power [ov5647]) from [bf18812c]
(isp_pipeline_pm_power_one+0x98/0x118 [omap3_isp])
[ 392.478454] [bf18812c] (isp_pipeline_pm_power_one [omap3_isp]) from
[bf188c84] (isp_pipeline_pm_power.part.2+0x54/0xb4 [omap3_isp])
[ 392.491333] [bf188c84] (isp_pipeline_pm_power.part.2 [omap3_isp])
from [bf188d04] (isp_pipeline_pm_power+0x20/0x2c [omap3_isp])
[ 392.503845] [bf188d04] (isp_pipeline_pm_power [omap3_isp]) from
[bf189630] (omap3isp_pipeline_pm_use+0x60/0x88 [omap3_isp])
[ 392.515991] [bf189630] (omap3isp_pipeline_pm_use [omap3_isp])
RE: [PATCH] V4L/DVB: dvb-usb-v2: Update firmware and driver for performance of ITEtech IT9135
Hi, Antti!
Thank you for your reply. We hope the performance was improved and the patch
meets your requirements. But the challenges are some tuner registers needed to
set before initializing the demodulator. See comments below.
Moikka Bimow!
I did a lot of testing today for that patch. I used only single tuner device
having IT9135 BX chip. Running it against modulator I saw sensitivity was
increased around 5 dBm (TX power).
However, I am not 100% happy with that patch. See comments below.
On 07/25/2014 11:11 AM, Bimow Chen wrote:
Fix performance issue of IT9135 AX and BX chip versions.
0001-Update-firmware-and-driver-for-performance-of-ITEtec.patch
From 57fe102419e83e73080af15cc3ad3fe241d7f8b4 Mon Sep 17 00:00:00 2001
From: Bimow Chenbimow.c...@ite.com.tw
Date: Thu, 24 Jul 2014 13:23:39 +0800
Subject: [PATCH 1/1] Update firmware and driver for performance of
ITEtech IT9135
Fix performance issue of IT9135 AX and BX chip versions.
Signed-off-by: Bimow Chenbimow.c...@ite.com.tw
Signed-off-by: Bimow Chenbimow.c...@ite.com.tw
---
Documentation/dvb/get_dvb_firmware| 24 +---
drivers/media/dvb-frontends/af9033.c | 18 ++
drivers/media/dvb-frontends/af9033_priv.h | 20 +---
drivers/media/tuners/tuner_it913x.c |6 --
drivers/media/usb/dvb-usb-v2/af9035.c | 11 +++
5 files changed, 51 insertions(+), 28 deletions(-)
diff --git a/Documentation/dvb/get_dvb_firmware
b/Documentation/dvb/get_dvb_firmware
index d91b8be..efa100a 100755
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware
@@ -708,23 +708,25 @@ sub drxk_terratec_htc_stick {
}
sub it9135 {
- my $sourcefile = dvb-usb-it9135.zip;
- my $url =http://www.ite.com.tw/uploads/firmware/v3.6.0.0/$sourcefile;;
- my $hash = 1e55f6c8833f1d0ae067c2bb2953e6a9;
- my $tmpdir = tempdir(DIR = /tmp, CLEANUP = 0);
- my $outfile = dvb-usb-it9135.fw;
+ my $url =http://www.ite.com.tw/uploads/firmware/v3.25.0.0/;;
+ my $file1 = dvb-usb-it9135-01.zip;
my $fwfile1 = dvb-usb-it9135-01.fw;
+ my $hash1 = 02fcf11174eda84745dae7e61c5ff9ba;
+ my $file2 = dvb-usb-it9135-02.zip;
my $fwfile2 = dvb-usb-it9135-02.fw;
+ my $hash2 = d5e1437dc24358578e07999475d4cac9;
checkstandard();
- wgetfile($sourcefile, $url);
- unzip($sourcefile, $tmpdir);
- verify($tmpdir/$outfile, $hash);
- extract($tmpdir/$outfile, 64, 8128, $fwfile1);
- extract($tmpdir/$outfile, 12866, 5817, $fwfile2);
+ wgetfile($file1, $url . $file1);
+ unzip($file1, );
+ verify($fwfile1, $hash1);
+
+ wgetfile($file2, $url . $file2);
+ unzip($file2, );
+ verify($fwfile2, $hash2);
- $fwfile1 $fwfile2
+ $file1 $file2
}
sub tda10071 {
Split that get_dvb_firmware stuff to own separate patch.
diff --git a/drivers/media/dvb-frontends/af9033.c
b/drivers/media/dvb-frontends/af9033.c
index be4bec2..e96e655 100644
--- a/drivers/media/dvb-frontends/af9033.c
+++ b/drivers/media/dvb-frontends/af9033.c
@@ -274,6 +274,22 @@ static int af9033_init(struct dvb_frontend *fe)
{ 0x800045, state-cfg.adc_multiplier, 0xff },
};
+ /* power up tuner - for performance */
+ switch (state-cfg.tuner) {
+ case AF9033_TUNER_IT9135_38:
+ case AF9033_TUNER_IT9135_51:
+ case AF9033_TUNER_IT9135_52:
+ case AF9033_TUNER_IT9135_60:
+ case AF9033_TUNER_IT9135_61:
+ case AF9033_TUNER_IT9135_62:
+ ret = af9033_wr_reg(state, 0x80ec40, 0x1);
+ ret |= af9033_wr_reg(state, 0x80fba8, 0x0);
+ ret |= af9033_wr_reg(state, 0x80ec57, 0x0);
+ ret |= af9033_wr_reg(state, 0x80ec58, 0x0);
+ if (ret 0)
+ goto err;
+ }
+
You moved that initialization here from tuner_it913x driver. What I
understand register range 0xec00 - 0xefff belongs to integrated RF tuner.
This is demodulator driver and I really like to separate functionality as
much as possible per correct driver.
I did some testing and find out the actual need here is 0xfba8 register,
which is needed to set before FSM is triggered. That reg is 0 by default, but
tuner_it913x driver set it to 1 during sleep.
Name of 0xfba8 register is p_reg_dyn0_clk, which indicates it is some sort of
clock. I don't have documentation... Maybe it should be controlled by demod
driver power-management?
All the other registers should just go back to tuner_it913x driver.
0xfba8 register is needed to set before FSM is triggered. And ec40 register is
the tuner register mapping switch, which is needed to set before setting tuner
registers like loading tuner specific setting.
All the other registers will go back to tuner_it913x driver in next patch.
/* program clock control */
clock_cw = af9033_div(state, state-cfg.clock, 100ul,
Re: [PATCH] videobuf2-core: simplify and unify the kernel api
On 07/31/2014 10:28 AM, panpan liu wrote: Making the kernel api more simplified and unified. Signed-off-by: panpan liu panpan1@samsung.com Has been fixed already in 3.15. Always check the latest code! Regards, Hans --- drivers/media/v4l2-core/videobuf2-core.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) mode change 100644 = 100755 drivers/media/v4l2-core/videobuf2-core.c diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c old mode 100644 new mode 100755 index 9abb15e..71ba92c --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -1194,7 +1194,7 @@ static void __enqueue_in_driver(struct vb2_buffer *vb) for (plane = 0; plane vb-num_planes; ++plane) call_memop(q, prepare, vb-planes[plane].mem_priv); - q-ops-buf_queue(vb); + call_qop(q, buf_queue, vb); } static int __buf_prepare(struct vb2_buffer *vb, const struct v4l2_buffer *b) -- 1.7.9.5 -- 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: Configurable Video Controller Driver
Hi Sakari, Thank you for your answer. Le 21/07/2014 13:14, Sakari Ailus a écrit : Hi Julien, On Thu, Jul 10, 2014 at 04:19:06PM +0200, Julien BERAUD wrote: We are developing a driver for our video controller which has the particularity of being very reconfigurable. We have reached a point at which the complexity and variety of the applications we need to implement forces us to design an api/library that allows us to configure the interconnection of the different video processing units(Camera interfaces, LCD interfaces, scalers, rotators, demosaicing, dead pixel correction, etc...) from userland. The media controller api has the limitation of not being able to create links but just browsing and activating/deactivating them. If we just allowed a user to activate/deactivate links, then we would have to declare all the possible connections between the different blocks, which would make it very confusing from a userland point of view. Moreover, the interconnection constraints would have to be dealt with very generically, which would make it very difficult in the kernel too. How many different blocks do you have? Can they be connected in arbitrary ways? If not, what kind of limitations do you have? The Media controller is originally intended for modelling complex devices with hardware data paths between the sub-blocks. The question is: does your device fit into that group, even if could be a little more complex than the devices that are currently supported? We have 44 different hardware blocks that can be connected in arbitrary ways but with some constraints. Some of the blocks have several inputs(blenders) and some(one type only) have 2 outputs(the block is a fork). There are some limitations. Some blocks only accept Raw Bayer as input(ISP). There are some small limitations here and there, like if you use a scaler with a high scaling factor, you need to go to memory because the internal memory is not sufficient. Some of the blocks are FIFOs to write/read to memory. In the end, there are 6 camera inputs and 2 lcd outputs, all of them parallel, 2 ISPs with 2 blocks each(bayer/yuv), and 2 stat calculators, 12 Fifos, 4 color converters, 2 blenders with 4 inputs each, 2 scalers/rotators, 4 forks, 2 sat, 2 I3D, 2 gamma converters. Our device might be a little more complex than the devices that are currently supported, though I am not aware of all the currently supported devices. Something else, the Media controller doesn't allow to create links from userland, which is what I think we would need in order to avoid to declare all the possible combinations because that would be hard to understand in userland and complicated to handle in the kernel. We have come from a totally rigid interconnection declared in the BSP to become more and more generic but it is probable that becoming too generic wouldn't make things any better. The conclusion we have reached yet is that we have to design an API that allows us to create v4l2 subdevices that have certain capabilities(scaling,rotating, demosaicing, etc...) and then to create links between them from a userland library. Can you create arbitrary devices at will, or do these devices exist on hardware all the time? The devices exist on hardware at all time. What I would like to do is to create virtual subdevices that have some of the capabilities provided by the blocks in order to benefit from all the features the hardware provides in order to have a media controller tree that is clear and that fits the needs of the current application. We are currently thinking about designing a kernel driver along with a userland library that allows us to reconfigure our hardware paths in order to create those virtual subdevices and then expose them with the Media Controller/V4L2 subdev api. I have tried to bring the topic up on the v4l irc because it is a complicated matter. I will try again. There may be a better way to handle such a complicated video controller, but I haven't found it yet. If you have any idea, I am totally open to reconsider the path we are taking. In the end, it would be possible to handle each hardware block as an independant subdev or input/output as long as we would be able to create links with the media api but 2 considerations make it easier to do what we are currently doing : - In our applications, most of the hardware paths between the blocks won't move at runtime, just a few links would have to be reconfigured at runtime which could be exposed with the media api. - We already have a low level api that allows us to handle the creation of a hardware block that provide a list of capabilities. Thank you, Julien -- 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: omap3isp with DM3730 not working?!
Am 30.07.2014 17:21, schrieb Enrico: Standard question: are you using media-ctl from git://linuxtv.org/pinchartl/v4l-utils.git field branch and latest yavta from git://git.ideasonboard.org/yavta.git ? Enrico No, not exactly. I used older versions which came with Yocto Poky Daisy. But I also tried with these newer ones and get the same: root@overo:~$ ./media-ctl -v -r -l 'tvp5150 3-005c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' Opening media device /dev/media0 Enumerating entities Found 16 entities Enumerating pads and links Resetting all links to inactive Opening media device /dev/media0 Opening media device /dev/media0 Opening media device /dev/media0 Opening media device /dev/media0 Opening media device /dev/media0 Opening media device /dev/media0 Opening media device /dev/media0 Opening media device /dev/media0 Opening media device /dev/media0 Opening media device /dev/media0 Opening media device /dev/media0 Opening media device /dev/media0 Opening media device /dev/media0 Setting up link 16:0 - 5:0 [1] Opening media device /dev/media0 Setting up link 5:1 - 6:0 [1] Opening media device /dev/media0 root@overo:~$ ./media-ctl -v -f 'tvp5150 3-005c:0 [UYVY2X8 720x576], OMAP3 ISP CCDC:1 [UYVY2X8 720x576]' Warning: the -f option is deprecated and has been replaced by -V. Opening media device /dev/media0 Enumerating entities Found 16 entities Enumerating pads and links Setting up format UYVY2X8 720x576 on pad tvp5150 3-005c/0 Format set: UYVY2X8 720x240 Setting up format UYVY2X8 720x240 on pad OMAP3 ISP CCDC/0 Format set: UYVY2X8 720x240 Setting up format UYVY2X8 720x576 on pad OMAP3 ISP CCDC/1 Format set: UYVY 720x240 root@overo:~$ ./yavta -f UYVY -s 720x576 --capture=1 --file=image.raw /dev/video2 Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video output (without mplanes) device. Video format set: UYVY (59565955) 720x576 (stride 1440) field none buffer size 829440 Video format: UYVY (59565955) 720x576 (stride 1440) field none buffer size 829440 8 buffers requested. length: 829440 offset: 0 timestamp type/source: mono/(null) Buffer 0/0 mapped at address 0xb6e59000. length: 829440 offset: 831488 timestamp type/source: mono/(null) Buffer 1/0 mapped at address 0xb6d8e000. length: 829440 offset: 1662976 timestamp type/source: mono/(null) Buffer 2/0 mapped at address 0xb6cc3000. length: 829440 offset: 2494464 timestamp type/source: mono/(null) Buffer 3/0 mapped at address 0xb6bf8000. length: 829440 offset: 3325952 timestamp type/source: mono/(null) Buffer 4/0 mapped at address 0xb6b2d000. length: 829440 offset: 4157440 timestamp type/source: mono/(null) Buffer 5/0 mapped at address 0xb6a62000. length: 829440 offset: 4988928 timestamp type/source: mono/(null) Buffer 6/0 mapped at address 0xb6997000. length: 829440 offset: 5820416 timestamp type/source: mono/(null) Buffer 7/0 mapped at address 0xb68cc000. Unable to start streaming: Invalid argument (22). 8 buffers released. -- 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 00/11] OMAP3 ISP BT.656 support
On Wed, Jul 30, 2014 at 11:01 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Enrico, On Wednesday 23 July 2014 15:57:51 Enrico wrote: On Wed, Jul 23, 2014 at 3:54 PM, Enrico wrote: [snip] You were right i was using the wrong binary, now the output is: ... - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 pad0: Sink [fmt:UYVY2X8/720x625 field:interlaced] ... pad1: Source [fmt:UYVY/720x624 field:interlaced crop.bounds:(0,0)/720x624 crop:(0,0)/720x624] ... - entity 16: tvp5150 1-005c (1 pad, 1 link) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev8 pad0: Source [fmt:UYVY2X8/720x625 field:interlaced] That's surprising. Have you applied the tvp5150 patches from the omap3isp/bt656 branch ? The field should be hardcoded to V4L2_FIELD_ALTERNATE (reported as alternate by media-ctl), as the tvp5150 alternates between the top and bottom fields in consecutive frames. The CCDC input should then be configured to V4L2_FIELD_ALTERNATE as well, and the CCDC output to V4L2_FIELD_ALTERNATE (alternate), V4L2_FIELD_INTERLACED_TB (interlaced-tb) or V4L2_FIELD_INTERLACED_BT (interlaced-bt). No, i missed those patches i was using only the omap3isp patches you posted here. With those patches and configuring the pipleline as you suggested i could finally capture some good frames with yavta. But i think there is some race, because it's not very reliable. This is what i see: (with yavta -c50 -f UYVY -s 720x576 --field interlaced-tb /dev/video2) 1) first run, ok 2) if i re-run it soon after it finishes, it just hangs on start (in VIDIOC_DQBUF). I have to stop it with ctrl+c and after some seconds it exits, and the kernel prints the ccdc stop timeout message. in any case when it doesn't hang i can capture 200 frames with no errors. And if i wait some seconds before running it again it usually works (not always). 3) if i add -F to yavta (saving to a tmpfs in ram), it hangs after capturing some frames (usually between 20 and 30). yet again, same ctrl+c thing (it exits, ccdc stop timeout...). Apart from these issues your patches are much better then the old ones! Any hints on what i can try to fix these issues? Thanks, Enrico -- 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: omap3isp with DM3730 not working?!
On Thu, Jul 31, 2014 at 12:06 PM, Michael Dietschi michael.diets...@inunum.com wrote: Am 30.07.2014 17:21, schrieb Enrico: Standard question: are you using media-ctl from git://linuxtv.org/pinchartl/v4l-utils.git field branch and latest yavta from git://git.ideasonboard.org/yavta.git ? Enrico No, not exactly. I used older versions which came with Yocto Poky Daisy. But I also tried with these newer ones and get the same: root@overo:~$ ./media-ctl -v -r -l 'tvp5150 3-005c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' root@overo:~$ ./media-ctl -v -f 'tvp5150 3-005c:0 [UYVY2X8 720x576], OMAP3 ISP CCDC:1 [UYVY2X8 720x576]' root@overo:~$ ./yavta -f UYVY -s 720x576 --capture=1 --file=image.raw /dev/video2 I think you are missing the ccdc sink pad setup, basically you should have something like this: - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 pad0: Sink [fmt:UYVY2X8/720x288 field:alternate] - OMAP3 ISP CCP2:1 [] - OMAP3 ISP CSI2a:1 [] - tvp5150 1-005c:0 [ENABLED] pad1: Source [fmt:UYVY/720x576 field:interlaced-tb crop.bounds:(0,0)/720x288 crop:(0,0)/720x288] - OMAP3 ISP CCDC output:0 [ENABLED] - OMAP3 ISP resizer:0 [] with this setup i can correctly capture deinterlaced frames with yavta, but have a look at the [PATCH 00/11] OMAP3 ISP BT.656 support thread, i noticed some problems maybe it's the same for you. Enrico -- 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] videobuf2: fix lockdep warning
The following lockdep warning has been there ever since commit
a517cca6b24fc54ac209e44118ec8962051662e3
one year ago:
[ 403.117947] ==
[ 403.117949] [ INFO: possible circular locking dependency detected ]
[ 403.117953] 3.16.0-rc6-test-media #961 Not tainted
[ 403.117954] ---
[ 403.117956] v4l2-ctl/15377 is trying to acquire lock:
[ 403.117959] (dev-mutex#3){+.+.+.}, at: [a005a6c3]
vb2_fop_mmap+0x33/0x90 [videobuf2_core]
[ 403.117974]
[ 403.117974] but task is already holding lock:
[ 403.117976] (mm-mmap_sem){++}, at: [8118291f]
vm_mmap_pgoff+0x6f/0xc0
[ 403.117987]
[ 403.117987] which lock already depends on the new lock.
[ 403.117987]
[ 403.117990]
[ 403.117990] the existing dependency chain (in reverse order) is:
[ 403.117992]
[ 403.117992] - #1 (mm-mmap_sem){++}:
[ 403.117997][810d733c] validate_chain.isra.39+0x5fc/0x9a0
[ 403.118006][810d8bc3] __lock_acquire+0x4d3/0xd30
[ 403.118010][810d9da7] lock_acquire+0xa7/0x160
[ 403.118014][8118c9ec] might_fault+0x7c/0xb0
[ 403.118018][a0028a25] video_usercopy+0x425/0x610 [videodev]
[ 403.118028][a0028c25] video_ioctl2+0x15/0x20 [videodev]
[ 403.118034][a0022764] v4l2_ioctl+0x184/0x1a0 [videodev]
[ 403.118040][811d77d0] do_vfs_ioctl+0x2f0/0x4f0
[ 403.118307][811d7a51] SyS_ioctl+0x81/0xa0
[ 403.118311][8199dc69] system_call_fastpath+0x16/0x1b
[ 403.118319]
[ 403.118319] - #0 (dev-mutex#3){+.+.+.}:
[ 403.118324][810d6a96] check_prevs_add+0x746/0x9f0
[ 403.118329][810d733c] validate_chain.isra.39+0x5fc/0x9a0
[ 403.118333][810d8bc3] __lock_acquire+0x4d3/0xd30
[ 403.118336][810d9da7] lock_acquire+0xa7/0x160
[ 403.118340][81999664]
mutex_lock_interruptible_nested+0x64/0x640
[ 403.118344][a005a6c3] vb2_fop_mmap+0x33/0x90
[videobuf2_core]
[ 403.118349][a0022122] v4l2_mmap+0x62/0xa0 [videodev]
[ 403.118354][81197270] mmap_region+0x3d0/0x5d0
[ 403.118359][8119778d] do_mmap_pgoff+0x31d/0x400
[ 403.118363][81182940] vm_mmap_pgoff+0x90/0xc0
[ 403.118366][81195cef] SyS_mmap_pgoff+0x1df/0x2a0
[ 403.118369][810085c2] SyS_mmap+0x22/0x30
[ 403.118376][8199dc69] system_call_fastpath+0x16/0x1b
[ 403.118381]
[ 403.118381] other info that might help us debug this:
[ 403.118381]
[ 403.118383] Possible unsafe locking scenario:
[ 403.118383]
[ 403.118385]CPU0CPU1
[ 403.118387]
[ 403.118388] lock(mm-mmap_sem);
[ 403.118391]lock(dev-mutex#3);
[ 403.118394]lock(mm-mmap_sem);
[ 403.118397] lock(dev-mutex#3);
[ 403.118400]
[ 403.118400] *** DEADLOCK ***
[ 403.118400]
[ 403.118403] 1 lock held by v4l2-ctl/15377:
[ 403.118405] #0: (mm-mmap_sem){++}, at: [8118291f]
vm_mmap_pgoff+0x6f/0xc0
[ 403.118411]
[ 403.118411] stack backtrace:
[ 403.118415] CPU: 0 PID: 15377 Comm: v4l2-ctl Not tainted
3.16.0-rc6-test-media #961
[ 403.118418] Hardware name: VMware, Inc. VMware Virtual Platform/440BX
Desktop Reference Platform, BIOS 6.00 07/31/2013
[ 403.118420] 82a6c9d0 8800af37fb00 819916a2
82a6c9d0
[ 403.118425] 8800af37fb40 810d5715 8802308e4200
[ 403.118429] 8802308e4a48 8802308e4a48 8802308e4200
0001
[ 403.118433] Call Trace:
[ 403.118441] [819916a2] dump_stack+0x4e/0x7a
[ 403.118445] [810d5715] print_circular_bug+0x1d5/0x2a0
[ 403.118449] [810d6a96] check_prevs_add+0x746/0x9f0
[ 403.118455] [8119c172] ? find_vmap_area+0x42/0x70
[ 403.118459] [810d733c] validate_chain.isra.39+0x5fc/0x9a0
[ 403.118463] [810d8bc3] __lock_acquire+0x4d3/0xd30
[ 403.118468] [810d9da7] lock_acquire+0xa7/0x160
[ 403.118472] [a005a6c3] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core]
[ 403.118476] [a005a6c3] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core]
[ 403.118480] [81999664] mutex_lock_interruptible_nested+0x64/0x640
[ 403.118484] [a005a6c3] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core]
[ 403.118488] [a005a6c3] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core]
[ 403.118493] [810d8055] ? mark_held_locks+0x75/0xa0
[ 403.118497] [a005a6c3] vb2_fop_mmap+0x33/0x90 [videobuf2_core]
[ 403.118502] [a0022122] v4l2_mmap+0x62/0xa0 [videodev]
[ 403.118506] [81197270] mmap_region+0x3d0/0x5d0
[ 403.118510] [8119778d] do_mmap_pgoff+0x31d/0x400
[ 403.118513] [81182940]
Re: omap3isp with DM3730 not working?!
Am 31.07.2014 12:36, schrieb Enrico: I think you are missing the ccdc sink pad setup, basically you should have something like this: - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 pad0: Sink [fmt:UYVY2X8/720x288 field:alternate] - OMAP3 ISP CCP2:1 [] - OMAP3 ISP CSI2a:1 [] - tvp5150 1-005c:0 [ENABLED] pad1: Source [fmt:UYVY/720x576 field:interlaced-tb crop.bounds:(0,0)/720x288 crop:(0,0)/720x288] - OMAP3 ISP CCDC output:0 [ENABLED] - OMAP3 ISP resizer:0 [] with this setup i can correctly capture deinterlaced frames with yavta, but have a look at the [PATCH 00/11] OMAP3 ISP BT.656 support thread, i noticed some problems maybe it's the same for you. Enrico Hi Enrico, the setup looks like: ... - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 pad0: Sink [fmt:UYVY2X8/720x240 field:alternate] - OMAP3 ISP CCP2:1 [] - OMAP3 ISP CSI2a:1 [] - tvp5150 3-005c:0 [ENABLED] pad1: Source [fmt:UYVY/720x240 field:alternate crop.bounds:(0,0)/720x240 crop:(0,0)/720x240] - OMAP3 ISP CCDC output:0 [ENABLED] - OMAP3 ISP resizer:0 [] pad2: Source [fmt:unknown/720x239 field:alternate] - OMAP3 ISP preview:0 [] - OMAP3 ISP AEWB:0 [ENABLED,IMMUTABLE] - OMAP3 ISP AF:0 [ENABLED,IMMUTABLE] - OMAP3 ISP histogram:0 [ENABLED,IMMUTABLE] - entity 6: OMAP3 ISP CCDC output (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video2 pad0: Sink - OMAP3 ISP CCDC:1 [ENABLED] ... - entity 16: tvp5150 3-005c (1 pad, 1 link) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev8 pad0: Source [fmt:UYVY2X8/720x240 field:alternate] - OMAP3 ISP CCDC:0 [ENABLED] And I could not find any help in[PATCH 00/11] OMAP3 ISP BT.656 support because it seems that all the mentioned things are already done. Michael -- 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] videobuf2: fix lockdep warning
That finally fixes the issue I reported last year.
http://www.spinics.net/lists/linux-media/msg70935.html
Tested-by: Antti Palosaari cr...@iki.fi
On 07/31/2014 02:52 PM, Hans Verkuil wrote:
The following lockdep warning has been there ever since commit
a517cca6b24fc54ac209e44118ec8962051662e3
one year ago:
[ 403.117947] ==
[ 403.117949] [ INFO: possible circular locking dependency detected ]
[ 403.117953] 3.16.0-rc6-test-media #961 Not tainted
[ 403.117954] ---
[ 403.117956] v4l2-ctl/15377 is trying to acquire lock:
[ 403.117959] (dev-mutex#3){+.+.+.}, at: [a005a6c3]
vb2_fop_mmap+0x33/0x90 [videobuf2_core]
[ 403.117974]
[ 403.117974] but task is already holding lock:
[ 403.117976] (mm-mmap_sem){++}, at: [8118291f]
vm_mmap_pgoff+0x6f/0xc0
[ 403.117987]
[ 403.117987] which lock already depends on the new lock.
[ 403.117987]
[ 403.117990]
[ 403.117990] the existing dependency chain (in reverse order) is:
[ 403.117992]
[ 403.117992] - #1 (mm-mmap_sem){++}:
[ 403.117997][810d733c] validate_chain.isra.39+0x5fc/0x9a0
[ 403.118006][810d8bc3] __lock_acquire+0x4d3/0xd30
[ 403.118010][810d9da7] lock_acquire+0xa7/0x160
[ 403.118014][8118c9ec] might_fault+0x7c/0xb0
[ 403.118018][a0028a25] video_usercopy+0x425/0x610 [videodev]
[ 403.118028][a0028c25] video_ioctl2+0x15/0x20 [videodev]
[ 403.118034][a0022764] v4l2_ioctl+0x184/0x1a0 [videodev]
[ 403.118040][811d77d0] do_vfs_ioctl+0x2f0/0x4f0
[ 403.118307][811d7a51] SyS_ioctl+0x81/0xa0
[ 403.118311][8199dc69] system_call_fastpath+0x16/0x1b
[ 403.118319]
[ 403.118319] - #0 (dev-mutex#3){+.+.+.}:
[ 403.118324][810d6a96] check_prevs_add+0x746/0x9f0
[ 403.118329][810d733c] validate_chain.isra.39+0x5fc/0x9a0
[ 403.118333][810d8bc3] __lock_acquire+0x4d3/0xd30
[ 403.118336][810d9da7] lock_acquire+0xa7/0x160
[ 403.118340][81999664]
mutex_lock_interruptible_nested+0x64/0x640
[ 403.118344][a005a6c3] vb2_fop_mmap+0x33/0x90
[videobuf2_core]
[ 403.118349][a0022122] v4l2_mmap+0x62/0xa0 [videodev]
[ 403.118354][81197270] mmap_region+0x3d0/0x5d0
[ 403.118359][8119778d] do_mmap_pgoff+0x31d/0x400
[ 403.118363][81182940] vm_mmap_pgoff+0x90/0xc0
[ 403.118366][81195cef] SyS_mmap_pgoff+0x1df/0x2a0
[ 403.118369][810085c2] SyS_mmap+0x22/0x30
[ 403.118376][8199dc69] system_call_fastpath+0x16/0x1b
[ 403.118381]
[ 403.118381] other info that might help us debug this:
[ 403.118381]
[ 403.118383] Possible unsafe locking scenario:
[ 403.118383]
[ 403.118385]CPU0CPU1
[ 403.118387]
[ 403.118388] lock(mm-mmap_sem);
[ 403.118391]lock(dev-mutex#3);
[ 403.118394]lock(mm-mmap_sem);
[ 403.118397] lock(dev-mutex#3);
[ 403.118400]
[ 403.118400] *** DEADLOCK ***
[ 403.118400]
[ 403.118403] 1 lock held by v4l2-ctl/15377:
[ 403.118405] #0: (mm-mmap_sem){++}, at: [8118291f]
vm_mmap_pgoff+0x6f/0xc0
[ 403.118411]
[ 403.118411] stack backtrace:
[ 403.118415] CPU: 0 PID: 15377 Comm: v4l2-ctl Not tainted
3.16.0-rc6-test-media #961
[ 403.118418] Hardware name: VMware, Inc. VMware Virtual Platform/440BX
Desktop Reference Platform, BIOS 6.00 07/31/2013
[ 403.118420] 82a6c9d0 8800af37fb00 819916a2
82a6c9d0
[ 403.118425] 8800af37fb40 810d5715 8802308e4200
[ 403.118429] 8802308e4a48 8802308e4a48 8802308e4200
0001
[ 403.118433] Call Trace:
[ 403.118441] [819916a2] dump_stack+0x4e/0x7a
[ 403.118445] [810d5715] print_circular_bug+0x1d5/0x2a0
[ 403.118449] [810d6a96] check_prevs_add+0x746/0x9f0
[ 403.118455] [8119c172] ? find_vmap_area+0x42/0x70
[ 403.118459] [810d733c] validate_chain.isra.39+0x5fc/0x9a0
[ 403.118463] [810d8bc3] __lock_acquire+0x4d3/0xd30
[ 403.118468] [810d9da7] lock_acquire+0xa7/0x160
[ 403.118472] [a005a6c3] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core]
[ 403.118476] [a005a6c3] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core]
[ 403.118480] [81999664] mutex_lock_interruptible_nested+0x64/0x640
[ 403.118484] [a005a6c3] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core]
[ 403.118488] [a005a6c3] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core]
[ 403.118493] [810d8055] ? mark_held_locks+0x75/0xa0
[ 403.118497] [a005a6c3] vb2_fop_mmap+0x33/0x90 [videobuf2_core]
[ 403.118502] [a0022122]
Re: omap3isp with DM3730 not working?!
On Thu, Jul 31, 2014 at 2:31 PM, Michael Dietschi michael.diets...@inunum.com wrote: Am 31.07.2014 12:36, schrieb Enrico: I think you are missing the ccdc sink pad setup, basically you should have something like this: - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 pad1: Source [fmt:UYVY/720x576 field:interlaced-tb crop.bounds:(0,0)/720x288 crop:(0,0)/720x288] - OMAP3 ISP CCDC output:0 [ENABLED] - OMAP3 ISP resizer:0 [] pad1: Source [fmt:UYVY/720x240 field:alternate crop.bounds:(0,0)/720x240 crop:(0,0)/720x240] It seems you are missing this: media-ctl --set-format 'OMAP3 ISP CCDC:1 [UYVY 720x480 field:interlaced-tb]' and add --field interlaced-tb to yavta. Enrico -- 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
FW: Delivery Status Notification (Failure)
I'm trying to build the V4L-DVB drivers for an embedded system (OMAP3530/DM3730) that uses the 2.6.37 kernel. I'm using the build instructions from http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-D VB_Device_Drivers and am following the more manually intensive approach column. The first make crashes (make tar DIR=/home/me/mykernel) with missing file errors. It lists about 20 missing files such as include/linux/dma-buf.h and include/trace/events/v4l2.h. It doesn't look like those files show up in the kernel source until versions 3.3 and 3.14 respectively. What is the best approach to resolve the missing file errors for my 2.6.37 kernel and still have the drivers build and run? Thanks, Chris -- 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
Cross Compiling V4L-DVB Device Drivers for Older (2.6.37) Kernel
I'm trying to build the V4L-DVB drivers for an embedded system (OMAP3530/DM3730) that uses the 2.6.37 kernel. I'm using the build instructions from http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-D VB_Device_Drivers and am following the more manually intensive approach column. The first make crashes (make tar DIR=/home/me/mykernel) with missing file errors. It lists about 20 missing files such as include/linux/dma-buf.h and include/trace/events/v4l2.h. It doesn't look like those files show up in the kernel source until versions 3.3 and 3.14 respectively. What is the best approach to resolve the missing file errors for my 2.6.37 kernel and still have the drivers build and run? Thanks, Chris -- 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 05/28] gpu: ipu-v3: Add units required for video capture
Am Mittwoch, den 25.06.2014, 18:05 -0700 schrieb Steve Longerbeam:
Adds the following new IPU units:
- Camera Sensor Interface (csi)
- Image Converter (ic)
This patch should be split in two parts, IC and CSI.
[...]
+/*
+ * Enable error detection and correction for CCIR interlaced mode.
+ */
+static inline void ipu_csi_ccir_err_detection_enable(struct ipu_csi *csi)
+{
+ u32 temp;
+
+ temp = ipu_csi_read(csi, CSI_CCIR_CODE_1);
+ temp |= CSI_CCIR_ERR_DET_EN;
+ ipu_csi_write(csi, temp, CSI_CCIR_CODE_1);
+
+}
+
+/*
+ * Disable error detection and correction for CCIR interlaced mode.
+ */
+static inline void ipu_csi_ccir_err_detection_disable(struct ipu_csi *csi)
+{
+ u32 temp;
+
+ temp = ipu_csi_read(csi, CSI_CCIR_CODE_1);
+ temp = ~CSI_CCIR_ERR_DET_EN;
+ ipu_csi_write(csi, temp, CSI_CCIR_CODE_1);
+
+}
This is too complicated for my taste, can't we just set the flag when
CCIR_CODE_1 is written below and remove these two functions?
[...]
+int ipu_csi_init_interface(struct ipu_csi *csi, u16 width, u16 height,
+struct ipu_csi_signal_cfg *cfg)
+{
+ unsigned long flags;
+ u32 data = 0;
+ u32 ipu_clk;
ipu_clk is unused.
+
+ /* Set the CSI_SENS_CONF register remaining fields */
+ data |= cfg-data_width CSI_SENS_CONF_DATA_WIDTH_SHIFT |
+ cfg-data_fmt CSI_SENS_CONF_DATA_FMT_SHIFT |
Instead of having the user call ipu_csi_mbus_fmt_to_sig_cfg to fill
these fields, can't we just pass the mbus_code parameter directly and
calculate data_width and data_fmt inside ipu_csi_init_interface?
+ cfg-data_pol CSI_SENS_CONF_DATA_POL_SHIFT |
+ cfg-vsync_pol CSI_SENS_CONF_VSYNC_POL_SHIFT |
+ cfg-hsync_pol CSI_SENS_CONF_HSYNC_POL_SHIFT |
+ cfg-pixclk_pol CSI_SENS_CONF_PIX_CLK_POL_SHIFT |
Same for those, here I'd prefer we use v4l2_mbus_config.
+ cfg-ext_vsync CSI_SENS_CONF_EXT_VSYNC_SHIFT |
+ cfg-clk_mode CSI_SENS_CONF_SENS_PRTCL_SHIFT |
+ cfg-pack_tight CSI_SENS_CONF_PACK_TIGHT_SHIFT |
+ cfg-force_eof CSI_SENS_CONF_FORCE_EOF_SHIFT |
+ cfg-data_en_pol CSI_SENS_CONF_DATA_EN_POL_SHIFT;
+
+ ipu_clk = clk_get_rate(csi-clk_ipu);
ipu_clk is unused.
+ spin_lock_irqsave(csi-lock, flags);
+
+ ipu_csi_write(csi, data, CSI_SENS_CONF);
+
+ /* Setup sensor frame size */
+ ipu_csi_write(csi, (width - 1) | (height - 1) 16, CSI_SENS_FRM_SIZE);
+
+ /* Set CCIR registers */
+
+ switch (cfg-clk_mode) {
+ case IPU_CSI_CLK_MODE_CCIR656_PROGRESSIVE:
+ ipu_csi_write(csi, 0x40030, CSI_CCIR_CODE_1);
+ ipu_csi_write(csi, 0xFF, CSI_CCIR_CODE_3);
+ break;
+ case IPU_CSI_CLK_MODE_CCIR656_INTERLACED:
+ if (width == 720 height == 625) {
Shouldn't we also accept 576 lines here? I'd like to capture just the
visible frame.
+ /*
+ * PAL case
+ *
+ * Field0BlankEnd = 0x6, Field0BlankStart = 0x2,
+ * Field0ActiveEnd = 0x4, Field0ActiveStart = 0
+ * Field1BlankEnd = 0x7, Field1BlankStart = 0x3,
+ * Field1ActiveEnd = 0x5, Field1ActiveStart = 0x1
+ */
+ ipu_csi_write(csi, 0x40596, CSI_CCIR_CODE_1);
As mentioned above, you could just set CCIR_ERR_DET_EN here:
ccir1 = 0x40596 | CSI_CCIR_ERR_DET_EN;
ipu_csi_write(csi, ccir1, CSI_CCIR_CODE_1);
And using something like
#define CSI_CCIR_STRT_BLNK_1ST(x) (((x) 0x7) 0)
#define CSI_CCIR_END_BLNK_1ST(x)(((x) 0x7) 3)
#define CSI_CCIR_STRT_BLNK_2ND(x) (((x) 0x7) 6)
#define CSI_CCIR_END_BLNK_2ND(x)(((x) 0x7) 9)
#define CSI_CCIR_STRT_ACTV(x) (((x) 0x7) 16)
#define CSI_CCIR_END_ACTV(x)(((x) 0x7) 19)
instead of the hex-value + comment combination would better document
where which bit fields actually are.
+ ipu_csi_write(csi, 0xD07DF, CSI_CCIR_CODE_2);
+ ipu_csi_write(csi, 0xFF, CSI_CCIR_CODE_3);
The TRM says CSI_CCIR_PRECOM is bits [29:0], and [31:30] are reserved /
read-only / always zero. Also, for BT.656 bits [29:24] are ignored. Did
you investigate whether this value is correct?
+
+ } else if (width == 720 height == 525) {
As above, shouldn't we also accept 480 lines here?
+ /*
+ * NTSC case
+ *
+ * Field0BlankEnd = 0x7, Field0BlankStart = 0x3,
+ * Field0ActiveEnd = 0x5, Field0ActiveStart = 0x1
+ * Field1BlankEnd = 0x6, Field1BlankStart = 0x2,
+ * Field1ActiveEnd = 0x4, Field1ActiveStart = 0
+ */
+ ipu_csi_write(csi, 0xD07DF, CSI_CCIR_CODE_1);
+
Re: [PATCH 01/28] ARM: dts: imx6qdl: Add ipu aliases
Am Mittwoch, den 25.06.2014, 18:05 -0700 schrieb Steve Longerbeam:
Add ipu0 (and ipu1 for quad) aliases to ipu1/ipu2 nodes respectively.
Signed-off-by: Steve Longerbeam steve_longerb...@mentor.com
Acked-by: Philipp Zabel p.za...@pengutronix.de
---
arch/arm/boot/dts/imx6q.dtsi |1 +
arch/arm/boot/dts/imx6qdl.dtsi |1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index addd3f8..fcfbac2 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -14,6 +14,7 @@
/ {
aliases {
+ ipu1 = ipu2;
spi4 = ecspi5;
};
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index ce05991..3b3d8fe 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -29,6 +29,7 @@
i2c0 = i2c1;
i2c1 = i2c2;
i2c2 = i2c3;
+ ipu0 = ipu1;
mmc0 = usdhc1;
mmc1 = usdhc2;
mmc2 = usdhc3;
I think Shawn (added to Cc:) should take this patch separately, please
consider sending it to him.
regards
Philipp
--
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 02/28] gpu: ipu-v3: Add ipu_get_num()
Am Mittwoch, den 25.06.2014, 18:05 -0700 schrieb Steve Longerbeam:
Adds of-alias id to ipu_soc and retrieve with ipu_get_num().
ipu_get_num() is used to select inputs to CSI units in IOMUXC.
It is also used to select an SMFC channel for video capture.
I still don't see the use of this. The IOMUXC multiplexing will be
handled outside of the IPU driver, and why would SMFC channel allocation
be different for the two IPUs? I'd say let's drop this for now.
regards
Philipp
Signed-off-by: Steve Longerbeam steve_longerb...@mentor.com
---
drivers/gpu/ipu-v3/ipu-common.c |8
drivers/gpu/ipu-v3/ipu-prv.h|1 +
include/video/imx-ipu-v3.h |5 +
3 files changed, 14 insertions(+)
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 04e7b2e..a92f48b 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -55,6 +55,12 @@ static inline void ipu_idmac_write(struct ipu_soc *ipu,
u32 value,
writel(value, ipu-idmac_reg + offset);
}
+int ipu_get_num(struct ipu_soc *ipu)
+{
+ return ipu-id;
+}
+EXPORT_SYMBOL_GPL(ipu_get_num);
+
void ipu_srm_dp_sync_update(struct ipu_soc *ipu)
{
u32 val;
@@ -1205,6 +1211,7 @@ static int ipu_probe(struct platform_device *pdev)
{
const struct of_device_id *of_id =
of_match_device(imx_ipu_dt_ids, pdev-dev);
+ struct device_node *np = pdev-dev.of_node;
struct ipu_soc *ipu;
struct resource *res;
unsigned long ipu_base;
@@ -1233,6 +1240,7 @@ static int ipu_probe(struct platform_device *pdev)
ipu-channel[i].ipu = ipu;
ipu-devtype = devtype;
ipu-ipu_type = devtype-type;
+ ipu-id = of_alias_get_id(np, ipu);
spin_lock_init(ipu-lock);
mutex_init(ipu-channel_lock);
diff --git a/drivers/gpu/ipu-v3/ipu-prv.h b/drivers/gpu/ipu-v3/ipu-prv.h
index c93f50e..55ae20c 100644
--- a/drivers/gpu/ipu-v3/ipu-prv.h
+++ b/drivers/gpu/ipu-v3/ipu-prv.h
@@ -166,6 +166,7 @@ struct ipu_soc {
void __iomem*idmac_reg;
struct ipu_ch_param __iomem *cpmem_base;
+ int id;
int usecount;
struct clk *clk;
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index 3e43e22..739d204 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -93,6 +93,11 @@ int ipu_idmac_channel_irq(struct ipu_soc *ipu, struct
ipuv3_channel *channel,
#define IPU_IRQ_VSYNC_PRE_1 (448 + 15)
/*
+ * IPU Common functions
+ */
+int ipu_get_num(struct ipu_soc *ipu);
+
+/*
* IPU Image DMA Controller (idmac) functions
*/
struct ipuv3_channel *ipu_idmac_get(struct ipu_soc *ipu, unsigned channel);
--
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 05/28] gpu: ipu-v3: Add units required for video capture
Sorry about the near full-quote, this mail was sent prematurely as I just learned Evolution does send mail on Ctrl+Enter. I'll continue this later. regards Philipp -- 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 00/28] IPUv3 prep for video capture
Hi Steve, Am Mittwoch, den 25.06.2014, 18:05 -0700 schrieb Steve Longerbeam: Hi Philip, Sascha, Here is a rebased set of IPU patches that prepares for video capture support. Video capture is not included in this set. I've addressed all your IPU-specific concerns from the previous patch set, the major ones being: - the IOMUXC control for CSI input selection has been removed. This should be part of a future CSI media entity driver. - the ipu-irt unit has been removed. Enabling the IRT module is folded into ipu-ic unit. The ipu-ic unit is also cleaned up a bit. - the ipu-csi APIs are consolidated/simplified. - added CSI and IC base offsets for i.MX51/i.MX53. Sorry for the delay, I have only now started to look at the IPU again in detail, and I still have a few comments. I'll reply to the individual patches. regards Philipp -- 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: omap3isp with DM3730 not working?!
Am 31.07.2014 15:15, schrieb Enrico: It seems you are missing this: media-ctl --set-format 'OMAP3 ISP CCDC:1 [UYVY 720x480 field:interlaced-tb]' and add --field interlaced-tb to yavta. Enrico Yippieh! It seems to work now - At least I am getting an file... If it is a nice image will be determined tomorrow! Thank you for the help, Michael -- 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/2] [media] V4L: Add camera pan/tilt speed controls
ping ...
Any opinion on adding those new controls ? since re-using the existing
relative ones was seen as too twisted.
Thanks,
--
Vincent
On Tue, Jul 8, 2014 at 4:49 PM, Vincent Palatin vpala...@chromium.org wrote:
The V4L2_CID_PAN_SPEED and V4L2_CID_TILT_SPEED controls allow to move the
camera by setting its rotation speed around its axis.
Signed-off-by: Vincent Palatin vpala...@chromium.org
---
Documentation/DocBook/media/v4l/compat.xml | 10 ++
Documentation/DocBook/media/v4l/controls.xml | 21 +
drivers/media/v4l2-core/v4l2-ctrls.c | 2 ++
include/uapi/linux/v4l2-controls.h | 2 ++
4 files changed, 35 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/compat.xml
b/Documentation/DocBook/media/v4l/compat.xml
index eee6f0f..21910e9 100644
--- a/Documentation/DocBook/media/v4l/compat.xml
+++ b/Documentation/DocBook/media/v4l/compat.xml
@@ -2545,6 +2545,16 @@ fields changed from _s32 to _u32.
/orderedlist
/section
+section
+ titleV4L2 in Linux 3.17/title
+ orderedlist
+ listitem
+ paraAdded constantV4L2_CID_PAN_SPEED/constant and
+ constantV4L2_CID_TILT_SPEED/constant camera controls./para
+ /listitem
+ /orderedlist
+/section
+
section id=other
titleRelation of V4L2 to other Linux multimedia APIs/title
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index 47198ee..cdf97f0 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -3914,6 +3914,27 @@ by exposure, white balance or focus controls./entry
/row
rowentry/entry/row
+ row
+ entry
spanname=idconstantV4L2_CID_PAN_SPEED/constantnbsp;/entry
+ entryinteger/entry
+ /rowrowentry spanname=descrThis control turns the
+camera horizontally at the specific speed. The unit is undefined. A
+positive value moves the camera to the right (clockwise when viewed
+from above), a negative value to the left. A value of zero does not
+cause or stop the motion./entry
+ /row
+ rowentry/entry/row
+
+ row
+ entry
spanname=idconstantV4L2_CID_TILT_SPEED/constantnbsp;/entry
+ entryinteger/entry
+ /rowrowentry spanname=descrThis control turns the
+camera vertically at the specified speed. The unit is undefined. A
+positive value moves the camera up, a negative value down. A value of
+zero does not cause or stop the motion./entry
+ /row
+ rowentry/entry/row
+
/tbody
/tgroup
/table
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 55c6832..57ddaf4 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -787,6 +787,8 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_AUTO_FOCUS_STOP: return Auto Focus, Stop;
case V4L2_CID_AUTO_FOCUS_STATUS:return Auto Focus, Status;
case V4L2_CID_AUTO_FOCUS_RANGE: return Auto Focus, Range;
+ case V4L2_CID_PAN_SPEED:return Pan, Speed;
+ case V4L2_CID_TILT_SPEED: return Tilt, Speed;
/* FM Radio Modulator control */
/* Keep the order of the 'case's the same as in videodev2.h! */
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 2ac5597..5576044 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -745,6 +745,8 @@ enum v4l2_auto_focus_range {
V4L2_AUTO_FOCUS_RANGE_INFINITY = 3,
};
+#define V4L2_CID_PAN_SPEED
(V4L2_CID_CAMERA_CLASS_BASE+32)
+#define V4L2_CID_TILT_SPEED
(V4L2_CID_CAMERA_CLASS_BASE+33)
/* FM Modulator class control IDs */
--
2.0.0.526.g5318336
--
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 05/28] gpu: ipu-v3: Add units required for video capture
Am Donnerstag, den 31.07.2014, 17:27 +0200 schrieb Philipp Zabel:
+static void init_csc_rgb2ycbcr(u32 __iomem *base)
+{
+ /*
+* Y = R * .299 + G * .587 + B * .114;
+* U = R * -.169 + G * -.332 + B * .500 + 128.;
+* V = R * .500 + G * -.419 + B * -.0813 + 128.;
+*/
+ const u32 coeff[4][3] = {
+ {0x004D, 0x0096, 0x001D},
+ {0x01D5, 0x01AB, 0x0080},
+ {0x0080, 0x0195, 0x01EB},
+ {0x, 0x0200, 0x0200}, /* A0, A1, A2 */
+ };
+ u32 param;
+
+ param = (coeff[3][0] 27) | (coeff[0][0] 18) |
+ (coeff[1][1] 9) | coeff[2][2];
+ writel(param, base++);
+
+ /* scale = 1, sat = 0 */
+ param = (coeff[3][0] 5) | (1UL 8);
+ writel(param, base++);
+
+ param = (coeff[3][1] 27) | (coeff[0][1] 18) |
+ (coeff[1][0] 9) | coeff[2][0];
+ writel(param, base++);
+
+ param = (coeff[3][1] 5);
+ writel(param, base++);
+
+ param = (coeff[3][2] 27) | (coeff[0][2] 18) |
+ (coeff[1][2] 9) | coeff[2][1];
+ writel(param, base++);
+
+ param = (coeff[3][2] 5);
+ writel(param, base++);
+}
+
+static void init_csc_rgb2rgb(u32 __iomem *base)
+{
+ /* transparent RGB-RGB matrix for graphics combining */
+ const u32 coeff[4][3] = {
+ {0x0080, 0x, 0x},
+ {0x, 0x0080, 0x},
+ {0x, 0x, 0x0080},
+ {0x, 0x, 0x}, /* A0, A1, A2 */
+ };
+ u32 param;
+
+ param = (coeff[3][0] 27) | (coeff[0][0] 18) |
+ (coeff[1][1] 9) | coeff[2][2];
+ writel(param, base++);
+
+ /* scale = 2, sat = 0 */
+ param = (coeff[3][0] 5) | (2UL 8);
+ writel(param, base++);
+
+ param = (coeff[3][1] 27) | (coeff[0][1] 18) |
+ (coeff[1][0] 9) | coeff[2][0];
+ writel(param, base++);
+
+ param = (coeff[3][1] 5);
+ writel(param, base++);
+
+ param = (coeff[3][2] 27) | (coeff[0][2] 18) |
+ (coeff[1][2] 9) | coeff[2][1];
+ writel(param, base++);
+
+ param = (coeff[3][2] 5);
+ writel(param, base++);
+}
+
+static void init_csc_ycbcr2rgb(u32 __iomem *base)
+{
+ /*
+* R = (1.164 * (Y - 16)) + (1.596 * (Cr - 128));
+* G = (1.164 * (Y - 16)) - (0.392 * (Cb - 128)) - (0.813 * (Cr - 128));
+* B = (1.164 * (Y - 16)) + (2.017 * (Cb - 128);
+*/
+ const u32 coeff[4][3] = {
+ {149, 0, 204},
+ {149, 462, 408},
+ {149, 255, 0},
+ {8192 - 446, 266, 8192 - 554}, /* A0, A1, A2 */
+ };
+ u32 param;
+
+ param = (coeff[3][0] 27) | (coeff[0][0] 18) |
+ (coeff[1][1] 9) | coeff[2][2];
+ writel(param, base++);
+
+ /* scale = 2, sat = 0 */
+ param = (coeff[3][0] 5) | (2L (40 - 32));
+ writel(param, base++);
+
+ param = (coeff[3][1] 27) | (coeff[0][1] 18) |
+ (coeff[1][0] 9) | coeff[2][0];
+ writel(param, base++);
+
+ param = (coeff[3][1] 5);
+ writel(param, base++);
+
+ param = (coeff[3][2] 27) | (coeff[0][2] 18) |
+ (coeff[1][2] 9) | coeff[2][1];
+ writel(param, base++);
+
+ param = (coeff[3][2] 5);
+ writel(param, base++);
+}
Instead of repeating the same code three times, we could have three
global static const arrays for coefficients and scaling factors, and
only one function to apply any of them (or merge the code into
init_csc).
[...]
+static int calc_resize_coeffs(struct ipu_ic *ic,
+ u32 in_size, u32 out_size,
+ u32 *resize_coeff,
+ u32 *downsize_coeff)
+{
+ struct ipu_ic_priv *priv = ic-priv;
+ struct ipu_soc *ipu = priv-ipu;
+ u32 temp_size, temp_downsize;
+
+ /*
+* Input size cannot be more than 4096, and output size cannot
+* be more than 1024
+*/
+ if (in_size 4096) {
+ dev_err(ipu-dev, Unsupported resize (in_size 4096)\n);
+ return -EINVAL;
+ }
+ if (out_size 1024) {
+ dev_err(ipu-dev, Unsupported resize (out_size 1024)\n);
+ return -EINVAL;
+ }
+
+ /* Cannot downsize more than 8:1 */
+ if ((out_size 3) in_size) {
+ dev_err(ipu-dev, Unsupported downsize\n);
+ return -EINVAL;
+ }
+
+ /* Compute downsizing coefficient */
+ temp_downsize = 0;
+ temp_size = in_size;
+ while (((temp_size 1024) || (temp_size = out_size * 2))
+ (temp_downsize 2)) {
+ temp_size = 1;
+ temp_downsize++;
+ }
+ *downsize_coeff = temp_downsize;
+
+ /*
+* compute resizing coefficient using the following equation:
+* resize_coeff = M * (SI - 1) / (SO - 1)
+* where M = 2^13, SI = input size, SO = output size
+*/
+ *resize_coeff = (8192L * (temp_size - 1)) / (out_size - 1);
Re: [PATCH 27/28] gpu: ipu-cpmem: Add ipu_cpmem_dump()
Am Mittwoch, den 25.06.2014, 18:05 -0700 schrieb Steve Longerbeam: Adds ipu_cpmem_dump() which dumps a channel's cpmem to debug. Maybe #ifdef DEBUG this and ipu_dump? regards Philipp -- 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 16/28] gpu: ipu-v3: Add ipu_stride_to_bytes()
Am Mittwoch, den 25.06.2014, 18:05 -0700 schrieb Steve Longerbeam: Adds ipu_stride_to_bytes(), which converts a pixel stride to bytes, suitable for passing to cpmem. This is not IPU specific. You already have the bytesperline information from the V4L2 driver or have to calculate it there, and that shouldn't be done by calling into IPU core code. regards Philipp -- 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: [PATCHv1 02/12] vivid.txt: add documentation for the vivid driver.
On Wed, 2014-07-30 at 16:23 +0200, Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com The vivid Virtual Video Test Driver helps testing V4L2 applications and can emulate V4L2 hardware. Add the documentation for this driver first. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/video4linux/vivid.txt | 1108 +++ 1 file changed, 1108 insertions(+) create mode 100644 Documentation/video4linux/vivid.txt diff --git a/Documentation/video4linux/vivid.txt b/Documentation/video4linux/vivid.txt new file mode 100644 index 000..2dc7354 --- /dev/null +++ b/Documentation/video4linux/vivid.txt @@ -0,0 +1,1108 @@ +vivid: Virtual Video Test Driver + + +Section 8: Software Defined Radio Receiver +-- + +The SDR receiver has three frequency bands for the ADC tuner: + + - 300 kHz + - 900 kHz - 2800 kHz + - 3200 kHz + +The RF tuner supports 50 MHz - 2000 MHz. + +The generated data contains sinus and cosinus signals. + In (American) English the names are sine and cosine for sin(x) and cos(x). Maybe say: The generated data contains the In-phase and Quadrature components of a 1 kHz tone that has an amplitude of sqrt(2). FWIW, the signals are the In-phase and Quadrature components of the signal A*cos(2*pi*f + phi), where f = 1 kHz, A = sqrt(2), and phi = -pi/4 + +Section 15: Some Future Improvements + + +Just as a reminder and in no particular order: + +- Add a virtual alsa driver to test audio +- Add virtual sub-devices and media controller support +- Some support for testing compressed video +- Add support to loop raw VBI output to raw VBI input +- Fix sequence/field numbering when looping of video with alternate fields +- Add support for V4L2_CID_BG_COLOR for video outputs +- Add ARGB888 overlay support: better testing of the alpha channel +- Add custom DV timings support +- Add support for V4L2_DV_FL_REDUCED_FPS +- Improve pixel aspect support in the tpg code by passing a real v4l2_fract +- Use per-queue locks and/or per-device locks to improve throughput +- Add support to loop from a specific output to a specific input across + vivid instances +- Add support for VIDIOC_EXPBUF once support for that has been added to vb2 +- The SDR radio should use the same 'frequencies' for stations as the normal + radio receiver, and give back noise if the frequency doesn't match up with + a station frequency +- Improve the sinus generation of the SDR radio. Maybe a lookup table, containing the first quarter wave of cos() from 0 to pi/2 in pi/200 steps, and then linear interpolation for cos() of angles in between those steps. You could go with a larger lookup table with finer grained steps to reduce the approximation errors. A lookup table with linear interpolation, I would think, requires fewer mutliplies and divides than the current Taylor expansion computation. +- Make a thread for the RDS generation, that would help in particular for the + Controls RDS Rx I/O Mode as the read-only RDS controls could be updated + in real-time. Regards, Andy -- 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 3/4] cxd2843: Sony CXD2843 DVB-C/C2/T/T2 demodulator driver
Sony CXD2843 DVB-C/C2/T/T2 demodulator driver.
Driver taken from Digital Devices Linux driver package
dddvb-0.9.15a.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/Kconfig |8 +
drivers/media/dvb-frontends/Makefile |1 +
drivers/media/dvb-frontends/cxd2843.c | 2025 +
drivers/media/dvb-frontends/cxd2843.h | 30 +
4 files changed, 2064 insertions(+)
create mode 100644 drivers/media/dvb-frontends/cxd2843.c
create mode 100644 drivers/media/dvb-frontends/cxd2843.h
diff --git a/drivers/media/dvb-frontends/Kconfig
b/drivers/media/dvb-frontends/Kconfig
index fe0ddcc..5475f59 100644
--- a/drivers/media/dvb-frontends/Kconfig
+++ b/drivers/media/dvb-frontends/Kconfig
@@ -72,6 +72,14 @@ config DVB_SI2165
Say Y when you want to support this frontend.
+config DVB_CXD2843
+ tristate Sony CXD2843
+ depends on DVB_CORE I2C
+ default m if !MEDIA_SUBDRV_AUTOSELECT
+ help
+ Sony CXD2843 DVB-C/C2/T/T2 demodulator driver.
+ Say Y when you want to support this frontend.
+
comment DVB-S (satellite) frontends
depends on DVB_CORE
diff --git a/drivers/media/dvb-frontends/Makefile
b/drivers/media/dvb-frontends/Makefile
index edf103d..9a9f131 100644
--- a/drivers/media/dvb-frontends/Makefile
+++ b/drivers/media/dvb-frontends/Makefile
@@ -103,6 +103,7 @@ obj-$(CONFIG_DVB_MB86A20S) += mb86a20s.o
obj-$(CONFIG_DVB_IX2505V) += ix2505v.o
obj-$(CONFIG_DVB_STV0367) += stv0367.o
obj-$(CONFIG_DVB_CXD2820R) += cxd2820r.o
+obj-$(CONFIG_DVB_CXD2843) += cxd2843.o
obj-$(CONFIG_DVB_DRXK) += drxk.o
obj-$(CONFIG_DVB_TDA18271C2DD) += tda18271c2dd.o
obj-$(CONFIG_DVB_SI2165) += si2165.o
diff --git a/drivers/media/dvb-frontends/cxd2843.c
b/drivers/media/dvb-frontends/cxd2843.c
new file mode 100644
index 000..10fc240
--- /dev/null
+++ b/drivers/media/dvb-frontends/cxd2843.c
@@ -0,0 +1,2025 @@
+/*
+ * Driver for the Sony CXD2843ER DVB-T/T2/C/C2 demodulator.
+ * Also supports the CXD2837ER DVB-T/T2/C and the
+ * CXD2838ER ISDB-T demodulator.
+ *
+ * Copyright (C) 2013-2014 Digital Devices GmbH
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 only, as published by the Free Software Foundation.
+ *
+ *
+ * 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
+ * Or, point your browser to http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/moduleparam.h
+#include linux/init.h
+#include linux/delay.h
+#include linux/firmware.h
+#include linux/i2c.h
+#include linux/version.h
+#include linux/mutex.h
+#include asm/div64.h
+
+#include dvb_frontend.h
+#include cxd2843.h
+
+#define USE_ALGO 1
+
+enum EDemodType { CXD2843, CXD2837, CXD2838 };
+enum EDemodState { Unknown, Shutdown, Sleep, ActiveT,
+ ActiveT2, ActiveC, ActiveC2, ActiveIT };
+enum ET2Profile { T2P_Base, T2P_Lite };
+enum omode { OM_NONE, OM_DVBT, OM_DVBT2, OM_DVBC,
+OM_QAM_ITU_C, OM_DVBC2, OM_ISDBT };
+
+struct cxd_state {
+ struct dvb_frontend frontend;
+ struct i2c_adapter *i2c;
+ struct mutex mutex;
+
+ u8 adrt;
+ u8 curbankt;
+
+ u8 adrx;
+ u8 curbankx;
+
+ enum EDemodType type;
+ enum EDemodState state;
+ enum ET2Profile T2Profile;
+ enum omode omode;
+
+ u8IF_FS;
+ int ContinuousClock;
+ int SerialMode;
+ u8SerialClockFrequency;
+
+ u32 LockTimeout;
+ u32 TSLockTimeout;
+ u32 L1PostTimeout;
+ u32 DataSliceID;
+ int FirstTimeLock;
+ u32 plp;
+ u32 last_status;
+
+ u32 bandwidth;
+ u32 bw;
+
+ unsigned long tune_time;
+
+ u32 LastBERNominator;
+ u32 LastBERDenominator;
+ u8BERScaleMax;
+};
+
+static int i2c_write(struct i2c_adapter *adap, u8 adr, u8 *data, int len)
+{
+ struct i2c_msg msg = {
+ .addr = adr, .flags = 0, .buf = data, .len = len};
+
+ if (i2c_transfer(adap, msg, 1) != 1) {
+ pr_err(cxd2843: i2c_write error\n);
+ return -1;
+ }
+ return 0;
+}
+
+static int writeregs(struct cxd_state *state, u8 adr, u8 reg,
+u8 *regd, u16 len)
+{
+ u8 data[len + 1];
+
+ data[0] = reg;
+ memcpy(data + 1, regd, len);
+ return i2c_write(state-i2c, adr, data, len + 1);
+}
+
+static int writereg(struct cxd_state *state, u8 adr, u8
[PATCH 4/4] ddbridge: add support for DVB-C/C2/T/T2 extension card
Add support for DD DuoFlex C/C2/T/T2 Expansion card. These are for
card revision that has Sony CXD2843ER, CXD2837ER or CXD2838ER
ISDB-T demodulator.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/pci/ddbridge/Kconfig | 2 +
drivers/media/pci/ddbridge/ddbridge-core.c | 127 +
drivers/media/pci/ddbridge/ddbridge.h | 3 +
3 files changed, 132 insertions(+)
diff --git a/drivers/media/pci/ddbridge/Kconfig
b/drivers/media/pci/ddbridge/Kconfig
index 44e5dc1..15f33a2 100644
--- a/drivers/media/pci/ddbridge/Kconfig
+++ b/drivers/media/pci/ddbridge/Kconfig
@@ -6,6 +6,8 @@ config DVB_DDBRIDGE
select DVB_STV090x if MEDIA_SUBDRV_AUTOSELECT
select DVB_DRXK if MEDIA_SUBDRV_AUTOSELECT
select DVB_TDA18271C2DD if MEDIA_SUBDRV_AUTOSELECT
+ select DVB_CXD2843 if MEDIA_SUBDRV_AUTOSELECT
+ select MEDIA_TUNER_TDA18212 if MEDIA_SUBDRV_AUTOSELECT
---help---
Support for cards with the Digital Devices PCI express bridge:
- Octopus PCIe Bridge
diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c
b/drivers/media/pci/ddbridge/ddbridge-core.c
index da8f848..9f5837f 100644
--- a/drivers/media/pci/ddbridge/ddbridge-core.c
+++ b/drivers/media/pci/ddbridge/ddbridge-core.c
@@ -43,6 +43,8 @@
#include stv090x.h
#include lnbh24.h
#include drxk.h
+#include cxd2843.h
+#include tda18212.h
DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
@@ -78,6 +80,21 @@ static int i2c_read_reg16(struct i2c_adapter *adapter, u8
adr,
return (i2c_transfer(adapter, msgs, 2) == 2) ? 0 : -1;
}
+static int i2c_write(struct i2c_adapter *adap, u8 adr, u8 *data, int len)
+{
+ struct i2c_msg msg = {.addr = adr, .flags = 0,
+ .buf = data, .len = len};
+
+ return (i2c_transfer(adap, msg, 1) == 1) ? 0 : -1;
+}
+
+static int i2c_write_reg(struct i2c_adapter *adap, u8 adr, u8 reg, u8 val)
+{
+ u8 msg[2] = {reg, val};
+
+ return i2c_write(adap, adr, msg, 2);
+}
+
static int ddb_i2c_cmd(struct ddb_i2c *i2c, u32 adr, u32 cmd)
{
struct ddb *dev = i2c-dev;
@@ -592,6 +609,30 @@ static int demod_attach_drxk(struct ddb_input *input)
return 0;
}
+static int demod_attach_cxd2843(struct ddb_input *input)
+{
+ struct i2c_adapter *i2c = input-port-i2c-adap;
+ struct dvb_frontend *fe;
+ struct cxd2843_cfg cxd2843_0 = {
+ .adr = 0x6c,
+ };
+ struct cxd2843_cfg cxd2843_1 = {
+ .adr = 0x6d,
+ };
+
+ fe = input-fe = dvb_attach(cxd2843_attach, i2c,
+ (input-nr 1) ?
+ cxd2843_1 : cxd2843_0);
+ if (!input-fe) {
+ pr_err(No cxd2837/38/43 found!\n);
+ return -ENODEV;
+ }
+ fe-sec_priv = input;
+ input-gate_ctrl = fe-ops.i2c_gate_ctrl;
+ fe-ops.i2c_gate_ctrl = drxk_gate_ctrl;
+ return 0;
+}
+
static int tuner_attach_tda18271(struct ddb_input *input)
{
struct i2c_adapter *i2c = input-port-i2c-adap;
@@ -609,6 +650,47 @@ static int tuner_attach_tda18271(struct ddb_input *input)
return 0;
}
+static struct tda18212_config tda18212_config_60 = {
+ .i2c_address = 0x60,
+ .if_dvbt_6 = 3550,
+ .if_dvbt_7 = 3700,
+ .if_dvbt_8 = 4150,
+ .if_dvbt2_6 = 3250,
+ .if_dvbt2_7 = 4000,
+ .if_dvbt2_8 = 4000,
+ .if_dvbc = 5000,
+};
+
+static struct tda18212_config tda18212_config_63 = {
+ .i2c_address = 0x63,
+ .if_dvbt_6 = 3550,
+ .if_dvbt_7 = 3700,
+ .if_dvbt_8 = 4150,
+ .if_dvbt2_6 = 3250,
+ .if_dvbt2_7 = 4000,
+ .if_dvbt2_8 = 4000,
+ .if_dvbc = 5000,
+};
+
+static int tuner_attach_tda18212(struct ddb_input *input)
+{
+ struct i2c_adapter *i2c = input-port-i2c-adap;
+ struct dvb_frontend *fe;
+ struct tda18212_config *config;
+
+ if (input-nr 1)
+ config = tda18212_config_63;
+ else
+ config = tda18212_config_60;
+
+ fe = dvb_attach(tda18212_attach, input-fe, i2c, config);
+ if (!fe) {
+ pr_err(No TDA18212 found!\n);
+ return -ENODEV;
+ }
+ return 0;
+}
+
/**/
/**/
/**/
@@ -887,6 +969,18 @@ static int dvb_input_attach(struct ddb_input *input)
sizeof(struct dvb_tuner_ops));
}
break;
+ case DDB_TUNER_DVBCT2_SONY:
+ case DDB_TUNER_DVBC2T2_SONY:
+ case DDB_TUNER_ISDBT_SONY:
+ if (demod_attach_cxd2843(input) 0)
+ return -ENODEV;
+ if (tuner_attach_tda18212(input) 0)
+ return -ENODEV;
+ if
[PATCH 1/4] tda18212: add support for slave chip version
There is 2 different versions of that chip available, master and
slave. Slave is used only on dual tuner devices with master tuner.
Laser printing top of chip is 18212/M or 18212/S according to chip
version.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/tuners/tda18212.c | 31 ++-
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/drivers/media/tuners/tda18212.c b/drivers/media/tuners/tda18212.c
index 05a4ac9..15b09f8 100644
--- a/drivers/media/tuners/tda18212.c
+++ b/drivers/media/tuners/tda18212.c
@@ -306,7 +306,8 @@ struct dvb_frontend *tda18212_attach(struct dvb_frontend
*fe,
{
struct tda18212_priv *priv = NULL;
int ret;
- u8 val;
+ u8 chip_id = chip_id;
+ char *version;
priv = kzalloc(sizeof(struct tda18212_priv), GFP_KERNEL);
if (priv == NULL)
@@ -320,26 +321,38 @@ struct dvb_frontend *tda18212_attach(struct dvb_frontend
*fe,
fe-ops.i2c_gate_ctrl(fe, 1); /* open I2C-gate */
/* check if the tuner is there */
- ret = tda18212_rd_reg(priv, 0x00, val);
+ ret = tda18212_rd_reg(priv, 0x00, chip_id);
+ dev_dbg(priv-i2c-dev, %s: chip_id=%02x\n, __func__, chip_id);
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 0); /* close I2C-gate */
- if (!ret)
- dev_dbg(priv-i2c-dev, %s: chip id=%02x\n, __func__, val);
- if (ret || val != 0xc7) {
- kfree(priv);
- return NULL;
+ if (ret)
+ goto err;
+
+ switch (chip_id) {
+ case 0xc7:
+ version = M; /* master */
+ break;
+ case 0x47:
+ version = S; /* slave */
+ break;
+ default:
+ goto err;
}
dev_info(priv-i2c-dev,
- %s: NXP TDA18212HN successfully identified\n,
- KBUILD_MODNAME);
+ %s: NXP TDA18212HN/%s successfully identified\n,
+ KBUILD_MODNAME, version);
memcpy(fe-ops.tuner_ops, tda18212_tuner_ops,
sizeof(struct dvb_tuner_ops));
return fe;
+err:
+ dev_dbg(i2c-dev, %s: failed=%d\n, __func__, ret);
+ kfree(priv);
+ return NULL;
}
EXPORT_SYMBOL(tda18212_attach);
--
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 2/4] uapi: dvb: initial support for DVB-C2 standard
Just add delivery system for DVB-C2 standard. Other parameters
should be added later.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
include/uapi/linux/dvb/frontend.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/dvb/frontend.h
b/include/uapi/linux/dvb/frontend.h
index c56d77c..98648eb 100644
--- a/include/uapi/linux/dvb/frontend.h
+++ b/include/uapi/linux/dvb/frontend.h
@@ -410,6 +410,7 @@ typedef enum fe_delivery_system {
SYS_DVBT2,
SYS_TURBO,
SYS_DVBC_ANNEX_C,
+ SYS_DVBC2,
} fe_delivery_system_t;
/* backward compatibility */
--
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
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: Fri Aug 1 04:00:16 CEST 2014 git branch: test git hash: 27dcb00d0dc1d532b0da940e35a6d020ee33bd47 gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-16-g1db35d0 host hardware: x86_64 host os:3.15-5.slh.2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16-rc1-i686: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16-rc1-x86_64: OK apps: WARNINGS spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.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
tvtuner pixelview B1000
hello. I have pixelview B1000 card and this card won't work with assigned modules cx8800, cx8802. May be I'm use wrong modules or cardid prefix: 1554:4952, board: PixelView [card=3... # /usr/bin/tvtime-scanner Reading configuration from /etc/tvtime/tvtime.xml Scanning using TV standard NTSC. Scanning from 44.00 MHz to 958.00 MHz. MHz: - No signal === 01:06.0 Multimedia video controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder (rev 05) Subsystem: PROLINK Microsystems Corp Device 4952 Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at fd00 (32-bit, non-prefetchable) [size=16M] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 Kernel modules: cx8800 01:06.1 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [Audio Port] (rev 05) Subsystem: PROLINK Microsystems Corp Device 4952 Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at fc00 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 Kernel modules: cx88-alsa 01:06.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] (rev 05) Subsystem: PROLINK Microsystems Corp Device 4952 Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at fb00 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 Kernel modules: cx8802 === [18334.495349] Linux video capture interface: v2.00 [18334.603004] IR NEC protocol handler initialized [18334.614074] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.8 loaded [18334.618258] cx88[0]: subsystem: 1554:4952, board: PixelView [card=3,autodetected], frontend(s): 0 [18334.618263] cx88[0]: TV tuner type 5, Radio tuner type -1 [18334.628915] IR RC5(x) protocol handler initialized [18334.660809] IR RC6 protocol handler initialized [18334.687047] IR JVC protocol handler initialized [18334.714899] IR Sony protocol handler initialized [18334.754031] lirc_dev: IR Remote Control driver registered, major 252 [18334.764669] IR LIRC bridge handler initialized [18334.850358] cx88[0]/2: cx2388x 8802 Driver Manager [18343.108212] cx88/0: cx2388x v4l2 driver version 0.0.8 loaded [18343.108317] cx8800 :01:06.0: PCI INT A - GSI 20 (level, low) - IRQ 20 [18343.112467] cx88[0]: subsystem: 1554:4952, board: PixelView [card=3,autodetected], frontend(s): 0 [18343.112473] cx88[0]: TV tuner type 5, Radio tuner type -1 [18343.312410] cx88[0]/0: found at :01:06.0, rev: 5, irq: 20, latency: 32, mmio: 0xfd00 [18343.316831] cx88[0]/0: registered device video0 [v4l2] [18343.326623] cx88[0]/0: registered device vbi0 [18343.333136] cx88[0]/0: registered device radio0 -- 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: ddbridge -- kernel 3.15.6
On Do, 2014-07-31 at 09:38 +0200, Ralph Metzler wrote: Bjoern writes: I don't know anything about any old or new style. Digital Devices did not submit any changes to the kernel tree. Why does that not happen? Wouldn't it be easier for your consumers? Plug in your card and voila, it works out of the box? But fine, Oliver indeed has done some attempts there it seems. Oliver Endriss did and afterwards some strange things happened. That something changed in V4L I found here (after I bought the devices): http://linuxtv.org/wiki/index.php/Digital_Devices_DuoFlex_C%26T E.g. the CI driver (cxd2099) is still in staging for no valid reason. The reasons given apply only to ddbridge. Why isn't ddbridge in staging? What are the reasons? And if that is the case - _who is responsible_ for this still being in staging? Then we can ask that person what is going on - if there is no reason then that is bad and wrong. And I hope there is not only one single person who decides what leaves staging, some backup should be around I hope? It is not like drivers are not available and supported, just not in the mainline kernel tree. Right... and I hope that can be changed. I really really like the DD hardware I have, but always having to rebuild everything with a new kernel is just not my idea of how hardware should run in 2014 on Linux anymore. Regards, Ralph Regards, Bjoern -- 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: ddbridge -- kernel 3.15.6
On 8/1/14 7:54 AM, Bjoern wrote: On Do, 2014-07-31 at 09:38 +0200, Ralph Metzler wrote: It is not like drivers are not available and supported, just not in the mainline kernel tree. Right... and I hope that can be changed. I really really like the DD hardware I have, but always having to rebuild everything with a new kernel is just not my idea of how hardware should run in 2014 on Linux anymore. I have more than 30 ddbridge dvb-s devices and more than 30 dvb-c/t devices. The fact that the drivers are not in the main tree is the biggest problem with these devices. The hardware is great (never had a problem with it) but having to install experimental media build is just stupid. When I bought the devices I knew that the driver is not in the main tree but I really hoped that this would change. Now 3 years later it is still not the case. That's bullshit. Come on Digital Devices, you have the drivers, please, pretty please, submit them upstream, go through the merge process and make us - our clients a happy bunch. Like Bjoern said, it's 2014, you have the drivers, keeping them out of main kernel and having your customers go through hoops to get them working is not acceptable. -- Georgi Chorbadzhiyski | http://georgi.unixsol.org/ | http://github.com/gfto/ -- 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
