Re: [PATCH 04/14] MAINTAINERS: fix drivers/media/i2c/cx2341x.c
On Sun March 3 2013 02:53:42 Cesar Eduardo Barros wrote: This file was moved to drivers/media/common/ by commit 6259582 ([media] cx2341x: move from media/i2c to media/common). Cc: Hans Verkuil hverk...@xs4all.nl Cc: linux-media@vger.kernel.org Signed-off-by: Cesar Eduardo Barros ces...@cesarb.net --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 5af82f9..261b245 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2286,7 +2286,7 @@ L: linux-media@vger.kernel.org T: git git://linuxtv.org/media_tree.git W: http://linuxtv.org S: Maintained -F: drivers/media/i2c/cx2341x* +F: drivers/media/common/cx2341x* F: include/media/cx2341x* CX88 VIDEO4LINUX DRIVER Acked-by: Hans Verkuil hans.verk...@cisco.com Thanks! I completely forgot to update this when I moved the file. Regards, Hans -- 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
uvcvideo USERPTR mode busted?
Hello, Trying to use USERPTR buffers with UVC, user space gets stuck either in poll(POLLIN) or in ioctl(VIDIOC_DQBUF). It seems the UVC driver never ever returns a frame in USERPTR mode. The symptoms are identical with kernel versions 3.6, 3.7 and 3.8. I also tested 3.2, but it did not support USERPTR. Tested hardware was Logitech HD Pro Webcam C920 with YUY2 pixel format. The same hardware and the same driver work fine with MMAP buffers. The same USERPTR userspace code works fine with the vivi test device... Did any have any better luck? -- Rémi Denis-Courmont http://www.remlab.net/ -- 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: mb86a20s and cx23885
Hi Mauro and others from the list
El 06/02/13 11:12, Alfredo Jesús Delaiti escribió:
Hi
El 28/01/13 17:47, Alfredo Jesús Delaiti escribió:
Hi
El 28/01/13 07:23, Mauro Carvalho Chehab escribió:
Em Sun, 27 Jan 2013 18:48:57 -0300
Alfredo Jesús Delaiti alfredodela...@netscape.net escreveu:
Hi
El 27/01/13 13:16, Mauro Carvalho Chehab escribió:
Em Sun, 27 Jan 2013 12:27:21 -0300
Alfredo Jesús Delaiti alfredodela...@netscape.net escreveu:
Hi all
I'm trying to run the digital part of the card MyGica X8507 and I
need
help on some issues.
Need data sheet of IC MB86A20S and no where to get it. Fujitsu
People of
Germany told me: This is a very old product and not supported any
more. Does anyone know where to get it?
I never found any public datasheet for this device.
Congratulations for driver you have made
Thanks!
linux-puon:/home/alfredo # modprobe cx23885 i2c_scan=1
...
[ 7011.618381] cx23885[0]: scan bus 0:
[ 7011.620759] cx23885[0]: i2c scan: found device @ 0x20 [???]
[ 7011.625653] cx23885[0]: i2c scan: found device @ 0x66 [???]
[ 7011.629702] cx23885[0]: i2c scan: found device @ 0xa0 [eeprom]
[ 7011.629983] cx23885[0]: i2c scan: found device @ 0xa4 [???]
[ 7011.630267] cx23885[0]: i2c scan: found device @ 0xa8 [???]
[ 7011.630548] cx23885[0]: i2c scan: found device @ 0xac [???]
[ 7011.636438] cx23885[0]: scan bus 1:
[ 7011.650108] cx23885[0]: i2c scan: found device @ 0xc2
[tuner/mt2131/tda8275/xc5000/xc3028]
[ 7011.654460] cx23885[0]: scan bus 2:
[ 7011.656434] cx23885[0]: i2c scan: found device @ 0x66 [???]
[ 7011.657087] cx23885[0]: i2c scan: found device @ 0x88 [cx25837]
[ 7011.657393] cx23885[0]: i2c scan: found device @ 0x98 [flatiron]
...
In the bus 0 is demodulator mb86a20s 0x20 (0x10) and in the bus 1
the
tuner (xc5000). I understand that would have to be cancel the
mb86a20s
i2c_gate_ctrl similarly as in the IC zl10353. If this is
possible, is
not yet implemented in the controller of mb86a20s. The IC cx23885 is
always who controls the tuner i2c bus.
Well, if you don't add an i2c_gate_ctrl() callback, the mb86a20s
won't
be calling it. So, IMO, the cleanest approach would simply to do:
fe-dvb.frontend-ops.i2c_gate_ctrl = NULL;
after tuner attach, if the tuner or the bridge driver implements
an i2c gate.
I don't think xc5000 does. The mb86a20s also has its own i2c gate
and gpio
ports that might be used to control an external gate, but support
for it is
currently not implemented, as no known device uses it.
If in this way, it does not work:
case CX23885_BOARD_MYGICA_X8507:
i2c_bus = dev-i2c_bus[0];
i2c_bus2 = dev-i2c_bus[1];
fe0-dvb.frontend = dvb_attach(mb86a20s_attach,
mygica_x8507_mb86a20s_config,
i2c_bus-i2c_adap);
if (fe0-dvb.frontend != NULL) {
dvb_attach(xc5000_attach,
fe0-dvb.frontend,
i2c_bus2-i2c_adap,
mygica_x8507_xc5000_config);
fe0-dvb.frontend-ops.i2c_gate_ctrl = NULL;
fe0-dvb.frontend-ops.tuner_ops.init(fe0-dvb.frontend);
I get:
...dmesg
...
[ 964.105688] mb86a20s: mb86a20s_read_status: val = 2, status = 0x01
[ 964.105696] mb86a20s: mb86a20s_set_frontend:
[ 964.105700] mb86a20s: mb86a20s_set_frontend: Calling tuner set
parameters
It seems that the driver is able to talk with mb86a20s and read the
status
and version registers. If the xc5000 firmware got loaded, that means
that
there's no issue with I2C.
So, the issue is likely something else.
From this:
;Demod Comm mode : 0x00 = Serial, 0x01 = Parallel
HKR,DriverData,DemodTransferMode,0x00010001, 0x01, 0x00, 0x00,
0x00
mb86a20s_config.is_serial should be false (default).
static struct mb86a20s_config mygica_x8507_mb86a20s_config = {
.demod_address = 0x10,
};
nothing of .is_serial
Can you confirm if the XTAL at the side of mb86a20s is 32.57MHz?
The exact value is 32.571MHz
If the XTAL is the same and the device driver is set to parallel mode,
then we'll need to investigate other setups that happen during init
time.
There are a few places at the driver that you could play with.
For example, on this register set:
{ 0x09, 0x3e },
You could try, instead of 0x3e, 0x1e, 0x1a or 0x3a.
I tested with the three new values and get nothing different
However, I recommend you to sniff the PCI traffic, in order to be
sure about
what this specific device does.
For this I need a little more time to study and apply. In a few days
it I obtained commented
When I was writing the driver for mb86a20s, I used this technique to
be sure about what it was needed to make one PCI card to work with it.
What I did then was to patch kvm to force it to emulate all DMA
transfers,
writing a dump of all such transfers at the host kernel. Then, I ran
some
parsing scripts to get the mb86a20s and tuner initialization. I made
the
patches available at:
Re: uvcvideo USERPTR mode busted?
On Sun, Mar 3, 2013 at 4:37 AM, Rémi Denis-Courmont r...@remlab.net wrote: Hello, Trying to use USERPTR buffers with UVC, user space gets stuck either in poll(POLLIN) or in ioctl(VIDIOC_DQBUF). It seems the UVC driver never ever returns a frame in USERPTR mode. The symptoms are identical with kernel versions 3.6, 3.7 and 3.8. I also tested 3.2, but it did not support USERPTR. Tested hardware was Logitech HD Pro Webcam C920 with YUY2 pixel format. The same hardware and the same driver work fine with MMAP buffers. The same USERPTR userspace code works fine with the vivi test device... Did any have any better luck? Hi Remi, I've used userptr mode with the C920 on an ARM platform (with YUYV mode and not MPEG). It's worth noting that there is actually a bug I hit where if the memory you pass is not aligned on a page boundary then you will get garbage video. I have a fix or this but haven't submitted it upstream yet. So it should work, aside from the bug I found. Have you tried testing with v42l-ctl's streaming command? That would help identify whether it's something special about your code or whether it's the driver. Don't get me wrong, it's almost certainly a driver issue in either case, but it would help narrow down the issue if you're using v4l2-ctl as that app is really simple and readily available to the driver developers. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/11] [media] mb86a20s: don't pollute dmesg with debug messages
There are a few debug tests that are shown with dev_err() or
dev_info(). Replace them by dev_dbg().
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/dvb-frontends/mb86a20s.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb-frontends/mb86a20s.c
b/drivers/media/dvb-frontends/mb86a20s.c
index f19cd73..44bfb88 100644
--- a/drivers/media/dvb-frontends/mb86a20s.c
+++ b/drivers/media/dvb-frontends/mb86a20s.c
@@ -1095,7 +1095,7 @@ static int mb86a20s_get_blk_error(struct dvb_frontend *fe,
if (rc 0)
return rc;
*error |= rc;
- dev_err(state-i2c-dev, %s: block error for layer %c: %d.\n,
+ dev_dbg(state-i2c-dev, %s: block error for layer %c: %d.\n,
__func__, 'A' + layer, *error);
/* Read Bit Count */
@@ -1386,7 +1386,7 @@ static int mb86a20s_get_main_CNR(struct dvb_frontend *fe)
return rc;
if (!(rc 0x40)) {
- dev_info(state-i2c-dev, %s: CNR is not available yet.\n,
+ dev_dbg(state-i2c-dev, %s: CNR is not available yet.\n,
__func__);
return -EBUSY;
}
@@ -1441,7 +1441,7 @@ static int mb86a20s_get_blk_error_layer_CNR(struct
dvb_frontend *fe)
/* Check if data is available */
if (!(rc 0x01)) {
- dev_info(state-i2c-dev,
+ dev_dbg(state-i2c-dev,
%s: MER measures aren't available yet.\n, __func__);
return -EBUSY;
}
--
1.8.1.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
[PATCH 04/11] [media] mb86a20s: Fix signal strength calculus
A register typo made the calculation to not work. Fix it. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- drivers/media/dvb-frontends/mb86a20s.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/dvb-frontends/mb86a20s.c b/drivers/media/dvb-frontends/mb86a20s.c index e222e55..983fb3b 100644 --- a/drivers/media/dvb-frontends/mb86a20s.c +++ b/drivers/media/dvb-frontends/mb86a20s.c @@ -335,7 +335,7 @@ static int mb86a20s_read_signal_strength(struct dvb_frontend *fe) rc = mb86a20s_writereg(state, 0x04, 0x20); if (rc 0) return rc; - rc = mb86a20s_writereg(state, 0x04, rf); + rc = mb86a20s_writereg(state, 0x05, rf); if (rc 0) return rc; -- 1.8.1.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
[PATCH 08/11] [media] mb86a20s: Don't reset strength with the other stats
Signal strength is always available. There's no reason to reset
it, as it has its own logic to reset it already.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/dvb-frontends/mb86a20s.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/mb86a20s.c
b/drivers/media/dvb-frontends/mb86a20s.c
index 1589662..7238947 100644
--- a/drivers/media/dvb-frontends/mb86a20s.c
+++ b/drivers/media/dvb-frontends/mb86a20s.c
@@ -754,7 +754,6 @@ static int mb86a20s_reset_counters(struct dvb_frontend *fe)
/* Reset the counters, if the channel changed */
if (state-last_frequency != c-frequency) {
- memset(c-strength, 0, sizeof(c-strength));
memset(c-cnr, 0, sizeof(c-cnr));
memset(c-pre_bit_error, 0, sizeof(c-pre_bit_error));
memset(c-pre_bit_count, 0, sizeof(c-pre_bit_count));
--
1.8.1.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
[PATCH 07/11] [media] mb86a20s: Always reset the frontend with set_frontend
Always init the frontend when set_frontend is called. The rationale
is: it was noticed that, on some devices, it fails to lock with a
different channel. It seems that some other registers need to be
restored to its initial state, when the channel changes.
As it is better to reset everything, even wasting a few more
miliseconds than to loose channel lock, let's change the logic
to always reset.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/dvb-frontends/mb86a20s.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/media/dvb-frontends/mb86a20s.c
b/drivers/media/dvb-frontends/mb86a20s.c
index c552300..1589662 100644
--- a/drivers/media/dvb-frontends/mb86a20s.c
+++ b/drivers/media/dvb-frontends/mb86a20s.c
@@ -1854,18 +1854,9 @@ static int mb86a20s_set_frontend(struct dvb_frontend *fe)
fe-ops.i2c_gate_ctrl(fe, 1);
fe-ops.tuner_ops.set_params(fe);
- if (fe-ops.tuner_ops.get_if_frequency) {
+ if (fe-ops.tuner_ops.get_if_frequency)
fe-ops.tuner_ops.get_if_frequency(fe, if_freq);
- /*
-* If the IF frequency changed, re-initialize the
-* frontend. This is needed by some drivers like tda18271,
-* that only sets the IF after receiving a set_params() call
-*/
- if (if_freq != state-if_freq)
- state-need_init = true;
- }
-
/*
* Make it more reliable: if, for some reason, the initial
* device initialization doesn't happen, initialize it when
@@ -1877,9 +1868,13 @@ static int mb86a20s_set_frontend(struct dvb_frontend *fe)
* So, this hack is needed, in order to make Kworld SBTVD to work.
*
* It is also needed to change the IF after the initial init.
+*
+* HACK: Always init the frontend when set_frontend is called:
+* it was noticed that, on some devices, it fails to lock on a
+* different channel. So, it is better to reset everything, even
+* wasting some time, than to loose channel lock.
*/
- if (state-need_init)
- mb86a20s_initfe(fe);
+ mb86a20s_initfe(fe);
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 0);
--
1.8.1.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
[PATCH 06/11] [media] mb86a20s: change AGC tuning parameters
Use the AGC settings present on a newer device.
The initial settings were taken from one of the first devices with
mb86a20s, and there are several reports that this is not working
properly on some places.
So, instead of keeping using it, get the parameters taken from a
newer device. Tests are welcomed.
Tested also with cx231xx PixelView SBTVD Hybrid with no regressions
noticed so far.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/dvb-core/dmxdev.c| 3 +-
drivers/media/dvb-frontends/mb86a20s.c | 86 +-
2 files changed, 46 insertions(+), 43 deletions(-)
diff --git a/drivers/media/dvb-core/dmxdev.c b/drivers/media/dvb-core/dmxdev.c
index d81dbb2..8896993 100644
--- a/drivers/media/dvb-core/dmxdev.c
+++ b/drivers/media/dvb-core/dmxdev.c
@@ -852,7 +852,8 @@ static int dvb_dmxdev_filter_set(struct dmxdev *dmxdev,
struct dmxdev_filter *dmxdevfilter,
struct dmx_sct_filter_params *params)
{
- dprintk(function : %s\n, __func__);
+ dprintk(function : %s, PID=0x%04x, flags=%02x, timeout=%d\n,
+ __func__, params-pid, params-flags, params-timeout);
dvb_dmxdev_filter_stop(dmxdevfilter);
diff --git a/drivers/media/dvb-frontends/mb86a20s.c
b/drivers/media/dvb-frontends/mb86a20s.c
index 82fa2af..c552300 100644
--- a/drivers/media/dvb-frontends/mb86a20s.c
+++ b/drivers/media/dvb-frontends/mb86a20s.c
@@ -55,7 +55,7 @@ static struct regdata mb86a20s_init1[] = {
{ 0x70, 0xff },
{ 0x08, 0x01 },
{ 0x09, 0x3e },
- { 0x50, 0xd1 }, { 0x51, 0x22 },
+ { 0x50, 0xd1 }, { 0x51, 0x20 },
{ 0x39, 0x01 },
{ 0x71, 0x00 },
{ 0x28, 0x2a }, { 0x29, 0x00 }, { 0x2a, 0xff }, { 0x2b, 0x80 },
@@ -64,23 +64,23 @@ static struct regdata mb86a20s_init1[] = {
static struct regdata mb86a20s_init2[] = {
{ 0x28, 0x22 }, { 0x29, 0x00 }, { 0x2a, 0x1f }, { 0x2b, 0xf0 },
{ 0x3b, 0x21 },
- { 0x3c, 0x3a },
+ { 0x3c, 0x38 },
{ 0x01, 0x0d },
- { 0x04, 0x08 }, { 0x05, 0x05 },
+ { 0x04, 0x08 }, { 0x05, 0x03 },
{ 0x04, 0x0e }, { 0x05, 0x00 },
- { 0x04, 0x0f }, { 0x05, 0x14 },
- { 0x04, 0x0b }, { 0x05, 0x8c },
+ { 0x04, 0x0f }, { 0x05, 0x37 },
+ { 0x04, 0x0b }, { 0x05, 0x78 },
{ 0x04, 0x00 }, { 0x05, 0x00 },
- { 0x04, 0x01 }, { 0x05, 0x07 },
- { 0x04, 0x02 }, { 0x05, 0x0f },
- { 0x04, 0x03 }, { 0x05, 0xa0 },
+ { 0x04, 0x01 }, { 0x05, 0x1e },
+ { 0x04, 0x02 }, { 0x05, 0x07 },
+ { 0x04, 0x03 }, { 0x05, 0xd0 },
{ 0x04, 0x09 }, { 0x05, 0x00 },
{ 0x04, 0x0a }, { 0x05, 0xff },
- { 0x04, 0x27 }, { 0x05, 0x64 },
+ { 0x04, 0x27 }, { 0x05, 0x00 },
{ 0x04, 0x28 }, { 0x05, 0x00 },
- { 0x04, 0x1e }, { 0x05, 0xff },
- { 0x04, 0x29 }, { 0x05, 0x0a },
- { 0x04, 0x32 }, { 0x05, 0x0a },
+ { 0x04, 0x1e }, { 0x05, 0x00 },
+ { 0x04, 0x29 }, { 0x05, 0x64 },
+ { 0x04, 0x32 }, { 0x05, 0x02 },
{ 0x04, 0x14 }, { 0x05, 0x02 },
{ 0x04, 0x04 }, { 0x05, 0x00 },
{ 0x04, 0x05 }, { 0x05, 0x22 },
@@ -147,39 +147,39 @@ static struct regdata mb86a20s_init2[] = {
{ 0x50, 0xd5 }, { 0x51, 0x01 }, /* Serial */
{ 0x50, 0xd6 }, { 0x51, 0x1f },
{ 0x50, 0xd2 }, { 0x51, 0x03 },
- { 0x50, 0xd7 }, { 0x51, 0x3f },
- { 0x28, 0x74 }, { 0x29, 0x00 }, { 0x28, 0x74 }, { 0x29, 0x40 },
- { 0x28, 0x46 }, { 0x29, 0x2c }, { 0x28, 0x46 }, { 0x29, 0x0c },
+ { 0x50, 0xd7 }, { 0x51, 0xbf },
+ { 0x28, 0x74 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0xff },
+ { 0x28, 0x46 }, { 0x29, 0x00 }, { 0x2a, 0x1a }, { 0x2b, 0x0c },
{ 0x04, 0x40 }, { 0x05, 0x00 },
- { 0x28, 0x00 }, { 0x29, 0x10 },
- { 0x28, 0x05 }, { 0x29, 0x02 },
+ { 0x28, 0x00 }, { 0x2b, 0x08 },
+ { 0x28, 0x05 }, { 0x2b, 0x00 },
{ 0x1c, 0x01 },
- { 0x28, 0x06 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x03 },
- { 0x28, 0x07 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x0d },
- { 0x28, 0x08 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x02 },
- { 0x28, 0x09 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x01 },
- { 0x28, 0x0a }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x21 },
- { 0x28, 0x0b }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x29 },
- { 0x28, 0x0c }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x16 },
- { 0x28, 0x0d }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x31 },
- { 0x28, 0x0e }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x0e },
- { 0x28, 0x0f }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x4e },
- { 0x28, 0x10 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x46 },
- { 0x28, 0x11 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x0f },
- { 0x28, 0x12 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x56 },
- { 0x28, 0x13 }, { 0x29, 0x00 }, { 0x2a,
[PATCH 05/11] [media] mb86a20s: don't allow updating signal strength too fast
Getting signal strength requires some loop poking with I2C.
Don't let it happen too fast.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/dvb-frontends/mb86a20s.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/media/dvb-frontends/mb86a20s.c
b/drivers/media/dvb-frontends/mb86a20s.c
index 983fb3b..82fa2af 100644
--- a/drivers/media/dvb-frontends/mb86a20s.c
+++ b/drivers/media/dvb-frontends/mb86a20s.c
@@ -34,6 +34,7 @@ struct mb86a20s_state {
u32 if_freq;
u32 estimated_rate[3];
+ unsigned long get_strength_time;
bool need_init;
};
@@ -318,9 +319,17 @@ static int mb86a20s_read_status(struct dvb_frontend *fe,
fe_status_t *status)
static int mb86a20s_read_signal_strength(struct dvb_frontend *fe)
{
struct mb86a20s_state *state = fe-demodulator_priv;
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
int rc;
unsigned rf_max, rf_min, rf;
+ if (state-get_strength_time
+ (!time_after(jiffies, state-get_strength_time)))
+ return c-strength.stat[0].uvalue;
+
+ /* Reset its value if an error happen */
+ c-strength.stat[0].uvalue = 0;
+
/* Does a binary search to get RF strength */
rf_max = 0xfff;
rf_min = 0;
@@ -350,15 +359,19 @@ static int mb86a20s_read_signal_strength(struct
dvb_frontend *fe)
rf = (rf_max + rf_min) / 2;
/* Rescale it from 2^12 (4096) to 2^16 */
- rf = (16 - 12);
+ rf = rf (16 - 12);
+ if (rf)
+ rf |= (1 12) - 1;
+
dev_dbg(state-i2c-dev,
%s: signal strength = %d (%d RF=%d %d)\n,
__func__, rf, rf_min, rf 4, rf_max);
- return rf;
+ c-strength.stat[0].uvalue = rf;
+ state-get_strength_time = jiffies +
+ msecs_to_jiffies(1000);
+ return 0;
}
} while (1);
-
- return 0;
}
static int mb86a20s_get_modulation(struct mb86a20s_state *state,
@@ -1882,7 +1895,6 @@ static int mb86a20s_read_status_and_stats(struct
dvb_frontend *fe,
fe_status_t *status)
{
struct mb86a20s_state *state = fe-demodulator_priv;
- struct dtv_frontend_properties *c = fe-dtv_property_cache;
int rc, status_nr;
dev_dbg(state-i2c-dev, %s called.\n, __func__);
@@ -1913,8 +1925,6 @@ static int mb86a20s_read_status_and_stats(struct
dvb_frontend *fe,
rc = 0; /* Status is OK */
goto error;
}
- /* Fill signal strength */
- c-strength.stat[0].uvalue = rc;
if (status_nr = 7) {
/* Get TMCC info*/
--
1.8.1.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
[PATCH 00/11] Do some improvements/fixups on mb86a20s, cx231xx and em28xx
While working to add support for a new device, I discovered a series of issues with mb86a20s and one with em28xx. While here, I also changed cx231xx to improve its signal detection, by using a different IF frequency and increasing the IF signal level from the tuner by 12dB. Mauro Carvalho Chehab (11): [media] mb86a20s: don't pollute dmesg with debug messages [media] mb86a20s: adjust IF based on what's set on the tuner [media] mb86a20s: provide CNR stats before FE_HAS_SYNC [media] mb86a20s: Fix signal strength calculus [media] mb86a20s: don't allow updating signal strength too fast [media] mb86a20s: change AGC tuning parameters [media] mb86a20s: Always reset the frontend with set_frontend [media] mb86a20s: Don't reset strength with the other stats [media] mb86a20s: cleanup the status at set_frontend() [media] cx231xx: Improve signal reception for PV SBTVD [media] em28xx-dvb: Don't put device in suspend mode at feed stop drivers/media/dvb-core/dmxdev.c | 3 +- drivers/media/dvb-frontends/mb86a20s.c | 200 +--- drivers/media/usb/cx231xx/cx231xx-dvb.c | 4 +- drivers/media/usb/em28xx/em28xx-dvb.c | 2 - 4 files changed, 136 insertions(+), 73 deletions(-) -- 1.8.1.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
[PATCH 02/11] [media] mb86a20s: adjust IF based on what's set on the tuner
Instead of hardcoding a fixed IF frequency of 3.3 MHz, use
the IF frequency provided by the tuner driver.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/dvb-frontends/mb86a20s.c | 57 +++---
1 file changed, 53 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb-frontends/mb86a20s.c
b/drivers/media/dvb-frontends/mb86a20s.c
index 44bfb88..daeee81 100644
--- a/drivers/media/dvb-frontends/mb86a20s.c
+++ b/drivers/media/dvb-frontends/mb86a20s.c
@@ -31,6 +31,8 @@ struct mb86a20s_state {
struct dvb_frontend frontend;
+ u32 if_freq;
+
u32 estimated_rate[3];
bool need_init;
@@ -47,7 +49,7 @@ struct regdata {
* Initialization sequence: Use whatevere default values that PV SBTVD
* does on its initialisation, obtained via USB snoop
*/
-static struct regdata mb86a20s_init[] = {
+static struct regdata mb86a20s_init1[] = {
{ 0x70, 0x0f },
{ 0x70, 0xff },
{ 0x08, 0x01 },
@@ -56,7 +58,9 @@ static struct regdata mb86a20s_init[] = {
{ 0x39, 0x01 },
{ 0x71, 0x00 },
{ 0x28, 0x2a }, { 0x29, 0x00 }, { 0x2a, 0xff }, { 0x2b, 0x80 },
- { 0x28, 0x20 }, { 0x29, 0x33 }, { 0x2a, 0xdf }, { 0x2b, 0xa9 },
+};
+
+static struct regdata mb86a20s_init2[] = {
{ 0x28, 0x22 }, { 0x29, 0x00 }, { 0x2a, 0x1f }, { 0x2b, 0xf0 },
{ 0x3b, 0x21 },
{ 0x3c, 0x3a },
@@ -1737,6 +1741,7 @@ static int mb86a20s_get_stats(struct dvb_frontend *fe)
static int mb86a20s_initfe(struct dvb_frontend *fe)
{
struct mb86a20s_state *state = fe-demodulator_priv;
+ u64 pll;
int rc;
u8 regD5 = 1;
@@ -1746,10 +1751,35 @@ static int mb86a20s_initfe(struct dvb_frontend *fe)
fe-ops.i2c_gate_ctrl(fe, 0);
/* Initialize the frontend */
- rc = mb86a20s_writeregdata(state, mb86a20s_init);
+ rc = mb86a20s_writeregdata(state, mb86a20s_init1);
if (rc 0)
goto err;
+ /* Adjust IF frequency to match tuner */
+ if (fe-ops.tuner_ops.get_if_frequency)
+ fe-ops.tuner_ops.get_if_frequency(fe, state-if_freq);
+
+ if (!state-if_freq)
+ state-if_freq = 330;
+
+ /* pll = freq[Hz] * 2^24/10^6 / 16.285714286 */
+ pll = state-if_freq * 1677721600L;
+ do_div(pll, 1628571429L);
+ rc = mb86a20s_writereg(state, 0x28, 0x20);
+ if (rc 0)
+ goto err;
+ rc = mb86a20s_writereg(state, 0x29, (pll 16) 0xff);
+ if (rc 0)
+ goto err;
+ rc = mb86a20s_writereg(state, 0x2a, (pll 8) 0xff);
+ if (rc 0)
+ goto err;
+ rc = mb86a20s_writereg(state, 0x2b, pll 0xff);
+ if (rc 0)
+ goto err;
+ dev_dbg(state-i2c-dev, %s: IF=%d, PLL=0x%06llx\n,
+ __func__, state-if_freq, (long long)pll);
+
if (!state-config-is_serial) {
regD5 = ~1;
@@ -1761,6 +1791,11 @@ static int mb86a20s_initfe(struct dvb_frontend *fe)
goto err;
}
+ rc = mb86a20s_writeregdata(state, mb86a20s_init2);
+ if (rc 0)
+ goto err;
+
+
err:
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 1);
@@ -1779,7 +1814,7 @@ err:
static int mb86a20s_set_frontend(struct dvb_frontend *fe)
{
struct mb86a20s_state *state = fe-demodulator_priv;
- int rc;
+ int rc, if_freq;
#if 0
/*
* FIXME: Properly implement the set frontend properties
@@ -1796,6 +1831,18 @@ static int mb86a20s_set_frontend(struct dvb_frontend *fe)
fe-ops.i2c_gate_ctrl(fe, 1);
fe-ops.tuner_ops.set_params(fe);
+ if (fe-ops.tuner_ops.get_if_frequency) {
+ fe-ops.tuner_ops.get_if_frequency(fe, if_freq);
+
+ /*
+* If the IF frequency changed, re-initialize the
+* frontend. This is needed by some drivers like tda18271,
+* that only sets the IF after receiving a set_params() call
+*/
+ if (if_freq != state-if_freq)
+ state-need_init = true;
+ }
+
/*
* Make it more reliable: if, for some reason, the initial
* device initialization doesn't happen, initialize it when
@@ -1805,6 +1852,8 @@ static int mb86a20s_set_frontend(struct dvb_frontend *fe)
* the agc callback logic is not called during DVB attach time,
* causing mb86a20s to not be initialized with Kworld SBTVD.
* So, this hack is needed, in order to make Kworld SBTVD to work.
+*
+* It is also needed to change the IF after the initial init.
*/
if (state-need_init)
mb86a20s_initfe(fe);
--
1.8.1.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
[PATCH 03/11] [media] mb86a20s: provide CNR stats before FE_HAS_SYNC
State 9 means TS started to be output, and it should be
associated with FE_HAS_SYNC.
The mb86a20scan get CNR statistics at state 7, when frame sync
is obtained.
As CNR may help to adjust the antenna, provide it earlier.
A latter patch could eventually start outputing MER measures
earlier, but that would require a bigger change, and probably
won't be better than the current way, as the time between
changing from state 8 to 9 is generally lower than the time
to get the stats collected.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/dvb-frontends/mb86a20s.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/media/dvb-frontends/mb86a20s.c
b/drivers/media/dvb-frontends/mb86a20s.c
index daeee81..e222e55 100644
--- a/drivers/media/dvb-frontends/mb86a20s.c
+++ b/drivers/media/dvb-frontends/mb86a20s.c
@@ -312,7 +312,7 @@ static int mb86a20s_read_status(struct dvb_frontend *fe,
fe_status_t *status)
dev_dbg(state-i2c-dev, %s: Status = 0x%02x (state = %d)\n,
__func__, *status, val);
- return 0;
+ return val;
}
static int mb86a20s_read_signal_strength(struct dvb_frontend *fe)
@@ -1564,7 +1564,7 @@ static void mb86a20s_stats_not_ready(struct dvb_frontend
*fe)
}
}
-static int mb86a20s_get_stats(struct dvb_frontend *fe)
+static int mb86a20s_get_stats(struct dvb_frontend *fe, int status_nr)
{
struct mb86a20s_state *state = fe-demodulator_priv;
struct dtv_frontend_properties *c = fe-dtv_property_cache;
@@ -1584,6 +1584,14 @@ static int mb86a20s_get_stats(struct dvb_frontend *fe)
/* Get per-layer stats */
mb86a20s_get_blk_error_layer_CNR(fe);
+ /*
+* At state 7, only CNR is available
+* For BER measures, state=9 is required
+* FIXME: we may get MER measures with state=8
+*/
+ if (status_nr 9)
+ return 0;
+
for (i = 0; i 3; i++) {
if (c-isdbt_layer_enabled (1 i)) {
/* Layer is active and has rc segments */
@@ -1875,7 +1883,7 @@ static int mb86a20s_read_status_and_stats(struct
dvb_frontend *fe,
{
struct mb86a20s_state *state = fe-demodulator_priv;
struct dtv_frontend_properties *c = fe-dtv_property_cache;
- int rc;
+ int rc, status_nr;
dev_dbg(state-i2c-dev, %s called.\n, __func__);
@@ -1883,12 +1891,12 @@ static int mb86a20s_read_status_and_stats(struct
dvb_frontend *fe,
fe-ops.i2c_gate_ctrl(fe, 0);
/* Get lock */
- rc = mb86a20s_read_status(fe, status);
- if (!(*status FE_HAS_LOCK)) {
+ status_nr = mb86a20s_read_status(fe, status);
+ if (status_nr 7) {
mb86a20s_stats_not_ready(fe);
mb86a20s_reset_frontend_cache(fe);
}
- if (rc 0) {
+ if (state 0) {
dev_err(state-i2c-dev,
%s: Can't read frontend lock status\n, __func__);
goto error;
@@ -1908,7 +1916,7 @@ static int mb86a20s_read_status_and_stats(struct
dvb_frontend *fe,
/* Fill signal strength */
c-strength.stat[0].uvalue = rc;
- if (*status FE_HAS_LOCK) {
+ if (status_nr = 7) {
/* Get TMCC info*/
rc = mb86a20s_get_frontend(fe);
if (rc 0) {
@@ -1919,7 +1927,7 @@ static int mb86a20s_read_status_and_stats(struct
dvb_frontend *fe,
}
/* Get statistics */
- rc = mb86a20s_get_stats(fe);
+ rc = mb86a20s_get_stats(fe, status_nr);
if (rc 0 rc != -EBUSY) {
dev_err(state-i2c-dev,
%s: Can't get FE statistics.\n, __func__);
--
1.8.1.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
[PATCH 10/11] [media] cx231xx: Improve signal reception for PV SBTVD
Instead of using 3.3 MHz IF, use 4MHz. That's the standard
value for the demod, and, while it can be adjusted, 3.3 MHz
is out of the recommended range. So, let's stick with the
default.
With regards to the IF voltage level, instead of using
0.5 V(p-p) for IF, use 2V, giving a 12dB gain.
The rationale is that, on PixelView SBTVD Hybrid,
even 2V(p-p) would be in the nominal range for IF,
as the maximum range on this particular device is 3V.
A higher gain here should help to improve reception under
weak signals.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/usb/cx231xx/cx231xx-dvb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c
b/drivers/media/usb/cx231xx/cx231xx-dvb.c
index 7c4e360..14e2610 100644
--- a/drivers/media/usb/cx231xx/cx231xx-dvb.c
+++ b/drivers/media/usb/cx231xx/cx231xx-dvb.c
@@ -89,8 +89,8 @@ static struct tda18271_std_map cnxt_rde253s_tda18271_std_map
= {
};
static struct tda18271_std_map mb86a20s_tda18271_config = {
- .dvbt_6 = { .if_freq = 3300, .agc_mode = 3, .std = 4,
- .if_lvl = 7, .rfagc_top = 0x37, },
+ .dvbt_6 = { .if_freq = 4000, .agc_mode = 3, .std = 4,
+ .if_lvl = 0, .rfagc_top = 0x37, },
};
static struct tda18271_config cnxt_rde253s_tunerconfig = {
--
1.8.1.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
[PATCH 11/11] [media] em28xx-dvb: Don't put device in suspend mode at feed stop
Putting em28xx in suspend mode when a feed stops is just plain wrong. Every time a new PES filter is changed, the DVB demux code will stop the current feed, and then start a new one. If are there any code that switches off the frontend, via some GPIO setting, this would make the DVB fail. This condition was actually trigged with one device, during DVB scan, as, during scan, it is common that userspace apps to change the filter several times, in order to get all tables. Also, this is not needed at all, since the em28xx code already hooks into ops.ts_bus_ctrl(). This warrants that em28xx can check there if DVB frontend is in usage or not. The code there already puts the device on suspend mode, if the DVB frontend is not used (closed). Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- drivers/media/usb/em28xx/em28xx-dvb.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c b/drivers/media/usb/em28xx/em28xx-dvb.c index a81ec2e..7200dfe 100644 --- a/drivers/media/usb/em28xx/em28xx-dvb.c +++ b/drivers/media/usb/em28xx/em28xx-dvb.c @@ -220,8 +220,6 @@ static int em28xx_stop_streaming(struct em28xx_dvb *dvb) em28xx_stop_urbs(dev); - em28xx_set_mode(dev, EM28XX_SUSPEND); - return 0; } -- 1.8.1.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
[PATCH 09/11] [media] mb86a20s: cleanup the status at set_frontend()
As the device got re-initialized, the stats should vanish until the device gets lock again. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- drivers/media/dvb-frontends/mb86a20s.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/dvb-frontends/mb86a20s.c b/drivers/media/dvb-frontends/mb86a20s.c index 7238947..2d85131 100644 --- a/drivers/media/dvb-frontends/mb86a20s.c +++ b/drivers/media/dvb-frontends/mb86a20s.c @@ -1880,6 +1880,7 @@ static int mb86a20s_set_frontend(struct dvb_frontend *fe) rc = mb86a20s_writeregdata(state, mb86a20s_reset_reception); mb86a20s_reset_counters(fe); + mb86a20s_stats_not_ready(fe); if (fe-ops.i2c_gate_ctrl) fe-ops.i2c_gate_ctrl(fe, 1); -- 1.8.1.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: mb86a20s and cx23885
Em Sun, 03 Mar 2013 11:50:25 -0300
Alfredo Jesús Delaiti alfredodela...@netscape.net escreveu:
Hi Mauro and others from the list
I searched for a plan B to get the data bus and after several
alternative plans that were available to me was to do a logic analyzer
(http://tfla-01.berlios.de).
Yeah, that should work too.
With the logic analyzer I could get the data transmitted by the I2C bus
under Windows, but when I put this data in replacement of originals in
mb86a20s.c and I try to run the Linux TV board, do not get the logic
analyzer with the same sequence.
Well, there are other I2C devices on the bus, and the order that they're
initialized in Linux are different than on the original driver.
The new data replacement in mb86a20s
I just posted today a series of patches improving several things on
mb86a20s and replacing its initialization table to one found on a newer
driver. It also allows using different IF frequencies on the tuner side.
Perhaps this is enough to fix.
/*
* Initialization sequence: Use whatevere default values that PV SBTVD
* does on its initialisation, obtained via USB snoop
*/
static struct regdata mb86a20s_init[] = {
{ 0x70, 0x0f },
{ 0x70, 0xff },
{ 0x09, 0x3a },
{ 0x50, 0xd1 },
{ 0x51, 0x22 },
{ 0x39, 0x00 },
{ 0x28, 0x2a },
{ 0x29, 0x00 },
{ 0x2a, 0xfd },
{ 0x2b, 0xc8 },
{ 0x3b, 0x21 },
{ 0x3c, 0x38 },
{ 0x28, 0x20 },
{ 0x29, 0x3e },
{ 0x2a, 0xde },
{ 0x2b, 0x4d },
{ 0x28, 0x22 },
{ 0x29, 0x00 },
{ 0x2a, 0x1f },
{ 0x2b, 0xf0 },
{ 0x01, 0x0d },
{ 0x04, 0x08 },
{ 0x05, 0x03 },
{ 0x04, 0x0e },
{ 0x05, 0x00 },
{ 0x08, 0x1e },
{ 0x05, 0x32 },
{ 0x04, 0x0b },
{ 0x05, 0x78 },
{ 0x04, 0x00 },
{ 0x05, 0x00 },
{ 0x04, 0x01 },
{ 0x05, 0x1e },
{ 0x04, 0x02 },
{ 0x05, 0x07 },
{ 0x04, 0x03 },
{ 0x0a, 0xa0 },
{ 0x04, 0x09 },
{ 0x05, 0x00 },
{ 0x04, 0x0a },
{ 0x05, 0xff },
{ 0x04, 0x27 },
{ 0x05, 0x00 },
{ 0x08, 0x50 },
{ 0x05, 0x00 },
{ 0x04, 0x28 },
{ 0x05, 0x00 },
{ 0x04, 0x1e },
{ 0x05, 0x00 },
{ 0x04, 0x29 },
{ 0x05, 0x64 },
{ 0x04, 0x32 },
{ 0x05, 0x68 },
{ 0x04, 0x14 },
{ 0x05, 0x02 },
{ 0x04, 0x04 },
{ 0x05, 0x00 },
{ 0x08, 0x0a },
{ 0x05, 0x22 },
{ 0x04, 0x06 },
{ 0x05, 0x0e },
{ 0x04, 0x07 },
{ 0x05, 0xd8 },
{ 0x04, 0x12 },
{ 0x05, 0x00 },
{ 0x04, 0x13 },
{ 0x05, 0xff },
{ 0x52, 0x01 },
{ 0x50, 0xa7 },
{ 0x51, 0x00 },
{ 0x50, 0xa8 },
{ 0x51, 0xfe },
{ 0x50, 0xa9 },
{ 0x51, 0xff },
{ 0x50, 0xaa },
{ 0x51, 0x00 },
{ 0x50, 0xab },
{ 0x51, 0xff },
{ 0x50, 0xac },
{ 0x51, 0xff },
{ 0x50, 0xad },
{ 0x51, 0x00 },
{ 0x50, 0xae },
{ 0x51, 0xff },
{ 0x50, 0xaf },
{ 0x51, 0xff },
{ 0x5e, 0x07 },
{ 0x50, 0xdc },
{ 0x51, 0x3f },
{ 0x50, 0xdd },
{ 0x51, 0xff },
{ 0x50, 0xde },
{ 0x51, 0x3f },
{ 0x80, 0xdf },
So I conclude that there must be some logic that I'm not understanding.
Could you indicate the meaning of the data in the table if there are
any? or if I'm doing something wrong, what do I do wrong?
I'll take a look on it, and see what it is doing differently.
I have also observed that the data passing through the I2C bus are not
always the same under Windows, there are some differences between them
in parts.
Hmm... that's interesting. Did you map the changes?
Then I put a few fragments of what I get under Windows 7 and Linux. Not
the entire I put because they are of a size of 200KiB.
_Under_Windows_7_
0.184315 - Start
0.268094 - b0011 - 0x21 - 33
0.279265 - ACK
0.361182 - b00010011 - 0x13 - 19
0.372353 - NACK
This is a read.
0.511985 - b0010 - 0x20 - 32
0.523156 - ACK
0.603211 - b0111 - 0x70 - 112
0.614382 - ACK
0.698161 - b - 0x0f - 15
0.70747 - ACK
0.847102 - b0010 - 0x20 - 32
0.858273 - ACK
0.938329 - b0111 - 0x70 - 112
0.949499 - ACK
1.03514 - b - 0xff - 255
1.04445 - ACK
Funny that it doesn't write 01 to register 08 here.
I think that the this is to disable TS while resetting.
...
_Under_Linux_
0.268594 - Start
0.358125 - b0010 - 0x20 - 32
0.367451 - ACK
0.447656 - b0111 - 0x70 - 112
0.456982 - ACK
0.548379 - b - 0xff - 255
0.55957 - ACK
0.686406 - b0010 - 0x20 - 32
0.697597 - ACK
0.781533 - b1000 - 0x08 - 8
0.790859 - NACK
0.871064 - b0001 - 0x01 - 1
0.882256 - ACK
You're likely still using the old table.
In the next letter, if you let me, I'll cut the old text, because I
guess we're back on topic and not too heavy (KB) message.
Sure. I always cut not commented parts of the
Re: mb86a20s and cx23885
Em Sun, 03 Mar 2013 11:50:25 -0300
Alfredo Jesús Delaiti alfredodela...@netscape.net escreveu:
The new data replacement in mb86a20s
/*
* Initialization sequence: Use whatevere default values that PV SBTVD
* does on its initialisation, obtained via USB snoop
*/
static struct regdata mb86a20s_init[] = {
Please test first my mb86a20s patchset. If it doesn't work, we'll need
to dig into the differences.
The better is to group these and reorder them to look like what's there
at the driver, and send it like a diff. That would make a way easier to
see what's different there.
Anyway, it follows my comments about a few things that came into my eyes.
{ 0x09, 0x3a },
No idea what's here, but it seems a worth trial to change it.
{ 0x28, 0x2a },
{ 0x29, 0x00 },
{ 0x2a, 0xfd },
{ 0x2b, 0xc8 },
Hmm... the above may explain why it is not working. This is calculated
from the XTAL frequency, and IF (if different than 4MHz).
Just changing it could fix the issue.
{ 0x28, 0x20 },
{ 0x29, 0x3e },
{ 0x2a, 0xde },
{ 0x2b, 0x4d },
This doesn't matter anymore. It will be now be calculated based on the
frequency you use for IF at the tuner.
The above frequency is not 4MHz.
{ 0x08, 0x1e },
This looks weird. You probably got it wrong.
{ 0x80, 0xdf },
This also looks weird. I suspect that you also lost data here.
Regards,
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
[PATCH v2 00/11] em28xx: i2c debugging cleanups and support for newer eeproms
The first 3 patches clean up / simplify the debugging and info messages a bit. Patches 4, 5 and 6 fix two bugs I've noticed while working on the eeprom stuff. Patches 7-10 add support for the newer eeproms with 16 bit address width. This allows us to display the eeprom content, to calculate the eeprom hash for board hints for devices with generic USB IDs, to read the device configuration and to use tveeprom for Hauppauge devices just as with the old eeprom type. The used eeprom type depends on the chip type/id (confirmed by the Empia datasheets). For unknown chips, the old 8 bit eeprom type is assumed, which makes sure that the eeprom content can't be damaged accidentally. In video capturing/TV/DVB devices, the new eeprom still has the old eeprom content (device configuration + tveeprom structure for Hauppauge devices) embedded. Camera devices (em25xx, em276x+) however are using a different data structure, which isn't supported yet. Patch 11 is a follow-up which enables tveeprom for the Hauppauge HVR-930C All patches have been tested with the following devices: - Hauppauge HVR-900 (normal 8 bit eeprom) - Hauppauge HVR-930C (16 bit eeprom, tveeprom) - SpeedLink VAD Laplace webcam (16 bit eeprom, no device config dataset) I also checked the USB log of the MSI Digivox ATSC which confirms that non-Hauppauge devices are using the same eeprom format. Changes since v1: - fixed the sanity check in patch 8 - fixed a minor output format issue in patch 10 Frank Schäfer (11): em28xx-i2c: replace printk() with the corresponding em28xx macros em28xx-i2c: get rid of the dprintk2 macro em28xx-i2c: also print debug messages at debug level 1 em28xx: do not interpret eeprom content if eeprom key is invalid em28xx: fix eeprom data endianess em28xx: make sure we are at i2c bus A when calling em28xx_i2c_register() em28xx: add basic support for eeproms with 16 bit address width em28xx: add helper function for reading data blocks from i2c clients em28xx: do not store eeprom content permanently em28xx: extract the device configuration dataset from eeproms with 16 bit address width em28xx: enable tveeprom for device Hauppauge HVR-930C drivers/media/usb/em28xx/em28xx-cards.c | 45 +++-- drivers/media/usb/em28xx/em28xx-i2c.c | 284 --- drivers/media/usb/em28xx/em28xx.h | 17 +- 3 Dateien geändert, 225 Zeilen hinzugefügt(+), 121 Zeilen entfernt(-) -- 1.7.10.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
[PATCH v2 02/11] em28xx-i2c: get rid of the dprintk2 macro
There is only a single place where the dprintk2 macro is used, so get rid of it.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-i2c.c | 17 ++---
1 Datei geändert, 6 Zeilen hinzugefügt(+), 11 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c
b/drivers/media/usb/em28xx/em28xx-i2c.c
index 8819b54..f970c29 100644
--- a/drivers/media/usb/em28xx/em28xx-i2c.c
+++ b/drivers/media/usb/em28xx/em28xx-i2c.c
@@ -41,14 +41,6 @@ static unsigned int i2c_debug;
module_param(i2c_debug, int, 0644);
MODULE_PARM_DESC(i2c_debug, enable debug messages [i2c]);
-#define dprintk2(lvl, fmt, args...)\
-do { \
- if (i2c_debug = lvl) { \
- printk(KERN_DEBUG %s at %s: fmt, \
- dev-name, __func__ , ##args); \
- }\
-} while (0)
-
/*
* em2800_i2c_send_bytes()
* send up to 4 bytes to the em2800 i2c device
@@ -295,9 +287,12 @@ static int em28xx_i2c_xfer(struct i2c_adapter *i2c_adap,
return 0;
for (i = 0; i num; i++) {
addr = msgs[i].addr 1;
- dprintk2(2, %s %s addr=%x len=%d:,
-(msgs[i].flags I2C_M_RD) ? read : write,
-i == num - 1 ? stop : nonstop, addr, msgs[i].len);
+ if (i2c_debug = 2)
+ printk(KERN_DEBUG %s at %s: %s %s addr=%02x len=%d:,
+ dev-name, __func__ ,
+ (msgs[i].flags I2C_M_RD) ? read : write,
+ i == num - 1 ? stop : nonstop,
+ addr, msgs[i].len );
if (!msgs[i].len) { /* no len: check only for device presence */
if (dev-board.is_em2800)
rc = em2800_i2c_check_for_device(dev, addr);
--
1.7.10.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
[PATCH v2 01/11] em28xx-i2c: replace printk() with the corresponding em28xx macros
Reduces the number of characters/lines, unifies the code and improves
readability.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-i2c.c | 55 ++---
1 Datei geändert, 24 Zeilen hinzugefügt(+), 31 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c
b/drivers/media/usb/em28xx/em28xx-i2c.c
index 8532c1d..8819b54 100644
--- a/drivers/media/usb/em28xx/em28xx-i2c.c
+++ b/drivers/media/usb/em28xx/em28xx-i2c.c
@@ -399,7 +399,7 @@ static int em28xx_i2c_eeprom(struct em28xx *dev, unsigned
char *eedata, int len)
/* Check if board has eeprom */
err = i2c_master_recv(dev-i2c_client, buf, 0);
if (err 0) {
- em28xx_errdev(board has no eeprom\n);
+ em28xx_info(board has no eeprom\n);
memset(eedata, 0, len);
return -ENODEV;
}
@@ -408,8 +408,7 @@ static int em28xx_i2c_eeprom(struct em28xx *dev, unsigned
char *eedata, int len)
err = i2c_master_send(dev-i2c_client, buf, 1);
if (err != 1) {
- printk(KERN_INFO %s: Huh, no eeprom present (err=%d)?\n,
- dev-name, err);
+ em28xx_errdev(failed to read eeprom (err=%d)\n, err);
return err;
}
@@ -426,9 +425,7 @@ static int em28xx_i2c_eeprom(struct em28xx *dev, unsigned
char *eedata, int len)
if (block !=
(err = i2c_master_recv(dev-i2c_client, p, block))) {
- printk(KERN_WARNING
- %s: i2c eeprom read error (err=%d)\n,
- dev-name, err);
+ em28xx_errdev(i2c eeprom read error (err=%d)\n, err);
return err;
}
size -= block;
@@ -436,7 +433,7 @@ static int em28xx_i2c_eeprom(struct em28xx *dev, unsigned
char *eedata, int len)
}
for (i = 0; i len; i++) {
if (0 == (i % 16))
- printk(KERN_INFO %s: i2c eeprom %02x:, dev-name, i);
+ em28xx_info(i2c eeprom %02x:, i);
printk( %02x, eedata[i]);
if (15 == (i % 16))
printk(\n);
@@ -445,55 +442,51 @@ static int em28xx_i2c_eeprom(struct em28xx *dev, unsigned
char *eedata, int len)
if (em_eeprom-id == 0x9567eb1a)
dev-hash = em28xx_hash_mem(eedata, len, 32);
- printk(KERN_INFO %s: EEPROM ID= 0x%08x, EEPROM hash = 0x%08lx\n,
- dev-name, em_eeprom-id, dev-hash);
+ em28xx_info(EEPROM ID = 0x%08x, EEPROM hash = 0x%08lx\n,
+ em_eeprom-id, dev-hash);
- printk(KERN_INFO %s: EEPROM info:\n, dev-name);
+ em28xx_info(EEPROM info:\n);
switch (em_eeprom-chip_conf 4 0x3) {
case 0:
- printk(KERN_INFO %s:\tNo audio on board.\n, dev-name);
+ em28xx_info(\tNo audio on board.\n);
break;
case 1:
- printk(KERN_INFO %s:\tAC97 audio (5 sample rates)\n,
-dev-name);
+ em28xx_info(\tAC97 audio (5 sample rates)\n);
break;
case 2:
- printk(KERN_INFO %s:\tI2S audio, sample rate=32k\n,
-dev-name);
+ em28xx_info(\tI2S audio, sample rate=32k\n);
break;
case 3:
- printk(KERN_INFO %s:\tI2S audio, 3 sample rates\n,
-dev-name);
+ em28xx_info(\tI2S audio, 3 sample rates\n);
break;
}
if (em_eeprom-chip_conf 1 3)
- printk(KERN_INFO %s:\tUSB Remote wakeup capable\n, dev-name);
+ em28xx_info(\tUSB Remote wakeup capable\n);
if (em_eeprom-chip_conf 1 2)
- printk(KERN_INFO %s:\tUSB Self power capable\n, dev-name);
+ em28xx_info(\tUSB Self power capable\n);
switch (em_eeprom-chip_conf 0x3) {
case 0:
- printk(KERN_INFO %s:\t500mA max power\n, dev-name);
+ em28xx_info(\t500mA max power\n);
break;
case 1:
- printk(KERN_INFO %s:\t400mA max power\n, dev-name);
+ em28xx_info(\t400mA max power\n);
break;
case 2:
- printk(KERN_INFO %s:\t300mA max power\n, dev-name);
+ em28xx_info(\t300mA max power\n);
break;
case 3:
- printk(KERN_INFO %s:\t200mA max power\n, dev-name);
+ em28xx_info(\t200mA max power\n);
break;
}
- printk(KERN_INFO %s:\tTable at 0x%02x, strings=0x%04x, 0x%04x,
0x%04x\n,
- dev-name,
- em_eeprom-string_idx_table,
- em_eeprom-string1,
- em_eeprom-string2,
-
[PATCH v2 03/11] em28xx-i2c: also print debug messages at debug level 1
The current code uses only a single debug level and all debug messages are
printed for i2c_debug = 2 only. So debug level 1 is actually the same as
level 0, which is odd.
Users expect debugging messages to become enabled for anything else than
debug level 0.
Fix it and simplify the code a bit by printing the debug messages also at debug
level 1;
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-i2c.c | 12 ++--
1 Datei geändert, 6 Zeilen hinzugefügt(+), 6 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c
b/drivers/media/usb/em28xx/em28xx-i2c.c
index f970c29..d765567 100644
--- a/drivers/media/usb/em28xx/em28xx-i2c.c
+++ b/drivers/media/usb/em28xx/em28xx-i2c.c
@@ -287,7 +287,7 @@ static int em28xx_i2c_xfer(struct i2c_adapter *i2c_adap,
return 0;
for (i = 0; i num; i++) {
addr = msgs[i].addr 1;
- if (i2c_debug = 2)
+ if (i2c_debug)
printk(KERN_DEBUG %s at %s: %s %s addr=%02x len=%d:,
dev-name, __func__ ,
(msgs[i].flags I2C_M_RD) ? read : write,
@@ -299,7 +299,7 @@ static int em28xx_i2c_xfer(struct i2c_adapter *i2c_adap,
else
rc = em28xx_i2c_check_for_device(dev, addr);
if (rc == -ENODEV) {
- if (i2c_debug = 2)
+ if (i2c_debug)
printk( no device\n);
return rc;
}
@@ -313,13 +313,13 @@ static int em28xx_i2c_xfer(struct i2c_adapter *i2c_adap,
rc = em28xx_i2c_recv_bytes(dev, addr,
msgs[i].buf,
msgs[i].len);
- if (i2c_debug = 2) {
+ if (i2c_debug) {
for (byte = 0; byte msgs[i].len; byte++)
printk( %02x, msgs[i].buf[byte]);
}
} else {
/* write bytes */
- if (i2c_debug = 2) {
+ if (i2c_debug) {
for (byte = 0; byte msgs[i].len; byte++)
printk( %02x, msgs[i].buf[byte]);
}
@@ -334,11 +334,11 @@ static int em28xx_i2c_xfer(struct i2c_adapter *i2c_adap,
i == num - 1);
}
if (rc 0) {
- if (i2c_debug = 2)
+ if (i2c_debug)
printk( ERROR: %i\n, rc);
return rc;
}
- if (i2c_debug = 2)
+ if (i2c_debug)
printk(\n);
}
--
1.7.10.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
[PATCH v2 06/11] em28xx: make sure we are at i2c bus A when calling em28xx_i2c_register()
The current code first configures register EM28XX_R06_I2C_CLK, which includes
i2c speed, ack, wait and (on some devices) i2c bus selection.
The register value usually comes from the board definition.
em28xx_i2c_register() is called afterwards, which also tries to read the eeprom.
If the device uses i2c bus B, eeprom reading fails.
Fix the problem by selecting bus A before calling em28xx_i2c_register() and
apply the board settings for register EM28XX_R06_I2C_CLK afterwards.
I also noticed that this is what the Windows driver does.
To be sure the i2c bus scan works as expected/before, remove its call from
em28xx_i2c_register() and call it directly after the i2c bus has been
configured.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-cards.c | 31 ---
drivers/media/usb/em28xx/em28xx-i2c.c |7 ---
2 Dateien geändert, 20 Zeilen hinzugefügt(+), 18 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index 9332d05..0d74734 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -66,6 +66,10 @@ module_param(usb_xfer_mode, int, 0444);
MODULE_PARM_DESC(usb_xfer_mode,
USB transfer mode for frame data (-1 = auto, 0 = prefer isoc,
1 = prefer bulk));
+static unsigned int i2c_scan;
+module_param(i2c_scan, int, 0444);
+MODULE_PARM_DESC(i2c_scan, scan i2c bus at insmod time);
+
/* Bitmask marking allocated devices from 0 to EM28XX_MAXBOARDS - 1 */
static unsigned long em28xx_devused;
@@ -3074,8 +3078,20 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
snprintf(dev-name, sizeof(dev-name), %s #%d, chip_name,
dev-devno);
}
+ /* Select i2c bus A (if necessary) */
+ if (dev-chip_id == CHIP_ID_EM2874 ||
+ dev-chip_id == CHIP_ID_EM28174 ||
+ dev-chip_id == CHIP_ID_EM2884)
+ em28xx_write_reg_bits(dev, EM28XX_R06_I2C_CLK, 0,
EM2874_I2C_SECONDARY_BUS_SELECT);
+ /* Register i2c bus */
+ retval = em28xx_i2c_register(dev);
+ if (retval 0) {
+ em28xx_errdev(%s: em28xx_i2c_register - error [%d]!\n,
+ __func__, retval);
+ return retval;
+ }
+ /* Configure i2c bus */
if (!dev-board.is_em2800) {
- /* Resets I2C speed */
retval = em28xx_write_reg(dev, EM28XX_R06_I2C_CLK,
dev-board.i2c_speed);
if (retval 0) {
em28xx_errdev(%s: em28xx_write_reg failed!
@@ -3084,6 +3100,9 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
return retval;
}
}
+ /* Scan i2c bus */
+ if (i2c_scan)
+ em28xx_do_i2c_scan(dev);
retval = v4l2_device_register(interface-dev, dev-v4l2_dev);
if (retval 0) {
@@ -3094,14 +3113,6 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
v4l2_ctrl_handler_init(hdl, 8);
dev-v4l2_dev.ctrl_handler = hdl;
- /* register i2c bus */
- retval = em28xx_i2c_register(dev);
- if (retval 0) {
- em28xx_errdev(%s: em28xx_i2c_register - error [%d]!\n,
- __func__, retval);
- goto unregister_dev;
- }
-
/*
* Default format, used for tvp5150 or saa711x output formats
*/
@@ -3173,8 +3184,6 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
fail:
em28xx_i2c_unregister(dev);
v4l2_ctrl_handler_free(dev-ctrl_handler);
-
-unregister_dev:
v4l2_device_unregister(dev-v4l2_dev);
return retval;
diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c
b/drivers/media/usb/em28xx/em28xx-i2c.c
index 19f3e4f..ebe4b20 100644
--- a/drivers/media/usb/em28xx/em28xx-i2c.c
+++ b/drivers/media/usb/em28xx/em28xx-i2c.c
@@ -33,10 +33,6 @@
/* --- */
-static unsigned int i2c_scan;
-module_param(i2c_scan, int, 0444);
-MODULE_PARM_DESC(i2c_scan, scan i2c bus at insmod time);
-
static unsigned int i2c_debug;
module_param(i2c_debug, int, 0644);
MODULE_PARM_DESC(i2c_debug, enable debug messages [i2c]);
@@ -606,9 +602,6 @@ int em28xx_i2c_register(struct em28xx *dev)
return retval;
}
- if (i2c_scan)
- em28xx_do_i2c_scan(dev);
-
return 0;
}
--
1.7.10.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
[PATCH v2 08/11] em28xx: add helper function for reading data blocks from i2c clients
Add a helper function for reading data blocks from i2c devices with 8 or 16 bit
address width and 8 bit register width.
This allows us to reduce the size of new code added by the following patches.
Works only for devices with activated register auto incrementation.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-i2c.c | 74 -
1 Datei geändert, 46 Zeilen hinzugefügt(+), 28 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c
b/drivers/media/usb/em28xx/em28xx-i2c.c
index 7185812..a3e9547 100644
--- a/drivers/media/usb/em28xx/em28xx-i2c.c
+++ b/drivers/media/usb/em28xx/em28xx-i2c.c
@@ -366,51 +366,69 @@ static inline unsigned long em28xx_hash_mem(char *buf,
int length, int bits)
return (hash (32 - bits)) 0xUL;
}
+/* Helper function to read data blocks from i2c clients with 8 or 16 bit
+ * address width, 8 bit register width and auto incrementation been activated
*/
+static int em28xx_i2c_read_block(struct em28xx *dev, u16 addr, bool addr_w16,
+u16 len, u8 *data)
+{
+ int remain = len, rsize, rsize_max, ret;
+ u8 buf[2];
+
+ /* Sanity check */
+ if (addr + remain (addr_w16 * 0xff00 + 0xff + 1))
+ return -EINVAL;
+ /* Select address */
+ buf[0] = addr 8;
+ buf[1] = addr 0xff;
+ ret = i2c_master_send(dev-i2c_client, buf + !addr_w16, 1 + addr_w16);
+ if (ret 0)
+ return ret;
+ /* Read data */
+ if (dev-board.is_em2800)
+ rsize_max = 4;
+ else
+ rsize_max = 64;
+ while (remain 0) {
+ if (remain rsize_max)
+ rsize = rsize_max;
+ else
+ rsize = remain;
+
+ ret = i2c_master_recv(dev-i2c_client, data, rsize);
+ if (ret 0)
+ return ret;
+
+ remain -= rsize;
+ data += rsize;
+ }
+
+ return len;
+}
+
static int em28xx_i2c_eeprom(struct em28xx *dev, unsigned char *eedata, int
len)
{
- unsigned char buf[2], *p = eedata;
+ unsigned char buf, *p = eedata;
struct em28xx_eeprom *em_eeprom = (void *)eedata;
- int i, err, size = len, block, block_max;
+ int i, err;
dev-i2c_client.addr = 0xa0 1;
/* Check if board has eeprom */
- err = i2c_master_recv(dev-i2c_client, buf, 0);
+ err = i2c_master_recv(dev-i2c_client, buf, 0);
if (err 0) {
em28xx_info(board has no eeprom\n);
memset(eedata, 0, len);
return -ENODEV;
}
- /* Select address memory address 0x00(00) */
- buf[0] = 0;
- buf[1] = 0;
- err = i2c_master_send(dev-i2c_client, buf, 1 +
dev-eeprom_addrwidth_16bit);
- if (err != 1 + dev-eeprom_addrwidth_16bit) {
+ /* Read EEPROM content */
+ err = em28xx_i2c_read_block(dev, 0x, dev-eeprom_addrwidth_16bit,
+ len, p);
+ if (err != len) {
em28xx_errdev(failed to read eeprom (err=%d)\n, err);
return err;
}
- /* Read eeprom content */
- if (dev-board.is_em2800)
- block_max = 4;
- else
- block_max = 64;
- while (size 0) {
- if (size block_max)
- block = block_max;
- else
- block = size;
-
- if (block !=
- (err = i2c_master_recv(dev-i2c_client, p, block))) {
- em28xx_errdev(i2c eeprom read error (err=%d)\n, err);
- return err;
- }
- size -= block;
- p += block;
- }
-
/* Display eeprom content */
for (i = 0; i len; i++) {
if (0 == (i % 16)) {
--
1.7.10.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
[PATCH v2 10/11] em28xx: extract the device configuration dataset from eeproms with 16 bit address width
The new eeproms with 16 address width still have the the device config dataset
(the content of the old 8 bit eeproms) embedded.
Hauppauge also continues to include the tveeprom data structure inside this
dataset in their devices.
The start address of the dataset depends on the start address of the microcode
and a variable additional offset.
It should be mentioned that Camera devices seem to use a different dataset type,
which is not yet supported.
Tested with devices Hauppauge HVR-930C. I've also checked the USB-log from the
MSI Digivox ATSC and it works the same way.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-i2c.c | 117 +++--
drivers/media/usb/em28xx/em28xx.h |4 +-
2 Dateien geändert, 85 Zeilen hinzugefügt(+), 36 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c
b/drivers/media/usb/em28xx/em28xx-i2c.c
index dfbc22e..44bef43 100644
--- a/drivers/media/usb/em28xx/em28xx-i2c.c
+++ b/drivers/media/usb/em28xx/em28xx-i2c.c
@@ -405,13 +405,18 @@ static int em28xx_i2c_read_block(struct em28xx *dev, u16
addr, bool addr_w16,
return len;
}
-static int em28xx_i2c_eeprom(struct em28xx *dev, unsigned char **eedata, int
len)
+static int em28xx_i2c_eeprom(struct em28xx *dev, u8 **eedata, u16 *eedata_len)
{
- u8 buf, *data;
- struct em28xx_eeprom *em_eeprom;
+ const u16 len = 256;
+ /* FIXME common length/size for bytes to read, to display, hash
+* calculation and returned device dataset. Simplifies the code a lot,
+* but we might have to deal with multiple sizes in the future ! */
int i, err;
+ struct em28xx_eeprom *dev_config;
+ u8 buf, *data;
*eedata = NULL;
+ *eedata_len = 0;
dev-i2c_client.addr = 0xa0 1;
@@ -431,8 +436,7 @@ static int em28xx_i2c_eeprom(struct em28xx *dev, unsigned
char **eedata, int len
len, data);
if (err != len) {
em28xx_errdev(failed to read eeprom (err=%d)\n, err);
- kfree(data);
- return err;
+ goto error;
}
/* Display eeprom content */
@@ -447,15 +451,25 @@ static int em28xx_i2c_eeprom(struct em28xx *dev, unsigned
char **eedata, int len
if (15 == (i % 16))
printk(\n);
}
+ if (dev-eeprom_addrwidth_16bit)
+ em28xx_info(i2c eeprom %04x: ... (skipped)\n, i);
if (dev-eeprom_addrwidth_16bit
data[0] == 0x26 data[3] == 0x00) {
/* new eeprom format; size 4-64kb */
+ u16 mc_start;
+ u16 hwconf_offset;
+
dev-hash = em28xx_hash_mem(data, len, 32);
- em28xx_info(EEPROM hash = 0x%08lx\n, dev-hash);
- em28xx_info(EEPROM info: boot page address = 0x%02x04,
+ mc_start = (data[1] 8) + 4; /* usually 0x0004 */
+
+ em28xx_info(EEPROM ID = %02x %02x %02x %02x,
+ EEPROM hash = 0x%08lx\n,
+ data[0], data[1], data[2], data[3], dev-hash);
+ em28xx_info(EEPROM info:\n);
+ em28xx_info(\tmicrocode start address = 0x%04x,
boot configuration = 0x%02x\n,
- data[1], data[2]);
+ mc_start, data[2]);
/* boot configuration (address 0x0002):
* [0] microcode download speed: 1 = 400 kHz; 0 = 100 kHz
* [1] always selects 12 kb RAM
@@ -465,32 +479,61 @@ static int em28xx_i2c_eeprom(struct em28xx *dev, unsigned
char **eedata, int len
* characterization
*/
- /* FIXME:
-* - read more than 256 bytes / addresses above 0x00ff
-* - find offset for device config dataset and extract it
-* - decrypt eeprom data for camera bridges (em25xx, em276x+)
-* - use separate/different eeprom hashes (not yet used)
+ /* Read hardware config dataset offset from address
+* (microcode start + 46) */
+ err = em28xx_i2c_read_block(dev, mc_start + 46, 1, 2, data);
+ if (err != 2) {
+ em28xx_errdev(failed to read hardware configuration
data from eeprom (err=%d)\n,
+ err);
+ goto error;
+ }
+
+ /* Calculate hardware config dataset start address */
+ hwconf_offset = mc_start + data[0] + (data[1] 8);
+
+ /* Read hardware config dataset */
+ /* NOTE: the microcode copy can be multiple pages long, but
+* we assume the hardware config dataset is the same as in
+* the old eeprom and not longer than 256 bytes.
+*
[PATCH v2 11/11] em28xx: enable tveeprom for device Hauppauge HVR-930C
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-cards.c |1 +
1 Datei geändert, 1 Zeile hinzugefügt(+)
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index 2e3d3ad..5a5b637 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -2741,6 +2741,7 @@ static void em28xx_card_setup(struct em28xx *dev)
case EM2880_BOARD_HAUPPAUGE_WINTV_HVR_900_R2:
case EM2883_BOARD_HAUPPAUGE_WINTV_HVR_850:
case EM2883_BOARD_HAUPPAUGE_WINTV_HVR_950:
+ case EM2884_BOARD_HAUPPAUGE_WINTV_HVR_930C:
{
struct tveeprom tv;
--
1.7.10.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
[PATCH v2 07/11] em28xx: add basic support for eeproms with 16 bit address width
Newer devices (em2874, em2884, em28174, em25xx, em27[6,7,8]x) use eeproms with
16 bit instead of 8 bit address width.
The used eeprom type depends on the chip type, which makes sure eeproms can't
be damaged.
This patch adds basic support for 16 bit eeproms only, which includes
- reading the content
- calculating the eeprom hash
- displaying the content
The eeprom content uses a different format, for which support will be added with
subsequent patches.
Tested with the Hauppauge HVR-930C and the Speedlink VAD Laplace webcam
(with additional experimental patches).
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-cards.c |4 ++
drivers/media/usb/em28xx/em28xx-i2c.c | 69 ---
drivers/media/usb/em28xx/em28xx.h |1 +
3 Dateien geändert, 49 Zeilen hinzugefügt(+), 25 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index 0d74734..fa51f81 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -2187,6 +2187,7 @@ static struct em28xx_hash_table em28xx_i2c_hash[] = {
{0x4ba50080, EM2861_BOARD_GADMEI_UTV330PLUS, TUNER_TNF_5335MF},
{0x6b800080, EM2874_BOARD_LEADERSHIP_ISDBT, TUNER_ABSENT},
};
+/* NOTE: introduce a separate hash table for devices with 16 bit eeproms */
/* I2C possible address to saa7115, tvp5150, msp3400, tvaudio */
static unsigned short saa711x_addrs[] = {
@@ -3023,11 +3024,13 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
chip_name = em2874;
dev-reg_gpio_num = EM2874_R80_GPIO;
dev-wait_after_write = 0;
+ dev-eeprom_addrwidth_16bit = 1;
break;
case CHIP_ID_EM28174:
chip_name = em28174;
dev-reg_gpio_num = EM2874_R80_GPIO;
dev-wait_after_write = 0;
+ dev-eeprom_addrwidth_16bit = 1;
break;
case CHIP_ID_EM2883:
chip_name = em2882/3;
@@ -3037,6 +3040,7 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
chip_name = em2884;
dev-reg_gpio_num = EM2874_R80_GPIO;
dev-wait_after_write = 0;
+ dev-eeprom_addrwidth_16bit = 1;
break;
default:
printk(KERN_INFO DRIVER_NAME
diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c
b/drivers/media/usb/em28xx/em28xx-i2c.c
index ebe4b20..7185812 100644
--- a/drivers/media/usb/em28xx/em28xx-i2c.c
+++ b/drivers/media/usb/em28xx/em28xx-i2c.c
@@ -368,46 +368,34 @@ static inline unsigned long em28xx_hash_mem(char *buf,
int length, int bits)
static int em28xx_i2c_eeprom(struct em28xx *dev, unsigned char *eedata, int
len)
{
- unsigned char buf, *p = eedata;
+ unsigned char buf[2], *p = eedata;
struct em28xx_eeprom *em_eeprom = (void *)eedata;
int i, err, size = len, block, block_max;
- if (dev-chip_id == CHIP_ID_EM2874 ||
- dev-chip_id == CHIP_ID_EM28174 ||
- dev-chip_id == CHIP_ID_EM2884) {
- /* Empia switched to a 16-bit addressable eeprom in newer
- devices. While we could certainly write a routine to read
- the eeprom, there is nothing of use in there that cannot be
- accessed through registers, and there is the risk that we
- could corrupt the eeprom (since a 16-bit read call is
- interpreted as a write call by 8-bit eeproms).
- */
- return 0;
- }
-
dev-i2c_client.addr = 0xa0 1;
/* Check if board has eeprom */
- err = i2c_master_recv(dev-i2c_client, buf, 0);
+ err = i2c_master_recv(dev-i2c_client, buf, 0);
if (err 0) {
em28xx_info(board has no eeprom\n);
memset(eedata, 0, len);
return -ENODEV;
}
- buf = 0;
-
- err = i2c_master_send(dev-i2c_client, buf, 1);
- if (err != 1) {
+ /* Select address memory address 0x00(00) */
+ buf[0] = 0;
+ buf[1] = 0;
+ err = i2c_master_send(dev-i2c_client, buf, 1 +
dev-eeprom_addrwidth_16bit);
+ if (err != 1 + dev-eeprom_addrwidth_16bit) {
em28xx_errdev(failed to read eeprom (err=%d)\n, err);
return err;
}
+ /* Read eeprom content */
if (dev-board.is_em2800)
block_max = 4;
else
block_max = 64;
-
while (size 0) {
if (size block_max)
block = block_max;
@@ -422,17 +410,48 @@ static int em28xx_i2c_eeprom(struct em28xx *dev, unsigned
char *eedata, int len)
[PATCH v2 09/11] em28xx: do not store eeprom content permanently
We currently reserve an array of 256 bytes for the eeprom content in the device
struct. For eeproms with 16 bit address width it might even be necessary to
increase the buffer size further.
Having such a big chunk of memory reserved even if the device has no eeprom and
keeping it after it has already been processed seems to be a waste of memory.
Change the code to allocate + free the eeprom memory dynamically.
This also makes it possible to handle different dataset sizes depending on what
is stored/found in the eeprom.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-cards.c |9 +++-
drivers/media/usb/em28xx/em28xx-i2c.c | 35 +++
drivers/media/usb/em28xx/em28xx.h |2 +-
3 Dateien geändert, 31 Zeilen hinzugefügt(+), 15 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index fa51f81..2e3d3ad 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -2743,6 +2743,9 @@ static void em28xx_card_setup(struct em28xx *dev)
case EM2883_BOARD_HAUPPAUGE_WINTV_HVR_950:
{
struct tveeprom tv;
+
+ if (dev-eedata == NULL)
+ break;
#if defined(CONFIG_MODULES) defined(MODULE)
request_module(tveeprom);
#endif
@@ -2796,7 +2799,7 @@ static void em28xx_card_setup(struct em28xx *dev)
em28xx_set_mode(dev, EM28XX_ANALOG_MODE);
break;
-/*
+ /*
* The Dikom DK300 is detected as an Kworld VS-DVB-T 323UR.
*
* This occurs because they share identical USB vendor and
@@ -2831,6 +2834,10 @@ static void em28xx_card_setup(struct em28xx *dev)
addresses)\n\n);
}
+ /* Free eeprom data memory */
+ kfree(dev-eedata);
+ dev-eedata = NULL;
+
/* Allow override tuner type by a module parameter */
if (tuner = 0)
dev-tuner_type = tuner;
diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c
b/drivers/media/usb/em28xx/em28xx-i2c.c
index a3e9547..dfbc22e 100644
--- a/drivers/media/usb/em28xx/em28xx-i2c.c
+++ b/drivers/media/usb/em28xx/em28xx-i2c.c
@@ -405,27 +405,33 @@ static int em28xx_i2c_read_block(struct em28xx *dev, u16
addr, bool addr_w16,
return len;
}
-static int em28xx_i2c_eeprom(struct em28xx *dev, unsigned char *eedata, int
len)
+static int em28xx_i2c_eeprom(struct em28xx *dev, unsigned char **eedata, int
len)
{
- unsigned char buf, *p = eedata;
- struct em28xx_eeprom *em_eeprom = (void *)eedata;
+ u8 buf, *data;
+ struct em28xx_eeprom *em_eeprom;
int i, err;
+ *eedata = NULL;
+
dev-i2c_client.addr = 0xa0 1;
/* Check if board has eeprom */
err = i2c_master_recv(dev-i2c_client, buf, 0);
if (err 0) {
em28xx_info(board has no eeprom\n);
- memset(eedata, 0, len);
return -ENODEV;
}
+ data = kzalloc(len, GFP_KERNEL);
+ if (data == NULL)
+ return -ENOMEM;
+
/* Read EEPROM content */
err = em28xx_i2c_read_block(dev, 0x, dev-eeprom_addrwidth_16bit,
- len, p);
+ len, data);
if (err != len) {
em28xx_errdev(failed to read eeprom (err=%d)\n, err);
+ kfree(data);
return err;
}
@@ -437,19 +443,19 @@ static int em28xx_i2c_eeprom(struct em28xx *dev, unsigned
char *eedata, int len)
else
em28xx_info(i2c eeprom %02x:, i);
}
- printk( %02x, eedata[i]);
+ printk( %02x, data[i]);
if (15 == (i % 16))
printk(\n);
}
if (dev-eeprom_addrwidth_16bit
- eedata[0] == 0x26 eedata[3] == 0x00) {
+ data[0] == 0x26 data[3] == 0x00) {
/* new eeprom format; size 4-64kb */
- dev-hash = em28xx_hash_mem(eedata, len, 32);
+ dev-hash = em28xx_hash_mem(data, len, 32);
em28xx_info(EEPROM hash = 0x%08lx\n, dev-hash);
em28xx_info(EEPROM info: boot page address = 0x%02x04,
boot configuration = 0x%02x\n,
- eedata[1], eedata[2]);
+ data[1], data[2]);
/* boot configuration (address 0x0002):
* [0] microcode download speed: 1 = 400 kHz; 0 = 100 kHz
* [1] always selects 12 kb RAM
@@ -467,13 +473,16 @@ static int em28xx_i2c_eeprom(struct em28xx *dev, unsigned
char *eedata, int len)
*/
return 0;
- } else if (em_eeprom-id[0] != 0x1a || em_eeprom-id[1] != 0xeb ||
-
[PATCH v2 05/11] em28xx: fix eeprom data endianess
The data is stored as little endian in the eeprom.
Hence the correct data types should be used and the data should be converted
to the machine endianess before using it.
The eeprom id (key) also isn't a 32 bit value but 4 separate bytes instead.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-i2c.c | 22 --
drivers/media/usb/em28xx/em28xx.h | 12 ++--
2 Dateien geändert, 18 Zeilen hinzugefügt(+), 16 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c
b/drivers/media/usb/em28xx/em28xx-i2c.c
index 9612086..19f3e4f 100644
--- a/drivers/media/usb/em28xx/em28xx-i2c.c
+++ b/drivers/media/usb/em28xx/em28xx-i2c.c
@@ -434,19 +434,21 @@ static int em28xx_i2c_eeprom(struct em28xx *dev, unsigned
char *eedata, int len)
printk(\n);
}
- if (em_eeprom-id != 0x9567eb1a) {
+ if (em_eeprom-id[0] != 0x1a || em_eeprom-id[1] != 0xeb ||
+ em_eeprom-id[2] != 0x67 || em_eeprom-id[3] != 0x95 ) {
em28xx_errdev(Unknown eeprom type or eeprom corrupted !);
return -ENODEV;
}
dev-hash = em28xx_hash_mem(eedata, len, 32);
- em28xx_info(EEPROM ID = 0x%08x, EEPROM hash = 0x%08lx\n,
- em_eeprom-id, dev-hash);
+ em28xx_info(EEPROM ID = %02x %02x %02x %02x, EEPROM hash = 0x%08lx\n,
+ em_eeprom-id[0], em_eeprom-id[1],
+ em_eeprom-id[2], em_eeprom-id[3], dev-hash);
em28xx_info(EEPROM info:\n);
- switch (em_eeprom-chip_conf 4 0x3) {
+ switch (le16_to_cpu(em_eeprom-chip_conf) 4 0x3) {
case 0:
em28xx_info(\tNo audio on board.\n);
break;
@@ -461,13 +463,13 @@ static int em28xx_i2c_eeprom(struct em28xx *dev, unsigned
char *eedata, int len)
break;
}
- if (em_eeprom-chip_conf 1 3)
+ if (le16_to_cpu(em_eeprom-chip_conf) 1 3)
em28xx_info(\tUSB Remote wakeup capable\n);
- if (em_eeprom-chip_conf 1 2)
+ if (le16_to_cpu(em_eeprom-chip_conf) 1 2)
em28xx_info(\tUSB Self power capable\n);
- switch (em_eeprom-chip_conf 0x3) {
+ switch (le16_to_cpu(em_eeprom-chip_conf) 0x3) {
case 0:
em28xx_info(\t500mA max power\n);
break;
@@ -483,9 +485,9 @@ static int em28xx_i2c_eeprom(struct em28xx *dev, unsigned
char *eedata, int len)
}
em28xx_info(\tTable at offset 0x%02x, strings=0x%04x, 0x%04x,
0x%04x\n,
em_eeprom-string_idx_table,
- em_eeprom-string1,
- em_eeprom-string2,
- em_eeprom-string3);
+ le16_to_cpu(em_eeprom-string1),
+ le16_to_cpu(em_eeprom-string2),
+ le16_to_cpu(em_eeprom-string3));
return 0;
}
diff --git a/drivers/media/usb/em28xx/em28xx.h
b/drivers/media/usb/em28xx/em28xx.h
index 4160a2a..90266a1 100644
--- a/drivers/media/usb/em28xx/em28xx.h
+++ b/drivers/media/usb/em28xx/em28xx.h
@@ -405,15 +405,15 @@ struct em28xx_board {
};
struct em28xx_eeprom {
- u32 id; /* 0x9567eb1a */
- u16 vendor_ID;
- u16 product_ID;
+ u8 id[4]; /* 1a eb 67 95 */
+ __le16 vendor_ID;
+ __le16 product_ID;
- u16 chip_conf;
+ __le16 chip_conf;
- u16 board_conf;
+ __le16 board_conf;
- u16 string1, string2, string3;
+ __le16 string1, string2, string3;
u8 string_idx_table;
};
--
1.7.10.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
[PATCH v2 04/11] em28xx: do not interpret eeprom content if eeprom key is invalid
If the eeprom key isn't valid, either a different (currently unknown) format
is used or the eeprom is corrupted.
In both cases it doesn't make sense to interpret the data.
Also print an error message.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-i2c.c |8 ++--
1 Datei geändert, 6 Zeilen hinzugefügt(+), 2 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c
b/drivers/media/usb/em28xx/em28xx-i2c.c
index d765567..9612086 100644
--- a/drivers/media/usb/em28xx/em28xx-i2c.c
+++ b/drivers/media/usb/em28xx/em28xx-i2c.c
@@ -434,8 +434,12 @@ static int em28xx_i2c_eeprom(struct em28xx *dev, unsigned
char *eedata, int len)
printk(\n);
}
- if (em_eeprom-id == 0x9567eb1a)
- dev-hash = em28xx_hash_mem(eedata, len, 32);
+ if (em_eeprom-id != 0x9567eb1a) {
+ em28xx_errdev(Unknown eeprom type or eeprom corrupted !);
+ return -ENODEV;
+ }
+
+ dev-hash = em28xx_hash_mem(eedata, len, 32);
em28xx_info(EEPROM ID = 0x%08x, EEPROM hash = 0x%08lx\n,
em_eeprom-id, dev-hash);
--
1.7.10.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
[PATCH 0/5] em28xx: add support for the em2765 bridge
This patch series adds basic support for the em25xx/276x/7x/8x camera bridges. These devices differ from the em2710/2750 and em28xx bridges in several points: 1) a second i2c bus is provided which has to be accessed with a different read/write algorithm (= patch 1) 2) a different frame data format is used (= patch 3) 3) additional output formats (e.g. mpeg) are provided. This patch series does not (yet) add support for them, but it fixes the output format selection for these bridges (the current code sets bit 5 of the output format register, which has a different meaning for the other bridges and breaks capturing with em25xx family sdevices). (= patch 4) 4) registers 0x34+0x35 (VBI_START_H/V for em28xx devices) are used for a different (unknown) purpose. This needs to be investigated further (could be zooming, cropping, image statistics or AWB/AE window selection). At normal operation, these registers are set to capturing (input) width/height / 16. (= patch 5) Patch 2 add the chip id of the em2765 as found in the SpeedLink Vicious And Devine Laplace webcam. The changes have also been tested with this device. Frank Schäfer (5): em28xx: add support for em25xx i2c bus B read/write/check device operations em28xx: add chip id of the em2765 em28xx: add support for em25xx/em276x/em277x/em278x frame data processing em28xx: make em28xx_set_outfmt() working with EM25xx family bridges em28xx: write output frame resolution to regs 0x34+0x35 for em25xx family bridges drivers/media/usb/em28xx/em28xx-cards.c | 17 +++- drivers/media/usb/em28xx/em28xx-core.c | 27 - drivers/media/usb/em28xx/em28xx-i2c.c | 164 +++ drivers/media/usb/em28xx/em28xx-reg.h |7 ++ drivers/media/usb/em28xx/em28xx-video.c | 72 +- drivers/media/usb/em28xx/em28xx.h |8 ++ 6 Dateien geändert, 271 Zeilen hinzugefügt(+), 24 Zeilen entfernt(-) -- 1.7.10.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
[PATCH 1/5] em28xx: add support for em25xx i2c bus B read/write/check device operations
The webcam SpeedLink VAD Laplace (em2765 + ov2640) uses a special algorithm
for i2c communication with the sensor, which is connected to a second i2c bus.
We don't know yet how to find out which devices support/use it.
It's very likely used by all em25xx and em276x+ bridges.
Tests with other em28xx chips (em2820, em2882/em2883) show, that this
algorithm always succeeds there although no slave device is connected.
The algorithm likely also works for real I2C client devices (OV2640 uses SCCB),
because the Windows driver seems to use it for probing Samsung and Kodak
sensors.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-cards.c |6 +-
drivers/media/usb/em28xx/em28xx-i2c.c | 164 +++
drivers/media/usb/em28xx/em28xx.h |7 ++
3 Dateien geändert, 159 Zeilen hinzugefügt(+), 18 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index 5a5b637..75d4aef 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -3103,7 +3103,11 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
return retval;
}
/* Configure i2c bus */
- if (!dev-board.is_em2800) {
+ if (dev-board.is_em2800) {
+ dev-i2c_algo_type = EM28XX_I2C_ALGO_EM2800;
+ } else {
+ dev-i2c_algo_type = EM28XX_I2C_ALGO_EM28XX;
+
retval = em28xx_write_reg(dev, EM28XX_R06_I2C_CLK,
dev-board.i2c_speed);
if (retval 0) {
em28xx_errdev(%s: em28xx_write_reg failed!
diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c
b/drivers/media/usb/em28xx/em28xx-i2c.c
index 44bef43..6e86ffc 100644
--- a/drivers/media/usb/em28xx/em28xx-i2c.c
+++ b/drivers/media/usb/em28xx/em28xx-i2c.c
@@ -5,6 +5,7 @@
Markus Rechberger mrechber...@gmail.com
Mauro Carvalho Chehab mche...@infradead.org
Sascha Sommer saschasom...@freenet.de
+ Copyright (C) 2013 Frank Schäfer fschaefer@googlemail.com
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -270,6 +271,114 @@ static int em28xx_i2c_check_for_device(struct em28xx
*dev, u16 addr)
}
/*
+ * em25xx_bus_B_send_bytes
+ * write bytes to the i2c device
+ */
+static int em25xx_bus_B_send_bytes(struct em28xx *dev, u16 addr, u8 *buf,
+ u16 len)
+{
+ int ret;
+
+ if (len 1 || len 64)
+ return -EOPNOTSUPP;
+ /* NOTE: limited by the USB ctrl message constraints
+* Zero length reads always succeed, even if no device is connected */
+
+ /* Set register and write value */
+ ret = dev-em28xx_write_regs_req(dev, 0x06, addr, buf, len);
+ /* NOTE:
+* 0 byte writes always succeed, even if no device is connected. */
+ if (ret != len) {
+ if (ret 0) {
+ em28xx_warn(writing to i2c device at 0x%x failed
+ (error=%i)\n, addr, ret);
+ return ret;
+ } else {
+ em28xx_warn(%i bytes write to i2c device at 0x%x
+ requested, but %i bytes written\n,
+ len, addr, ret);
+ return -EIO;
+ }
+ }
+ /* Check success */
+ ret = dev-em28xx_read_reg_req(dev, 0x08, 0x);
+ /* NOTE: the only error we've seen so far is
+* 0x01 when the slave device is not present */
+ if (ret == 0x00) {
+ return len;
+ } else if (ret 0) {
+ return -ENODEV;
+ }
+
+ return ret;
+ /* NOTE: With chips which do not support this operation,
+* it seems to succeed ALWAYS ! (even if no device connected) */
+}
+
+/*
+ * em25xx_bus_B_recv_bytes
+ * read bytes from the i2c device
+ */
+static int em25xx_bus_B_recv_bytes(struct em28xx *dev, u16 addr, u8 *buf,
+ u16 len)
+{
+ int ret;
+
+ if (len 1 || len 64)
+ return -EOPNOTSUPP;
+ /* NOTE: limited by the USB ctrl message constraints
+* Zero length reads always succeed, even if no device is connected */
+
+ /* Read value */
+ ret = dev-em28xx_read_reg_req_len(dev, 0x06, addr, buf, len);
+ /* NOTE:
+* 0 byte reads always succeed, even if no device is connected. */
+ if (ret != len) {
+ if (ret 0) {
+ em28xx_warn(reading from i2c device at 0x%x failed
+ (error=%i)\n, addr, ret);
+ return ret;
+ } else {
+ em28xx_warn(%i bytes requested from i2c device at
+
[PATCH 2/5] em28xx: add chip id of the em2765
This chip can be found in the SpeedLink VAD Laplace webcam (1ae7:9003 and
1ae7:9004).
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-cards.c | 13 -
drivers/media/usb/em28xx/em28xx-reg.h |1 +
drivers/media/usb/em28xx/em28xx.h |1 +
3 Dateien geändert, 14 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index 75d4aef..e4d14e7 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -3015,6 +3015,12 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
case CHIP_ID_EM2750:
chip_name = em2750;
break;
+ case CHIP_ID_EM2765:
+ chip_name = em2765;
+ dev-wait_after_write = 0;
+ dev-is_em25xx = 1;
+ dev-eeprom_addrwidth_16bit = 1;
+ break;
case CHIP_ID_EM2820:
chip_name = em2710/2820;
break;
@@ -3106,7 +3112,12 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
if (dev-board.is_em2800) {
dev-i2c_algo_type = EM28XX_I2C_ALGO_EM2800;
} else {
- dev-i2c_algo_type = EM28XX_I2C_ALGO_EM28XX;
+ if (dev-is_em25xx)
+ /* Use i2c bus B */
+ dev-i2c_algo_type = EM28XX_I2C_ALGO_EM25XX_BUS_B;
+ /* FIXME: really do this always ? */
+ else
+ dev-i2c_algo_type = EM28XX_I2C_ALGO_EM28XX;
retval = em28xx_write_reg(dev, EM28XX_R06_I2C_CLK,
dev-board.i2c_speed);
if (retval 0) {
diff --git a/drivers/media/usb/em28xx/em28xx-reg.h
b/drivers/media/usb/em28xx/em28xx-reg.h
index 1e369ba..d765d59 100644
--- a/drivers/media/usb/em28xx/em28xx-reg.h
+++ b/drivers/media/usb/em28xx/em28xx-reg.h
@@ -219,6 +219,7 @@ enum em28xx_chip_id {
CHIP_ID_EM2860 = 34,
CHIP_ID_EM2870 = 35,
CHIP_ID_EM2883 = 36,
+ CHIP_ID_EM2765 = 54,
CHIP_ID_EM2874 = 65,
CHIP_ID_EM2884 = 68,
CHIP_ID_EM28174 = 113,
diff --git a/drivers/media/usb/em28xx/em28xx.h
b/drivers/media/usb/em28xx/em28xx.h
index b7c8134..131fdaa 100644
--- a/drivers/media/usb/em28xx/em28xx.h
+++ b/drivers/media/usb/em28xx/em28xx.h
@@ -469,6 +469,7 @@ struct em28xx {
int model; /* index in the device_data struct */
int devno; /* marks the number of this device */
enum em28xx_chip_id chip_id;
+ unsigned int is_em25xx:1; /* em25xx/em276x/7x/8x family bridge */
unsigned char disconnected:1; /* device has been diconnected */
--
1.7.10.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
[PATCH 3/5] em28xx: add support for em25xx/em276x/em277x/em278x frame data processing
The em25xx/em276x/em277x/em278x frame data format is different to the one used
by the em2710/em2750/em28xx chips.
With the recent cleanups and reorganization of the frame data processing code it
can be easily extended to support these devices.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-video.c | 72 ++-
1 Datei geändert, 71 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-video.c
b/drivers/media/usb/em28xx/em28xx-video.c
index 93fc620..2e8681f 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -76,6 +76,16 @@ MODULE_DESCRIPTION(DRIVER_DESC);
MODULE_LICENSE(GPL);
MODULE_VERSION(EM28XX_VERSION);
+
+#define EM25XX_FRMDATAHDR_BYTE10x02
+#define EM25XX_FRMDATAHDR_BYTE2_STILL_IMAGE0x20
+#define EM25XX_FRMDATAHDR_BYTE2_FRAME_END 0x02
+#define EM25XX_FRMDATAHDR_BYTE2_FRAME_ID 0x01
+#define EM25XX_FRMDATAHDR_BYTE2_MASK (EM25XX_FRMDATAHDR_BYTE2_STILL_IMAGE | \
+EM25XX_FRMDATAHDR_BYTE2_FRAME_END | \
+EM25XX_FRMDATAHDR_BYTE2_FRAME_ID)
+
+
static unsigned int video_nr[] = {[0 ... (EM28XX_MAXBOARDS - 1)] = -1U };
static unsigned int vbi_nr[] = {[0 ... (EM28XX_MAXBOARDS - 1)] = -1U };
static unsigned int radio_nr[] = {[0 ... (EM28XX_MAXBOARDS - 1)] = -1U };
@@ -408,6 +418,62 @@ static inline void process_frame_data_em28xx(struct em28xx
*dev,
em28xx_copy_video(dev, buf, data_pkt, data_len);
}
+/*
+ * Process data packet according to the em25xx/em276x/7x/8x frame data format
+ */
+static inline void process_frame_data_em25xx(struct em28xx *dev,
+unsigned char *data_pkt,
+unsigned int data_len)
+{
+ struct em28xx_buffer*buf = dev-usb_ctl.vid_buf;
+ struct em28xx_dmaqueue *dmaq = dev-vidq;
+ bool frame_end = 0;
+
+ /* Check for header */
+ /* NOTE: at least with bulk transfers, only the first packet
+* has a header and has always set the FRAME_END bit */
+ if (data_len = 2) {/* em25xx header is only 2 bytes long */
+ if ((data_pkt[0] == EM25XX_FRMDATAHDR_BYTE1)
+ ((data_pkt[1] ~EM25XX_FRMDATAHDR_BYTE2_MASK) == 0x00)) {
+ dev-top_field = !(data_pkt[1]
+ EM25XX_FRMDATAHDR_BYTE2_FRAME_ID);
+ frame_end = data_pkt[1]
+ EM25XX_FRMDATAHDR_BYTE2_FRAME_END;
+ data_pkt += 2;
+ data_len -= 2;
+ }
+
+ /* Finish field and prepare next (BULK only) */
+ if (dev-analog_xfer_bulk frame_end) {
+ buf = finish_field_prepare_next(dev, buf, dmaq);
+ dev-usb_ctl.vid_buf = buf;
+ }
+ /* NOTE: in ISOC mode when a new frame starts and buf==NULL,
+* we COULD already prepare a buffer here to avoid skipping the
+* first frame.
+*/
+ }
+
+ /* Copy data */
+ if (buf != NULL data_len 0)
+ em28xx_copy_video(dev, buf, data_pkt, data_len);
+
+ /* Finish frame (ISOC only) = avoids lag of 1 frame */
+ if (!dev-analog_xfer_bulk frame_end) {
+ buf = finish_field_prepare_next(dev, buf, dmaq);
+ dev-usb_ctl.vid_buf = buf;
+ }
+
+ /* NOTE: Tested with USB bulk transfers only !
+* The wording in the datasheet suggests that isoc might work different.
+* The current code assumes that with isoc transfers each packet has a
+* header like with the other em28xx devices.
+*/
+ /* NOTE: Support for interlaced mode is pure theory. It has not been
+* tested and it is unknown if these devices actually support it. */
+ /* NOTE: No VBI support yet (these chips likely do not support VBI). */
+}
+
/* Processes and copies the URB data content (video and VBI data) */
static inline int em28xx_urb_data_copy(struct em28xx *dev, struct urb *urb)
{
@@ -460,7 +526,11 @@ static inline int em28xx_urb_data_copy(struct em28xx *dev,
struct urb *urb)
continue;
}
- process_frame_data_em28xx(dev, usb_data_pkt, usb_data_len);
+ if (dev-is_em25xx)
+ process_frame_data_em25xx(dev, usb_data_pkt,
usb_data_len);
+ else
+ process_frame_data_em28xx(dev, usb_data_pkt,
usb_data_len);
+
}
return 1;
}
--
1.7.10.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
[PATCH 4/5] em28xx: make em28xx_set_outfmt() working with EM25xx family bridges
Streaming doesn't work with the EM2765 if bit 5 of the output format register
0x27 is set.
It's actually not clear if really has to be set for the other chips, but for
now let's keep it to avoid regressions and add a comment to the code.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-core.c | 20 +++-
1 Datei geändert, 15 Zeilen hinzugefügt(+), 5 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-core.c
b/drivers/media/usb/em28xx/em28xx-core.c
index b2dcb3d..7b9f76b 100644
--- a/drivers/media/usb/em28xx/em28xx-core.c
+++ b/drivers/media/usb/em28xx/em28xx-core.c
@@ -697,12 +697,22 @@ int em28xx_vbi_supported(struct em28xx *dev)
int em28xx_set_outfmt(struct em28xx *dev)
{
int ret;
- u8 vinctrl;
-
- ret = em28xx_write_reg_bits(dev, EM28XX_R27_OUTFMT,
- dev-format-reg | 0x20, 0xff);
+ u8 fmt, vinctrl;
+
+ fmt = dev-format-reg;
+ if (!dev-is_em25xx)
+ fmt |= 0x20;
+ /* NOTE: it's not clear if this is really needed !
+* The datasheets say bit 5 is a reserved bit and devices seem to work
+* fine without it. But the Windows driver sets it for em2710/50+em28xx
+* devices and we've always been setting it, too.
+*
+* em2765 (em25xx, em276x/7x/8x ?) devices do NOT work with this bit
set,
+* it's likely used for an additional (compressed ?) format there.
+*/
+ ret = em28xx_write_reg(dev, EM28XX_R27_OUTFMT, fmt);
if (ret 0)
- return ret;
+ return ret;
ret = em28xx_write_reg(dev, EM28XX_R10_VINMODE, dev-vinmode);
if (ret 0)
--
1.7.10.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
[PATCH 5/5] em28xx: write output frame resolution to regs 0x34+0x35 for em25xx family bridges
The Windows driver writes the output resolution to registers 0x34 (width / 16)
and 0x35 (height / 16) always.
We don't know yet what these registers are used for.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-core.c |7 +++
drivers/media/usb/em28xx/em28xx-reg.h |6 ++
2 Dateien geändert, 13 Zeilen hinzugefügt(+)
diff --git a/drivers/media/usb/em28xx/em28xx-core.c
b/drivers/media/usb/em28xx/em28xx-core.c
index 7b9f76b..0ce6b0f 100644
--- a/drivers/media/usb/em28xx/em28xx-core.c
+++ b/drivers/media/usb/em28xx/em28xx-core.c
@@ -766,6 +766,13 @@ static void em28xx_capture_area_set(struct em28xx *dev, u8
hstart, u8 vstart,
em28xx_write_regs(dev, EM28XX_R1E_CWIDTH, cwidth, 1);
em28xx_write_regs(dev, EM28XX_R1F_CHEIGHT, cheight, 1);
em28xx_write_regs(dev, EM28XX_R1B_OFLOW, overflow, 1);
+
+ if (dev-is_em25xx) {
+ em28xx_write_reg(dev, 0x34, width 4);
+ em28xx_write_reg(dev, 0x35, height 4);
+ }
+ /* FIXME: function/meaning of these registers ? */
+ /* FIXME: align width+height to multiples of 4 ?! */
}
static int em28xx_scaler_set(struct em28xx *dev, u16 h, u16 v)
diff --git a/drivers/media/usb/em28xx/em28xx-reg.h
b/drivers/media/usb/em28xx/em28xx-reg.h
index d765d59..3ec5528 100644
--- a/drivers/media/usb/em28xx/em28xx-reg.h
+++ b/drivers/media/usb/em28xx/em28xx-reg.h
@@ -167,6 +167,12 @@
#define EM28XX_R34_VBI_START_H 0x34
#define EM28XX_R35_VBI_START_V 0x35
+/* NOTE: the EM276x (and EM25xx, EM277x/8x ?) (camera bridges) use these
+ * registers for a different unknown purpose.
+ * = register 0x34 is set to capture width / 16
+ * = register 0x35 is set to capture height / 16
+ */
+
#define EM28XX_R36_VBI_WIDTH 0x36
#define EM28XX_R37_VBI_HEIGHT 0x37
--
1.7.10.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
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sun Mar 3 19:00:34 CET 2013 git branch: for_v3.9 git hash: ed72d37a33fdf43dc47787fe220532cdec9da528 gcc version:i686-linux-gcc (GCC) 4.7.2 host hardware: x86_64 host os:3.8.03-marune linux-git-arm-davinci: WARNINGS linux-git-arm-exynos: ERRORS linux-git-arm-omap: WARNINGS linux-git-blackfin: ERRORS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: OK linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
