Re: [PATCH] Nova-S-Plus audio line input
On Sat, 2010-08-07 at 10:29 -0400, Andy Walls wrote:
On Sat, 2010-07-31 at 16:37 +0200, lawrence rust wrote:
Hi everyone,
This patch adds audio DMA capture and ALSA mixer elements for the line
input jack of the Hauppauge Nova-S-plus DVB-S PCI card.
I'm using a Hauppauge Nova-S-plus PCI card to watch sat TV and it's been
very robust - thanks to everyone here. I have one minor niggle - when I
use it with composite video input from an external STB I can't connect
the audio to the line input jack on the card. So I developed this
patch, originally in late 2008 with lots of feedback and input from
Darron Broad.
The Nova-S-plus has a WM8775 ADC that is currently not detected. This
patch enables this chip and exports elements for ALSA mixer controls.
I've used this patch with kernels from 2.6.24 to 2.6.35-rc6 and I'm just
a little tired of tweaking it every time a new kernel comes out so I'm
hoping that it can be permanently included.
Signed-off by Lawrence Rust lawrence (at) softsystem.co.uk
diff --git a/drivers/media/video/cx88/cx88-alsa.c
b/drivers/media/video/cx88/cx88-alsa.c
index 33082c9..044516b 100644
--- a/drivers/media/video/cx88/cx88-alsa.c
+++ b/drivers/media/video/cx88/cx88-alsa.c
@@ -588,6 +588,30 @@ static int snd_cx88_volume_put(struct snd_kcontrol
*kcontrol,
int changed = 0;
u32 old;
+/* If a WM8775 is used for audio input utilise the audio controls */
+if ( core-board.audio_chip core-board.audio_chip ==
V4L2_IDENT_WM8775) {
+struct v4l2_control client_ctl;
+
+if ( value-value.integer.value[0] =
value-value.integer.value[1]) {
+v = value-value.integer.value[0] 10;
+b = value-value.integer.value[0] ?
+ (0x8000 * value-value.integer.value[1]) /
value-value.integer.value[0] :
+ 0x8000;
+} else {
+v = value-value.integer.value[1] 10;
+b = value-value.integer.value[1] ?
+ 0x - (0x8000 * value-value.integer.value[0]) /
value-value.integer.value[1] :
+ 0x8000;
+}
+client_ctl.value = v;
+client_ctl.id = V4L2_CID_AUDIO_VOLUME;
+call_all(core, core, s_ctrl, client_ctl);
+
+client_ctl.value = b;
+client_ctl.id = V4L2_CID_AUDIO_BALANCE;
+call_all(core, core, s_ctrl, client_ctl);
+}
+
With the subdev construct, there is really no need for the conditional
check on the chip's existence. Just do the call_all().
Or better yet, when the audio control subdevice is instantiated,
squirrel away a v4l2_subdev * to it in the card's instance structure and
just use that instead of call_all(). Or when the subdev is
instantiated, mark the subdev's grp_id with some sort of WM8775 or audio
control marker value and call the subdev by grp_ip match. Using
call_all() isn't the best thing to do, when you know you're just after
one or two specific devices.
OK, saving the v4l2_subdev * at instantiation looks best.
left = value-value.integer.value[0] 0x3f;
right = value-value.integer.value[1] 0x3f;
b = right - left;
@@ -601,10 +625,10 @@ static int snd_cx88_volume_put(struct snd_kcontrol
*kcontrol,
spin_lock_irq(chip-reg_lock);
old = cx_read(AUD_VOL_CTL);
if (v != (old 0x3f)) {
- cx_write(AUD_VOL_CTL, (old ~0x3f) | v);
+cx_swrite(SHADOW_AUD_VOL_CTL, AUD_VOL_CTL, (old ~0x3f) | v);
changed = 1;
}
- if (cx_read(AUD_BAL_CTL) != b) {
+if ((cx_read(AUD_BAL_CTL) 0x7f) != b) {
cx_write(AUD_BAL_CTL, b);
changed = 1;
}
@@ -619,7 +643,7 @@ static struct snd_kcontrol_new snd_cx88_volume = {
.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
.access = SNDRV_CTL_ELEM_ACCESS_READWRITE |
SNDRV_CTL_ELEM_ACCESS_TLV_READ,
- .name = Playback Volume,
+ .name = Tuner Volume,
I'd call this Analog TV Capture Volume myself, but meh, it doesn't
really matter.
I thought long and hard about this name to find something meaningful.
The problem I found was that many of the ALSA mixer GUIs leave little
space for the name or just truncate it. Analog-TV Volume might work -
avoiding the word break. I'll play with this some more.
.info = snd_cx88_volume_info,
.get = snd_cx88_volume_get,
.put = snd_cx88_volume_put,
@@ -650,7 +674,14 @@ static int snd_cx88_switch_put(struct snd_kcontrol
*kcontrol,
vol = cx_read(AUD_VOL_CTL);
if (value-value.integer.value[0] != !(vol bit)) {
vol ^= bit;
- cx_write(AUD_VOL_CTL, vol);
+cx_swrite(SHADOW_AUD_VOL_CTL, AUD_VOL_CTL, vol);
+/* If a WM8775 is used for audio input utilise the audio controls
*/
+if ( (16) == bit core-board.audio_chip
core-board.audio_chip == V4L2_IDENT_WM8775) {
+struct v4l2_control client_ctl;
+
[PATCH] USB DVB-T Stick CTX1921 Chipset DIB7770
Following small patch adds support for USB DVB-T device Creatix
CTX1921(DIB7770):
diff -r c9cb8918dcb2 linux/drivers/media/dvb/dvb-usb/dib0700_devices.c
--- a/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Tue Jun 01
12:47:42 2010 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Sun Aug 08
16:49:40 2010 +0200
@@ -2091,6 +2091,7 @@
{ USB_DEVICE(USB_VID_PINNACLE, USB_PID_PINNACLE_PCTV282E) },
{ USB_DEVICE(USB_VID_DIBCOM,USB_PID_DIBCOM_STK8096GP) },
{ USB_DEVICE(USB_VID_ELGATO,USB_PID_ELGATO_EYETV_DIVERSITY) },
+ { USB_DEVICE(USB_VID_MEDION,USB_PID_CREATIX_CTX1921) },
{ 0 } /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, dib0700_usb_id_table);
@@ -2606,7 +2607,7 @@
},
},
- .num_device_descs = 2,
+ .num_device_descs = 3,
.devices = {
{ DiBcom STK7770P reference design,
{ dib0700_usb_id_table[59], NULL },
@@ -2618,6 +2619,10 @@
dib0700_usb_id_table[60], NULL},
{ NULL },
},
+ { Medion CTX1921 DVB-T USB,
+ { dib0700_usb_id_table[69], NULL },
+ { NULL },
+ },
},
.rc_interval = DEFAULT_RC_INTERVAL,
.rc_key_map = ir_codes_dib0700_table,
diff -r c9cb8918dcb2 linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
--- a/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h Tue Jun 01
12:47:42 2010 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h Sun Aug 08
16:49:40 2010 +0200
@@ -107,6 +107,7 @@
#define USB_PID_DIBCOM_STK8096GP0x1fa0
#define USB_PID_DIBCOM_ANCHOR_2135_COLD0x2131
#define USB_PID_DIBCOM_STK7770P0x1e80
+#define USB_PID_CREATIX_CTX19210x1921
#define USB_PID_DPOSH_M9206_COLD 0x9206
#define USB_PID_DPOSH_M9206_WARM 0xa090
#define USB_PID_E3C_EC168 0x1689
--
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
knc1 dvb-c card frequently looses CAM when switching channels quickly
Hello, I have experienced the following on my vdr machine: When changing channels quickly between encrypted channels, the card loosses cam and I get the following in my /var/log/messages: [ 67.645354] dvb_ca adapter 0: DVB CAM detected and initialised successfully [ 84.659047] budget-av: cam inserted A [ 85.656855] dvb_ca adapter 0: DVB CAM detected and initialised successfully [60706.931218] budget-av: cam inserted A [60707.485891] dvb_ca adapter 0: DVB CAM detected and initialised successfully lspci -vvv 03:00.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: KNC One Device 0022 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 64 (3750ns min, 9500ns max) Interrupt: pin A routed to IRQ 19 Region 0: Memory at f9fffc00 (32-bit, non-prefetchable) [size=512] Kernel driver in use: budget_av I am using drivers from kernel 2.6.34. Any Ideas for solving this issue? Thx. Halim -- 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] dvb: siano: free spinlock before schedule()
On Wed, Jul 28, 2010 at 12:24:39AM +0200, Jiri Slaby wrote:
sorry for seeing this so late, was flooded with email lately.
There is a better fix (which fixes the potential NULL dereference):
http://lkml.org/lkml/2010/6/7/175
Richard, could you address the comments there and resend?
I am running this patch since many weeks (after fixing the compile error
obviously).
Did not implement your beautification suggestion yet, was doing all kinds of
experiments
with IR and had plenty of unrelated issues.
Richard
--- linux-2.6.34/drivers/media/dvb/siano/smscoreapi.c.rz2010-06-03
21:58:11.0 +0200
+++ linux-2.6.34/drivers/media/dvb/siano/smscoreapi.c 2010-06-07
14:32:06.0 +0200
@@ -1100,31 +1100,26 @@
*
* @return pointer to descriptor on success, NULL on error.
*/
-struct smscore_buffer_t *smscore_getbuffer(struct smscore_device_t *coredev)
+
+struct smscore_buffer_t *get_entry(struct smscore_device_t *coredev)
{
struct smscore_buffer_t *cb = NULL;
unsigned long flags;
- DEFINE_WAIT(wait);
-
spin_lock_irqsave(coredev-bufferslock, flags);
-
- /* This function must return a valid buffer, since the buffer list is
-* finite, we check that there is an available buffer, if not, we wait
-* until such buffer become available.
-*/
-
- prepare_to_wait(coredev-buffer_mng_waitq, wait, TASK_INTERRUPTIBLE);
-
- if (list_empty(coredev-buffers))
- schedule();
-
- finish_wait(coredev-buffer_mng_waitq, wait);
-
+ if (!list_empty(coredev-buffers)) {
cb = (struct smscore_buffer_t *) coredev-buffers.next;
list_del(cb-entry);
-
+ }
spin_unlock_irqrestore(coredev-bufferslock, flags);
+ return cb;
+}
+
+struct smscore_buffer_t *smscore_getbuffer(struct smscore_device_t *coredev)
+{
+ struct smscore_buffer_t *cb = NULL;
+
+ wait_event(coredev-buffer_mng_waitq, (cb = get_entry(coredev)));
return cb;
}
--
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] 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:Sun Aug 8 19:00:23 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14995:c9cb8918dcb2 git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 1c1371c2fe53ded8ede3a0404c9415fbf3321328 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/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: Tree for August 7 (IR)
On Sat, 7 Aug 2010 20:39:20 -0700 Randy Dunlap wrote: [adding linux-media] On Sat, 7 Aug 2010 16:07:10 +1000 Stephen Rothwell wrote: Hi all, As the merge window is open, please do not add 2.6.37 material to your linux-next included trees until after 2.6.36-rc1. Changes since 20100806: 2 sets of IR build errors (2 .config files attached): #5091: ERROR: ir_keydown [drivers/media/video/ir-kbd-i2c.ko] undefined! ERROR: __ir_input_register [drivers/media/video/ir-kbd-i2c.ko] undefined! ERROR: get_rc_map [drivers/media/video/ir-kbd-i2c.ko] undefined! ERROR: ir_input_unregister [drivers/media/video/ir-kbd-i2c.ko] undefined! ERROR: get_rc_map [drivers/media/video/cx88/cx88xx.ko] undefined! ERROR: ir_repeat [drivers/media/video/cx88/cx88xx.ko] undefined! ERROR: ir_input_unregister [drivers/media/video/cx88/cx88xx.ko] undefined! ERROR: ir_keydown [drivers/media/video/cx88/cx88xx.ko] undefined! ERROR: __ir_input_register [drivers/media/video/cx88/cx88xx.ko] undefined! ERROR: get_rc_map [drivers/media/video/bt8xx/bttv.ko] undefined! ERROR: ir_input_unregister [drivers/media/video/bt8xx/bttv.ko] undefined! ERROR: __ir_input_register [drivers/media/video/bt8xx/bttv.ko] undefined! ERROR: ir_g_keycode_from_table [drivers/media/IR/ir-common.ko] undefined! #5101: (.text+0x8306e2): undefined reference to `ir_core_debug' (.text+0x830729): undefined reference to `ir_core_debug' ir-functions.c:(.text+0x830906): undefined reference to `ir_core_debug' (.text+0x8309d8): undefined reference to `ir_g_keycode_from_table' (.text+0x830acf): undefined reference to `ir_core_debug' (.text+0x830b92): undefined reference to `ir_core_debug' (.text+0x830bef): undefined reference to `ir_core_debug' (.text+0x830c6a): undefined reference to `ir_core_debug' (.text+0x830cf7): undefined reference to `ir_core_debug' budget-ci.c:(.text+0x89f5c8): undefined reference to `ir_keydown' budget-ci.c:(.text+0x8a0c58): undefined reference to `get_rc_map' budget-ci.c:(.text+0x8a0c80): undefined reference to `__ir_input_register' budget-ci.c:(.text+0x8a0ee0): undefined reference to `get_rc_map' budget-ci.c:(.text+0x8a11cd): undefined reference to `ir_input_unregister' (.text+0x8a8adb): undefined reference to `ir_input_unregister' dvb-usb-remote.c:(.text+0x8a9188): undefined reference to `get_rc_map' dvb-usb-remote.c:(.text+0x8a91b1): undefined reference to `__ir_input_register' dvb-usb-remote.c:(.text+0x8a9238): undefined reference to `get_rc_map' dib0700_core.c:(.text+0x8b04ca): undefined reference to `ir_keydown' dib0700_devices.c:(.text+0x8b2ea8): undefined reference to `ir_keydown' dib0700_devices.c:(.text+0x8b2ef0): undefined reference to `ir_keydown' --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- 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: [libdvben50221] stack leaks resources on non-MMI session reconnect.
On 15/07/2010 15:20, Stephan Trebels wrote: The issue was, that LIBDVBEN50221 did not allow a CAM to re-establish the session holding non-MMI resources if using the lowlevel interface. The session_number was recorded on open, but not freed on close (which IMO is an bug in the code, I attach the scaled down hg changeset). With this change, the SMIT CAM with a showtime card works fine according to tests so far. The effect was, that the CAM tried to constantly close and re-open the session and the LIBDVBEN50221 kept telling it, that the resource is already allocated to a different session. Additionally this caused the library to use the _old_ session number in communications with the CAM, which did not even exist anymore, so caused all writes of CA PMTs to fail with EINTR. Stephan Hello Just to inform that this patch solves problems with CAM PowerCAM v4.3, so I think it can interest more people. Before gnutv -cammenu (and other applications using libdvben50221) was returning ti;eout (-3) errors constantly after the display of the system IDs. Now, the menu is working flawlessly I cannot test the descrambling for the moment but it improved quite a lot the situation (communication with th CAM is now possible). One note concerning the patch itself, the last else if (resource_id == EN50221_APP_MMI_RESOURCEID) is useless. Best regards -- Brice A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: OMAP3 Bridge Problems
Hi Lane,
On Thursday 05 August 2010 18:06:51 Lane Brooks wrote:
On 08/04/2010 02:57 PM, Laurent Pinchart wrote:
On Tuesday 03 August 2010 17:26:48 Lane Brooks wrote:
[snip]
My question:
- Are there other things I need to when I enable the parallel bridge?
For example, do I need to change a clock rate somewhere? From the TRM,
it seems like it should just work without any changes, but maybe I am
missing something.
Good question. ISP bridge and YUV modes support are not implemented in
the driver, but you're probably already aware of that.
I unfortunately have no straightforward answer. Try tracing the ISP
interrupts and monitoring the CCDC SBL busy bits to see if the CCDC
writes images to memory correctly.
I found at least some of the problem. In my platform data I was enabling
the bridge using the #defines in ispreg.h as in
static struct isp_platform_data bmi_isp_platform_data = {
.parallel = {
.data_lane_shift= 3,
.clk_pol= 0,
.bridge = ISPCTRL_PAR_BRIDGE_LENDIAN,
},
.subdevs = bmi_camera_subdevs,
};
The bridge related #defines in ispreg.h, however, have a shift of 2
applied to them. The problem is that the shift is applied again in isp.c
when the options are actually applied. In other words, the bridge
parameters are being shifted up twice, which is causing corruption to
the control register and causing my hanging problems when I try to
enable the bridge. It seems there are several other such cases in the
ispreg.h where double shifting might occur if the user tries to use them
in the platform data.
My question:
Is this an oversight or is it this way on purpose? Am I not supposed to
be using these defines in my platform definitions? It seems that *some*
of the parameters in ispreg.h should not be shifted up (like the bridge
options).
It's a bug, thanks for pointing it out. The value shouldn't be shifted again
in isp_select_bridge_input(). Do you want to submit a patch ?
--
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
Re: OMAP3 Bridge Problems
Hi Lane,
Thanks for the patch.
On Thursday 05 August 2010 20:53:50 Lane Brooks wrote:
[snip]
I was able to get YUV CCDC capture mode working with rather minimal
effort. Attached is a patch with the initial effort. Can you comment?
When sending patches for review, please send them inline instead of attaching
them to the mail. It makes the review easier.
diff --git a/drivers/media/video/isp/ispccdc.c
b/drivers/media/video/isp/ispccdc.c
index 90bcc6c..cc91fa1 100644
--- a/drivers/media/video/isp/ispccdc.c
+++ b/drivers/media/video/isp/ispccdc.c
@@ -1563,6 +1563,15 @@ __ccdc_get_format(struct isp_ccdc_device *ccdc,
struct v4l2_subdev_fh *fh,
* @pad: Pad number
* @fmt: Format
*/
+
+static enum v4l2_mbus_pixelcode sink_fmts[] = {
+ V4L2_MBUS_FMT_SGRBG10_1X10,
+ V4L2_MBUS_FMT_YUYV16_1X16,
+ V4L2_MBUS_FMT_UYVY16_1X16,
+ V4L2_MBUS_FMT_YVYU16_1X16,
+ V4L2_MBUS_FMT_VYUY16_1X16,
+};
+
static void
ccdc_try_format(struct isp_ccdc_device *ccdc, struct v4l2_subdev_fh *fh,
unsigned int pad, struct v4l2_mbus_framefmt *fmt,
There's a very similar patch that is currently pending in my queue. It adds
support for other Bayer patterns. Your overall approach is good, but the two
patches will conflict.
Once the other one will get committed, your patch will become much simpler. I
thus won't comment on the parts that will disappear then.
@@ -1719,6 +1736,45 @@ static int ccdc_set_format(struct v4l2_subdev *sd,
struct v4l2_subdev_fh *fh,
/* Propagate the format from sink to source */
if (pad == CCDC_PAD_SINK) {
+ u32 syn_mode, ispctrl_val;
+ struct isp_device *isp = to_isp_device(ccdc);
+ if (!isp_get(isp))
+ return -EBUSY;
+
+ syn_mode= isp_reg_readl(isp, OMAP3_ISP_IOMEM_CCDC,
+ ISPCCDC_SYN_MODE);
+ ispctrl_val = isp_reg_readl(isp, OMAP3_ISP_IOMEM_MAIN,
+ ISP_CTRL);
+ syn_mode= ISPCCDC_SYN_MODE_INPMOD_MASK;
+ ispctrl_val = ~(ISPCTRL_PAR_BRIDGE_MASK
+ ISPCTRL_PAR_BRIDGE_SHIFT);
+ switch(format-code) {
Documentation/CodingStyle requires a space after the switch keyword. Please
run scripts/checkpatch.pl before submitting patches.
+ case V4L2_MBUS_FMT_YUYV16_1X16:
+ case V4L2_MBUS_FMT_UYVY16_1X16:
+ case V4L2_MBUS_FMT_YVYU16_1X16:
+ case V4L2_MBUS_FMT_VYUY16_1X16:
+ syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR16;
+
+ /* TODO: In YCBCR16 mode, the bridge has to be
+ * enabled, so we enable it here and force it
+ * big endian. Whether to do big or little endian
+ * should somehow come from the platform data.*/
+ ispctrl_val |= ISPCTRL_PAR_BRIDGE_BENDIAN
+ ISPCTRL_PAR_BRIDGE_SHIFT;
+ break;
+ default:
+ syn_mode |= ISPCCDC_SYN_MODE_INPMOD_RAW;
+ ispctrl_val |= isp-pdata-parallel.bridge
+ ISPCTRL_PAR_BRIDGE_SHIFT;
+ break;
+ }
+ isp_reg_writel(isp, syn_mode, OMAP3_ISP_IOMEM_CCDC,
+ISPCCDC_SYN_MODE);
Writing to the ISPCCDC_SYN_MODE register should be moved to ccdc_configure().
Just move the switch statement there right after the
format = ccdc-formats[CCDC_PAD_SINK];
line (without the ispctrl_val settings), it should be enough.
+ isp_reg_writel(isp, ispctrl_val, OMAP3_ISP_IOMEM_MAIN,
+ISP_CTRL);
The ISP_CTRL register should be written in isp_select_bridge_input() only. As
you correctly mention, whether the data is in little endian or big endian
format should come from platform data, so I think it's fine to force board
files to set the isp-pdata-parallel.bridge field to the correct value.
+ isp_put(isp);
+
+
format = __ccdc_get_format(ccdc, fh, CCDC_PAD_SOURCE_OF, which);
memcpy(format, fmt, sizeof(*format));
ccdc_try_format(ccdc, fh, CCDC_PAD_SOURCE_OF, format, which);
diff --git a/drivers/media/video/isp/ispreg.h
b/drivers/media/video/isp/ispreg.h
index 7efcfaa..4c191af 100644
--- a/drivers/media/video/isp/ispreg.h
+++ b/drivers/media/video/isp/ispreg.h
@@ -732,10 +732,10 @@
#define ISPCTRL_PAR_SER_CLK_SEL_MASK 0xFFFC
#define ISPCTRL_PAR_BRIDGE_SHIFT 2
-#define ISPCTRL_PAR_BRIDGE_DISABLE (0x0 2)
-#define ISPCTRL_PAR_BRIDGE_LENDIAN (0x2 2)
-#define ISPCTRL_PAR_BRIDGE_BENDIAN (0x3 2)
-#define ISPCTRL_PAR_BRIDGE_MASK (0x3 2)
+#define ISPCTRL_PAR_BRIDGE_DISABLE 0x0
+#define
Re: OMAP3 Bridge Problems
On 08/08/2010 04:13 PM, Laurent Pinchart wrote:
Hi Lane,
On Thursday 05 August 2010 18:06:51 Lane Brooks wrote:
On 08/04/2010 02:57 PM, Laurent Pinchart wrote:
On Tuesday 03 August 2010 17:26:48 Lane Brooks wrote:
[snip]
My question:
- Are there other things I need to when I enable the parallel bridge?
For example, do I need to change a clock rate somewhere? From the TRM,
it seems like it should just work without any changes, but maybe I am
missing something.
Good question. ISP bridge and YUV modes support are not implemented in
the driver, but you're probably already aware of that.
I unfortunately have no straightforward answer. Try tracing the ISP
interrupts and monitoring the CCDC SBL busy bits to see if the CCDC
writes images to memory correctly.
I found at least some of the problem. In my platform data I was enabling
the bridge using the #defines in ispreg.h as in
static struct isp_platform_data bmi_isp_platform_data = {
.parallel = {
.data_lane_shift= 3,
.clk_pol= 0,
.bridge = ISPCTRL_PAR_BRIDGE_LENDIAN,
},
.subdevs = bmi_camera_subdevs,
};
The bridge related #defines in ispreg.h, however, have a shift of 2
applied to them. The problem is that the shift is applied again in isp.c
when the options are actually applied. In other words, the bridge
parameters are being shifted up twice, which is causing corruption to
the control register and causing my hanging problems when I try to
enable the bridge. It seems there are several other such cases in the
ispreg.h where double shifting might occur if the user tries to use them
in the platform data.
My question:
Is this an oversight or is it this way on purpose? Am I not supposed to
be using these defines in my platform definitions? It seems that *some*
of the parameters in ispreg.h should not be shifted up (like the bridge
options).
It's a bug, thanks for pointing it out. The value shouldn't be shifted again
in isp_select_bridge_input(). Do you want to submit a patch ?
The isp_parallel_platform_data struct specifies the bridge definition as
2 bits, so if the shift is removed from isp_select_bridge instead of
from the ispreg.h file, then the platform_data definition needs modified
as well. Is that what you want?
--
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: OMAP3 Bridge Problems
Hi Lane,
On Monday 09 August 2010 00:34:24 Lane Brooks wrote:
On 08/08/2010 04:13 PM, Laurent Pinchart wrote:
On Thursday 05 August 2010 18:06:51 Lane Brooks wrote:
On 08/04/2010 02:57 PM, Laurent Pinchart wrote:
On Tuesday 03 August 2010 17:26:48 Lane Brooks wrote:
[snip]
My question:
- Are there other things I need to when I enable the parallel bridge?
For example, do I need to change a clock rate somewhere? From the TRM,
it seems like it should just work without any changes, but maybe I am
missing something.
Good question. ISP bridge and YUV modes support are not implemented in
the driver, but you're probably already aware of that.
I unfortunately have no straightforward answer. Try tracing the ISP
interrupts and monitoring the CCDC SBL busy bits to see if the CCDC
writes images to memory correctly.
I found at least some of the problem. In my platform data I was enabling
the bridge using the #defines in ispreg.h as in
static struct isp_platform_data bmi_isp_platform_data = {
.parallel = {
.data_lane_shift= 3,
.clk_pol= 0,
.bridge = ISPCTRL_PAR_BRIDGE_LENDIAN,
},
.subdevs = bmi_camera_subdevs,
};
The bridge related #defines in ispreg.h, however, have a shift of 2
applied to them. The problem is that the shift is applied again in isp.c
when the options are actually applied. In other words, the bridge
parameters are being shifted up twice, which is causing corruption to
the control register and causing my hanging problems when I try to
enable the bridge. It seems there are several other such cases in the
ispreg.h where double shifting might occur if the user tries to use them
in the platform data.
My question:
Is this an oversight or is it this way on purpose? Am I not supposed to
be using these defines in my platform definitions? It seems that *some*
of the parameters in ispreg.h should not be shifted up (like the bridge
options).
It's a bug, thanks for pointing it out. The value shouldn't be shifted
again in isp_select_bridge_input(). Do you want to submit a patch ?
The isp_parallel_platform_data struct specifies the bridge definition as
2 bits, so if the shift is removed from isp_select_bridge instead of
from the ispreg.h file, then the platform_data definition needs modified
as well. Is that what you want?
Good point. I think it's important to keep the registers definitions
consistent (they all have - or should have - the shift applied), so please
extend the bridge field to 4 bits.
--
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
Re: OMAP3 Bridge Problems
On 08/08/2010 04:29 PM, Laurent Pinchart wrote: Hi Lane, Thanks for the patch. On Thursday 05 August 2010 20:53:50 Lane Brooks wrote: [snip] I was able to get YUV CCDC capture mode working with rather minimal effort. Attached is a patch with the initial effort. Can you comment? Writing to the ISPCCDC_SYN_MODE register should be moved to ccdc_configure(). Just move the switch statement there right after the format =ccdc-formats[CCDC_PAD_SINK]; line (without the ispctrl_val settings), it should be enough. + isp_reg_writel(isp, ispctrl_val, OMAP3_ISP_IOMEM_MAIN, + ISP_CTRL); The ISP_CTRL register should be written in isp_select_bridge_input() only. As you correctly mention, whether the data is in little endian or big endian format should come from platform data, so I think it's fine to force board files to set the isp-pdata-parallel.bridge field to the correct value. Putting the bridge settings in the platform data is tricky because they need to change depending on the selected format. For example, for my board, when in SGRBG mode, the bridge needs disabled. When in YUV16 mode, however, I need need to select BIG/LITTLE endian depending on whether it is YUYV or UYVY or ... I am not quite sure how to capture that in the platform data without enumerating every supported format code in the platform data. The current patch knows (based on the OMAP TRM) that YUV16 mode requires the bridge to be enabled. So in the platform data I specify the bridge state for SGBRG mode and force the bridge to BIG endian in YUV16 mode. This leaves the sensor to switch the phasing based on YUYV, YVYU, etc. mode. I am not sure who should be in charge of doing byte swapping in general, but if the input and output modes are the same, then big endian should be used to avoid a byte swap. In other words, the mode is completely determinable based on the formats, so perhaps I should implement it that way. If the input and output port require a byte swap, then go little endian, otherwise go big endian. The reason why I put both writes to the ISPCTRL and SYN_MODE registers where I did. Moving them to other places will require querying the selected format code. Is that what you want as well? Lane -- 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
pinnacle 801e help please!
I am new to Linux (somewhat) and I am running Linux mint 9. So far so good, I have replaced dreamweaver with NVU, office with open office. Outlook with evolution and so on. Everything is now perfect no looking back to windows except I just spent about 1.5 hours going through configuring mythtv only to find it doesn't think my pinnacle usb hd stick is a dvb device. So i did more research and stumbled upon all of your hard work and tried downloading the tar for my device but it wouldn't download. 2 questions 1) will this device work now 2) how do I implement all of you fixes in mint Linux 9 gnome running mythtv? thanks for any help Ray -- 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: pinnacle 801e help please!
On Sun, Aug 8, 2010 at 7:53 PM, Ray Bullins bbull...@triad.rr.com wrote: I am new to Linux (somewhat) and I am running Linux mint 9. So far so good, I have replaced dreamweaver with NVU, office with open office. Outlook with evolution and so on. Everything is now perfect no looking back to windows except I just spent about 1.5 hours going through configuring mythtv only to find it doesn't think my pinnacle usb hd stick is a dvb device. So i did more research and stumbled upon all of your hard work and tried downloading the tar for my device but it wouldn't download. 2 questions 1) will this device work now 2) how do I implement all of you fixes in mint Linux 9 gnome running mythtv? thanks for any help Ray The 801e driver only has support currently for ATSC/ClearQAM (which is why it appears as a DVB device). The driver does not have any support for analog (e.g. the analog tuner or the composite/s-video inputs). Run ls /dev/dvb/adapter0/frontend0 and if you see an entry then the driver loaded successfully. Also, you may need to load firmware (it's bundled by default with a number of distributions but I don't know about Mint). If you don't have it, you can get it here: http://kernellabs.com/firmware/dib0700/ Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL for 2.6.36] drivers/media updates
Linus, Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git v4l_for_linus It contains some patches that were waiting for updates at some ARM trees, several improvements at Remote Controllers (including the migration of some drivers from staging), a new driver for the camera found on Samsung cellphones, and some other misc improvements, fixes and cleanups. Thanks, Mauro --- The following changes since commit 45d7f32c7a43cbb9592886d38190e379e2eb2226: Merge git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile (2010-08-08 10:10:11 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git v4l_for_linus Andy Shevchenko (2): V4L/DVB: drivers: usbvideo: remove custom implementation of hex_to_bin() V4L/DVB: media: video: pvrusb2: remove custom hex_to_bin() Andy Walls (20): V4L/DVB: cx25840: Make cx25840 i2c register read transactions atomic V4L/DVB: cx23885: Add correct detection of the HVR-1250 model 79501 V4L/DVB: cx23885: Add a VIDIOC_LOG_STATUS ioctl function for analog video devices V4L/DVB: v4l2_subdev: Add s_io_pin_config to v4l2_subdev_core_ops V4L/DVB: cx25840: Add s_io_pin_config core subdev ops for the CX2388[578] V4L/DVB: v4l2_subdev, cx23885: Differentiate IR carrier sense and I/O pin inversion V4L/DVB: cx23885: For CX23888 IR, configure the IO pin mux IR pins explcitly V4L/DVB: v4l2_subdev: Move interrupt_service_routine ptr to v4l2_subdev_core_ops V4L/DVB: cx25840: Add support for CX2388[57] A/V core integrated IR controllers V4L/DVB: cx23885: Add a v4l2_subdev group id for the CX2388[578] integrated AV core V4L/DVB: cx23885: Add preliminary IR Rx support for the HVR-1250 and TeVii S470 V4L/DVB: cx23885: Protect PCI interrupt mask manipulations with a spinlock V4L/DVB: cx23885: Move AV Core irq handling to a work handler V4L/DVB: cx23885: Require user to explicitly enable CX2388[57] IR via module param V4L/DVB: cx23885: Change Kconfig dependencies to new IR_CORE functions V4L/DVB: cx23885, cx25840: Report IR max pulse width regardless of mod/demod use V4L/DVB: cx23885, cx25840: Report the actual length of an IR Rx timeout event V4L/DVB: cx23885, cx25840: Change IR measurment records to use struct ir_raw_event V4L/DVB: v4l2_subdev: Get rid of now unused IR pulse width defines V4L/DVB: IR keymap: Add print button for HP OEM version of MCE remote Arnuschky (1): V4L/DVB: Report supported QAM modes on bt8xx Dan Carpenter (1): V4L/DVB: media: ir-keytable: null dereference in debug code Guennadi Liakhovetski (2): V4L/DVB: soc-camera: prohibit S_CROP, if internal G_CROP has failed V4L/DVB: V4L: do not autoselect components on embedded systems Hans Verkuil (15): V4L/DVB: v4l2: Add new control handling framework V4L/DVB: v4l2-ctrls: reorder 'case' statements to match order in header V4L/DVB: Documentation: add v4l2-controls.txt documenting the new controls API V4L/DVB: v4l2: hook up the new control framework into the core framework V4L/DVB: saa7115: convert to the new control framework V4L/DVB: msp3400: convert to the new control framework V4L/DVB: saa717x: convert to the new control framework V4L/DVB: cx25840/ivtv: replace ugly priv control with s_config V4L/DVB: cx25840: convert to the new control framework V4L/DVB: cx2341x: convert to the control framework V4L/DVB: wm8775: convert to the new control framework V4L/DVB: cs53l32a: convert to new control framework V4L/DVB: wm8739: convert to the new control framework V4L/DVB: ivtv: convert gpio subdev to new control framework V4L/DVB: ivtv: convert to the new control framework Janne Grunau (1): V4L/DVB: staging/lirc: fix Kconfig dependencies Jarod Wilson (7): V4L/DVB: IR/imon: remove incorrect calls to input_free_device V4L/DVB: IR/imon: remove bad ir_input_dev use V4L/DVB: IR/mceusb: remove bad ir_input_dev use V4L/DVB: staging/lirc: fix non-CONFIG_MODULES build horkage V4L/DVB: IR/mceusb: less generic callback name and remove cruft V4L/DVB: staging/lirc: port lirc_streamzap to ir-core V4L/DVB: IR: put newly ported streamzap driver in proper home Jean Delvare (3): V4L/DVB: cx23885: Return -ENXIO on slave nack V4L/DVB: cx23885: Check for slave nack on all transactions V4L/DVB: cx23885: i2c_wait_done returns 0 or 1, don't check for 0 return value Jean-François Moine (18): V4L/DVB: gspca - sonixj / sq930x / t613: Remove unused variable in struct sd V4L/DVB: gspca - main: Version change V4L/DVB: gspca - sq930x: Bad init sequence for sensor mt9v111 V4L/DVB: gspca - sq930x: Change the gain value for Micron sensors V4L/DVB: gspca - sq930x: Change the default values of gain and
