Re: Reception issue: DViCO Fusion HDTV DVB-T Dual Express
On 14/07/2010, at 10:24, David Shirley wrote: > Can you tell me what kernel version you are using? Also are you using > vanilla kernel v4l or chris pascoes tree or the v4l tree for drivers? Vanilla.. Linux mythtv 2.6.31-20-generic #58-Ubuntu SMP Fri Mar 12 04:38:19 UTC 2010 x86_64 GNU/Linux I did use Chris' a while ago but found I didn't need to this time. > So I take it you don't get any "audio blips" throughout the recording ? I haven't had a chance to try something for more that 20 seconds on channel 9 sorry.. > Any chance of a longer TZAP run as well? http://www.dons.net.au/~darius/tzap-9.log I saw you found some patches so I dunno how helpful it will be :) Sorry for the delayed response. > Thanks in advance! > > Cheers > D. > > On 13 July 2010 19:53, Daniel O'Connor wrote: >> >> On 13/07/2010, at 17:24, David Shirley wrote: >>> I am having reception issues with this particular card, the problem >>> manifests itself with missing video frames and popping sounds on the >>> audio streams. >>> >>> As far as I can tell it only some channels do it, "Nine" and its >>> multiplexes are the worst for it >> >> I have the same card an It Works For Me (tm). >> >> However I had serious issues with mythtv when I upgraded recently, however >> mplayer seemed fine and it turned out to be a DB problem (I think it was a >> bit of voodoo getting it working..) >>> >>> You can see that TZAP every now and reports some unc/ber: >>> >>> crystal:/usr/share/dvb/dvb-t# tzap -a 0 -c 0 "Nine Digital HD" >>> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' >>> reading channels from file '0' >>> tuning to 191625000 Hz >>> video pid 0x0200, audio pid 0x >>> status 00 | signal 0b28 | snr | ber | unc 12c8 | >>> status 1e | signal b64c | snr dede | ber | unc 13ce | >>> FE_HAS_LOCK >> >> >> [mythtv 19:22] ~ >tzap -a 1 "Nine HD" >> using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0' >> reading channels from file '/home/myth/.tzap/channels.conf' >> tuning to 191625000 Hz >> video pid 0x0201, audio pid 0x >> status 00 | signal c520 | snr | ber | unc 3691 | >> status 1e | signal c4a8 | snr | ber | unc 36f0 | >> FE_HAS_LOCK >> status 1e | signal c4f0 | snr abab | ber | unc 36f0 | >> FE_HAS_LOCK >> status 1e | signal c4e4 | snr abab | ber | unc 36f0 | >> FE_HAS_LOCK >> status 1e | signal c4d8 | snr acac | ber | unc 36f0 | >> FE_HAS_LOCK >> status 1e | signal c50c | snr | ber | unc 36f0 | >> FE_HAS_LOCK >> status 1e | signal c4fc | snr abab | ber 0792 | unc 36f0 | >> FE_HAS_LOCK >> status 1e | signal c540 | snr acac | ber 0792 | unc 36f0 | >> FE_HAS_LOCK >> >>> Hopefully someone can help or give me instructions on how to debug... >> >> Dunno sorry :( >> However if you need some comparison stuff run let me know :) >> >> -- >> Daniel O'Connor software and network engineer >> for Genesis Software - http://www.gsoft.com.au >> "The nice thing about standards is that there >> are so many of them to choose from." >> -- Andrew Tanenbaum >> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C >> >> >> >> >> >> >> > -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -- 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
Is it feasible to add another driver for CCIC?
Hi, I am working on CCIC camera controller driver and want to push it into kernel. This CCIC IP is similar with IP of cafe_ccic, but with lots of change: no I2C bus, embedded in SOC/no PCI, support both parallel and CSI interface. So some register definition changes. I just want to confirm that a new driver for SOC CCIC is acceptable for community. Thanks! Jun -- 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/2] drivers/video/omap2/displays: add missing mutex_unlock
From: Julia Lawall
Add a mutex_unlock missing on the error paths. The use of the mutex is
balanced elsewhere in the file.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
//
@@
expression E1;
@@
* mutex_lock(E1,...);
<+... when != E1
if (...) {
... when != E1
* return ...;
}
...+>
* mutex_unlock(E1,...);
//
Signed-off-by: Julia Lawall
Acked-By: Mike Isely
Cc: Mauro Carvalho Chehab
Signed-off-by: Andrew Morton
---
drivers/video/omap2/displays/panel-acx565akm.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff -puN
drivers/video/omap2/displays/panel-acx565akm.c~drivers-video-omap2-displays-add-missing-mutex_unlock
drivers/video/omap2/displays/panel-acx565akm.c
---
a/drivers/video/omap2/displays/panel-acx565akm.c~drivers-video-omap2-displays-add-missing-mutex_unlock
+++ a/drivers/video/omap2/displays/panel-acx565akm.c
@@ -592,7 +592,7 @@ static int acx_panel_power_on(struct oma
r = omapdss_sdi_display_enable(dssdev);
if (r) {
pr_err("%s sdi enable failed\n", __func__);
- return r;
+ goto fail_unlock;
}
/*FIXME tweak me */
@@ -633,6 +633,8 @@ static int acx_panel_power_on(struct oma
return acx565akm_bl_update_status(md->bl_dev);
fail:
omapdss_sdi_display_disable(dssdev);
+fail_unlock:
+ mutex_unlock(&md->mutex);
return r;
}
_
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 1/2] "dib3000mc: reduce large stack usage" fix
From: Andrew Morton s/ENODEV/ENOMEM, per Andreas. This fix got lost when someone merged "dib3000mc: reduce large stack usage". Please don't lose fixes. Cc: Mauro Carvalho Chehab Cc: Patrick Boettcher Cc: Randy Dunlap Cc: Andreas Oberritter Signed-off-by: Andrew Morton --- drivers/media/dvb/frontends/dib3000mc.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/media/dvb/frontends/dib3000mc.c~dib3000mc-reduce-large-stack-usage-fix drivers/media/dvb/frontends/dib3000mc.c --- a/drivers/media/dvb/frontends/dib3000mc.c~dib3000mc-reduce-large-stack-usage-fix +++ a/drivers/media/dvb/frontends/dib3000mc.c @@ -822,7 +822,7 @@ int dib3000mc_i2c_enumeration(struct i2c dmcst = kzalloc(sizeof(struct dib3000mc_state), GFP_KERNEL); if (dmcst == NULL) - return -ENODEV; + return -ENOMEM; dmcst->i2c_adap = i2c; _ -- 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: mmotm 2010-07-19-16-37 uploaded
On Tue, Jul 20, 2010 at 05:11:40PM -0400, valdis.kletni...@vt.edu wrote: > On Tue, 20 Jul 2010 13:50:27 PDT, Dmitry Torokhov said: > > > > And things go downhill from there... > > > > I guess you need these 2 from Jarod... > > Hmm. I seem to remember 2 similar patches from the last time I reported it. :) > > System boots fine after applying those two patches. I'll let somebody else > worry about making sure they end up in linux-next in time for the next merge > window... I believe Mauro's on vacation at the moment, but due back Real Soon Now, and I'd expect him to pick up both fixes shortly after he settles back in at his desk, so they should be in next before much longer, and definitely before the merge window. -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mmotm 2010-07-19-16-37 uploaded
On Tue, 20 Jul 2010 13:50:27 PDT, Dmitry Torokhov said: > > And things go downhill from there... > > I guess you need these 2 from Jarod... Hmm. I seem to remember 2 similar patches from the last time I reported it. :) System boots fine after applying those two patches. I'll let somebody else worry about making sure they end up in linux-next in time for the next merge window... pgpawIUT0lOwE.pgp Description: PGP signature
Re: mmotm 2010-07-19-16-37 uploaded
On Tue, Jul 20, 2010 at 04:41:32PM -0400, valdis.kletni...@vt.edu wrote: > On Mon, 19 Jul 2010 16:38:09 PDT, a...@linux-foundation.org said: > > The mm-of-the-moment snapshot 2010-07-19-16-37 has been uploaded to > > > >http://userweb.kernel.org/~akpm/mmotm/ > > (Andrew - did we lose a bunch of -swedish-chef-fix-fix-fix.patch files? This > is the second > thing that I reported back in May, worked in mm-rc3-0701, but dies in > -rc5-0719...) > > [ 50.949361] BUG: unable to handle kernel NULL pointer dereference at (null) > [ 50.950978] IP: [<(null)>] (null) > [ 50.952045] PGD 11b7b0067 PUD 119d9c067 PMD 0 > [ 50.954744] Oops: 0010 [#1] PREEMPT SMP > [ 50.954744] last sysfs file: /sys/devices/pci:00/:00:1b.0/device > [ 50.954744] CPU 0 > [ 50.954744] Modules linked in: microcode(+) [last unloaded: scsi_wait_scan] > [ 50.954744] > [ 50.967468] Pid: 2994, comm: keymap Tainted: GW > 2.6.35-rc5-mmotm0719 #1 0X564R/Latitude E6500 > [ 50.967468] RIP: 0010:[<>] [<(null)>] (null) > [ 50.967468] RSP: 0018:88011e7e5cb0 EFLAGS: 00010046 > [ 50.967468] RAX: RBX: 88011d8b5000 RCX: > > [ 50.967468] RDX: 88011e7e5cc8 RSI: 88011e7e5cc8 RDI: > 88011d8b5000 > [ 50.967468] RBP: 88011e7e5d28 R08: 0890 R09: > 0001 > [ 50.967468] R10: 88011d8b5858 R11: 88011d8b5840 R12: > > [ 50.967468] R13: 00a4 R14: 88011d8b5840 R15: > 0296 > [ 50.967468] FS: 7fea0676e720() GS:88000260() > knlGS: > [ 50.967468] CS: 0010 DS: ES: CR0: 80050033 > [ 50.967468] CR2: CR3: 00011f72b000 CR4: > 000406f0 > [ 50.967468] DR0: DR1: DR2: > > [ 50.967468] DR3: DR6: 0ff0 DR7: > 0400 > [ 50.967468] Process keymap (pid: 2994, threadinfo 88011e7e4000, task > 88011e620100) > [ 50.967468] Stack: > [ 50.967468] 813b4b54 88011e7e5cc8 00810246 > 008100a4 > [ 50.967468] <0> 0004 88011e7e5cc4 > 7fffe9f95f00 > [ 50.967468] <0> 88011b4a3300 88011e7e5d28 0081 > fff2 > [ 50.967468] Call Trace: > [ 50.967468] [] ? input_set_keycode+0xbc/0x13c > [ 50.967468] [] evdev_do_ioctl+0x24c/0x816 > [ 51.016215] [] ? evdev_ioctl_handler+0x3a/0x81 > [ 51.018336] [] ? evdev_ioctl_handler+0x3a/0x81 > [ 51.021130] [] evdev_ioctl_handler+0x64/0x81 > [ 51.022519] [] evdev_ioctl+0xb/0xd > [ 51.024439] [] vfs_ioctl+0x31/0xa2 > [ 51.026408] [] do_vfs_ioctl+0x496/0x4c9 > [ 51.028337] [] sys_ioctl+0x57/0x96 > [ 51.030245] [] system_call_fastpath+0x16/0x1b > [ 51.032123] Code: Bad RIP value. > [ 51.034015] RIP [<(null)>] (null) > [ 51.037307] RSP > [ 51.038270] CR2: > [ 51.038270] ---[ end trace 84b562a00a6053a0 ]--- > > And things go downhill from there... This looks like the same trace we got in the Red Hat bugzilla a few days ago, and for which I submitted this: https://patchwork.kernel.org/patch/112791/ -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mmotm 2010-07-19-16-37 uploaded
On Mon, 19 Jul 2010 16:38:09 PDT, a...@linux-foundation.org said: > The mm-of-the-moment snapshot 2010-07-19-16-37 has been uploaded to > >http://userweb.kernel.org/~akpm/mmotm/ (Andrew - did we lose a bunch of -swedish-chef-fix-fix-fix.patch files? This is the second thing that I reported back in May, worked in mm-rc3-0701, but dies in -rc5-0719...) [ 50.949361] BUG: unable to handle kernel NULL pointer dereference at (null) [ 50.950978] IP: [<(null)>] (null) [ 50.952045] PGD 11b7b0067 PUD 119d9c067 PMD 0 [ 50.954744] Oops: 0010 [#1] PREEMPT SMP [ 50.954744] last sysfs file: /sys/devices/pci:00/:00:1b.0/device [ 50.954744] CPU 0 [ 50.954744] Modules linked in: microcode(+) [last unloaded: scsi_wait_scan] [ 50.954744] [ 50.967468] Pid: 2994, comm: keymap Tainted: GW 2.6.35-rc5-mmotm0719 #1 0X564R/Latitude E6500 [ 50.967468] RIP: 0010:[<>] [<(null)>] (null) [ 50.967468] RSP: 0018:88011e7e5cb0 EFLAGS: 00010046 [ 50.967468] RAX: RBX: 88011d8b5000 RCX: [ 50.967468] RDX: 88011e7e5cc8 RSI: 88011e7e5cc8 RDI: 88011d8b5000 [ 50.967468] RBP: 88011e7e5d28 R08: 0890 R09: 0001 [ 50.967468] R10: 88011d8b5858 R11: 88011d8b5840 R12: [ 50.967468] R13: 00a4 R14: 88011d8b5840 R15: 0296 [ 50.967468] FS: 7fea0676e720() GS:88000260() knlGS: [ 50.967468] CS: 0010 DS: ES: CR0: 80050033 [ 50.967468] CR2: CR3: 00011f72b000 CR4: 000406f0 [ 50.967468] DR0: DR1: DR2: [ 50.967468] DR3: DR6: 0ff0 DR7: 0400 [ 50.967468] Process keymap (pid: 2994, threadinfo 88011e7e4000, task 88011e620100) [ 50.967468] Stack: [ 50.967468] 813b4b54 88011e7e5cc8 00810246 008100a4 [ 50.967468] <0> 0004 88011e7e5cc4 7fffe9f95f00 [ 50.967468] <0> 88011b4a3300 88011e7e5d28 0081 fff2 [ 50.967468] Call Trace: [ 50.967468] [] ? input_set_keycode+0xbc/0x13c [ 50.967468] [] evdev_do_ioctl+0x24c/0x816 [ 51.016215] [] ? evdev_ioctl_handler+0x3a/0x81 [ 51.018336] [] ? evdev_ioctl_handler+0x3a/0x81 [ 51.021130] [] evdev_ioctl_handler+0x64/0x81 [ 51.022519] [] evdev_ioctl+0xb/0xd [ 51.024439] [] vfs_ioctl+0x31/0xa2 [ 51.026408] [] do_vfs_ioctl+0x496/0x4c9 [ 51.028337] [] sys_ioctl+0x57/0x96 [ 51.030245] [] system_call_fastpath+0x16/0x1b [ 51.032123] Code: Bad RIP value. [ 51.034015] RIP [<(null)>] (null) [ 51.037307] RSP [ 51.038270] CR2: [ 51.038270] ---[ end trace 84b562a00a6053a0 ]--- And things go downhill from there... pgpGI8M04vRZc.pgp Description: PGP signature
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Tue Jul 20 19:00:19 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14993:9652f85e688a git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 41c5f984b67b331064e69acc9fca5e99bf73d400 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-armv5: WARNINGS linux-2.6.35-rc1-armv5: ERRORS linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35-rc1-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35-rc1-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.34-i686: WARNINGS linux-2.6.35-rc1-i686: ERRORS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35-rc1-m32r: ERRORS linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-mips: WARNINGS linux-2.6.35-rc1-mips: ERRORS linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-powerpc64: WARNINGS linux-2.6.35-rc1-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-x86_64: WARNINGS linux-2.6.35-rc1-x86_64: ERRORS linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 0/6] Add camera support to the OMAP1 Amstrad Delta videophone
Tuesday 20 July 2010 11:49:54 Guennadi Liakhovetski wrote: > Hi Janusz Hi Guennadi, Thanks for your answer. > On Sun, 18 Jul 2010, Janusz Krzysztofik wrote: > > This series consists of the following patches: > > > > 1/6 SoC Camera: add driver for OMAP1 camera interface > > 2/6 OMAP1: Add support for SoC camera interface > > 3/6 SoC Camera: add driver for OV6650 sensor > > 4/6 SoC Camera: add support for g_parm / s_parm operations > > 5/6 OMAP1: Amstrad Delta: add support for on-board camera > > 6/6 OMAP1: Amstrad Delta: add camera controlled LEDS trigger > > It is an interesting decision to use soc-camera for an OMAP SoC, as you > most probably know OMAP3 and OMAP2 camera drivers do not use soc-camera. I > certainly do not want to discourage you from using soc-camera, just don't > want you to go the wrong way and then regret it or spend time re-designing > your driver. If this way occures wrong, then it's only my fault, since I've taken it myself, without consulting it neither on omap nor media list, so I'm not going to blame anyone except myself. > Have you had specific reasons for this design? It looked like the most simple way for me. And while implementing it, I haven't faced any restrictions that would lead me to changing my mind and doing it another way. > Is OMAP1 so different from 2 (and 3)? I think so, but let's see what OMAP guys have to say. > In any case - thanks for the patches, if you do > insist on going this path (;)) I'll review them and get back to you after > that. Beware, it might be difficult to finish the review process in time > for 2.6.36... Since not all patches from the series are OMAP related, and those that are not, don't depend on others, I think you could have a look at 4/6 and see if it makes sense or not. You could also examine 6/6 and see if you would like the idea of a camera LED trigger implemented, this way or another, at the soc_camera framework level rather than specific machine or platform. Last, the sensor driver (3/6), even if soc_camera specific, could be considered, if accepted, for adopting it as a regular v4l2-subdev, if required by a different implementation of OMAP part choosen. Thanks, Janusz -- 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/PATCH 05/10] media: Reference count and power handling
Laurent Pinchart wrote: > Hi Sakari, Heippa, ... > To summarize the discussion, what should I change here ? Just remove the "ret > = " in the second set_power call ? Yes, and also return 0 instead of ret, which is always zero at that point. -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 05/10] media: Reference count and power handling
Hi Sakari,
On Monday 19 July 2010 13:20:33 Sakari Ailus wrote:
> Hans Verkuil wrote:
> +/*
> + * Apply use count change to an entity and change power state based
> on + * new use count.
> + */
> +static int media_entity_power_apply_one(struct media_entity *entity,
> int change)
> +{
> +int ret = 0;
> +
> +if (entity->use_count == 0 && change > 0 &&
> +entity->ops && entity->ops->set_power) {
> +ret = entity->ops->set_power(entity, 1);
> +if (ret)
> +return ret;
> +}
> +
> +media_entity_use_apply_one(entity, change);
> +
> +if (entity->use_count == 0 && change < 0 &&
> +entity->ops && entity->ops->set_power)
> +ret = entity->ops->set_power(entity, 0);
> >>>
> >>> Shouldn't this code be executed before the call to
> >>> media_entity_use_apply_one()?
> >>> Or at least call media_entity_use_apply_one(entity, -change) in case of
> >>> an error? Since it failed to power off the entity it should ensure that
> >>> the use_count remains > 0.
>
> Forgot to answer this one.
>
> The first entity->ops->set_power() is called to power on the device.
> This will be done when the use_count was 0 and change is positive, i.e.
> we're asked to power on the entity. The actual use count is not changed
> in case of a failure.
>
> The latter entity->ops->set_power() is called to power the device off.
> media_entity_use_apply_one() is called first to apply the change since
> the change isn't necessarily -1 or 1.The change was already applied to
> the entity->use_count that's why the comparison against 0. And the
> change was negative, i.e. the device is to be powered off.
>
> So I don't think there's an error in use_count calculation. But the
> second set_power() to power the device off shouldn't set ret at all and
> the function should return zero at the end.
>
> Then I think it'd be correct. Things can currently go wrong when
> media_entity_power_apply() is called from
> media_entity_node_power_change() with a negative change.
To summarize the discussion, what should I change here ? Just remove the "ret
= " in the second set_power call ?
--
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
HELP: Interface a CMOS sensor with the DM355 (fwd)
Forwarding on authors's behalf. Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- Forwarded message -- Date: Tue, 20 Jul 2010 11:01:36 +0200 From: ibrahima sakho Subject: HELP: Interface a CMOS sensor with the DM355 Hello, I come towards you because I work at present on the interfacing between the demo board DM355 and the CMOS sensor MT9J003 from Micron (Aptina) to make of the video. I use the Arago project for it. The problem which I have is situated at the configuration of the I2C bus. Indeed, the register address of the CMOS sensor MT9J003 is on 16 bits and I do not succeed in communicating via this bus. I am parit of the driver that you developed for the MT9T031, but without succés. The communication with the sensor is of this kind: I2C Block Read (2 Comm bytes) = This command reads a block of bytes from a device, from a designated register that is specified through the two Comm byte. S Addr Wr [A] Comm1 [A] Comm2 [A] S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P Is this I2C function implemented in the I2C module ? May I use Arago project to manage to configure this I2C communication ? I shall really need your help and your councils. I thank you beforehand. Ibrahima SAKHO _ Le nouveau Hotmail est presque arrivé, ne le manquez pas ! http://www.windowslive.fr/nouveau-hotmail/ -- 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 04/17] cx25840: Make cx25840 i2c register read transactions atomic
On Tue, 20 Jul 2010 08:35:26 -0400, Andy Walls wrote: > On Tue, 2010-07-20 at 08:42 +0200, Jean Delvare wrote: > > Hi Andy, > > > > On Mon, 19 Jul 2010 21:11:46 -0400, Andy Walls wrote: > > > There was a small window between writing the cx25840 register > > > address over the i2c bus and reading the register contents back from the > > > cx25840 device that the i2c adapter lock was released. This change > > > ensures the > > > adapter lock is not released until the register read is done. > > > > > > Signed-off-by: Andy Walls > > > > Good catch. > > Thanks. > > > Acked-by: Jean Delvare > > > > Note that cx25840_and_or() still has a (smaller and less dangerous) > > race window. If several calls to cx25840_and_or() happen in parallel on > > the same register, some of the changes may be lost. I don't know if > > this can be a problem in practice though. If it is, then additional > > locking around cx25840_and_or() would be needed. > > Ah, thank you for pointing that out. > > So, please bear with me while I think out loud: > > 1. There are many explicit cases of read-modify-write on a register in > the cx25840 module, this is not the only one. > > 2. The bridge driver historically has always serialized access to the > cx25840 module so races have never previously been an issue. > > 3. I have added a work handler in the cx23885 module that calls the > cx25840 module's interrupt handler. Calls by the work handler are > serialized with respect to themselves, but not with respect to > serialized calls in #2. > > 4. IIRC, registers written to by the cx25840 interrupt handler are never > written to by the other cx25840 module functions; and vice-versa. I > will have to audit the cx25840 module code to be sure. > > 5. There is always a race on r-m-w on *some* registers in the > 0x800-0x9ff range with the audio microcontroller that is built into the > chip. The only way to provide locking for those is to halt the > microcontroller. I've just looked at Patch 12/17 again. The interrupt > handler only reads the CX23885_AUD_MC_INT_MASK_REG, which is used by the > audio micrcontroller. The interrupt handler does do a r-m-w on the > CX25840_AUD_INT_STAT_REG, but that register is not used by the > microcontroller. > > > So, I think I'm OK with just not dropping the i2c adapter lock in a > cx25840 register read transaction until it is complete. > > Thanks for making me think that one through. :) Looks like you're OK then, but you may want to document this somewhere for future contributors to these drivers. -- Jean Delvare -- 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 04/17] cx25840: Make cx25840 i2c register read transactions atomic
On Tue, 2010-07-20 at 08:42 +0200, Jean Delvare wrote: > Hi Andy, > > On Mon, 19 Jul 2010 21:11:46 -0400, Andy Walls wrote: > > There was a small window between writing the cx25840 register > > address over the i2c bus and reading the register contents back from the > > cx25840 device that the i2c adapter lock was released. This change ensures > > the > > adapter lock is not released until the register read is done. > > > > Signed-off-by: Andy Walls > > Good catch. Thanks. > Acked-by: Jean Delvare > > Note that cx25840_and_or() still has a (smaller and less dangerous) > race window. If several calls to cx25840_and_or() happen in parallel on > the same register, some of the changes may be lost. I don't know if > this can be a problem in practice though. If it is, then additional > locking around cx25840_and_or() would be needed. Ah, thank you for pointing that out. So, please bear with me while I think out loud: 1. There are many explicit cases of read-modify-write on a register in the cx25840 module, this is not the only one. 2. The bridge driver historically has always serialized access to the cx25840 module so races have never previously been an issue. 3. I have added a work handler in the cx23885 module that calls the cx25840 module's interrupt handler. Calls by the work handler are serialized with respect to themselves, but not with respect to serialized calls in #2. 4. IIRC, registers written to by the cx25840 interrupt handler are never written to by the other cx25840 module functions; and vice-versa. I will have to audit the cx25840 module code to be sure. 5. There is always a race on r-m-w on *some* registers in the 0x800-0x9ff range with the audio microcontroller that is built into the chip. The only way to provide locking for those is to halt the microcontroller. I've just looked at Patch 12/17 again. The interrupt handler only reads the CX23885_AUD_MC_INT_MASK_REG, which is used by the audio micrcontroller. The interrupt handler does do a r-m-w on the CX25840_AUD_INT_STAT_REG, but that register is not used by the microcontroller. So, I think I'm OK with just not dropping the i2c adapter lock in a cx25840 register read transaction until it is complete. Thanks for making me think that one through. :) 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
Re: CAM Support for Terratec Cinergy S2 HD or Technisat SkyStar HD2
code unknown a écrit :
Hi,
I am using a Terratec Cinergy S2 HD with Mantis driver and so far the
card runs without problems.
The only thing is that CAM seems not to be supported - it is defined
out from the source code:
#if 0
err = mantis_ca_init(mantis);
if (err < 0) {
dprintk(MANTIS_ERROR, 1, "ERROR: Mantis CA initialization
failed <%d>", err);
}
#endif
My questions are:
1. Is anybody currently working on CAM support? Will it be supported soon?
2. Is there another DVB-S2 HD card which has CAM supported?
I am using a Technotrend S2-3200 with a CAM (Astoncrypt) with no problem
so far.
HTH
Bye
Manu
--
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 v6 1/5] V4L2: Add seek spacing and FM RX class.
Add spacing field to v4l2_hw_freq_seek and also add FM RX class to
control classes.
Signed-off-by: Matti J. Aaltonen
---
drivers/media/video/v4l2-common.c | 12
include/linux/videodev2.h | 15 ++-
2 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c
index 4e53b0b..7ffb16b 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -354,6 +354,12 @@ const char **v4l2_ctrl_get_menu(u32 id)
"75 useconds",
NULL,
};
+ static const char *fm_band[] = {
+ "87.5 - 108. MHz",
+ "76. - 90. MHz, Japan",
+ "65. - 74. MHz, OIRT",
+ NULL,
+ };
switch (id) {
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
@@ -394,6 +400,8 @@ const char **v4l2_ctrl_get_menu(u32 id)
return colorfx;
case V4L2_CID_TUNE_PREEMPHASIS:
return tune_preemphasis;
+ case V4L2_CID_FM_BAND:
+ return fm_band;
default:
return NULL;
}
@@ -520,6 +528,8 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_TUNE_PREEMPHASIS: return "Pre-emphasis settings";
case V4L2_CID_TUNE_POWER_LEVEL: return "Tune Power Level";
case V4L2_CID_TUNE_ANTENNA_CAPACITOR: return "Tune Antenna Capacitor";
+ case V4L2_CID_FM_RX_CLASS: return "FM Radio Tuner
Controls";
+ case V4L2_CID_FM_BAND: return "FM Band";
default:
return NULL;
@@ -585,6 +595,7 @@ int v4l2_ctrl_query_fill(struct v4l2_queryctrl *qctrl, s32
min, s32 max, s32 ste
case V4L2_CID_EXPOSURE_AUTO:
case V4L2_CID_COLORFX:
case V4L2_CID_TUNE_PREEMPHASIS:
+ case V4L2_CID_FM_BAND:
qctrl->type = V4L2_CTRL_TYPE_MENU;
step = 1;
break;
@@ -596,6 +607,7 @@ int v4l2_ctrl_query_fill(struct v4l2_queryctrl *qctrl, s32
min, s32 max, s32 ste
case V4L2_CID_CAMERA_CLASS:
case V4L2_CID_MPEG_CLASS:
case V4L2_CID_FM_TX_CLASS:
+ case V4L2_CID_FM_RX_CLASS:
qctrl->type = V4L2_CTRL_TYPE_CTRL_CLASS;
qctrl->flags |= V4L2_CTRL_FLAG_READ_ONLY;
min = max = step = def = 0;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 047f7e6..f840f97 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -929,6 +929,7 @@ struct v4l2_ext_controls {
#define V4L2_CTRL_CLASS_MPEG 0x0099/* MPEG-compression controls */
#define V4L2_CTRL_CLASS_CAMERA 0x009a /* Camera class controls */
#define V4L2_CTRL_CLASS_FM_TX 0x009b /* FM Modulator control class */
+#define V4L2_CTRL_CLASS_FM_RX 0x009c /* FM Tuner control class */
#define V4L2_CTRL_ID_MASK(0x0fff)
#define V4L2_CTRL_ID2CLASS(id)((id) & 0x0fffUL)
@@ -1327,6 +1328,17 @@ enum v4l2_preemphasis {
#define V4L2_CID_TUNE_POWER_LEVEL (V4L2_CID_FM_TX_CLASS_BASE +
113)
#define V4L2_CID_TUNE_ANTENNA_CAPACITOR
(V4L2_CID_FM_TX_CLASS_BASE + 114)
+/* FM Tuner class control IDs */
+#define V4L2_CID_FM_RX_CLASS_BASE (V4L2_CTRL_CLASS_FM_RX | 0x900)
+#define V4L2_CID_FM_RX_CLASS (V4L2_CTRL_CLASS_FM_RX | 1)
+
+#define V4L2_CID_FM_BAND (V4L2_CID_FM_RX_CLASS_BASE + 1)
+enum v4l2_fm_band {
+ V4L2_FM_BAND_OTHER = 0,
+ V4L2_FM_BAND_JAPAN = 1,
+ V4L2_FM_BAND_OIRT = 2
+};
+
/*
* T U N I N G
*/
@@ -1391,7 +1403,8 @@ struct v4l2_hw_freq_seek {
enum v4l2_tuner_type type;
__u32 seek_upward;
__u32 wrap_around;
- __u32 reserved[8];
+ __u32 spacing;
+ __u32 reserved[7];
};
/*
--
1.6.1.3
--
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 v6 4/5] V4L2: WL1273 FM Radio: Controls for the FM radio.
This file implements V4L2 controls for using the Texas Instruments
WL1273 FM Radio.
Signed-off-by: Matti J. Aaltonen
---
drivers/media/radio/Kconfig| 15 +
drivers/media/radio/Makefile |1 +
drivers/media/radio/radio-wl1273.c | 1960
drivers/mfd/Kconfig|6 +
drivers/mfd/Makefile |2 +
5 files changed, 1984 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/radio/radio-wl1273.c
diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index 83567b8..209fd37 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -452,4 +452,19 @@ config RADIO_TIMBERDALE
found behind the Timberdale FPGA on the Russellville board.
Enabling this driver will automatically select the DSP and tuner.
+config RADIO_WL1273
+ tristate "Texas Instruments WL1273 I2C FM Radio"
+depends on I2C && VIDEO_V4L2 && SND
+ select FW_LOADER
+ ---help---
+ Choose Y here if you have this FM radio chip.
+
+ In order to control your radio card, you will need to use programs
+ that are compatible with the Video For Linux 2 API. Information on
+ this API and pointers to "v4l2" programs may be found at
+ .
+
+ To compile this driver as a module, choose M here: the
+ module will be called radio-wl1273.
+
endif # RADIO_ADAPTERS
diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile
index f615583..d297074 100644
--- a/drivers/media/radio/Makefile
+++ b/drivers/media/radio/Makefile
@@ -26,5 +26,6 @@ obj-$(CONFIG_RADIO_TEA5764) += radio-tea5764.o
obj-$(CONFIG_RADIO_SAA7706H) += saa7706h.o
obj-$(CONFIG_RADIO_TEF6862) += tef6862.o
obj-$(CONFIG_RADIO_TIMBERDALE) += radio-timb.o
+obj-$(CONFIG_RADIO_WL1273) += radio-wl1273.o
EXTRA_CFLAGS += -Isound
diff --git a/drivers/media/radio/radio-wl1273.c
b/drivers/media/radio/radio-wl1273.c
new file mode 100644
index 000..737c682
--- /dev/null
+++ b/drivers/media/radio/radio-wl1273.c
@@ -0,0 +1,1960 @@
+/*
+ * Driver for the Texas Instruments WL1273 FM radio.
+ *
+ * Copyright (C) Nokia Corporation
+ * Author: Matti J. Aaltonen
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#undef DEBUG
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_DESC "Wl1273 FM Radio - V4L2"
+
+#define WL1273_POWER_SET_OFF 0
+#define WL1273_POWER_SET_FM(1 << 0)
+#define WL1273_POWER_SET_RDS (1 << 1)
+#define WL1273_POWER_SET_RETENTION (1 << 4)
+
+#define WL1273_PUPD_SET_OFF0x00
+#define WL1273_PUPD_SET_ON 0x01
+#define WL1273_PUPD_SET_RETENTION 0x10
+
+#define WL1273_FREQ(x) (x * 1 / 625)
+#define WL1273_INV_FREQ(x) (x * 625 / 1)
+
+/*
+ * static int radio_nr - The number of the radio device
+ *
+ * The default is 0.
+ */
+static int radio_nr = -1;
+module_param(radio_nr, int, 0);
+MODULE_PARM_DESC(radio_nr, "Radio Nr");
+
+struct wl1273_device {
+ struct v4l2_device v4l2dev;
+ struct video_device videodev;
+ struct device *dev;
+ struct wl1273_core *core;
+ struct file *owner;
+ char *write_buf;
+ bool rds_on;
+};
+
+static int wl1273_fm_set_tx_freq(struct wl1273_core *core, unsigned int freq)
+{
+ int r = 0;
+
+ if (freq < 76000) {
+ dev_err(&core->i2c_dev->dev,
+ "Frequency out of range: %d < %d\n",
+ freq, core->bands[core->band].bottom_frequency);
+ return -EDOM;
+ }
+
+ if (freq > 108000) {
+ dev_err(&core->i2c_dev->dev,
+ "Frequency out of range: %d > %d\n",
+ freq, core->bands[core->band].top_frequency);
+ return -EDOM;
+ }
+
+ /*
+* The driver works better with this msleep,
+* the documentation doesn't mention it.
+*/
+ msleep(5);
+ dev_dbg(&core->i2c_dev->dev, "%s: freq: %d kHz\n", __func__, freq);
+
+ INIT_COMPLETION(core->busy);
+ /* Set the current tx channel */
+ r = wl1273_fm_write_cmd(core, WL1273_CHANL_SET, freq / 10);
+ if (r)
+ return r;
+
+ /* wait for the FR IRQ */
+ r = wait_for_completion_timeout(&core->busy
[PATCH v6 5/5] Documentation: v4l: Add hw_seek spacing and FM_RX class
Add a couple of words about the spacing field in ithe HW seek struct and about the new FM RX control class. Signed-off-by: Matti J. Aaltonen --- Documentation/DocBook/v4l/controls.xml | 71 .../DocBook/v4l/vidioc-s-hw-freq-seek.xml | 10 ++- 2 files changed, 79 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/v4l/controls.xml b/Documentation/DocBook/v4l/controls.xml index 8408caa..e9512eb 100644 --- a/Documentation/DocBook/v4l/controls.xml +++ b/Documentation/DocBook/v4l/controls.xml @@ -2088,6 +2088,77 @@ manually or automatically if set to zero. Unit, range and step are driver-specif For more details about RDS specification, refer to document, from CENELEC. + + FM Tuner Control Reference + + The FM Tuner (FM_RX) class includes controls for common features of +devices that are capable of receiving FM transmissions. Currently this class includes a parameter +defining the FM radio band being used. + + + FM_RX Control IDs + + + + + + + + + + + ID + Type + Description + + + + + + V4L2_CID_FM_RX_CLASS + class + The FM_RX class +descriptor. Calling &VIDIOC-QUERYCTRL; for this control will return a +description of this control class. + + + V4L2_CID_FM_RX_BAND + integer + + Configures the FM radio +frequency range being used. Currently there are three bands in use, see http://en.wikipedia.org/wiki/FM_broadcasting";>Wikipedia. +Usually 87.5 to 108.0 MHz is used, or some portion thereof, with a few exceptions: +In Japan, the band 76-90 MHz is used and in the former Soviet republics +and some Eastern European countries, the older 65-74 MHz band, +referred also to as the OIRT band, is still used. + +The enum v4l2_fm_rx_band defines possible values for the FM band. They are: + + + + + V4L2_FM_BAND_OTHER + Frequencies from 87.5 to 108.0 MHz + + + V4L2_FM_BAND_JAPAN + from 65 to 74 MHz + + + V4L2_FM_BAND_OIRT + from 65 to 74 MHz + + + + + + + + + + +
[PATCH v6 3/5] ASoC: WL1273 FM Radio Digital audio codec.
The codec handles digital audio input to and output from the
WL1273 FM radio.
Signed-off-by: Matti J. Aaltonen
---
sound/soc/codecs/Kconfig |6 +
sound/soc/codecs/Makefile |2 +
sound/soc/codecs/wl1273.c | 593 +
sound/soc/codecs/wl1273.h | 42
4 files changed, 643 insertions(+), 0 deletions(-)
create mode 100644 sound/soc/codecs/wl1273.c
create mode 100644 sound/soc/codecs/wl1273.h
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 31ac553..bb85495 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -38,6 +38,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_TWL6040 if TWL4030_CORE
select SND_SOC_UDA134X
select SND_SOC_UDA1380 if I2C
+ select SND_SOC_WL1273 if I2C
select SND_SOC_WM2000 if I2C
select SND_SOC_WM8350 if MFD_WM8350
select SND_SOC_WM8400 if MFD_WM8400
@@ -179,6 +180,11 @@ config SND_SOC_UDA134X
config SND_SOC_UDA1380
tristate
+config SND_SOC_WL1273
+ tristate
+ select WL1273_CORE
+ default n
+
config SND_SOC_WM8350
tristate
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 91429ea..8a1e7c7 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -25,6 +25,7 @@ snd-soc-twl4030-objs := twl4030.o
snd-soc-twl6040-objs := twl6040.o
snd-soc-uda134x-objs := uda134x.o
snd-soc-uda1380-objs := uda1380.o
+snd-soc-wl1273-objs := wl1273.o
snd-soc-wm8350-objs := wm8350.o
snd-soc-wm8400-objs := wm8400.o
snd-soc-wm8510-objs := wm8510.o
@@ -90,6 +91,7 @@ obj-$(CONFIG_SND_SOC_TWL4030) += snd-soc-twl4030.o
obj-$(CONFIG_SND_SOC_TWL6040) += snd-soc-twl6040.o
obj-$(CONFIG_SND_SOC_UDA134X) += snd-soc-uda134x.o
obj-$(CONFIG_SND_SOC_UDA1380) += snd-soc-uda1380.o
+obj-$(CONFIG_SND_SOC_WL1273) += snd-soc-wl1273.o
obj-$(CONFIG_SND_SOC_WM8350) += snd-soc-wm8350.o
obj-$(CONFIG_SND_SOC_WM8400) += snd-soc-wm8400.o
obj-$(CONFIG_SND_SOC_WM8510) += snd-soc-wm8510.o
diff --git a/sound/soc/codecs/wl1273.c b/sound/soc/codecs/wl1273.c
new file mode 100644
index 000..2e324ef
--- /dev/null
+++ b/sound/soc/codecs/wl1273.c
@@ -0,0 +1,593 @@
+/*
+ * ALSA SoC WL1273 codec driver
+ *
+ * Author: Matti Aaltonen,
+ *
+ * Copyright: (C) 2010 Nokia Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 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 St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#undef DEBUG
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "wl1273.h"
+
+static int snd_wl1273_fm_set_i2s_mode(struct wl1273_core *core,
+ int rate, int width)
+{
+ struct device *dev = &core->i2c_dev->dev;
+ int r = 0;
+ u16 mode;
+
+ dev_dbg(dev, "rate: %d\n", rate);
+ dev_dbg(dev, "width: %d\n", width);
+
+ mutex_lock(&core->lock);
+
+ mode = core->i2s_mode & ~WL1273_IS2_WIDTH & ~WL1273_IS2_RATE;
+
+ switch (rate) {
+ case 48000:
+ mode |= WL1273_IS2_RATE_48K;
+ break;
+ case 44100:
+ mode |= WL1273_IS2_RATE_44_1K;
+ break;
+ case 32000:
+ mode |= WL1273_IS2_RATE_32K;
+ break;
+ case 22050:
+ mode |= WL1273_IS2_RATE_22_05K;
+ break;
+ case 16000:
+ mode |= WL1273_IS2_RATE_16K;
+ break;
+ case 12000:
+ mode |= WL1273_IS2_RATE_12K;
+ break;
+ case 11025:
+ mode |= WL1273_IS2_RATE_11_025;
+ break;
+ case 8000:
+ mode |= WL1273_IS2_RATE_8K;
+ break;
+ default:
+ dev_err(dev, "Sampling rate: %d not supported\n", rate);
+ r = -EINVAL;
+ goto out;
+ }
+
+ switch (width) {
+ case 16:
+ mode |= WL1273_IS2_WIDTH_32;
+ break;
+ case 20:
+ mode |= WL1273_IS2_WIDTH_40;
+ break;
+ case 24:
+ mode |= WL1273_IS2_WIDTH_48;
+ break;
+ case 25:
+ mode |= WL1273_IS2_WIDTH_50;
+ break;
+ case 30:
+ mode |= WL1273_IS2_WIDTH_60;
+ break;
+ case 32:
+ mode |= WL1273_IS2_WIDTH_64;
+ break;
+ case 40:
+ mode |= WL1
[PATCH v6 2/5] MFD: WL1273 FM Radio: MFD driver for the FM radio.
This is a parent driver for two child drivers: the V4L2 driver and
the ALSA codec driver. The MFD part provides the I2C communication
to the device and a couple of functions that are called from both
children.
Signed-off-by: Matti J. Aaltonen
---
drivers/mfd/wl1273-core.c | 613 +++
include/linux/mfd/wl1273-core.h | 313
2 files changed, 926 insertions(+), 0 deletions(-)
create mode 100644 drivers/mfd/wl1273-core.c
create mode 100644 include/linux/mfd/wl1273-core.h
diff --git a/drivers/mfd/wl1273-core.c b/drivers/mfd/wl1273-core.c
new file mode 100644
index 000..b305031
--- /dev/null
+++ b/drivers/mfd/wl1273-core.c
@@ -0,0 +1,613 @@
+/*
+ * MFD driver for wl1273 FM radio and audio codec submodules.
+ *
+ * Author: Matti Aaltonen
+ *
+ * Copyright: (C) 2010 Nokia Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 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 St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#undef DEBUG
+
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_DESC "WL1273 FM Radio Core"
+
+#define WL1273_IRQ_MASK (WL1273_FR_EVENT | \
+ WL1273_POW_ENB_EVENT)
+
+static const struct band_info bands[] = {
+ /* USA & Europe */
+ {
+ .bottom_frequency = 87500,
+ .top_frequency = 108000,
+ .band = V4L2_FM_BAND_OTHER,
+ },
+ /* Japan */
+ {
+ .bottom_frequency = 76000,
+ .top_frequency = 9,
+ .band = V4L2_FM_BAND_JAPAN,
+ },
+};
+
+/*
+ * static unsigned char radio_band - Band
+ *
+ * The bands are 0 == USA-Europe, 1 == Japan. USA-Europe is the default.
+ */
+static unsigned char radio_band;
+module_param(radio_band, byte, 0);
+MODULE_PARM_DESC(radio_band, "Band: 0=USA-Europe, 1=Japan");
+
+/*
+ * static unsigned int rds_buf - the number of RDS buffer blocks used.
+ *
+ * The default number is 100.
+ */
+static unsigned int rds_buf = 100;
+module_param(rds_buf, uint, 0);
+MODULE_PARM_DESC(rds_buf, "RDS buffer entries: *100*");
+
+int wl1273_fm_read_reg(struct wl1273_core *core, u8 reg, u16 *value)
+{
+ struct i2c_client *client = core->i2c_dev;
+ u8 b[2];
+ int r;
+
+ r = i2c_smbus_read_i2c_block_data(client, reg, 2, b);
+ if (r != 2) {
+ dev_err(&client->dev, "%s: Read: %d fails.\n", __func__, reg);
+ return -EREMOTEIO;
+ }
+
+ *value = (u16)b[0] << 8 | b[1];
+
+ return 0;
+}
+EXPORT_SYMBOL(wl1273_fm_read_reg);
+
+int wl1273_fm_write_cmd(struct wl1273_core *core, u8 cmd, u16 param)
+{
+ struct i2c_client *client = core->i2c_dev;
+ u8 buf[] = { (param >> 8) & 0xff, param & 0xff };
+ int r;
+
+ r = i2c_smbus_write_i2c_block_data(client, cmd, 2, buf);
+ if (r) {
+ dev_err(&client->dev, "%s: Cmd: %d fails.\n", __func__, cmd);
+ return r;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(wl1273_fm_write_cmd);
+
+int wl1273_fm_write_data(struct wl1273_core *core, u8 *data, u16 len)
+{
+ struct i2c_client *client = core->i2c_dev;
+ struct i2c_msg msg[1];
+ int r;
+
+ msg[0].addr = client->addr;
+ msg[0].flags = 0;
+ msg[0].buf = data;
+ msg[0].len = len;
+
+ r = i2c_transfer(client->adapter, msg, 1);
+
+ if (r != 1) {
+ dev_err(&client->dev, "%s: write error.\n", __func__);
+ return -EREMOTEIO;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(wl1273_fm_write_data);
+
+/**
+ * wl1273_fm_set_audio() - Set audio mode.
+ * @core: A pointer to the device struct.
+ * @new_mode: The new audio mode.
+ *
+ * Audio modes are WL1273_AUDIO_DIGITAL and WL1273_AUDIO_ANALOG.
+ */
+int wl1273_fm_set_audio(struct wl1273_core *core, unsigned int new_mode)
+{
+ int r = 0;
+
+ if (core->mode == WL1273_MODE_OFF ||
+ core->mode == WL1273_MODE_SUSPENDED)
+ return -EPERM;
+
+ if (core->mode == WL1273_MODE_RX && new_mode == WL1273_AUDIO_DIGITAL) {
+ r = wl1273_fm_write_cmd(core, WL1273_PCM_MODE_SET,
+ WL1273_PCM_DEF_MODE);
+ if (r)
+ goto out;
+
+ r = wl1273_fm_write_c
[PATCH v6 0/5] WL1273 FM Radio driver...
Hello All!
And thank for comments Hans and Mauro.
Here is the list of changes from v5:
include/linux/videodev2.h
Hans wrote:
>> +
>> +#define V4L2_CID_FM_RX_BAND (V4L2_CID_FM_TX_CLASS_BASE + 1)
>> +enum v4l2_fm_rx_band {
>
> Just a very small change: rename v4l2_fm_rx_band to v4l2_fm_band. We might
> need
> this enum later for transmitter devices as well so it is better to give it a
> slightly more generic name.
Changed the name to v4l2_fm_band. Also changed the define constant.
Hans wrote:
>Note: you also need to add support for the new class and control to
>v4l2-common.c.
>The following functions should be extended:
>
>v4l2_ctrl_get_menu()
>v4l2_ctrl_get_name()
>v4l2_ctrl_query_fill()
Added code...
sound/soc/codecs/wl1273.c
Hans wrote:
> You might want to have this reviewed on the alsa mailinglist. I don't think
> anyone on the linux-media list has the expertise to review this audio codec.
Yes, good idea, I'll send it to the ALSA list...
drivers/media/radio/radio-wl1273.c
>> + return POLLIN | POLLOUT | POLLRDNORM;
>
> You also need to add POLLWRNORM.
>
> I wonder if this code is correct. Doesn't this depend on whether the device
> is in receive or transmit mode? So either poll returns POLLIN|POLLRDNORM or
> POLLOUT|POLLWRNORM. Or am I missing something?
I don't think you are missing anything. I've added code for RX and TX.
>> + strcpy(tuner->name, WL1273_FM_DRIVER_NAME);
>
> strlcpy
Fixed. There was also another strcpy. Fixed also that.
>> + tuner->rxsubchans = V4L2_TUNER_SUB_MONO | V4L2_TUNER_SUB_STEREO;
>
> You can't detect whether mono or stereo is received? Does the alsa codec
> always
> receive two channel audio? How does it handle mono vs stereo?
Stereo and mono modes can be detected. ALSA can also handle both...
The codec conforms automatically to the audio source/sink.
>> + tuner->capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_RDS;
>
> Shouldn't CAP_STEREO be added?
Added.
>> + tuner->rxsubchans |= V4L2_TUNER_SUB_RDS;
>
> tuner->audmode isn't filled!
Filled...
>> + r = wl1273_fm_set_rds(core, WL1273_RDS_OFF);
>
> There is no support for SUB_MONO or SUB_STEREO?
Actually there is...
>> + modulator->capability = V4L2_TUNER_CAP_RDS;
>
> Shouldn't CAP_LOW and CAP_STEREO be added here?
I agree.
>> + modulator->txsubchans &= ~V4L2_TUNER_SUB_RDS;
>
> The SUB_MONO/SUB_STEREO flags aren't handled here.
Handling added.
> The g/s_tuner and g/s_modulator functions are always hard to get right. Lots
> of
> tricky flags and settings...
I agree... I kind of left the stereo/mono stuff to alsa...
> As Mauro's review mentioned: please specify the unit of this spacing field!
> (It should be Hz).
> Don't forget to read and reply to Mauro's review as well!
OK. I put kHz as the spacing unit, that should be fine grained enough? I also
reformulated the text somewhat. And yes, I didn't notice Mauro's comments on
v4 patch set. But now I've read his comments and also given some comments
back.
Cheers,
Matti A.
Matti J. Aaltonen (5):
V4L2: Add seek spacing and FM RX class.
MFD: WL1273 FM Radio: MFD driver for the FM radio.
ASoC: WL1273 FM Radio Digital audio codec.
V4L2: WL1273 FM Radio: Controls for the FM radio.
Documentation: v4l: Add hw_seek spacing and FM_RX class
Documentation/DocBook/v4l/controls.xml | 71 +
.../DocBook/v4l/vidioc-s-hw-freq-seek.xml | 10 +-
drivers/media/radio/Kconfig| 15 +
drivers/media/radio/Makefile |1 +
drivers/media/radio/radio-wl1273.c | 1960
drivers/media/video/v4l2-common.c | 12 +
drivers/mfd/Kconfig|6 +
drivers/mfd/Makefile |2 +
drivers/mfd/wl1273-core.c | 613 ++
include/linux/mfd/wl1273-core.h| 313
include/linux/videodev2.h | 15 +-
sound/soc/codecs/Kconfig |6 +
sound/soc/codecs/Makefile |2 +
sound/soc/codecs/wl1273.c | 593 ++
sound/soc/codecs/wl1273.h | 42 +
15 files changed, 3658 insertions(+), 3 deletions(-)
create mode 100644 drivers/media/radio/radio-wl1273.c
create mode 100644 drivers/mfd/wl1273-core.c
create mode 100644 include/linux/mfd/wl1273-core.h
create mode 100644 sound/soc/codecs/wl1273.c
create mode 100644 sound/soc/codecs/wl1273.h
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 0/6] Add camera support to the OMAP1 Amstrad Delta videophone
Hi Janusz On Sun, 18 Jul 2010, Janusz Krzysztofik wrote: > This series consists of the following patches: > > 1/6 SoC Camera: add driver for OMAP1 camera interface > 2/6 OMAP1: Add support for SoC camera interface > 3/6 SoC Camera: add driver for OV6650 sensor > 4/6 SoC Camera: add support for g_parm / s_parm operations > 5/6 OMAP1: Amstrad Delta: add support for on-board camera > 6/6 OMAP1: Amstrad Delta: add camera controlled LEDS trigger It is an interesting decision to use soc-camera for an OMAP SoC, as you most probably know OMAP3 and OMAP2 camera drivers do not use soc-camera. I certainly do not want to discourage you from using soc-camera, just don't want you to go the wrong way and then regret it or spend time re-designing your driver. Have you had specific reasons for this design? Is OMAP1 so different from 2 (and 3)? In any case - thanks for the patches, if you do insist on going this path (;)) I'll review them and get back to you after that. Beware, it might be difficult to finish the review process in time for 2.6.36... Thanks Guennadi > > arch/arm/mach-omap1/board-ams-delta.c | 69 + > arch/arm/mach-omap1/devices.c | 43 > arch/arm/mach-omap1/include/mach/camera.h |8 > drivers/media/video/Kconfig | 20 > drivers/media/video/Makefile |2 > drivers/media/video/omap1_camera.c| 1656 > ++ > drivers/media/video/ov6650.c | 1336 > drivers/media/video/soc_camera.c | 18 > include/media/omap1_camera.h | 16 > include/media/v4l2-chip-ident.h |1 > 10 files changed, 3169 insertions(+) > > Thanks, > Janusz > --- 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
CAM Support for Terratec Cinergy S2 HD or Technisat SkyStar HD2
Hi,
I am using a Terratec Cinergy S2 HD with Mantis driver and so far the
card runs without problems.
The only thing is that CAM seems not to be supported - it is defined
out from the source code:
#if 0
err = mantis_ca_init(mantis);
if (err < 0) {
dprintk(MANTIS_ERROR, 1, "ERROR: Mantis CA initialization
failed <%d>", err);
}
#endif
My questions are:
1. Is anybody currently working on CAM support? Will it be supported soon?
2. Is there another DVB-S2 HD card which has CAM supported?
Thanks,
rinf
--
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 04/17] cx25840: Make cx25840 i2c register read transactions atomic
Hi Andy,
On Mon, 19 Jul 2010 21:11:46 -0400, Andy Walls wrote:
> There was a small window between writing the cx25840 register
> address over the i2c bus and reading the register contents back from the
> cx25840 device that the i2c adapter lock was released. This change ensures
> the
> adapter lock is not released until the register read is done.
>
> Signed-off-by: Andy Walls
Good catch.
Acked-by: Jean Delvare
Note that cx25840_and_or() still has a (smaller and less dangerous)
race window. If several calls to cx25840_and_or() happen in parallel on
the same register, some of the changes may be lost. I don't know if
this can be a problem in practice though. If it is, then additional
locking around cx25840_and_or() would be needed.
> ---
> drivers/media/video/cx25840/cx25840-core.c | 58
> +++-
> 1 files changed, 39 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/media/video/cx25840/cx25840-core.c
> b/drivers/media/video/cx25840/cx25840-core.c
> index bb4872b..4f908fa 100644
> --- a/drivers/media/video/cx25840/cx25840-core.c
> +++ b/drivers/media/video/cx25840/cx25840-core.c
> @@ -80,33 +80,53 @@ int cx25840_write4(struct i2c_client *client, u16 addr,
> u32 value)
>
> u8 cx25840_read(struct i2c_client * client, u16 addr)
> {
> - u8 buffer[2];
> - buffer[0] = addr >> 8;
> - buffer[1] = addr & 0xff;
> -
> - if (i2c_master_send(client, buffer, 2) < 2)
> - return 0;
> -
> - if (i2c_master_recv(client, buffer, 1) < 1)
> + struct i2c_msg msgs[2];
> + u8 tx_buf[2], rx_buf[1];
> +
> + /* Write register address */
> + tx_buf[0] = addr >> 8;
> + tx_buf[1] = addr & 0xff;
> + msgs[0].addr = client->addr;
> + msgs[0].flags = 0;
> + msgs[0].len = 2;
> + msgs[0].buf = (char *) tx_buf;
> +
> + /* Read data from register */
> + msgs[1].addr = client->addr;
> + msgs[1].flags = I2C_M_RD;
> + msgs[1].len = 1;
> + msgs[1].buf = (char *) rx_buf;
> +
> + if (i2c_transfer(client->adapter, msgs, 2) < 2)
> return 0;
>
> - return buffer[0];
> + return rx_buf[0];
> }
>
> u32 cx25840_read4(struct i2c_client * client, u16 addr)
> {
> - u8 buffer[4];
> - buffer[0] = addr >> 8;
> - buffer[1] = addr & 0xff;
> -
> - if (i2c_master_send(client, buffer, 2) < 2)
> - return 0;
> -
> - if (i2c_master_recv(client, buffer, 4) < 4)
> + struct i2c_msg msgs[2];
> + u8 tx_buf[2], rx_buf[4];
> +
> + /* Write register address */
> + tx_buf[0] = addr >> 8;
> + tx_buf[1] = addr & 0xff;
> + msgs[0].addr = client->addr;
> + msgs[0].flags = 0;
> + msgs[0].len = 2;
> + msgs[0].buf = (char *) tx_buf;
> +
> + /* Read data from registers */
> + msgs[1].addr = client->addr;
> + msgs[1].flags = I2C_M_RD;
> + msgs[1].len = 4;
> + msgs[1].buf = (char *) rx_buf;
> +
> + if (i2c_transfer(client->adapter, msgs, 2) < 2)
> return 0;
>
> - return (buffer[3] << 24) | (buffer[2] << 16) |
> - (buffer[1] << 8) | buffer[0];
> + return (rx_buf[3] << 24) | (rx_buf[2] << 16) | (rx_buf[1] << 8) |
> + rx_buf[0];
> }
>
> int cx25840_and_or(struct i2c_client *client, u16 addr, unsigned and_mask,
--
Jean Delvare
--
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
length of card field in v4l2_capability
Hi, the card field in struct v4l2_capability has a length equal to 32 which leads to weird card names like this: Avermedia PCI pure analog (M135 which is defined as: .name = "Avermedia PCI pure analog (M135A)", in saa7134/saa7134-cards.c. Is there a way to get the full card name from v4l2 or should that field enlarged to fit the current card names? Thanks, --- Ozan Çağlayan TUBITAK/UEKAE - Pardus Linux http://www.pardus.org.tr/eng -- 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
