Re: SDMC DM1105N not being detected
Shows up now, but doesnt load the frontend :/
DVB: registering new adapter (dm1105)
dm1105 :00:08.0: MAC ff:ff:ff:ff:ff:ff
dm1105 :00:08.0: could not attach frontend
00:08.0 Ethernet controller: Unknown device 195d:1105 (rev 10)
Subsystem: Unknown device 195d:1105
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR- I wrote code to support card with subsystem/device 195d/1105, but no one
> reported success, so I
> decided to not include it in commit :(
>
> It was more then one year ago
>
> http://liplianin.at.tut.by/dvblipl.tar.bz2
>
> http://liplianin.at.tut.by/ds110en.html
> --
> Igor M. Liplianin
> Microsoft Windows Free Zone - Linux used for all Computing Tasks
>
diff -Naur s2-liplianin-org/linux/drivers/media/dvb/dm1105/dm1105.c s2-liplianin/linux/drivers/media/dvb/dm1105/dm1105.c
--- s2-liplianin-org/linux/drivers/media/dvb/dm1105/dm1105.c 2009-04-04 15:25:28.0 +1300
+++ s2-liplianin/linux/drivers/media/dvb/dm1105/dm1105.c 2009-04-04 16:59:20.0 +1300
@@ -54,12 +54,21 @@
#ifndef PCI_DEVICE_ID_DM1105
#define PCI_DEVICE_ID_DM1105 0x036f
#endif
+#ifndef PCI_DEVICE_ID_DM1105S
+#define PCI_DEVICE_ID_DM1105S 0x1105
+#endif
+#ifndef PCI_VENDOR_ID_AXESS
+#define PCI_VENDOR_ID_AXESS 0x195d
+#endif
#ifndef PCI_DEVICE_ID_DW2002
#define PCI_DEVICE_ID_DW2002 0x2002
#endif
#ifndef PCI_DEVICE_ID_DW2004
#define PCI_DEVICE_ID_DW2004 0x2004
#endif
+#ifndef PCI_DEVICE_ID_DM05
+#define PCI_DEVICE_ID_DM05 0x1105
+#endif
/* --- */
/* sdmc dm1105 registers */
@@ -150,6 +159,11 @@
#define DM1105_LNB_13V0x00010100
#define DM1105_LNB_18V0x0100
+/* GPIO's for LNB power control for Axess DM05 - EXPERIMENTAL!*/
+#define DM05_LNB_MASK0xfffc
+#define DM05_LNB_13V0x3fffd
+#define DM05_LNB_18V0x3fffc
+
static int ir_debug;
module_param(ir_debug, int, 0644);
MODULE_PARM_DESC(ir_debug, "enable debugging information for IR decoding");
@@ -316,7 +330,8 @@
static int dm1105dvb_set_voltage(struct dvb_frontend *fe, fe_sec_voltage_t voltage)
{
struct dm1105dvb *dm1105dvb = frontend_to_dm1105dvb(fe);
-
+ switch (dm1105dvb->pdev->subsystem_device){
+ case PCI_DEVICE_ID_DW2002:
if (voltage == SEC_VOLTAGE_18) {
outl(DM1105_LNB_MASK, dm_io_mem(DM1105_GPIOCTR));
outl(DM1105_LNB_18V, dm_io_mem(DM1105_GPIOVAL));
@@ -325,7 +340,19 @@
outl(DM1105_LNB_MASK, dm_io_mem(DM1105_GPIOCTR));
outl(DM1105_LNB_13V, dm_io_mem(DM1105_GPIOVAL));
}
-
+ break;
+
+ case PCI_DEVICE_ID_DM05:
+if (voltage == SEC_VOLTAGE_18) {
+ outl(DM05_LNB_MASK, dm_io_mem(DM1105_GPIOCTR));
+ outl(DM05_LNB_18V, dm_io_mem(DM1105_GPIOVAL));
+}else {
+/*LNB ON-13V by default!*/
+ outl(DM05_LNB_MASK, dm_io_mem(DM1105_GPIOCTR));
+ outl(DM05_LNB_13V, dm_io_mem(DM1105_GPIOVAL));
+}
+break;
+}
return 0;
}
@@ -632,6 +659,7 @@
dm1105dvb_set_voltage;
}
break;
+
case PCI_DEVICE_ID_DW2004:
dm1105dvb->fe = dvb_attach(
cx24116_attach, &serit_sp2633_config,
@@ -870,6 +898,11 @@
.subvendor = PCI_ANY_ID,
.subdevice = PCI_DEVICE_ID_DW2004,
}, {
+ .vendor = PCI_VENDOR_ID_AXESS,
+ .device = PCI_DEVICE_ID_DM1105S,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_DEVICE_ID_DM05,
+ }, {
/* empty */
},
};
Re: Kernel 2.6.29 breaks DVB-T ASUSTeK Tiger LNA Hybrid Capture Device
Am Samstag, den 04.04.2009, 02:45 +0200 schrieb hermann pitton:
> Hi Ralph,
>
> Am Freitag, den 03.04.2009, 20:49 + schrieb Ralph:
> > ASUSTeK Tiger LNA Hybrid Capture Device PCI - Analog/DVB-T card
> > Multimedia controller: Philips Semiconductors SAA7131/SAA7133/SAA7135 Video
> > Broadcast Decoder (rev d1)
> >
> > Works perfectly with kernel 2.6.28.4 (or older).
> > Recently, I have switched to 2.6.29 (same .config as 2.6.28.4) and now, at
> > boot
> > time, I get the message:
> >
> > IRQ 18/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs
> >
> > Signal strength is very low and Kaffeine is unable to tune in any channel.
> > Same problem with kernel 2.6.29.1
> >
> > -
> >
> > Messages from /var/log/dmesg
> >
> > saa7134 :03:0a.0: PCI INT A -> Link[APC3] -> GSI 18 (level, low) -> \
> > IRQ 18
> > saa7133[0]: found at :03:0a.0, rev: 209, irq: 18, latency: 32, mmio: \
> > 0xfdefe000
> > saa7133[0]: subsystem: 1043:4871, board: ASUS P7131 4871 \
> > [card=111,autodetected]
> > saa7133[0]: board init: gpio is 0
> > IRQ 18/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs
> > saa7133[0]: i2c eeprom 00: 43 10 71 48 54 20 1c 00 43 43 a9 1c 55 d2 b2 92
> > saa7133[0]: i2c eeprom 10: ff ff ff 0f ff 20 ff ff ff ff ff ff ff ff ff ff
> > saa7133[0]: i2c eeprom 20: 01 40 01 02 03 00 01 03 08 ff 00 cf ff ff ff ff
> > saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > saa7133[0]: i2c eeprom 40: ff 21 00 c2 96 10 03 22 15 50 ff ff ff ff ff ff
> > saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > tuner' 2-004b: chip found @ 0x96 (saa7133[0])
> > tda829x 2-004b: setting tuner address to 61
> > tda829x 2-004b: type set to tda8290+75a
> > saa7133[0]: registered device video0 [v4l2]
> > saa7133[0]: registered device vbi0
> > dvb_init() allocating 1 frontend
> > DVB: registering new adapter (saa7133[0])
> > DVB: registering adapter 0 frontend -32769 (Philips TDA10046H DVB-T)...
> > tda1004x: setting up plls for 48MHz sampling clock
> > tda1004x: timeout waiting for DSP ready
> > tda1004x: found firmware revision 0 -- invalid
> > tda1004x: trying to boot from eeprom
> > tda1004x: timeout waiting for DSP ready
> > tda1004x: found firmware revision 0 -- invalid
> > tda1004x: waiting for firmware upload...
> > saa7134 :03:0a.0: firmware: requesting dvb-fe-tda10046.fw
> > tda1004x: found firmware revision 29 -- ok
> > saa7134 ALSA driver for DMA sound loaded
> > IRQ 18/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs
> > saa7133[0]/alsa: saa7133[0] at 0xfdefe000 irq 18 registered as card -1
> >
>
> thanks for your report, as announced previously, I unfortunately did not
> have time to run with latest always ... (guess why ...)
>
> The driver always worked with shared IRQs, if not, it was always a
> limitation of certain hardware or mostly in some combination with binary
> only drivers.
>
> If the above should be the case in general now, and not only caused by
> some blacklist, no print out in that direction, the driver is pretty
> broken again.
>
> I for sure don't have all for last months, but that
> "IRQF_DISABLED is not guaranteed on shared IRQs" for sure does not come
> from us here.
Do use something unusual like pollirq or something?
We only have in saa7134-core.c
/* initialize hardware #1 */
saa7134_board_init1(dev);
saa7134_hwinit1(dev);
/* get irq */
err = request_irq(pci_dev->irq, saa7134_irq,
IRQF_SHARED | IRQF_DISABLED, dev->name, dev);
if (err < 0) {
printk(KERN_ERR "%s: can't get IRQ %d\n",
dev->name,pci_dev->irq);
goto fail3;
}
and in saa7134-alsa.c
err = request_irq(dev->pci->irq, saa7134_alsa_irq,
IRQF_SHARED | IRQF_DISABLED, dev->name,
(void*) &dev->dmasound);
if (err < 0) {
printk(KERN_ERR "%s: can't get IRQ %d for ALSA\n",
dev->name, dev->pci->irq);
goto __nodev;
}
Have fun ;)
Hermann
--
To unsubscribe f
Re: Kernel 2.6.29 breaks DVB-T ASUSTeK Tiger LNA Hybrid Capture Device
Hi Ralph, Am Freitag, den 03.04.2009, 20:49 + schrieb Ralph: > ASUSTeK Tiger LNA Hybrid Capture Device PCI - Analog/DVB-T card > Multimedia controller: Philips Semiconductors SAA7131/SAA7133/SAA7135 Video > Broadcast Decoder (rev d1) > > Works perfectly with kernel 2.6.28.4 (or older). > Recently, I have switched to 2.6.29 (same .config as 2.6.28.4) and now, at > boot > time, I get the message: > > IRQ 18/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs > > Signal strength is very low and Kaffeine is unable to tune in any channel. > Same problem with kernel 2.6.29.1 > > - > > Messages from /var/log/dmesg > > saa7134 :03:0a.0: PCI INT A -> Link[APC3] -> GSI 18 (level, low) -> \ > IRQ 18 > saa7133[0]: found at :03:0a.0, rev: 209, irq: 18, latency: 32, mmio: \ > 0xfdefe000 > saa7133[0]: subsystem: 1043:4871, board: ASUS P7131 4871 \ > [card=111,autodetected] > saa7133[0]: board init: gpio is 0 > IRQ 18/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs > saa7133[0]: i2c eeprom 00: 43 10 71 48 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 > saa7133[0]: i2c eeprom 10: ff ff ff 0f ff 20 ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom 20: 01 40 01 02 03 00 01 03 08 ff 00 cf ff ff ff ff > saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom 40: ff 21 00 c2 96 10 03 22 15 50 ff ff ff ff ff ff > saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > tuner' 2-004b: chip found @ 0x96 (saa7133[0]) > tda829x 2-004b: setting tuner address to 61 > tda829x 2-004b: type set to tda8290+75a > saa7133[0]: registered device video0 [v4l2] > saa7133[0]: registered device vbi0 > dvb_init() allocating 1 frontend > DVB: registering new adapter (saa7133[0]) > DVB: registering adapter 0 frontend -32769 (Philips TDA10046H DVB-T)... > tda1004x: setting up plls for 48MHz sampling clock > tda1004x: timeout waiting for DSP ready > tda1004x: found firmware revision 0 -- invalid > tda1004x: trying to boot from eeprom > tda1004x: timeout waiting for DSP ready > tda1004x: found firmware revision 0 -- invalid > tda1004x: waiting for firmware upload... > saa7134 :03:0a.0: firmware: requesting dvb-fe-tda10046.fw > tda1004x: found firmware revision 29 -- ok > saa7134 ALSA driver for DMA sound loaded > IRQ 18/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs > saa7133[0]/alsa: saa7133[0] at 0xfdefe000 irq 18 registered as card -1 > thanks for your report, as announced previously, I unfortunately did not have time to run with latest always ... (guess why ...) The driver always worked with shared IRQs, if not, it was always a limitation of certain hardware or mostly in some combination with binary only drivers. If the above should be the case in general now, and not only caused by some blacklist, no print out in that direction, the driver is pretty broken again. I for sure don't have all for last months, but that "IRQF_DISABLED is not guaranteed on shared IRQs" for sure does not come from us here. Cheers, Hermann -- 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
When is a wake_up() not a wake up?
Hi. I've got a problem where in the cx18 driver, the wake_up() call
doesn't seem to be waking up a process or work queue thread that tried
to wait on a wait queue.
While doing some investigation, I found I was unable to understand the
conditions under which try_to_wake_up() will return success or not. Can
anyone give short summary on the conditions under which it does not?
FYI:
$ uname -a
Linux palomino.walls.org 2.6.27.9-159.fc10.x86_64 #1 SMP Tue Dec 16 14:47:52
EST 2008 x86_64 x86_64 x86_64 GNU/Linux
Also, just to provide some context on the larger problem, here's what's
supposed to happen in the cx18 driver:
1. A work queue thread or read() call needs to send a command to the
CX23418 using the cx18_api_call() function
2. It fills out a mailbox with a command for the CX23418
3. It prepares to wait, just in case a wait is needed
4. A SW1 interrupt is sent to the CX23418 telling it a mailbox is ready
5. The ack filed in the mailbox, a PCI MMIO location, is checked to see
if the mailbox was ack'ed already
6. If not, schedule_timeout() for up to 10 msecs (a near eternity...)
7. Clean up the wait and move on
In response to the SW1 interrupt in step 4 above, the CX23418 processes
the command mailbox, fills out the "ack" field in the mailbox with a
good value, and sends a SW2 ack interrupt back. The cx18_irq_hander()
calls wake_up() in response to this.
However, I am running across occasions where the maximum timeout has
expired, and the mailbox has been ack'ed. It's as if the wake_up()
didn't work. Here's a sample from the log:
Mar 31 23:36:56 palomino kernel: cx18-0: irq: sending interrupt SW1: 8 to send
CX18_CPU_DE_SET_MDL
Mar 31 23:36:56 palomino kernel: cx18-0: api: scheduling to wait for ack of
CX18_CPU_DE_SET_MDL: req 51267 ack 51266, pid 21092, state 2
Mar 31 23:36:56 palomino kernel: cx18-0: irq: received interrupts SW1: 0 SW2:
8 HW2: 0
Mar 31 23:36:56 palomino kernel: cx18-0: irq: Wake up initiated on pid 21092
in state 2
Mar 31 23:36:56 palomino kernel: cx18-0: irq: Wake up succeeded on pid 21092,
state 2 -> 0
Mar 31 23:36:56 palomino kernel: cx18-0: api: done wait for ack of
CX18_CPU_DE_SET_MDL: req 51267 ack 51267, current pid 21092, current state 0,
state 0
Mar 31 23:36:56 palomino kernel: cx18-0: warning: failed to be awakened upon
RPU acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecs
A wait of 10 msecs is not impossible I guess. However, they should be
much less frequent that what I am seeing in my logs, given that this is
an ATSC video stream capture.
Here's the highlights from a patched cx18 driver that I have in place to
try and see what's going on:
static int cx18_autoremove_wake_function(wait_queue_t *w, unsigned mode,
int sync, void *key)
{
struct cx18 *cx = key;
struct task_struct *t = w->private;
long old_state;
int ret;
old_state = t->state;
CX18_DEBUG_HI_IRQ("Wake up initiated on pid %d in state %lx\n",
task_pid_nr(t), old_state);
ret = default_wake_function(w, mode, sync, NULL);
if (ret) {
CX18_DEBUG_HI_IRQ("Wake up succeeded on pid %d, "
"state %lx -> %lx\n",
task_pid_nr(t), old_state, t->state);
list_del_init(&w->task_list);
} else {
CX18_DEBUG_WARN("Wake up failed on pid %d, "
"state %lx -> %lx\n",
task_pid_nr(t), old_state, t->state);
}
return ret;
}
static int cx18_api_call(struct cx18 *cx, u32 cmd, int args, u32 data[])
{
u32 state, irq, req, ack, err;
struct cx18_mailbox __iomem *mb;
wait_queue_head_t *waitq;
struct mutex *mb_lock;
long int timeout, ret;
int i;
wait_queue_t w;
...
/* Setup pointers and values we need */
waitq = &cx->mb_cpu_waitq;
mb_lock = &cx->epu2cpu_mb_lock;
irq = IRQ_EPU_TO_CPU;
mb = &cx->scb->epu2cpu_mb;
...
/* Acquire the mutex for the mailbox, and put a request in it */
/* blah blah blah */
...
timeout = msecs_to_jiffies(10);
CX18_DEBUG_HI_IRQ("sending interrupt SW1: %x to send %s\n",
irq, info->name);
ret = timeout;
/* setup for a wait */
init_wait(&w);
w.func = cx18_autoremove_wake_function;
prepare_to_wait(waitq, &w, TASK_UNINTERRUPTIBLE);
/* Tell the device our request is in it's mailbox */
cx18_write_reg_expect(cx, irq, SW1_INT_SET, irq, irq);
/* Did it ack our request already? */
ack = cx18_readl(cx, &mb->ack);
if (req != ack) {
CX18_DEBUG_HI_API("scheduling to wait for ack of %s: req %u "
"ack %u, pid %u, sta
[patch 1/2] dsbr100 radio: convert to to v4l2_device
dsbr100: convert to v4l2_device.
Signed-off-by: Alexey Klimov
--
diff -r f86c84534cb4 linux/drivers/media/radio/dsbr100.c
--- a/linux/drivers/media/radio/dsbr100.c Sun Mar 29 22:54:35 2009 -0300
+++ b/linux/drivers/media/radio/dsbr100.c Tue Mar 31 15:54:36 2009 +0400
@@ -32,6 +32,9 @@
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
History:
+
+ Version 0.45:
+ Converted to v4l2_device.
Version 0.44:
Add suspend/resume functions, fix unplug of device,
@@ -88,7 +91,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include "compat.h"
@@ -98,39 +101,8 @@
*/
#include /* for KERNEL_VERSION MACRO */
-#define DRIVER_VERSION "v0.44"
-#define RADIO_VERSION KERNEL_VERSION(0, 4, 4)
-
-static struct v4l2_queryctrl radio_qctrl[] = {
- {
- .id= V4L2_CID_AUDIO_MUTE,
- .name = "Mute",
- .minimum = 0,
- .maximum = 1,
- .default_value = 1,
- .type = V4L2_CTRL_TYPE_BOOLEAN,
- },
-/* HINT: the disabled controls are only here to satify kradio and such apps */
- { .id = V4L2_CID_AUDIO_VOLUME,
- .flags = V4L2_CTRL_FLAG_DISABLED,
- },
- {
- .id = V4L2_CID_AUDIO_BALANCE,
- .flags = V4L2_CTRL_FLAG_DISABLED,
- },
- {
- .id = V4L2_CID_AUDIO_BASS,
- .flags = V4L2_CTRL_FLAG_DISABLED,
- },
- {
- .id = V4L2_CID_AUDIO_TREBLE,
- .flags = V4L2_CTRL_FLAG_DISABLED,
- },
- {
- .id = V4L2_CID_AUDIO_LOUDNESS,
- .flags = V4L2_CTRL_FLAG_DISABLED,
- },
-};
+#define DRIVER_VERSION "v0.45"
+#define RADIO_VERSION KERNEL_VERSION(0, 4, 5)
#define DRIVER_AUTHOR "Markus Demleitner "
#define DRIVER_DESC "D-Link DSB-R100 USB FM radio driver"
@@ -168,6 +140,8 @@
struct dsbr100_device {
struct usb_device *usbdev;
struct video_device videodev;
+ struct v4l2_device v4l2_dev;
+
u8 *transfer_buffer;
struct mutex lock; /* buffer locking */
int curfreq;
@@ -387,6 +361,7 @@
mutex_unlock(&radio->lock);
video_unregister_device(&radio->videodev);
+ v4l2_device_disconnect(&radio->v4l2_dev);
}
@@ -482,14 +457,11 @@
static int vidioc_queryctrl(struct file *file, void *priv,
struct v4l2_queryctrl *qc)
{
- int i;
+ switch (qc->id) {
+ case V4L2_CID_AUDIO_MUTE:
+ return v4l2_ctrl_query_fill(qc, 0, 1, 1, 1);
+ }
- for (i = 0; i < ARRAY_SIZE(radio_qctrl); i++) {
- if (qc->id && qc->id == radio_qctrl[i].id) {
- memcpy(qc, &(radio_qctrl[i]), sizeof(*qc));
- return 0;
- }
- }
return -EINVAL;
}
@@ -659,6 +631,7 @@
{
struct dsbr100_device *radio = videodev_to_radio(videodev);
+ v4l2_device_unregister(&radio->v4l2_dev);
kfree(radio->transfer_buffer);
kfree(radio);
}
@@ -686,22 +659,15 @@
.vidioc_s_input = vidioc_s_input,
};
-/* V4L2 interface */
-static struct video_device dsbr100_videodev_data = {
- .name = "D-Link DSB-R 100",
- .fops = &usb_dsbr100_fops,
- .ioctl_ops = &usb_dsbr100_ioctl_ops,
- .release= usb_dsbr100_video_device_release,
-};
-
/* check if the device is present and register with v4l and usb if it is */
static int usb_dsbr100_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
struct dsbr100_device *radio;
+ struct v4l2_device *v4l2_dev;
int retval;
- radio = kmalloc(sizeof(struct dsbr100_device), GFP_KERNEL);
+ radio = kzalloc(sizeof(struct dsbr100_device), GFP_KERNEL);
if (!radio)
return -ENOMEM;
@@ -713,17 +679,35 @@
return -ENOMEM;
}
+ v4l2_dev = &radio->v4l2_dev;
+
+ retval = v4l2_device_register(&intf->dev, v4l2_dev);
+ if (retval < 0) {
+ v4l2_err(v4l2_dev, "couldn't register v4l2_device\n");
+ kfree(radio->transfer_buffer);
+ kfree(radio);
+ return retval;
+ }
+
+ strlcpy(radio->videodev.name, v4l2_dev->name,
sizeof(radio->videodev.name));
+ radio->videodev.v4l2_dev = v4l2_dev;
+ radio->videodev.fops = &usb_dsbr100_fops;
+ radio->videodev.ioctl_ops = &usb_dsbr100_ioctl_ops;
+ radio->videodev.release = usb_dsbr100_video_device_release;
+
mutex_init(&radio->lock);
- radio->videodev = dsbr100_videodev_data;
radio->removed = 0;
radio->users = 0;
radio->usbdev = interface_to_usbdev(intf);
[patch 2/2] radio-mr800: convert to to v4l2_device
radio-mr800: convert to to v4l2_device.
Signed-off-by: Alexey Klimov
--
diff -r 4cd17f5a20cc linux/drivers/media/radio/radio-mr800.c
--- a/linux/drivers/media/radio/radio-mr800.c Thu Apr 02 20:50:21 2009 -0300
+++ b/linux/drivers/media/radio/radio-mr800.c Sat Apr 04 01:32:08 2009 +0400
@@ -43,6 +43,7 @@
* Douglas Schilling Landgraf and
* David Ellingsworth
* for discussion, help and support.
+ * Version 0.11: Converted to v4l2_device.
*
* Many things to do:
* - Correct power managment of device (suspend & resume)
@@ -59,7 +60,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include /* for KERNEL_VERSION MACRO */
@@ -68,8 +69,8 @@
/* driver and module definitions */
#define DRIVER_AUTHOR "Alexey Klimov "
#define DRIVER_DESC "AverMedia MR 800 USB FM radio driver"
-#define DRIVER_VERSION "0.10"
-#define RADIO_VERSION KERNEL_VERSION(0, 1, 0)
+#define DRIVER_VERSION "0.11"
+#define RADIO_VERSION KERNEL_VERSION(0, 1, 1)
MODULE_AUTHOR(DRIVER_AUTHOR);
MODULE_DESCRIPTION(DRIVER_DESC);
@@ -114,38 +115,6 @@
module_param(radio_nr, int, 0);
MODULE_PARM_DESC(radio_nr, "Radio Nr");
-static struct v4l2_queryctrl radio_qctrl[] = {
- {
- .id= V4L2_CID_AUDIO_MUTE,
- .name = "Mute",
- .minimum = 0,
- .maximum = 1,
- .step = 1,
- .default_value = 1,
- .type = V4L2_CTRL_TYPE_BOOLEAN,
- },
-/* HINT: the disabled controls are only here to satify kradio and such apps */
- { .id = V4L2_CID_AUDIO_VOLUME,
- .flags = V4L2_CTRL_FLAG_DISABLED,
- },
- {
- .id = V4L2_CID_AUDIO_BALANCE,
- .flags = V4L2_CTRL_FLAG_DISABLED,
- },
- {
- .id = V4L2_CID_AUDIO_BASS,
- .flags = V4L2_CTRL_FLAG_DISABLED,
- },
- {
- .id = V4L2_CID_AUDIO_TREBLE,
- .flags = V4L2_CTRL_FLAG_DISABLED,
- },
- {
- .id = V4L2_CID_AUDIO_LOUDNESS,
- .flags = V4L2_CTRL_FLAG_DISABLED,
- },
-};
-
static int usb_amradio_probe(struct usb_interface *intf,
const struct usb_device_id *id);
static void usb_amradio_disconnect(struct usb_interface *intf);
@@ -160,6 +129,7 @@
/* reference to USB and video device */
struct usb_device *usbdev;
struct video_device *videodev;
+ struct v4l2_device v4l2_dev;
unsigned char *buffer;
struct mutex lock; /* buffer locking */
@@ -332,6 +302,7 @@
usb_set_intfdata(intf, NULL);
video_unregister_device(radio->videodev);
+ v4l2_device_disconnect(&radio->v4l2_dev);
}
/* vidioc_querycap - query device capabilities */
@@ -466,14 +437,11 @@
static int vidioc_queryctrl(struct file *file, void *priv,
struct v4l2_queryctrl *qc)
{
- int i;
+ switch (qc->id) {
+ case V4L2_CID_AUDIO_MUTE:
+ return v4l2_ctrl_query_fill(qc, 0, 1, 1, 1);
+ }
- for (i = 0; i < ARRAY_SIZE(radio_qctrl); i++) {
- if (qc->id && qc->id == radio_qctrl[i].id) {
- memcpy(qc, &(radio_qctrl[i]), sizeof(*qc));
- return 0;
- }
- }
return -EINVAL;
}
@@ -674,34 +642,29 @@
.vidioc_s_input = vidioc_s_input,
};
-static void usb_amradio_device_release(struct video_device *videodev)
+static void usb_amradio_video_device_release(struct video_device *videodev)
{
struct amradio_device *radio = video_get_drvdata(videodev);
/* we call v4l to free radio->videodev */
video_device_release(videodev);
+ v4l2_device_unregister(&radio->v4l2_dev);
+
/* free rest memory */
kfree(radio->buffer);
kfree(radio);
}
-
-/* V4L2 interface */
-static struct video_device amradio_videodev_template = {
- .name = "AverMedia MR 800 USB FM Radio",
- .fops = &usb_amradio_fops,
- .ioctl_ops = &usb_amradio_ioctl_ops,
- .release= usb_amradio_device_release,
-};
/* check if the device is present and register with v4l and usb if it is */
static int usb_amradio_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
struct amradio_device *radio;
+ struct v4l2_device *v4l2_dev;
int retval;
- radio = kmalloc(sizeof(struct amradio_device), GFP_KERNEL);
+ radio = kzalloc(sizeof(struct amradio_device), GFP_KERNEL);
if (!radio) {
dev_err(&intf->dev, "kmalloc for amradio_device failed\n");
@@ -716,6 +679,15 @@
return -ENOMEM;
Re: [PATCH - RECALL] siano: smsendian & smsdvb - binding the smsendian to smsdvb
On Fri, 3 Apr 2009 13:31:32 -0700 (PDT)
Uri Shkolnik wrote:
>
> --- On Fri, 4/3/09, Mauro Carvalho Chehab wrote:
>
> From: Mauro Carvalho Chehab
> Subject: Re: [PATCH - RECALL] siano: smsendian & smsdvb - binding the
> smsendian to smsdvb
> To: "Uri Shkolnik"
> Cc: linux-media@vger.kernel.org
> Date: Friday, April 3, 2009, 3:15 PM
>
> Uri,
>
> On Fri, 3 Apr 2009 03:20:38 -0700 (PDT)
> Uri Shkolnik wrote:
>
> > Hi,
> >
> > The last patch in the series ("siano: smsendian & smsdvb - binding the
> > smsendian to smsdvb") breaks the driver, please ignore it.
> >
>
>
> It will be very hard (again) to handle your patch series. Especially when
> sending a big series of patches like this, you should number the patches, for
> they to be applied at the proper order.
>
> Also, when a patch is broken, you should reply to that patch, without changing
> the subject. The original message ID will be properly handled by patchwork,
> and
> the reply message will be folded with the original patch.
>
> In this case, this is the message ID of your patch message:
> Message-ID: <622468.86074...@web110805.mail.gq1.yahoo.com>
>
> However, your "RECALL" email doesn't contain any reference tag to the original
> message (since you didn't reply to your message). So, emailers and patchwork
> won't associate the reply with the patch you want to discard.
>
> Cheers,
> Mauro
>
> Hi Mauro,
>
>
>
>
> 1) Backport patch ("siano: smsdvb - add support for old dvb-core version") -
> If this patch causes problem, discard it (trashing it does not affect the
> other patches), let me know, and I'll submit only the one-line endian change.
> (We'll support old embedded devices, etc. using specific vendor patch from
> our customer support team, and the kernel version will not have any backport
> code).
>
> 2) I'll add global serial indication to the patches from now on. Regarding
> the already submmited patches, is it OK if I'll email you a text list of
> patches with their order?
Yes, if you provide me the patch numbers at patchwork. I just need a simple
list of patchwork sequence numbers, in the expected order.
> 3) Recall message - I didn't know about the reply option and I'll do that
> from now on. (Any day you learn something new, and that fact distinguish you
> from the dead:-) )
No problem.
>
> 4) If it's OK with you, I'll hold further submission, until the already
> submited patches will be reviewed and commited.
Seems the better for me.
> 5) Some related question... I emailed all patches to you and CC the
> "linux-media@vger.kernel.org" ML. I can not see any post other than your
> replys on the ML and nothing on
> http://patchwork.kernel.org/project/linux-media/list/ . Any idea why?
If patchwork didn't got, then the patch is broken. You don't need to CC me, but
you need to be sure that patchwork will catch they. For patchwork to do his
job, you should be sure that your emailer won't do line wrapping, and avoid use
attachments. Mime processing is tricky and some emailers set the wrong mime
type for attachments.
> Have a great weekend,
Same to you.
>
> Regards,
>
> Uri
>
>
>
>
>
>
>
>
Cheers,
Mauro
--
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
Kernel 2.6.29 breaks DVB-T ASUSTeK Tiger LNA Hybrid Capture Device
ASUSTeK Tiger LNA Hybrid Capture Device PCI - Analog/DVB-T card Multimedia controller: Philips Semiconductors SAA7131/SAA7133/SAA7135 Video Broadcast Decoder (rev d1) Works perfectly with kernel 2.6.28.4 (or older). Recently, I have switched to 2.6.29 (same .config as 2.6.28.4) and now, at boot time, I get the message: IRQ 18/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs Signal strength is very low and Kaffeine is unable to tune in any channel. Same problem with kernel 2.6.29.1 - Messages from /var/log/dmesg saa7134 :03:0a.0: PCI INT A -> Link[APC3] -> GSI 18 (level, low) -> \ IRQ 18 saa7133[0]: found at :03:0a.0, rev: 209, irq: 18, latency: 32, mmio: \ 0xfdefe000 saa7133[0]: subsystem: 1043:4871, board: ASUS P7131 4871 \ [card=111,autodetected] saa7133[0]: board init: gpio is 0 IRQ 18/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs saa7133[0]: i2c eeprom 00: 43 10 71 48 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7133[0]: i2c eeprom 10: ff ff ff 0f ff 20 ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 20: 01 40 01 02 03 00 01 03 08 ff 00 cf ff ff ff ff saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 40: ff 21 00 c2 96 10 03 22 15 50 ff ff ff ff ff ff saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff tuner' 2-004b: chip found @ 0x96 (saa7133[0]) tda829x 2-004b: setting tuner address to 61 tda829x 2-004b: type set to tda8290+75a saa7133[0]: registered device video0 [v4l2] saa7133[0]: registered device vbi0 dvb_init() allocating 1 frontend DVB: registering new adapter (saa7133[0]) DVB: registering adapter 0 frontend -32769 (Philips TDA10046H DVB-T)... tda1004x: setting up plls for 48MHz sampling clock tda1004x: timeout waiting for DSP ready tda1004x: found firmware revision 0 -- invalid tda1004x: trying to boot from eeprom tda1004x: timeout waiting for DSP ready tda1004x: found firmware revision 0 -- invalid tda1004x: waiting for firmware upload... saa7134 :03:0a.0: firmware: requesting dvb-fe-tda10046.fw tda1004x: found firmware revision 29 -- ok saa7134 ALSA driver for DMA sound loaded IRQ 18/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs saa7133[0]/alsa: saa7133[0] at 0xfdefe000 irq 18 registered as card -1 -- 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: topro 6800 driver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anders Blomdell wrote: > New version attached, handles both 640x480 and 320x240, corrected gamma table. > > Seems to work OK with mplayer, vlc and > https://launchpad.net/python-v4l2-capture > > vlc v4l2://dev/video0:width=320:height=240 > vlc v4l2://dev/video0:width=640:height=480 > > Jean-Francois: feel free to add this to gspca if it lives up to your > standards, > otherwise tell me what needs to be changed. > > Best regards > > /Anders > > Hi Anders, Before submitting a driver, please make sure it passes the checkpatch.pl script found in the linux/scripts/ folder. When I checked the tp6800.c file I got about ~4300 errors. This is due to that the file isn't using the indentation used by code in the linux tree. If you first run the Lindent script (found in the same folder) about 23 errors pop up that need to be corrected. Beware though that Lindent sometimes screw up lines so manual inspection of the code is needed. Best regards, / hälsningar, Erik -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknWd4EACgkQN7qBt+4UG0E8LgCfQYON+qQJS7gOjnmF8BqUuuW8 M8YAoJJroBbk2CXBS+z6qCL6ZU41EOXy =RBZP -END PGP SIGNATURE- -- 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 - RECALL] siano: smsendian & smsdvb - binding the smsendian to smsdvb
--- On Fri, 4/3/09, Mauro Carvalho Chehab wrote:
From: Mauro Carvalho Chehab
Subject: Re: [PATCH - RECALL] siano: smsendian & smsdvb - binding the smsendian
to smsdvb
To: "Uri Shkolnik"
Cc: linux-media@vger.kernel.org
Date: Friday, April 3, 2009, 3:15 PM
Uri,
On Fri, 3 Apr 2009 03:20:38 -0700 (PDT)
Uri Shkolnik wrote:
> Hi,
>
> The last patch in the series ("siano: smsendian & smsdvb - binding the
> smsendian to smsdvb") breaks the driver, please ignore it.
>
It will be very hard (again) to handle your patch series. Especially when
sending a big series of patches like this, you should number the patches, for
they to be applied at the proper order.
Also, when a patch is broken, you should reply to that patch, without changing
the subject. The original message ID will be properly handled by patchwork, and
the reply message will be folded with the original patch.
In this case, this is the message ID of your patch message:
Message-ID: <622468.86074...@web110805.mail.gq1.yahoo.com>
However, your "RECALL" email doesn't contain any reference tag to the original
message (since you didn't reply to your message). So, emailers and patchwork
won't associate the reply with the patch you want to discard.
Cheers,
Mauro
Hi Mauro,
1) Backport patch ("siano: smsdvb - add support for old dvb-core version") - If
this patch causes problem, discard it (trashing it does not affect the other
patches), let me know, and I'll submit only the one-line endian change. (We'll
support old embedded devices, etc. using specific vendor patch from our
customer support team, and the kernel version will not have any backport code).
2) I'll add global serial indication to the patches from now on. Regarding the
already submitted patches, is it OK if I'll email you a text list of patches
with their order?
3) Recall message - I didn't know about the reply option and I'll do that from
now on. (Any day you learn something new, and that fact distinguish you from
the dead:-) )
4) If it's OK with you, I'll hold further submission, until the already
submitted patches will be reviewed and committed.
5) Some related question... I emailed all patches to you and CC the
"linux-media@vger.kernel.org" ML. I can not see any post other than your replys
on the ML and nothing on http://patchwork.kernel.org/project/linux-media/list/
. Any idea why?
Have a great weekend,
Regards,
Uri
--
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
[PULL] soc-camera: one new host-driver, one driver extension and one fix
Hi Mauro, Please pull from http://linuxtv.org/hg/~gliakhovetski/v4l-dvb for the following 4 changesets: 01/04: mt9t031: use platform power hook http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=30f84934c1b5 (note: 02/04 is a "kernel-sync:") 02/04: sync: add files needed for the following two commits http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=59ff539ea946 03/04: mx3-camera: adapt the clock definition and the driver to the new clock naming http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=7876902cd114 04/04: Add camera (CSI) driver for MX1 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f115ddf29d64 b/linux/arch/arm/mach-mx1/Makefile | 11 b/linux/arch/arm/mach-mx1/devices.c | 263 ++ b/linux/arch/arm/mach-mx1/ksym_mx1.c| 18 b/linux/arch/arm/mach-mx1/mx1_camera_fiq.S | 35 b/linux/arch/arm/mach-mx3/clock.c | 605 ++ b/linux/arch/arm/plat-mxc/include/mach/memory.h | 28 b/linux/arch/arm/plat-mxc/include/mach/mx1_camera.h | 35 b/linux/drivers/media/video/mx1_camera.c| 827 linux/arch/arm/mach-mx1/Makefile|5 linux/arch/arm/mach-mx1/devices.c |2 linux/arch/arm/mach-mx3/clock.c |2 linux/arch/arm/plat-mxc/include/mach/memory.h |8 linux/drivers/media/video/Kconfig | 13 linux/drivers/media/video/Makefile |1 linux/drivers/media/video/mt9t031.c | 21 linux/drivers/media/video/mx3_camera.c |2 16 files changed, 1871 insertions(+), 5 deletions(-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- 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 v2] mx3-camera: adapt the clock definition and the driver to the new clock naming
On Fri, Apr 03, 2009 at 01:26:11PM +0200, Guennadi Liakhovetski wrote:
> With the i.MX31 transition to clkdev clock names have changed, but mistakenly
> the "mx3-camera.0" has been registered with a non-NULL connection ID, which is
> not necessary, since this is the only clock, used by the capture interface
> driver. Fix the clock definition and the driver to use NULL as a connection
> ID.
>
> Signed-off-by: Guennadi Liakhovetski
Acked-by Sascha Hauer
> ---
>
> Clock connection IDs fixed to NULL. Sascha, please, ack.
>
> arch/arm/mach-mx3/clock.c|2 +-
> drivers/media/video/mx3_camera.c |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-mx3/clock.c b/arch/arm/mach-mx3/clock.c
> index ca46f48..9957a11 100644
> --- a/arch/arm/mach-mx3/clock.c
> +++ b/arch/arm/mach-mx3/clock.c
> @@ -533,7 +533,7 @@ static struct clk_lookup lookups[] __initdata = {
> _REGISTER_CLOCK(NULL, "kpp", kpp_clk)
> _REGISTER_CLOCK("fsl-usb2-udc", "usb", usb_clk1)
> _REGISTER_CLOCK("fsl-usb2-udc", "usb_ahb", usb_clk2)
> - _REGISTER_CLOCK("mx3-camera.0", "csi", csi_clk)
> + _REGISTER_CLOCK("mx3-camera.0", NULL, csi_clk)
> _REGISTER_CLOCK("imx-uart.0", NULL, uart1_clk)
> _REGISTER_CLOCK("imx-uart.1", NULL, uart2_clk)
> _REGISTER_CLOCK("imx-uart.2", NULL, uart3_clk)
> diff --git a/drivers/media/video/mx3_camera.c
> b/drivers/media/video/mx3_camera.c
> index 70629e1..c462b81 100644
> --- a/drivers/media/video/mx3_camera.c
> +++ b/drivers/media/video/mx3_camera.c
> @@ -1100,7 +1100,7 @@ static int mx3_camera_probe(struct platform_device
> *pdev)
> }
> memset(mx3_cam, 0, sizeof(*mx3_cam));
>
> - mx3_cam->clk = clk_get(&pdev->dev, "csi_clk");
> + mx3_cam->clk = clk_get(&pdev->dev, NULL);
> if (IS_ERR(mx3_cam->clk)) {
> err = PTR_ERR(mx3_cam->clk);
> goto eclkget;
> --
> 1.5.4
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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
[PULL] http://linuxtv.org/hg/~eandren/v4l-dvb/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jean-Francois, Please pull http://linuxtv.org/hg/~eandren/v4l-dvb/ for more m5602-gspca changeset that are 2.6.30 material. Thanks, Erik -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknWVXIACgkQN7qBt+4UG0F1CwCfZQfuaCUYFWB9vTuwcY6OLwwI IY4An2OVVXgxbOF+/kBAE/R1zbKXUF5q =F3Mf -END PGP SIGNATURE- -- 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: OK, 2.6.16-2.6.21: WARNINGS
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:Fri Apr 3 19:00:04 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11346:4cd17f5a20cc gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-armv5-ixp: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29-i686: OK linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-m32r: OK linux-2.6.22.19-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-mips: OK linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29-powerpc64: OK linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29-x86_64: OK fw/apps: OK sparse (linux-2.6.29): OK linux-2.6.16.61-i686: WARNINGS linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: WARNINGS linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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: SDMC DM1105N not being detected
On 3 April 2009 08:02:20 mp3geek wrote: > Not even being detected in Linux 2.6.29.1, I have the modules "dm1105" > loaded, but since its not even being detected by linux.. > > lspci -vv shows this (I'm assuming this is the card..), dmesg shows > nothing dvb being loaded > > 00:0b.0 Ethernet controller: Device 195d:1105 (rev 10) > ═ ═Subsystem: Device 195d:1105 > ═ ═Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- > ParErr- Stepping- SERR- FastB2B- DisINTx- > ═ ═Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- > SERR- ═ ═Latency: 30 (4000ns min, 8000ns max), Cache Line Size: 32 bytes > ═ ═Interrupt: pin A routed to IRQ 5 > ═ ═Region 0: I/O ports at 9400 [size=256] > > > The chip says the following, SDMC DM1105N, EasyTV-DVBS V1.0B > (2008-04-26), 0735 E280034 > -- > 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 I wrote code to support card with subsystem/device 195d/1105, but no one reported success, so I decided to not include it in commit :( It was more then one year ago http://liplianin.at.tut.by/dvblipl.tar.bz2 http://liplianin.at.tut.by/ds110en.html -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4] Add camera (CSI) driver for MX1
On Fri, 3 Apr 2009, Darius Augulis wrote: > Guennadi Liakhovetski wrote: > > > > Confused... Then why the whole that "IMX/MX1" in the driver? And why will it > > never get it - are they compatible or not? Or just there's no demand / chips > > are EOLed or something... > > in Linux kernel "imx" is the old name of "mx1". > mx1 contains of two processors: i.MX1 and i.MXL. Ah, ok, I see now. I thought i.MXL was under ARCH_IMX and _not_ ARCH_MX1. That was my confusion. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4] Add camera (CSI) driver for MX1
Guennadi Liakhovetski wrote: On Fri, 3 Apr 2009, Sascha Hauer wrote: On Fri, Apr 03, 2009 at 02:15:34PM +0200, Guennadi Liakhovetski wrote: Wondering, if it still will work then... At least it compiles. BTW, should it really also work with IMX? Then you might want to change this depends on VIDEO_DEV && ARCH_MX1 && SOC_CAMERA to depends on VIDEO_DEV && (ARCH_MX1 || ARCH_IMX) && SOC_CAMERA This shouldn't be necessary. ARCH_IMX does not have the platform part to make use of this driver and will never get it. Confused... Then why the whole that "IMX/MX1" in the driver? And why will it never get it - are they compatible or not? Or just there's no demand / chips are EOLed or something... in Linux kernel "imx" is the old name of "mx1". mx1 contains of two processors: i.MX1 and i.MXL. but you can do this later, maybe, when you actually get a chance to test it on IMX (if you haven't done so yet). Sascha, we need your ack for the ARM part. I'm OK with this driver: I have never worked with FIQs though so I can't say much to it. Ok, I take it as an "Acked-by" then:-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4] Add camera (CSI) driver for MX1
On Fri, Apr 03, 2009 at 02:41:16PM +0200, Guennadi Liakhovetski wrote: > On Fri, 3 Apr 2009, Sascha Hauer wrote: > > > On Fri, Apr 03, 2009 at 02:15:34PM +0200, Guennadi Liakhovetski wrote: > > > Wondering, if it still will work then... At least it compiles. BTW, > > > should > > > it really also work with IMX? Then you might want to change this > > > > > > depends on VIDEO_DEV && ARCH_MX1 && SOC_CAMERA > > > > > > to > > > > > > depends on VIDEO_DEV && (ARCH_MX1 || ARCH_IMX) && SOC_CAMERA > > > > This shouldn't be necessary. ARCH_IMX does not have the platform part to > > make use of this driver and will never get it. > > Confused... Then why the whole that "IMX/MX1" in the driver? And why will > it never get it - are they compatible or not? Not just compatible, they are the same. A little bit of history: I originally brought i.MX1 support to the kernel in the early 2.6 days. around 2.6.25 Freescale pushed initial i.MX31 support using plat-mxc. We in turn based our i.MX27 port on this code and since then it evolved further. Darius based a new i.MX1 support on this code and now we can remove arch-imx. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4] Add camera (CSI) driver for MX1
On Fri, 3 Apr 2009, Sascha Hauer wrote: > On Fri, Apr 03, 2009 at 02:15:34PM +0200, Guennadi Liakhovetski wrote: > > Wondering, if it still will work then... At least it compiles. BTW, should > > it really also work with IMX? Then you might want to change this > > > > depends on VIDEO_DEV && ARCH_MX1 && SOC_CAMERA > > > > to > > > > depends on VIDEO_DEV && (ARCH_MX1 || ARCH_IMX) && SOC_CAMERA > > This shouldn't be necessary. ARCH_IMX does not have the platform part to > make use of this driver and will never get it. Confused... Then why the whole that "IMX/MX1" in the driver? And why will it never get it - are they compatible or not? Or just there's no demand / chips are EOLed or something... > > but you can do this later, maybe, when you actually get a chance to test > > it on IMX (if you haven't done so yet). > > > > Sascha, we need your ack for the ARM part. > > I'm OK with this driver: I have never worked with FIQs though so I can't > say much to it. Ok, I take it as an "Acked-by" then:-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4] Add camera (CSI) driver for MX1
Sascha Hauer wrote: On Fri, Apr 03, 2009 at 02:15:34PM +0200, Guennadi Liakhovetski wrote: On Fri, 3 Apr 2009, Darius Augulis wrote: From: Paulius Zaleckas Signed-off-by: Darius Augulis Signed-off-by: Paulius Zaleckas Ok, I'll just swap these two Sob's to reflect the processing chain, add a description like Add support for CMOS Sensor Interface on i.MX1 and i.MXL SoCs. and fix a couple of trivial conflicts, which probably appear, because you based your patches on an MXC tree, and not on current linux-next. Wondering, if it still will work then... At least it compiles. BTW, should it really also work with IMX? Then you might want to change this depends on VIDEO_DEV && ARCH_MX1 && SOC_CAMERA to depends on VIDEO_DEV && (ARCH_MX1 || ARCH_IMX) && SOC_CAMERA This shouldn't be necessary. ARCH_IMX does not have the platform part to make use of this driver and will never get it. but you can do this later, maybe, when you actually get a chance to test it on IMX (if you haven't done so yet). Sascha, we need your ack for the ARM part. I'm OK with this driver: I have never worked with FIQs though so I can't say much to it. At least I can confirm it worked well with 2.6.28.5 kernel version. Sascha -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4] Add camera (CSI) driver for MX1
On Fri, Apr 03, 2009 at 02:15:34PM +0200, Guennadi Liakhovetski wrote: > On Fri, 3 Apr 2009, Darius Augulis wrote: > > > From: Paulius Zaleckas > > > > Signed-off-by: Darius Augulis > > Signed-off-by: Paulius Zaleckas > > Ok, I'll just swap these two Sob's to reflect the processing chain, add a > description like > > Add support for CMOS Sensor Interface on i.MX1 and i.MXL SoCs. > > and fix a couple of trivial conflicts, which probably appear, because you > based your patches on an MXC tree, and not on current linux-next. > Wondering, if it still will work then... At least it compiles. BTW, should > it really also work with IMX? Then you might want to change this > > depends on VIDEO_DEV && ARCH_MX1 && SOC_CAMERA > > to > > depends on VIDEO_DEV && (ARCH_MX1 || ARCH_IMX) && SOC_CAMERA This shouldn't be necessary. ARCH_IMX does not have the platform part to make use of this driver and will never get it. > > but you can do this later, maybe, when you actually get a chance to test > it on IMX (if you haven't done so yet). > > Sascha, we need your ack for the ARM part. I'm OK with this driver: I have never worked with FIQs though so I can't say much to it. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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 - RECALL] siano: smsendian & smsdvb - binding the smsendian to smsdvb
Uri,
On Fri, 3 Apr 2009 03:20:38 -0700 (PDT)
Uri Shkolnik wrote:
> Hi,
>
> The last patch in the series ("siano: smsendian & smsdvb - binding the
> smsendian to smsdvb") breaks the driver, please ignore it.
>
It will be very hard (again) to handle your patch series. Especially when
sending a big series of patches like this, you should number the patches, for
they to be applied at the proper order.
Also, when a patch is broken, you should reply to that patch, without changing
the subject. The original message ID will be properly handled by patchwork, and
the reply message will be folded with the original patch.
In this case, this is the message ID of your patch message:
Message-ID: <622468.86074...@web110805.mail.gq1.yahoo.com>
However, your "RECALL" email doesn't contain any reference tag to the original
message (since you didn't reply to your message). So, emailers and patchwork
won't associate the reply with the patch you want to discard.
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4] Add camera (CSI) driver for MX1
On Fri, 3 Apr 2009, Darius Augulis wrote: > From: Paulius Zaleckas > > Signed-off-by: Darius Augulis > Signed-off-by: Paulius Zaleckas Ok, I'll just swap these two Sob's to reflect the processing chain, add a description like Add support for CMOS Sensor Interface on i.MX1 and i.MXL SoCs. and fix a couple of trivial conflicts, which probably appear, because you based your patches on an MXC tree, and not on current linux-next. Wondering, if it still will work then... At least it compiles. BTW, should it really also work with IMX? Then you might want to change this depends on VIDEO_DEV && ARCH_MX1 && SOC_CAMERA to depends on VIDEO_DEV && (ARCH_MX1 || ARCH_IMX) && SOC_CAMERA but you can do this later, maybe, when you actually get a chance to test it on IMX (if you haven't done so yet). Sascha, we need your ack for the ARM part. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- 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] siano: smsdvb - add support for old dvb-core version
Uri, I didn't started yet to analyse your patch series, but the subject of this message called my attention. Backport patches is something that should never go upstream. On Fri, 3 Apr 2009 04:36:09 -0700 (PDT) Uri Shkolnik wrote: > # HG changeset patch > # User Uri Shkolnik > # Date 1238758726 -10800 > # Node ID c582116cfbb96671629143fced33e3f88c28b3c7 > # Parent 856813745905e07d9fc6be5e136fdf7060c6fc37 > siano: smsdvb - add support for old dvb-core version > > From: Uri Shkolnik > > Multiple user takes the new driver sources from the LinuxTV > repository, but neglect to upgrade the dvb-core (this is > true especially for tiny and embedded device). This patch > enables the smsdvb to work with older version of dvb-core. > > This patch also add one more handling of message endianity. Never mix two different issues on the same patch. In this specific case, since the backport patch will be removed from upstream submission, the message endian changes should be on a separate patch, in order to get its way upstream. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] FM Transmitter driver
On Fri, Apr 03, 2009 at 01:29:27PM +0200, ext Hans Verkuil wrote: > On Friday 03 April 2009 12:48:19 Eduardo Valentin wrote: > > Hi, > > > > On Fri, Apr 03, 2009 at 12:36:53PM +0200, ext Hans Verkuil wrote: > > > On Friday 03 April 2009 12:12:30 Eduardo Valentin wrote: > > > > On Thu, Apr 02, 2009 at 06:36:37PM +0200, ext Hans Verkuil wrote: > > > > > On Thursday 02 April 2009 14:02:11 Eduardo Valentin wrote: > > > > > > Hi Hans, > > > > > > > > > > > > On Thu, Apr 02, 2009 at 09:47:11AM +0200, ext Hans Verkuil wrote: > > > > > > > On Wednesday 01 April 2009 11:43:28 Eduardo Valentin wrote: > > > > > > > > Hello Mauro and v4l guys, > > > > > > > > > > > > > > > > This series contains a v4l2 radio driver which > > > > > > > > adds support for Silabs si4713 devices. That is > > > > > > > > a FM transmitter device. > > > > > > > > > > > > > > > > As you should know, v4l2 does not contain representation > > > > > > > > of FM Transmitters (at least that I know). So this driver > > > > > > > > was written highly based on FM receivers API, which can > > > > > > > > cover most of basic functionality. However, as expected, > > > > > > > > there are some properties which were not covered. > > > > > > > > For those properties, sysfs nodes were added in order > > > > > > > > to get user interactions. > > > > > > > > > > > > > > > > Comments are wellcome. > > > > > > > > > > > > > > Can you explain in reasonable detail the extra properties > > > > > > > needed for a device like this? You will need to document that > > > > > > > anyway :-) Rather than implementing a private API it would be > > > > > > > much more interesting to turn this into a public V4L2 API that > > > > > > > everyone can use. > > > > > > > > > > > > Yes, here is a little description of them: > > > > > > > > > > > > Pilot is an audible tone sent by the device. > > > > > > > > > > > > pilot_frequency - Configures the frequency of the stereo pilot > > > > > > tone. pilot_deviation - Configures pilot tone frequency deviation > > > > > > level. pilot_enabled - Enables or disables the pilot tone > > > > > > feature. > > > > > > > > > > > > The si4713 device is capable of applying audio compression to the > > > > > > transmitted signal. > > > > > > > > > > > > acomp_enabled - Enables or disables the audio dynamic range > > > > > > control feature. acomp_gain - Sets the gain for audio dynamic > > > > > > range control. acomp_threshold - Sets the threshold level for > > > > > > audio dynamic range control. acomp_attack_time - Sets the attack > > > > > > time for audio dynamic range control. acomp_release_time - Sets > > > > > > the release time for audio dynamic range control. > > > > > > > > > > > > Limiter setups audio deviation limiter feature. Once a over > > > > > > deviation occurs, it is possible to adjust the front-end gain of > > > > > > the audio input and always prevent over deviation. > > > > > > > > > > > > limiter_enabled - Enables or disables the limiter feature. > > > > > > limiter_deviation - Configures audio frequency deviation level. > > > > > > limiter_release_time - Sets the limiter release time. > > > > > > > > > > > > power_level - Sets the output power level for signal > > > > > > transmission. > > > > > > > > > > Hmm, there are two ways to implement these: either make a bunch of > > > > > VIDIOC's for each of these categories, or use extended controls to > > > > > set all these values. I'm hardly an expert on FM transmitters, but > > > > > it all seems reasonable to me (i.e., not too specific for this > > > > > chip). > > > > > > > > > > I am leaning towards extended controls, since that's so easy to > > > > > extend if needed in the future. And I still intend to add sysfs > > > > > support to controls in the future. On the other hand, it's a bit > > > > > harder to use compared to normal VIDIOCs. > > > > > > > > Could you please explain more about extended controls vs. VIDIOC's? > > > > Pointing drivers which uses one of those also would be worth. But > > > > yes, looks like moving this properties to some sort of v4l2 control > > > > looks better implementation. > > > > > > The spec explains it pretty well. The most up to date version of the > > > spec is available here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html. > > > > > > Basically the extended controls API is more flexible than the older > > > VIDIOC_S/G_CTRL ioctls, allowing to set controls atomically (either all > > > are applied or none) and allowing for a wider range of types, although > > > currently that feature isn't used. > > > > > > It's used by uvcvideo and by MPEG encoders (e.g. cx18, ivtv and > > > others). > > > > > > Using VIDIOCs is easier, but much harder to make future-proof. One > > > disadvantage of using extended controls is that it is harder to > > > implement in drivers, although I plan on creating a much better > > > solution for that in the coming months. With the new v4l framework it > > > should be possible to move much of the control handling into
Re: [PATCH V4] Add camera (CSI) driver for MX1
Changelog since V3: - DMA buffer size decreased to 4Mbytes - Added pdata test in set_bus_param() -- 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 V4] Add camera (CSI) driver for MX1
From: Paulius Zaleckas
Signed-off-by: Darius Augulis
Signed-off-by: Paulius Zaleckas
---
arch/arm/mach-mx1/Makefile |5
arch/arm/mach-mx1/devices.c |2
arch/arm/mach-mx1/ksym_mx1.c| 18 +
arch/arm/mach-mx1/mx1_camera_fiq.S | 35 +
arch/arm/plat-mxc/include/mach/memory.h |8
arch/arm/plat-mxc/include/mach/mx1_camera.h | 35 +
drivers/media/video/Kconfig | 13
drivers/media/video/Makefile|1
drivers/media/video/mx1_camera.c| 827 +++
9 files changed, 941 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/mach-mx1/ksym_mx1.c
create mode 100644 arch/arm/mach-mx1/mx1_camera_fiq.S
create mode 100644 arch/arm/plat-mxc/include/mach/mx1_camera.h
create mode 100644 drivers/media/video/mx1_camera.c
diff --git a/arch/arm/mach-mx1/Makefile b/arch/arm/mach-mx1/Makefile
index 5e85456..2097021 100644
--- a/arch/arm/mach-mx1/Makefile
+++ b/arch/arm/mach-mx1/Makefile
@@ -6,6 +6,9 @@
obj-y += generic.o clock.o devices.o
+# Support for CMOS sensor interface
+obj-$(CONFIG_MX1_VIDEO)+= ksym_mx1.o mx1_camera_fiq.o
+
# Power management
obj-$(CONFIG_PM) += pm.o
@@ -15,4 +18,4 @@ endif
# Specific board support
obj-$(CONFIG_ARCH_MX1ADS) += mx1ads.o
-obj-$(CONFIG_MACH_SCB9328) += scb9328.o
\ No newline at end of file
+obj-$(CONFIG_MACH_SCB9328) += scb9328.o
diff --git a/arch/arm/mach-mx1/devices.c b/arch/arm/mach-mx1/devices.c
index 97f42d9..76d1ffb 100644
--- a/arch/arm/mach-mx1/devices.c
+++ b/arch/arm/mach-mx1/devices.c
@@ -44,7 +44,7 @@ static struct resource imx_csi_resources[] = {
static u64 imx_csi_dmamask = 0xUL;
struct platform_device imx_csi_device = {
- .name = "imx-csi",
+ .name = "mx1-camera",
.id = 0, /* This is used to put cameras on this interface */
.dev= {
.dma_mask = &imx_csi_dmamask,
diff --git a/arch/arm/mach-mx1/ksym_mx1.c b/arch/arm/mach-mx1/ksym_mx1.c
new file mode 100644
index 000..b09ee12
--- /dev/null
+++ b/arch/arm/mach-mx1/ksym_mx1.c
@@ -0,0 +1,18 @@
+/*
+ * Exported ksyms of ARCH_MX1
+ *
+ * Copyright (C) 2008, Darius Augulis
+ *
+ * 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.
+ */
+
+#include
+#include
+
+#include
+
+/* IMX camera FIQ handler */
+EXPORT_SYMBOL(mx1_camera_sof_fiq_start);
+EXPORT_SYMBOL(mx1_camera_sof_fiq_end);
diff --git a/arch/arm/mach-mx1/mx1_camera_fiq.S
b/arch/arm/mach-mx1/mx1_camera_fiq.S
new file mode 100644
index 000..9c69aa6
--- /dev/null
+++ b/arch/arm/mach-mx1/mx1_camera_fiq.S
@@ -0,0 +1,35 @@
+/*
+ * Copyright (C) 2008 Paulius Zaleckas
+ *
+ * Based on linux/arch/arm/lib/floppydma.S
+ * Copyright (C) 1995, 1996 Russell King
+ *
+ * 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.
+ */
+#include
+#include
+
+ .text
+ .global mx1_camera_sof_fiq_end
+ .global mx1_camera_sof_fiq_start
+mx1_camera_sof_fiq_start:
+ @ enable dma
+ ldr r12, [r9]
+ orr r12, r12, #0x0001
+ str r12, [r9]
+ @ unmask DMA interrupt
+ ldr r12, [r8]
+ bic r12, r12, r13
+ str r12, [r8]
+ @ disable SOF interrupt
+ ldr r12, [r10]
+ bic r12, r12, #0x0001
+ str r12, [r10]
+ @ clear SOF flag
+ mov r12, #0x0001
+ str r12, [r11]
+ @ return from FIQ
+ subspc, lr, #4
+mx1_camera_sof_fiq_end:
diff --git a/arch/arm/plat-mxc/include/mach/memory.h
b/arch/arm/plat-mxc/include/mach/memory.h
index e0783e6..eca37d0 100644
--- a/arch/arm/plat-mxc/include/mach/memory.h
+++ b/arch/arm/plat-mxc/include/mach/memory.h
@@ -24,4 +24,12 @@
#define PHYS_OFFSETUL(0x8000)
#endif
+#if defined(CONFIG_MX1_VIDEO)
+/*
+ * Increase size of DMA-consistent memory region.
+ * This is required for i.MX camera driver to capture at least four VGA frames.
+ */
+#define CONSISTENT_DMA_SIZE SZ_4M
+#endif /* CONFIG_MX1_VIDEO */
+
#endif /* __ASM_ARCH_MXC_MEMORY_H__ */
diff --git a/arch/arm/plat-mxc/include/mach/mx1_camera.h
b/arch/arm/plat-mxc/include/mach/mx1_camera.h
new file mode 100644
index 000..4fd6c70
--- /dev/null
+++ b/arch/arm/plat-mxc/include/mach/mx1_camera.h
@@ -0,0 +1,35 @@
+/*
+ * mx1_camera.h - i.MX1/i.MXL camera driver header file
+ *
+ * Copyright (c) 2008, Paulius Zaleckas
+ * Copyright (C) 2009, Darius Augulis
+ *
+ * Based on PXA camera.h file:
+ * Co
Re: [PATCH 0/3] FM Transmitter driver
On Friday 03 April 2009 12:48:19 Eduardo Valentin wrote: > Hi, > > On Fri, Apr 03, 2009 at 12:36:53PM +0200, ext Hans Verkuil wrote: > > On Friday 03 April 2009 12:12:30 Eduardo Valentin wrote: > > > On Thu, Apr 02, 2009 at 06:36:37PM +0200, ext Hans Verkuil wrote: > > > > On Thursday 02 April 2009 14:02:11 Eduardo Valentin wrote: > > > > > Hi Hans, > > > > > > > > > > On Thu, Apr 02, 2009 at 09:47:11AM +0200, ext Hans Verkuil wrote: > > > > > > On Wednesday 01 April 2009 11:43:28 Eduardo Valentin wrote: > > > > > > > Hello Mauro and v4l guys, > > > > > > > > > > > > > > This series contains a v4l2 radio driver which > > > > > > > adds support for Silabs si4713 devices. That is > > > > > > > a FM transmitter device. > > > > > > > > > > > > > > As you should know, v4l2 does not contain representation > > > > > > > of FM Transmitters (at least that I know). So this driver > > > > > > > was written highly based on FM receivers API, which can > > > > > > > cover most of basic functionality. However, as expected, > > > > > > > there are some properties which were not covered. > > > > > > > For those properties, sysfs nodes were added in order > > > > > > > to get user interactions. > > > > > > > > > > > > > > Comments are wellcome. > > > > > > > > > > > > Can you explain in reasonable detail the extra properties > > > > > > needed for a device like this? You will need to document that > > > > > > anyway :-) Rather than implementing a private API it would be > > > > > > much more interesting to turn this into a public V4L2 API that > > > > > > everyone can use. > > > > > > > > > > Yes, here is a little description of them: > > > > > > > > > > Pilot is an audible tone sent by the device. > > > > > > > > > > pilot_frequency - Configures the frequency of the stereo pilot > > > > > tone. pilot_deviation - Configures pilot tone frequency deviation > > > > > level. pilot_enabled - Enables or disables the pilot tone > > > > > feature. > > > > > > > > > > The si4713 device is capable of applying audio compression to the > > > > > transmitted signal. > > > > > > > > > > acomp_enabled - Enables or disables the audio dynamic range > > > > > control feature. acomp_gain - Sets the gain for audio dynamic > > > > > range control. acomp_threshold - Sets the threshold level for > > > > > audio dynamic range control. acomp_attack_time - Sets the attack > > > > > time for audio dynamic range control. acomp_release_time - Sets > > > > > the release time for audio dynamic range control. > > > > > > > > > > Limiter setups audio deviation limiter feature. Once a over > > > > > deviation occurs, it is possible to adjust the front-end gain of > > > > > the audio input and always prevent over deviation. > > > > > > > > > > limiter_enabled - Enables or disables the limiter feature. > > > > > limiter_deviation - Configures audio frequency deviation level. > > > > > limiter_release_time - Sets the limiter release time. > > > > > > > > > > power_level - Sets the output power level for signal > > > > > transmission. > > > > > > > > Hmm, there are two ways to implement these: either make a bunch of > > > > VIDIOC's for each of these categories, or use extended controls to > > > > set all these values. I'm hardly an expert on FM transmitters, but > > > > it all seems reasonable to me (i.e., not too specific for this > > > > chip). > > > > > > > > I am leaning towards extended controls, since that's so easy to > > > > extend if needed in the future. And I still intend to add sysfs > > > > support to controls in the future. On the other hand, it's a bit > > > > harder to use compared to normal VIDIOCs. > > > > > > Could you please explain more about extended controls vs. VIDIOC's? > > > Pointing drivers which uses one of those also would be worth. But > > > yes, looks like moving this properties to some sort of v4l2 control > > > looks better implementation. > > > > The spec explains it pretty well. The most up to date version of the > > spec is available here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html. > > > > Basically the extended controls API is more flexible than the older > > VIDIOC_S/G_CTRL ioctls, allowing to set controls atomically (either all > > are applied or none) and allowing for a wider range of types, although > > currently that feature isn't used. > > > > It's used by uvcvideo and by MPEG encoders (e.g. cx18, ivtv and > > others). > > > > Using VIDIOCs is easier, but much harder to make future-proof. One > > disadvantage of using extended controls is that it is harder to > > implement in drivers, although I plan on creating a much better > > solution for that in the coming months. With the new v4l framework it > > should be possible to move much of the control handling into the > > framework and so simplifying the drivers. > > > > > > > RDS related > > > > > > > > > > rds_enabled - Enables or disables the RDS feature. > > > > > rds_ps_name - Sets the RDS ps name field for transmission. > > > > > rds_radio_text - Sets the RDS
[PATCH v2] mx3-camera: adapt the clock definition and the driver to the new clock naming
With the i.MX31 transition to clkdev clock names have changed, but mistakenly
the "mx3-camera.0" has been registered with a non-NULL connection ID, which is
not necessary, since this is the only clock, used by the capture interface
driver. Fix the clock definition and the driver to use NULL as a connection ID.
Signed-off-by: Guennadi Liakhovetski
---
Clock connection IDs fixed to NULL. Sascha, please, ack.
arch/arm/mach-mx3/clock.c|2 +-
drivers/media/video/mx3_camera.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mx3/clock.c b/arch/arm/mach-mx3/clock.c
index ca46f48..9957a11 100644
--- a/arch/arm/mach-mx3/clock.c
+++ b/arch/arm/mach-mx3/clock.c
@@ -533,7 +533,7 @@ static struct clk_lookup lookups[] __initdata = {
_REGISTER_CLOCK(NULL, "kpp", kpp_clk)
_REGISTER_CLOCK("fsl-usb2-udc", "usb", usb_clk1)
_REGISTER_CLOCK("fsl-usb2-udc", "usb_ahb", usb_clk2)
- _REGISTER_CLOCK("mx3-camera.0", "csi", csi_clk)
+ _REGISTER_CLOCK("mx3-camera.0", NULL, csi_clk)
_REGISTER_CLOCK("imx-uart.0", NULL, uart1_clk)
_REGISTER_CLOCK("imx-uart.1", NULL, uart2_clk)
_REGISTER_CLOCK("imx-uart.2", NULL, uart3_clk)
diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
index 70629e1..c462b81 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -1100,7 +1100,7 @@ static int mx3_camera_probe(struct platform_device *pdev)
}
memset(mx3_cam, 0, sizeof(*mx3_cam));
- mx3_cam->clk = clk_get(&pdev->dev, "csi_clk");
+ mx3_cam->clk = clk_get(&pdev->dev, NULL);
if (IS_ERR(mx3_cam->clk)) {
err = PTR_ERR(mx3_cam->clk);
goto eclkget;
--
1.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3] Add camera (CSI) driver for MX1
Guennadi Liakhovetski wrote: On Fri, 3 Apr 2009, Darius Augulis wrote: Guennadi Liakhovetski wrote: Ok, we're almost there:-) Should be the last iteration. On Fri, 3 Apr 2009, Darius Augulis wrote: From: Paulius Zaleckas Changelog since V2: - My signed-off line added - Makefile updated - .init and .exit removed from pdata - includes sorted - Video memory limit added - Pointers in free_buffer() fixed - Indentation fixed - Spinlocks added - PM implementation removed - Added missed clk_put() - pdata test added - CSI device renamed - Platform flags fixed - "i.MX" replaced by "MX1" in debug prints I usually put such changelogs below the "---" line, so it doesn't appear in the git commit message, and here you just put a short description of the patch. I'm using Stgit and I can't put anything below --- with "stg edit", because Stgit automatically removes everything what is below ---. I don't want to send patches manually, so I will add changelog in the reply message. Signed-off-by: Darius Augulis Signed-off-by: Paulius Zaleckas --- [snip] -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3] Add camera (CSI) driver for MX1
On Fri, 3 Apr 2009, Darius Augulis wrote: > Guennadi Liakhovetski wrote: > > Ok, we're almost there:-) Should be the last iteration. > > > > On Fri, 3 Apr 2009, Darius Augulis wrote: > > > > > > > From: Paulius Zaleckas > > > > > > Changelog since V2: > > > - My signed-off line added > > > - Makefile updated > > > - .init and .exit removed from pdata > > > - includes sorted > > > - Video memory limit added > > > - Pointers in free_buffer() fixed > > > - Indentation fixed > > > - Spinlocks added > > > - PM implementation removed > > > - Added missed clk_put() > > > - pdata test added > > > - CSI device renamed > > > - Platform flags fixed > > > - "i.MX" replaced by "MX1" in debug prints > > > > > > > I usually put such changelogs below the "---" line, so it doesn't appear in > > the git commit message, and here you just put a short description of the > > patch. > > > > > > > Signed-off-by: Darius Augulis > > > Signed-off-by: Paulius Zaleckas > > > --- > > > > > > > [snip] > > > > > > > diff --git a/arch/arm/plat-mxc/include/mach/memory.h > > > b/arch/arm/plat-mxc/include/mach/memory.h > > > index e0783e6..7113b3e 100644 > > > --- a/arch/arm/plat-mxc/include/mach/memory.h > > > +++ b/arch/arm/plat-mxc/include/mach/memory.h > > > @@ -24,4 +24,12 @@ > > > #define PHYS_OFFSET UL(0x8000) > > > #endif > > > +#if defined(CONFIG_MX1_VIDEO) > > > > > > > This #ifdef is not needed any more now, the file is not compiled if > > CONFIG_MX1_VIDEO is not defined. > > > this header file is included by arch/arm/include/asm/memory.h > By default dma bufer size is only 2Mbytes. If we remove this ifdef, this bufer > will be increased to re-defined size. > Therefore I suggest to leave this ifdef. Ouch, sorry, I meant this one: diff --git a/arch/arm/mach-mx1/ksym_mx1.c b/arch/arm/mach-mx1/ksym_mx1.c new file mode 100644 index 000..9f1116b --- /dev/null +++ b/arch/arm/mach-mx1/ksym_mx1.c @@ -0,0 +1,20 @@ +/* + * Exported ksyms of ARCH_MX1 + * + * Copyright (C) 2008, Darius Augulis + * + * 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. + */ + +#include +#include + +#if defined(CONFIG_MX1_VIDEO) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] FM Transmitter driver
Hi, On Fri, Apr 03, 2009 at 12:36:53PM +0200, ext Hans Verkuil wrote: > On Friday 03 April 2009 12:12:30 Eduardo Valentin wrote: > > On Thu, Apr 02, 2009 at 06:36:37PM +0200, ext Hans Verkuil wrote: > > > On Thursday 02 April 2009 14:02:11 Eduardo Valentin wrote: > > > > Hi Hans, > > > > > > > > On Thu, Apr 02, 2009 at 09:47:11AM +0200, ext Hans Verkuil wrote: > > > > > On Wednesday 01 April 2009 11:43:28 Eduardo Valentin wrote: > > > > > > Hello Mauro and v4l guys, > > > > > > > > > > > > This series contains a v4l2 radio driver which > > > > > > adds support for Silabs si4713 devices. That is > > > > > > a FM transmitter device. > > > > > > > > > > > > As you should know, v4l2 does not contain representation > > > > > > of FM Transmitters (at least that I know). So this driver > > > > > > was written highly based on FM receivers API, which can > > > > > > cover most of basic functionality. However, as expected, > > > > > > there are some properties which were not covered. > > > > > > For those properties, sysfs nodes were added in order > > > > > > to get user interactions. > > > > > > > > > > > > Comments are wellcome. > > > > > > > > > > Can you explain in reasonable detail the extra properties needed > > > > > for a device like this? You will need to document that anyway :-) > > > > > Rather than implementing a private API it would be much more > > > > > interesting to turn this into a public V4L2 API that everyone can > > > > > use. > > > > > > > > Yes, here is a little description of them: > > > > > > > > Pilot is an audible tone sent by the device. > > > > > > > > pilot_frequency - Configures the frequency of the stereo pilot tone. > > > > pilot_deviation - Configures pilot tone frequency deviation level. > > > > pilot_enabled - Enables or disables the pilot tone feature. > > > > > > > > The si4713 device is capable of applying audio compression to the > > > > transmitted signal. > > > > > > > > acomp_enabled - Enables or disables the audio dynamic range control > > > > feature. acomp_gain - Sets the gain for audio dynamic range control. > > > > acomp_threshold - Sets the threshold level for audio dynamic range > > > > control. acomp_attack_time - Sets the attack time for audio dynamic > > > > range control. acomp_release_time - Sets the release time for audio > > > > dynamic range control. > > > > > > > > Limiter setups audio deviation limiter feature. Once a over deviation > > > > occurs, it is possible to adjust the front-end gain of the audio > > > > input and always prevent over deviation. > > > > > > > > limiter_enabled - Enables or disables the limiter feature. > > > > limiter_deviation - Configures audio frequency deviation level. > > > > limiter_release_time - Sets the limiter release time. > > > > > > > > power_level - Sets the output power level for signal transmission. > > > > > > Hmm, there are two ways to implement these: either make a bunch of > > > VIDIOC's for each of these categories, or use extended controls to set > > > all these values. I'm hardly an expert on FM transmitters, but it all > > > seems reasonable to me (i.e., not too specific for this chip). > > > > > > I am leaning towards extended controls, since that's so easy to extend > > > if needed in the future. And I still intend to add sysfs support to > > > controls in the future. On the other hand, it's a bit harder to use > > > compared to normal VIDIOCs. > > > > Could you please explain more about extended controls vs. VIDIOC's? > > Pointing drivers which uses one of those also would be worth. But yes, > > looks like moving this properties to some sort of v4l2 control looks > > better implementation. > > The spec explains it pretty well. The most up to date version of the spec is > available here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html. > > Basically the extended controls API is more flexible than the older > VIDIOC_S/G_CTRL ioctls, allowing to set controls atomically (either all are > applied or none) and allowing for a wider range of types, although > currently that feature isn't used. > > It's used by uvcvideo and by MPEG encoders (e.g. cx18, ivtv and others). > > Using VIDIOCs is easier, but much harder to make future-proof. One > disadvantage of using extended controls is that it is harder to implement > in drivers, although I plan on creating a much better solution for that in > the coming months. With the new v4l framework it should be possible to move > much of the control handling into the framework and so simplifying the > drivers. > > > > > RDS related > > > > > > > > rds_enabled - Enables or disables the RDS feature. > > > > rds_ps_name - Sets the RDS ps name field for transmission. > > > > rds_radio_text - Sets the RDS radio text for transmission. > > > > rds_pi - Sets the RDS PI field for transmission. > > > > rds_pty - Sets the RDS PTY field for transmission. > > > > > > So you set the fields and the RDS encoder will just start using them? > > > > Once you have rds_enabled set, ye
Re: [PATCH V3] Add camera (CSI) driver for MX1
Guennadi Liakhovetski wrote:
Ok, we're almost there:-) Should be the last iteration.
On Fri, 3 Apr 2009, Darius Augulis wrote:
From: Paulius Zaleckas
Changelog since V2:
- My signed-off line added
- Makefile updated
- .init and .exit removed from pdata
- includes sorted
- Video memory limit added
- Pointers in free_buffer() fixed
- Indentation fixed
- Spinlocks added
- PM implementation removed
- Added missed clk_put()
- pdata test added
- CSI device renamed
- Platform flags fixed
- "i.MX" replaced by "MX1" in debug prints
I usually put such changelogs below the "---" line, so it doesn't appear
in the git commit message, and here you just put a short description of
the patch.
Signed-off-by: Darius Augulis
Signed-off-by: Paulius Zaleckas
---
[snip]
diff --git a/arch/arm/plat-mxc/include/mach/memory.h
b/arch/arm/plat-mxc/include/mach/memory.h
index e0783e6..7113b3e 100644
--- a/arch/arm/plat-mxc/include/mach/memory.h
+++ b/arch/arm/plat-mxc/include/mach/memory.h
@@ -24,4 +24,12 @@
#define PHYS_OFFSETUL(0x8000)
#endif
+#if defined(CONFIG_MX1_VIDEO)
This #ifdef is not needed any more now, the file is not compiled if
CONFIG_MX1_VIDEO is not defined.
this header file is included by arch/arm/include/asm/memory.h
By default dma bufer size is only 2Mbytes. If we remove this ifdef, this
bufer will be increased to re-defined size.
Therefore I suggest to leave this ifdef.
+ /* Make choises, based on platform choice */
+ if ((common_flags & SOCAM_VSYNC_ACTIVE_HIGH) &&
+ (common_flags & SOCAM_VSYNC_ACTIVE_LOW)) {
+ if (pcdev->pdata->flags & MX1_CAMERA_VSYNC_HIGH)
+ common_flags &= ~SOCAM_VSYNC_ACTIVE_LOW;
+ else
+ common_flags &= ~SOCAM_VSYNC_ACTIVE_HIGH;
+ }
+
+ if ((common_flags & SOCAM_PCLK_SAMPLE_RISING) &&
+ (common_flags & SOCAM_PCLK_SAMPLE_FALLING)) {
+ if (pcdev->pdata->flags & MX1_CAMERA_PCLK_RISING)
+ common_flags &= ~SOCAM_PCLK_SAMPLE_FALLING;
+ else
+ common_flags &= ~SOCAM_PCLK_SAMPLE_RISING;
+ }
+
+ if ((common_flags & SOCAM_DATA_ACTIVE_HIGH) &&
+ (common_flags & SOCAM_DATA_ACTIVE_LOW)) {
+ if (pcdev->pdata->flags & MX1_CAMERA_DATA_HIGH)
+ common_flags &= ~SOCAM_DATA_ACTIVE_LOW;
+ else
+ common_flags &= ~SOCAM_DATA_ACTIVE_HIGH;
+ }
In all three clauses above pdata can be NULL.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] FM Transmitter driver
On Friday 03 April 2009 12:12:30 Eduardo Valentin wrote: > On Thu, Apr 02, 2009 at 06:36:37PM +0200, ext Hans Verkuil wrote: > > On Thursday 02 April 2009 14:02:11 Eduardo Valentin wrote: > > > Hi Hans, > > > > > > On Thu, Apr 02, 2009 at 09:47:11AM +0200, ext Hans Verkuil wrote: > > > > On Wednesday 01 April 2009 11:43:28 Eduardo Valentin wrote: > > > > > Hello Mauro and v4l guys, > > > > > > > > > > This series contains a v4l2 radio driver which > > > > > adds support for Silabs si4713 devices. That is > > > > > a FM transmitter device. > > > > > > > > > > As you should know, v4l2 does not contain representation > > > > > of FM Transmitters (at least that I know). So this driver > > > > > was written highly based on FM receivers API, which can > > > > > cover most of basic functionality. However, as expected, > > > > > there are some properties which were not covered. > > > > > For those properties, sysfs nodes were added in order > > > > > to get user interactions. > > > > > > > > > > Comments are wellcome. > > > > > > > > Can you explain in reasonable detail the extra properties needed > > > > for a device like this? You will need to document that anyway :-) > > > > Rather than implementing a private API it would be much more > > > > interesting to turn this into a public V4L2 API that everyone can > > > > use. > > > > > > Yes, here is a little description of them: > > > > > > Pilot is an audible tone sent by the device. > > > > > > pilot_frequency - Configures the frequency of the stereo pilot tone. > > > pilot_deviation - Configures pilot tone frequency deviation level. > > > pilot_enabled - Enables or disables the pilot tone feature. > > > > > > The si4713 device is capable of applying audio compression to the > > > transmitted signal. > > > > > > acomp_enabled - Enables or disables the audio dynamic range control > > > feature. acomp_gain - Sets the gain for audio dynamic range control. > > > acomp_threshold - Sets the threshold level for audio dynamic range > > > control. acomp_attack_time - Sets the attack time for audio dynamic > > > range control. acomp_release_time - Sets the release time for audio > > > dynamic range control. > > > > > > Limiter setups audio deviation limiter feature. Once a over deviation > > > occurs, it is possible to adjust the front-end gain of the audio > > > input and always prevent over deviation. > > > > > > limiter_enabled - Enables or disables the limiter feature. > > > limiter_deviation - Configures audio frequency deviation level. > > > limiter_release_time - Sets the limiter release time. > > > > > > power_level - Sets the output power level for signal transmission. > > > > Hmm, there are two ways to implement these: either make a bunch of > > VIDIOC's for each of these categories, or use extended controls to set > > all these values. I'm hardly an expert on FM transmitters, but it all > > seems reasonable to me (i.e., not too specific for this chip). > > > > I am leaning towards extended controls, since that's so easy to extend > > if needed in the future. And I still intend to add sysfs support to > > controls in the future. On the other hand, it's a bit harder to use > > compared to normal VIDIOCs. > > Could you please explain more about extended controls vs. VIDIOC's? > Pointing drivers which uses one of those also would be worth. But yes, > looks like moving this properties to some sort of v4l2 control looks > better implementation. The spec explains it pretty well. The most up to date version of the spec is available here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html. Basically the extended controls API is more flexible than the older VIDIOC_S/G_CTRL ioctls, allowing to set controls atomically (either all are applied or none) and allowing for a wider range of types, although currently that feature isn't used. It's used by uvcvideo and by MPEG encoders (e.g. cx18, ivtv and others). Using VIDIOCs is easier, but much harder to make future-proof. One disadvantage of using extended controls is that it is harder to implement in drivers, although I plan on creating a much better solution for that in the coming months. With the new v4l framework it should be possible to move much of the control handling into the framework and so simplifying the drivers. > > > RDS related > > > > > > rds_enabled - Enables or disables the RDS feature. > > > rds_ps_name - Sets the RDS ps name field for transmission. > > > rds_radio_text - Sets the RDS radio text for transmission. > > > rds_pi - Sets the RDS PI field for transmission. > > > rds_pty - Sets the RDS PTY field for transmission. > > > > So you set the fields and the RDS encoder will just start using them? > > Once you have rds_enabled set, yes, it will transmit them. > > > This too can be done with controls (needs some work, though, to support > > string controls). > > Yes, true. > > > > Region related > > > > > > Setting region will affect other region properties. > > > > > > region_bottom_frequency > > > r
Re: [PATCH V3] Add camera (CSI) driver for MX1
Ok, we're almost there:-) Should be the last iteration.
On Fri, 3 Apr 2009, Darius Augulis wrote:
> From: Paulius Zaleckas
>
> Changelog since V2:
> - My signed-off line added
> - Makefile updated
> - .init and .exit removed from pdata
> - includes sorted
> - Video memory limit added
> - Pointers in free_buffer() fixed
> - Indentation fixed
> - Spinlocks added
> - PM implementation removed
> - Added missed clk_put()
> - pdata test added
> - CSI device renamed
> - Platform flags fixed
> - "i.MX" replaced by "MX1" in debug prints
I usually put such changelogs below the "---" line, so it doesn't appear
in the git commit message, and here you just put a short description of
the patch.
>
> Signed-off-by: Darius Augulis
> Signed-off-by: Paulius Zaleckas
> ---
[snip]
> diff --git a/arch/arm/plat-mxc/include/mach/memory.h
> b/arch/arm/plat-mxc/include/mach/memory.h
> index e0783e6..7113b3e 100644
> --- a/arch/arm/plat-mxc/include/mach/memory.h
> +++ b/arch/arm/plat-mxc/include/mach/memory.h
> @@ -24,4 +24,12 @@
> #define PHYS_OFFSET UL(0x8000)
> #endif
>
> +#if defined(CONFIG_MX1_VIDEO)
This #ifdef is not needed any more now, the file is not compiled if
CONFIG_MX1_VIDEO is not defined.
> + /* Make choises, based on platform choice */
> + if ((common_flags & SOCAM_VSYNC_ACTIVE_HIGH) &&
> + (common_flags & SOCAM_VSYNC_ACTIVE_LOW)) {
> + if (pcdev->pdata->flags & MX1_CAMERA_VSYNC_HIGH)
> + common_flags &= ~SOCAM_VSYNC_ACTIVE_LOW;
> + else
> + common_flags &= ~SOCAM_VSYNC_ACTIVE_HIGH;
> + }
> +
> + if ((common_flags & SOCAM_PCLK_SAMPLE_RISING) &&
> + (common_flags & SOCAM_PCLK_SAMPLE_FALLING)) {
> + if (pcdev->pdata->flags & MX1_CAMERA_PCLK_RISING)
> + common_flags &= ~SOCAM_PCLK_SAMPLE_FALLING;
> + else
> + common_flags &= ~SOCAM_PCLK_SAMPLE_RISING;
> + }
> +
> + if ((common_flags & SOCAM_DATA_ACTIVE_HIGH) &&
> + (common_flags & SOCAM_DATA_ACTIVE_LOW)) {
> + if (pcdev->pdata->flags & MX1_CAMERA_DATA_HIGH)
> + common_flags &= ~SOCAM_DATA_ACTIVE_LOW;
> + else
> + common_flags &= ~SOCAM_DATA_ACTIVE_HIGH;
> + }
In all three clauses above pdata can be NULL.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] FM Transmitter driver
On Thu, Apr 02, 2009 at 06:36:37PM +0200, ext Hans Verkuil wrote: > On Thursday 02 April 2009 14:02:11 Eduardo Valentin wrote: > > Hi Hans, > > > > On Thu, Apr 02, 2009 at 09:47:11AM +0200, ext Hans Verkuil wrote: > > > On Wednesday 01 April 2009 11:43:28 Eduardo Valentin wrote: > > > > Hello Mauro and v4l guys, > > > > > > > > This series contains a v4l2 radio driver which > > > > adds support for Silabs si4713 devices. That is > > > > a FM transmitter device. > > > > > > > > As you should know, v4l2 does not contain representation > > > > of FM Transmitters (at least that I know). So this driver > > > > was written highly based on FM receivers API, which can > > > > cover most of basic functionality. However, as expected, > > > > there are some properties which were not covered. > > > > For those properties, sysfs nodes were added in order > > > > to get user interactions. > > > > > > > > Comments are wellcome. > > > > > > Can you explain in reasonable detail the extra properties needed for a > > > device like this? You will need to document that anyway :-) Rather than > > > implementing a private API it would be much more interesting to turn this > > > into a public V4L2 API that everyone can use. > > > > Yes, here is a little description of them: > > > > Pilot is an audible tone sent by the device. > > > > pilot_frequency - Configures the frequency of the stereo pilot tone. > > pilot_deviation - Configures pilot tone frequency deviation level. > > pilot_enabled - Enables or disables the pilot tone feature. > > > > The si4713 device is capable of applying audio compression to the > > transmitted signal. > > > > acomp_enabled - Enables or disables the audio dynamic range control feature. > > acomp_gain - Sets the gain for audio dynamic range control. > > acomp_threshold - Sets the threshold level for audio dynamic range control. > > acomp_attack_time - Sets the attack time for audio dynamic range control. > > acomp_release_time - Sets the release time for audio dynamic range control. > > > > Limiter setups audio deviation limiter feature. Once a over deviation > > occurs, > > it is possible to adjust the front-end gain of the audio input and always > > prevent over deviation. > > > > limiter_enabled - Enables or disables the limiter feature. > > limiter_deviation - Configures audio frequency deviation level. > > limiter_release_time - Sets the limiter release time. > > > > power_level - Sets the output power level for signal transmission. > > Hmm, there are two ways to implement these: either make a bunch of VIDIOC's > for each of these categories, or use extended controls to set all these > values. I'm hardly an expert on FM transmitters, but it all seems reasonable > to me (i.e., not too specific for this chip). > > I am leaning towards extended controls, since that's so easy to extend if > needed in the future. And I still intend to add sysfs support to controls > in the future. On the other hand, it's a bit harder to use compared to normal > VIDIOCs. Could you please explain more about extended controls vs. VIDIOC's? Pointing drivers which uses one of those also would be worth. But yes, looks like moving this properties to some sort of v4l2 control looks better implementation. > > > > > RDS related > > > > rds_enabled - Enables or disables the RDS feature. > > rds_ps_name - Sets the RDS ps name field for transmission. > > rds_radio_text - Sets the RDS radio text for transmission. > > rds_pi - Sets the RDS PI field for transmission. > > rds_pty - Sets the RDS PTY field for transmission. > > So you set the fields and the RDS encoder will just start using them? Once you have rds_enabled set, yes, it will transmit them. > > This too can be done with controls (needs some work, though, to support > string controls). Yes, true. > > > > > Region related > > > > Setting region will affect other region properties. > > > > region_bottom_frequency > > region_channel_spacing > > region_preemphasis > > region_top_frequency > > I do not know enough about FM transmissions to judge this. Are these region > properties something that is regulated by some standards commision? Do they > also apply when you modulate this over a TV/radio cable system? Do you have > some documentation or links that I can look at to learn more about this? > > > stereo_enabled - Enables or disables stereo mode. > > > > > > > > How does one pass the audio and rds data to the driver? Note that for > > > 2.6.31 > > > we will finalize the V4L2 RDS decoder API (I recently posted an RFC for > > > that, but I haven't had the time to implement the few changes needed). It > > > would be nice if rds modulator support would be modeled after this > > > demodulator API if possible. > > > > I see. This is good. I think the best way is to have a rds modulator > > interface. This driver have implemented it as sys properties, as > > described above. > > I don't think there is that much overlap, though. The similariti
Re: Hauppauge WinTV-HVR-4000 / Nova-HD-S2
Jonas Kvinge wrote: > Whats the command to extract the firmware from the new driver release at > http://www.wintvcd.co.uk/drivers/88x_2_123_27056_WHQL.zip > > The driver at http://www.wintvcd.co.uk/drivers/88x_2_122_26109_WHQL.zip > is no longer available, so the link on > http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-4000 is broken. > Hi Jonas, I can't remember the exact command off the top of my head. But I can tell you how to work it out. The problem is how to determine the offset to use. Look at this hex dump from the start of each firmware file: dvb-fe-cx24116-1.20.79.0.fw: 02 11 f9 ec 33 50 03 12 dvb-fe-cx24116-1.22.82.0.fw: 02 11 fb ec 33 50 03 12 dvb-fe-cx24116-1.23.86.1.fw: 02 12 02 ec 33 50 03 12 Note the magic `33 50 03 12` bytes that appear at offset 4 in each firmware file. You can use that to determine the offset of the firmware in the `hcw88bda.sys` file (at least for the existing firmware files). I used `hd hcw88bda.sys | more` and typed `/33 50 03 12` in `more` to find the offset. Make sure to subtract 4 from the offset of the `33 50 03 12` bytes. Convert the offset from hex to decimal and use that as the `skip` amount for the `dd` command. Verify the extracted firmware using `md5sum`. Perhaps when you get it to work you could update the wiki page you mentioned. Kevin -- 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] mx3-camera: fix to match the new clock naming
On Fri, Apr 03, 2009 at 10:49:32AM +0200, Guennadi Liakhovetski wrote:
> On Fri, 3 Apr 2009, Sascha Hauer wrote:
>
> > On Thu, Apr 02, 2009 at 11:49:55AM +0200, Guennadi Liakhovetski wrote:
> > > With the i.MX31 transition to clkdev clock names have changed, fix the
> > > driver to use the new name.
> > >
> > > Signed-off-by: Guennadi Liakhovetski
> > > ---
> > > diff --git a/drivers/media/video/mx3_camera.c
> > > b/drivers/media/video/mx3_camera.c
> > > index 70629e1..7e6b51d 100644
> > > --- a/drivers/media/video/mx3_camera.c
> > > +++ b/drivers/media/video/mx3_camera.c
> > > @@ -1100,7 +1100,7 @@ static int mx3_camera_probe(struct platform_device
> > > *pdev)
> > > }
> > > memset(mx3_cam, 0, sizeof(*mx3_cam));
> > >
> > > - mx3_cam->clk = clk_get(&pdev->dev, "csi_clk");
> > > + mx3_cam->clk = clk_get(&pdev->dev, "csi");
> >
> > clk_get(&pdev->dev, NULL) please. The name is only for distinguishing
> > the clocks when there is more than one clock per device which isn't the
> > case here.
> >
> > I just see that it's
> >
> > _REGISTER_CLOCK("mx3-camera.0", "csi", csi_clk)
> >
> > Should be
> >
> > _REGISTER_CLOCK("mx3-camera.0", NULL, csi_clk)
> >
> > instead.
>
> Right, that's why. What should we do now?
>
> 1. We leave this patch as is, and remove the connection ID later
> 2. I make a single patch that changes both, you ack it, and I pull it via
> V4L.
> 3. I make two patches, you ack the ARM part and I pull them via V$L.
> 4. We do not want to pull two patches via different trees
2) is ok for me.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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] mx3-camera: fix to match the new clock naming
On Fri, 3 Apr 2009, Sascha Hauer wrote:
> On Thu, Apr 02, 2009 at 11:49:55AM +0200, Guennadi Liakhovetski wrote:
> > With the i.MX31 transition to clkdev clock names have changed, fix the
> > driver to use the new name.
> >
> > Signed-off-by: Guennadi Liakhovetski
> > ---
> > diff --git a/drivers/media/video/mx3_camera.c
> > b/drivers/media/video/mx3_camera.c
> > index 70629e1..7e6b51d 100644
> > --- a/drivers/media/video/mx3_camera.c
> > +++ b/drivers/media/video/mx3_camera.c
> > @@ -1100,7 +1100,7 @@ static int mx3_camera_probe(struct platform_device
> > *pdev)
> > }
> > memset(mx3_cam, 0, sizeof(*mx3_cam));
> >
> > - mx3_cam->clk = clk_get(&pdev->dev, "csi_clk");
> > + mx3_cam->clk = clk_get(&pdev->dev, "csi");
>
> clk_get(&pdev->dev, NULL) please. The name is only for distinguishing
> the clocks when there is more than one clock per device which isn't the
> case here.
>
> I just see that it's
>
> _REGISTER_CLOCK("mx3-camera.0", "csi", csi_clk)
>
> Should be
>
> _REGISTER_CLOCK("mx3-camera.0", NULL, csi_clk)
>
> instead.
Right, that's why. What should we do now?
1. We leave this patch as is, and remove the connection ID later
2. I make a single patch that changes both, you ack it, and I pull it via
V4L.
3. I make two patches, you ack the ARM part and I pull them via V$L.
4. We do not want to pull two patches via different trees
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.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
Re: [PATCH] mx3-camera: fix to match the new clock naming
On Thu, Apr 02, 2009 at 11:49:55AM +0200, Guennadi Liakhovetski wrote:
> With the i.MX31 transition to clkdev clock names have changed, fix the
> driver to use the new name.
>
> Signed-off-by: Guennadi Liakhovetski
> ---
> diff --git a/drivers/media/video/mx3_camera.c
> b/drivers/media/video/mx3_camera.c
> index 70629e1..7e6b51d 100644
> --- a/drivers/media/video/mx3_camera.c
> +++ b/drivers/media/video/mx3_camera.c
> @@ -1100,7 +1100,7 @@ static int mx3_camera_probe(struct platform_device
> *pdev)
> }
> memset(mx3_cam, 0, sizeof(*mx3_cam));
>
> - mx3_cam->clk = clk_get(&pdev->dev, "csi_clk");
> + mx3_cam->clk = clk_get(&pdev->dev, "csi");
clk_get(&pdev->dev, NULL) please. The name is only for distinguishing
the clocks when there is more than one clock per device which isn't the
case here.
I just see that it's
_REGISTER_CLOCK("mx3-camera.0", "csi", csi_clk)
Should be
_REGISTER_CLOCK("mx3-camera.0", NULL, csi_clk)
instead.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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 V3] Add camera (CSI) driver for MX1
From: Paulius Zaleckas
Changelog since V2:
- My signed-off line added
- Makefile updated
- .init and .exit removed from pdata
- includes sorted
- Video memory limit added
- Pointers in free_buffer() fixed
- Indentation fixed
- Spinlocks added
- PM implementation removed
- Added missed clk_put()
- pdata test added
- CSI device renamed
- Platform flags fixed
- "i.MX" replaced by "MX1" in debug prints
Signed-off-by: Darius Augulis
Signed-off-by: Paulius Zaleckas
---
arch/arm/mach-mx1/Makefile |5
arch/arm/mach-mx1/devices.c |2
arch/arm/mach-mx1/ksym_mx1.c| 20 +
arch/arm/mach-mx1/mx1_camera_fiq.S | 35 +
arch/arm/plat-mxc/include/mach/memory.h |8
arch/arm/plat-mxc/include/mach/mx1_camera.h | 35 +
drivers/media/video/Kconfig | 13
drivers/media/video/Makefile|1
drivers/media/video/mx1_camera.c| 824 +++
9 files changed, 940 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/mach-mx1/ksym_mx1.c
create mode 100644 arch/arm/mach-mx1/mx1_camera_fiq.S
create mode 100644 arch/arm/plat-mxc/include/mach/mx1_camera.h
create mode 100644 drivers/media/video/mx1_camera.c
diff --git a/arch/arm/mach-mx1/Makefile b/arch/arm/mach-mx1/Makefile
index 5e85456..2097021 100644
--- a/arch/arm/mach-mx1/Makefile
+++ b/arch/arm/mach-mx1/Makefile
@@ -6,6 +6,9 @@
obj-y += generic.o clock.o devices.o
+# Support for CMOS sensor interface
+obj-$(CONFIG_MX1_VIDEO)+= ksym_mx1.o mx1_camera_fiq.o
+
# Power management
obj-$(CONFIG_PM) += pm.o
@@ -15,4 +18,4 @@ endif
# Specific board support
obj-$(CONFIG_ARCH_MX1ADS) += mx1ads.o
-obj-$(CONFIG_MACH_SCB9328) += scb9328.o
\ No newline at end of file
+obj-$(CONFIG_MACH_SCB9328) += scb9328.o
diff --git a/arch/arm/mach-mx1/devices.c b/arch/arm/mach-mx1/devices.c
index 97f42d9..76d1ffb 100644
--- a/arch/arm/mach-mx1/devices.c
+++ b/arch/arm/mach-mx1/devices.c
@@ -44,7 +44,7 @@ static struct resource imx_csi_resources[] = {
static u64 imx_csi_dmamask = 0xUL;
struct platform_device imx_csi_device = {
- .name = "imx-csi",
+ .name = "mx1-camera",
.id = 0, /* This is used to put cameras on this interface */
.dev= {
.dma_mask = &imx_csi_dmamask,
diff --git a/arch/arm/mach-mx1/ksym_mx1.c b/arch/arm/mach-mx1/ksym_mx1.c
new file mode 100644
index 000..9f1116b
--- /dev/null
+++ b/arch/arm/mach-mx1/ksym_mx1.c
@@ -0,0 +1,20 @@
+/*
+ * Exported ksyms of ARCH_MX1
+ *
+ * Copyright (C) 2008, Darius Augulis
+ *
+ * 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.
+ */
+
+#include
+#include
+
+#if defined(CONFIG_MX1_VIDEO)
+#include
+
+/* IMX camera FIQ handler */
+EXPORT_SYMBOL(mx1_camera_sof_fiq_start);
+EXPORT_SYMBOL(mx1_camera_sof_fiq_end);
+#endif
diff --git a/arch/arm/mach-mx1/mx1_camera_fiq.S
b/arch/arm/mach-mx1/mx1_camera_fiq.S
new file mode 100644
index 000..9c69aa6
--- /dev/null
+++ b/arch/arm/mach-mx1/mx1_camera_fiq.S
@@ -0,0 +1,35 @@
+/*
+ * Copyright (C) 2008 Paulius Zaleckas
+ *
+ * Based on linux/arch/arm/lib/floppydma.S
+ * Copyright (C) 1995, 1996 Russell King
+ *
+ * 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.
+ */
+#include
+#include
+
+ .text
+ .global mx1_camera_sof_fiq_end
+ .global mx1_camera_sof_fiq_start
+mx1_camera_sof_fiq_start:
+ @ enable dma
+ ldr r12, [r9]
+ orr r12, r12, #0x0001
+ str r12, [r9]
+ @ unmask DMA interrupt
+ ldr r12, [r8]
+ bic r12, r12, r13
+ str r12, [r8]
+ @ disable SOF interrupt
+ ldr r12, [r10]
+ bic r12, r12, #0x0001
+ str r12, [r10]
+ @ clear SOF flag
+ mov r12, #0x0001
+ str r12, [r11]
+ @ return from FIQ
+ subspc, lr, #4
+mx1_camera_sof_fiq_end:
diff --git a/arch/arm/plat-mxc/include/mach/memory.h
b/arch/arm/plat-mxc/include/mach/memory.h
index e0783e6..7113b3e 100644
--- a/arch/arm/plat-mxc/include/mach/memory.h
+++ b/arch/arm/plat-mxc/include/mach/memory.h
@@ -24,4 +24,12 @@
#define PHYS_OFFSETUL(0x8000)
#endif
+#if defined(CONFIG_MX1_VIDEO)
+/*
+ * Increase size of DMA-consistent memory region.
+ * This is required for i.MX camera driver to capture at least four VGA frames.
+ */
+#define CONSISTENT_DMA_SIZE SZ_8M
+#endif /* CONFIG_MX1_VIDEO */
+
#endif /* __ASM_ARCH_MXC_MEMORY_H__ */
Re: Wintv-1250 - EEPROM decoding - V4L DVB
I have rev E1D9. Below is my dmesg output after applying the same change as Michel had shown. [ 466.833952] cx23885 driver version 0.0.1 loaded [ 466.833979] cx23885 :03:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 [ 466.833981] cx23885[0]/0: cx23885_dev_setup() Memory configured for PCIe bridge type 885 [ 466.833982] cx23885[0]/0: cx23885_init_tsport(portno=2) [ 466.834054] CORE cx23885[0]: subsystem: 0070:7911, board: Hauppauge WinTV-HVR1250 [card=3,autodetected] [ 466.834055] cx23885[0]/0: cx23885_pci_quirks() [ 466.834057] cx23885[0]/0: cx23885_dev_setup() tuner_type = 0x0 tuner_addr = 0x0 [ 466.834059] cx23885[0]/0: cx23885_dev_setup() radio_type = 0x0 radio_addr = 0x0 [ 466.834059] cx23885[0]/0: cx23885_reset() [ 466.934080] cx23885[0]/0: cx23885_sram_channel_setup() Configuring channel [VID A] [ 466.934091] cx23885[0]/0: cx23885_sram_channel_setup() Erasing channel [ch2] [ 466.934092] cx23885[0]/0: cx23885_sram_channel_setup() Configuring channel [TS1 B] [ 466.934106] cx23885[0]/0: cx23885_sram_channel_setup() Erasing channel [ch4] [ 466.934107] cx23885[0]/0: cx23885_sram_channel_setup() Erasing channel [ch5] [ 466.934108] cx23885[0]/0: cx23885_sram_channel_setup() Configuring channel [TS2 C] [ 466.934122] cx23885[0]/0: cx23885_sram_channel_setup() Erasing channel [ch7] [ 466.934123] cx23885[0]/0: cx23885_sram_channel_setup() Erasing channel [ch8] [ 466.934125] cx23885[0]/0: cx23885_sram_channel_setup() Erasing channel [ch9] [ 466.961642] tveeprom 1-0050: Hauppauge model 79001, rev E1D9, serial# 3450857 [ 466.961645] tveeprom 1-0050: MAC address is 00-0D-FE-34-A7-E9 [ 466.961646] tveeprom 1-0050: tuner model is Microtune MT2131 (idx 139, type 4) [ 466.961648] tveeprom 1-0050: TV standards NTSC(M) ATSC/DVB Digital (eeprom 0x88) [ 466.961649] tveeprom 1-0050: audio processor is CX23885 (idx 39) [ 466.961650] tveeprom 1-0050: decoder processor is CX23885 (idx 33) [ 466.961651] tveeprom 1-0050: has no radio, has IR receiver, has no IR transmitter [ 466.961652] cx23885[0]: hauppauge eeprom: model=79001 [ 466.961654] cx23885_dvb_register() allocating 1 frontend(s) [ 466.962728] cx23885[0]: cx23885 based dvb card [ 466.991727] MT2131: successfully identified at address 0x61 [ 466.991730] DVB: registering new adapter (cx23885[0]) [ 466.991732] DVB: registering adapter 0 frontend -1601531515 (Samsung S5H1409 QAM/8VSB Frontend)... [ 466.992748] cx23885_dev_checkrevision() Hardware revision = 0xc0 [ 466.992754] cx23885[0]/0: found at :03:00.0, rev: 3, irq: 19, latency: 0, mmio: 0xea00 [ 466.992761] cx23885 :03:00.0: setting latency timer to 64 On Thursday April 02 2009 10:43:36 am Steven Toth wrote: > Michel Dansereau wrote: > > Steve, > >Point taken about dropping the mailing list. > >Thanks! > > Michel > > Thanks, one last question. > > Look a the white Hauppauge label on the HVR-1250 tuner, its should say > something like Rev . > > What is your rev? > > - Steve > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DTV2000H rev. J support (patch included)
Hi! I have an Leadtek DTV200H rev. J hybrid card, I bought it like a half of year back. It's not the same as regular DTV2000, rev. J was mentioned to be Vista compatible or so, they changed smth, like GPIO values. There was this guy Zbynek Hrabovsky who made path and posted it to kernel mailing list (I think), but he got quite funny responses and nothing really evolved. I want to help to support this card out of the box. I made a patch for 2.6.29 kernel, which differs from Zbynek's patch, however GPIO values were taken from his patch (video ones), I don't know about radio ones at all. I'll attach the patch to this email, I'll attach dmesg output as well. There are some problems with this card and driver currently. The card works only when computer is started for the second time - from the cold start card doesn't work at all, then I restart computer and card starts working. I suspect this is because of two TV inputs. The card have 2 TV inputs: one digital + analog and second only analog. This patch works with one TV input only (the first I think), previously I remember to have both of them working, only change in patch was vmux = 0 for both TV inputs. Now I changed them for 0 and 1 respectively. I don't have that knowledge to know what should be what. I really hope You guys can help with this. I haven't tested digital video and dmesg show funny messages about frontend not to be supported. I really hope this can be finished finally. If You will need anything, please ask, I'll do whatever I can to help. regards Kirurgs --- http://www.one.lv - Tavs mobilais e-pasts! Tagad lasi savu e-pastu ar mobilo telefonu - wap.one.lv! dmesg_output.txt Description: dmesg_output.txt add_dtv200hj.patch Description: add_dtv200hj.patch
