Re: mb86a20s and cx23885
Hi
El 01/08/13 09:04, Mauro Carvalho Chehab escribió:
I found the patch that affects the X8507 board is: commit
a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb
alfredo@linux-puon:/usr/src/git/linux git stash
Saved working directory and index state WIP on (no branch): c6f56e7
[media] dvb: don't use DVBv3 bandwidth macros
HEAD is now at c6f56e7 [media] dvb: don't use DVBv3 bandwidth macros
alfredo@linux-puon:/usr/src/git/linux git bisect good
a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb is the first bad commit
commit a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb
Author: Mauro Carvalho Chehab mchehab redhat.com
Date: Mon Dec 26 20:48:54 2011 -0300
[media] cx23885-dvb: Remove a dirty hack that would require DVBv3
The cx23885-dvb driver has a dirty hack:
1) it hooks the DVBv3 legacy call to FE_SET_FRONTEND;
2) it uses internally the DVBv3 struct to decide some
configs.
Replace it by a change during the gate control. This will
likely work, but requires testing. Anyway, the current way
will break, as soon as we stop copying data for DVBv3 for
pure DVBv5 calls.
Compile-tested only.
Cc: Michael Krufky mkrufky linuxtv.org
Signed-off-by: Mauro Carvalho Chehab mchehab redhat.com
:04 04 6d0695eb9e59b837425ed64d4e2be6625864b609
89700b867069ec0ad2713367e607763e91798e98 M drivers
I manually removed the patch, then the TV card works.
Unfortunately my lack of knowledge prevents me fix it.
I test new code with pleasure :) !
Hi Alfredo,
Please send me the patches you've made to make isdb-t work on
it, and I'll try to address this issue.
Regards,
Mauro
Mauro thank you very much for your interest.
I send the patch. 3.2 is on a kernel.
---
.../{ = }/media/dvb/frontends/mb86a20s.c | 332
++--
.../{ = }/media/video/cx23885/cx23885-cards.c | 38 +++
.../{ = }/media/video/cx23885/cx23885-dvb.c | 26 ++
.../{ = }/media/video/cx23885/cx23885-video.c |1 +
.../cx23885/{ = }/media/video/cx23885/cx23885.h |1 +
5 files changed, 163 insertions(+), 235 deletions(-)
diff --git a/drivers/media/dvb/frontends/mb86a20s.c
b/drivers/media/dvb/frontends/mb86a20s.c
index 0f867a5..26e06b4 100644
--- a/drivers/media/dvb/frontends/mb86a20s.c
+++ b/drivers/media/dvb/frontends/mb86a20s.c
@@ -47,271 +47,133 @@ struct mb86a20s_state {
bool need_init;
};
struct regdata {
u8 reg;
u8 data;
};
/*
* 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 },
-{ 0x08, 0x01 },
-{ 0x09, 0x3e },
-{ 0x50, 0xd1 },
-{ 0x51, 0x22 },
-{ 0x39, 0x01 },
-{ 0x71, 0x00 },
-{ 0x28, 0x2a },
-{ 0x29, 0x00 },
-{ 0x2a, 0xff },
-{ 0x2b, 0x80 },
-{ 0x28, 0x20 },
-{ 0x29, 0x33 },
-{ 0x2a, 0xdf },
-{ 0x2b, 0xa9 },
+{ 0x09, 0x3a },
+{ 0x50, 0xd1 }, { 0x51, 0x22 },
+{ 0x39, 0x00 },
+{ 0x28, 0x2a }, { 0x29, 0x00 }, { 0x2a, 0xfd }, { 0x2b, 0xc8 },
{ 0x3b, 0x21 },
-{ 0x3c, 0x3a },
+{ 0x3c, 0x38 },
+{ 0x28, 0x20 }, { 0x29, 0x3e }, { 0x2a, 0xde }, { 0x2b, 0x4d },
+{ 0x28, 0x22 }, { 0x29, 0x00 }, { 0x2a, 0x1f }, { 0x2b, 0xf0 },
{ 0x01, 0x0d },
-{ 0x04, 0x08 },
-{ 0x05, 0x05 },
-{ 0x04, 0x0e },
-{ 0x05, 0x00 },
-{ 0x04, 0x0f },
-{ 0x05, 0x14 },
-{ 0x04, 0x0b },
-{ 0x05, 0x8c },
-{ 0x04, 0x00 },
-{ 0x05, 0x00 },
-{ 0x04, 0x01 },
-{ 0x05, 0x07 },
-{ 0x04, 0x02 },
-{ 0x05, 0x0f },
-{ 0x04, 0x03 },
-{ 0x05, 0xa0 },
-{ 0x04, 0x09 },
-{ 0x05, 0x00 },
-{ 0x04, 0x0a },
-{ 0x05, 0xff },
-{ 0x04, 0x27 },
-{ 0x05, 0x64 },
-{ 0x04, 0x28 },
-{ 0x05, 0x00 },
-{ 0x04, 0x1e },
-{ 0x05, 0xff },
-{ 0x04, 0x29 },
-{ 0x05, 0x0a },
-{ 0x04, 0x32 },
-{ 0x05, 0x0a },
-{ 0x04, 0x14 },
-{ 0x05, 0x02 },
-{ 0x04, 0x04 },
-{ 0x05, 0x00 },
-{ 0x04, 0x05 },
-{ 0x05, 0x22 },
-{ 0x04, 0x06 },
-{ 0x05, 0x0e },
-{ 0x04, 0x07 },
-{ 0x05, 0xd8 },
-{ 0x04, 0x12 },
-{ 0x05, 0x00 },
-{ 0x04, 0x13 },
-{ 0x05, 0xff },
+{ 0x04, 0x08 }, { 0x05, 0x03 },
+{ 0x04, 0x0e }, { 0x05, 0x00 },
+{ 0x04, 0x0f }, { 0x05, 0x32 },
+{ 0x04, 0x0b }, { 0x05, 0x78 },
+{ 0x04, 0x00 }, { 0x05, 0x00 },
+{ 0x04, 0x01 }, { 0x05, 0x1e },
+{ 0x04, 0x02 }, { 0x05, 0x07 },
+{ 0x04, 0x03 }, { 0x05, 0xd0 },
+{ 0x04, 0x09 }, { 0x05, 0x00 },
+{ 0x04, 0x0a }, { 0x05, 0xff },
+{ 0x04, 0x27 }, { 0x05, 0x00 },
+{ 0x04, 0x28 }, { 0x05, 0x00 },
+{ 0x04, 0x1e }, { 0x05, 0x00 },
+{ 0x04, 0x29 }, { 0x05, 0x64 },
+{ 0x04, 0x32 }, { 0x05, 0x64 },
+{ 0x04, 0x14 }, { 0x05, 0x02 },
+{ 0x04, 0x04 }, { 0x05, 0x00
Re: mb86a20s and cx23885
Em Thu, 01 Aug 2013 14:16:32 -0300
Alfredo Jesús Delaiti alfredodela...@netscape.net escreveu:
Hi
El 01/08/13 09:04, Mauro Carvalho Chehab escribió:
I found the patch that affects the X8507 board is: commit
a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb
alfredo@linux-puon:/usr/src/git/linux git stash
Saved working directory and index state WIP on (no branch): c6f56e7
[media] dvb: don't use DVBv3 bandwidth macros
HEAD is now at c6f56e7 [media] dvb: don't use DVBv3 bandwidth macros
alfredo@linux-puon:/usr/src/git/linux git bisect good
a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb is the first bad commit
commit a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb
Author: Mauro Carvalho Chehab mchehab redhat.com
Date: Mon Dec 26 20:48:54 2011 -0300
[media] cx23885-dvb: Remove a dirty hack that would require DVBv3
The cx23885-dvb driver has a dirty hack:
1) it hooks the DVBv3 legacy call to FE_SET_FRONTEND;
2) it uses internally the DVBv3 struct to decide some
configs.
Replace it by a change during the gate control. This will
likely work, but requires testing. Anyway, the current way
will break, as soon as we stop copying data for DVBv3 for
pure DVBv5 calls.
Compile-tested only.
Cc: Michael Krufky mkrufky linuxtv.org
Signed-off-by: Mauro Carvalho Chehab mchehab redhat.com
:04 04 6d0695eb9e59b837425ed64d4e2be6625864b609
89700b867069ec0ad2713367e607763e91798e98 M drivers
I manually removed the patch, then the TV card works.
Unfortunately my lack of knowledge prevents me fix it.
I test new code with pleasure :) !
Hi Alfredo,
Please send me the patches you've made to make isdb-t work on
it, and I'll try to address this issue.
Regards,
Mauro
Mauro thank you very much for your interest.
I send the patch. 3.2 is on a kernel.
---
.../{ = }/media/dvb/frontends/mb86a20s.c | 332
++--
Hmm... unfortunately, your emailer broke the patch. It made a total mess
with whitespaces. Could you please resend it in a way that whitespaces
won't be damaged? Otherwise, patch tool won't apply it.
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mb86a20s and cx23885
Hi
El 01/08/13 14:37, Mauro Carvalho Chehab escribió:
Em Thu, 01 Aug 2013 14:16:32 -0300
Alfredo Jesús Delaiti alfredodela...@netscape.net escreveu:
Hi
El 01/08/13 09:04, Mauro Carvalho Chehab escribió:
I found the patch that affects the X8507 board is: commit
a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb
alfredo@linux-puon:/usr/src/git/linux git stash
Saved working directory and index state WIP on (no branch): c6f56e7
[media] dvb: don't use DVBv3 bandwidth macros
HEAD is now at c6f56e7 [media] dvb: don't use DVBv3 bandwidth macros
alfredo@linux-puon:/usr/src/git/linux git bisect good
a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb is the first bad commit
commit a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb
Author: Mauro Carvalho Chehab mchehab redhat.com
Date: Mon Dec 26 20:48:54 2011 -0300
[media] cx23885-dvb: Remove a dirty hack that would require DVBv3
The cx23885-dvb driver has a dirty hack:
1) it hooks the DVBv3 legacy call to FE_SET_FRONTEND;
2) it uses internally the DVBv3 struct to decide some
configs.
Replace it by a change during the gate control. This will
likely work, but requires testing. Anyway, the current way
will break, as soon as we stop copying data for DVBv3 for
pure DVBv5 calls.
Compile-tested only.
Cc: Michael Krufky mkrufky linuxtv.org
Signed-off-by: Mauro Carvalho Chehab mchehab redhat.com
:04 04 6d0695eb9e59b837425ed64d4e2be6625864b609
89700b867069ec0ad2713367e607763e91798e98 M drivers
I manually removed the patch, then the TV card works.
Unfortunately my lack of knowledge prevents me fix it.
I test new code with pleasure :) !
Hi Alfredo,
Please send me the patches you've made to make isdb-t work on
it, and I'll try to address this issue.
Regards,
Mauro
Mauro thank you very much for your interest.
I send the patch. 3.2 is on a kernel.
---
.../{ = }/media/dvb/frontends/mb86a20s.c | 332
++--
Hmm... unfortunately, your emailer broke the patch. It made a total mess
with whitespaces. Could you please resend it in a way that whitespaces
won't be damaged? Otherwise, patch tool won't apply it.
Cheers,
Mauro
GR
I send attached, I hope it will not break this time.
Again, Thanks
Alfredo
.../{ = }/media/dvb/frontends/mb86a20s.c | 332 ++--
.../{ = }/media/video/cx23885/cx23885-cards.c | 38 +++
.../{ = }/media/video/cx23885/cx23885-dvb.c | 26 ++
.../{ = }/media/video/cx23885/cx23885-video.c |1 +
.../cx23885/{ = }/media/video/cx23885/cx23885.h |1 +
5 files changed, 163 insertions(+), 235 deletions(-)
diff --git a/drivers/media/dvb/frontends/mb86a20s.c b/drivers/media/dvb/frontends/mb86a20s.c
index 0f867a5..26e06b4 100644
--- a/drivers/media/dvb/frontends/mb86a20s.c
+++ b/drivers/media/dvb/frontends/mb86a20s.c
@@ -47,271 +47,133 @@ struct mb86a20s_state {
bool need_init;
};
struct regdata {
u8 reg;
u8 data;
};
/*
* 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 },
- { 0x08, 0x01 },
- { 0x09, 0x3e },
- { 0x50, 0xd1 },
- { 0x51, 0x22 },
- { 0x39, 0x01 },
- { 0x71, 0x00 },
- { 0x28, 0x2a },
- { 0x29, 0x00 },
- { 0x2a, 0xff },
- { 0x2b, 0x80 },
- { 0x28, 0x20 },
- { 0x29, 0x33 },
- { 0x2a, 0xdf },
- { 0x2b, 0xa9 },
+ { 0x09, 0x3a },
+ { 0x50, 0xd1 }, { 0x51, 0x22 },
+ { 0x39, 0x00 },
+ { 0x28, 0x2a }, { 0x29, 0x00 }, { 0x2a, 0xfd }, { 0x2b, 0xc8 },
{ 0x3b, 0x21 },
- { 0x3c, 0x3a },
+ { 0x3c, 0x38 },
+ { 0x28, 0x20 }, { 0x29, 0x3e }, { 0x2a, 0xde }, { 0x2b, 0x4d },
+ { 0x28, 0x22 }, { 0x29, 0x00 }, { 0x2a, 0x1f }, { 0x2b, 0xf0 },
{ 0x01, 0x0d },
- { 0x04, 0x08 },
- { 0x05, 0x05 },
- { 0x04, 0x0e },
- { 0x05, 0x00 },
- { 0x04, 0x0f },
- { 0x05, 0x14 },
- { 0x04, 0x0b },
- { 0x05, 0x8c },
- { 0x04, 0x00 },
- { 0x05, 0x00 },
- { 0x04, 0x01 },
- { 0x05, 0x07 },
- { 0x04, 0x02 },
- { 0x05, 0x0f },
- { 0x04, 0x03 },
- { 0x05, 0xa0 },
- { 0x04, 0x09 },
- { 0x05, 0x00 },
- { 0x04, 0x0a },
- { 0x05, 0xff },
- { 0x04, 0x27 },
- { 0x05, 0x64 },
- { 0x04, 0x28 },
- { 0x05, 0x00 },
- { 0x04, 0x1e },
- { 0x05, 0xff },
- { 0x04, 0x29 },
- { 0x05, 0x0a },
- { 0x04, 0x32 },
- { 0x05, 0x0a },
- { 0x04, 0x14 },
- { 0x05, 0x02 },
- { 0x04, 0x04 },
- { 0x05, 0x00 },
- { 0x04, 0x05 },
- { 0x05, 0x22 },
- { 0x04, 0x06 },
- { 0x05, 0x0e },
- { 0x04, 0x07 },
- { 0x05, 0xd8 },
- { 0x04, 0x12 },
- { 0x05, 0x00 },
- { 0x04, 0x13 },
- { 0x05, 0xff },
+ { 0x04, 0x08 }, { 0x05, 0x03 },
+ { 0x04, 0x0e }, { 0x05, 0x00 },
+ { 0x04, 0x0f }, { 0x05, 0x32 },
+ { 0x04, 0x0b }, { 0x05, 0x78 },
+ { 0x04, 0x00 }, { 0x05, 0x00 },
+ { 0x04, 0x01 }, { 0x05, 0x1e },
+ { 0x04, 0x02 }, { 0x05, 0x07 },
+ { 0x04, 0x03 }, { 0x05, 0xd0 },
+ { 0x04, 0x09 }, {
Re: mb86a20s and cx23885
Em Thu, 01 Aug 2013 15:09:35 -0300
Alfredo Jesús Delaiti alfredodela...@netscape.net escreveu:
Hi
El 01/08/13 14:37, Mauro Carvalho Chehab escribió:
Em Thu, 01 Aug 2013 14:16:32 -0300
Alfredo Jesús Delaiti alfredodela...@netscape.net escreveu:
Hi
El 01/08/13 09:04, Mauro Carvalho Chehab escribió:
I found the patch that affects the X8507 board is: commit
a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb
alfredo@linux-puon:/usr/src/git/linux git stash
Saved working directory and index state WIP on (no branch): c6f56e7
[media] dvb: don't use DVBv3 bandwidth macros
HEAD is now at c6f56e7 [media] dvb: don't use DVBv3 bandwidth macros
alfredo@linux-puon:/usr/src/git/linux git bisect good
a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb is the first bad commit
commit a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb
Author: Mauro Carvalho Chehab mchehab redhat.com
Date: Mon Dec 26 20:48:54 2011 -0300
[media] cx23885-dvb: Remove a dirty hack that would require DVBv3
The cx23885-dvb driver has a dirty hack:
1) it hooks the DVBv3 legacy call to FE_SET_FRONTEND;
2) it uses internally the DVBv3 struct to decide some
configs.
Replace it by a change during the gate control. This will
likely work, but requires testing. Anyway, the current way
will break, as soon as we stop copying data for DVBv3 for
pure DVBv5 calls.
Compile-tested only.
Cc: Michael Krufky mkrufky linuxtv.org
Signed-off-by: Mauro Carvalho Chehab mchehab redhat.com
:04 04 6d0695eb9e59b837425ed64d4e2be6625864b609
89700b867069ec0ad2713367e607763e91798e98 M drivers
I manually removed the patch, then the TV card works.
Unfortunately my lack of knowledge prevents me fix it.
I test new code with pleasure :) !
Hi Alfredo,
Please send me the patches you've made to make isdb-t work on
it, and I'll try to address this issue.
Regards,
Mauro
Mauro thank you very much for your interest.
I send the patch. 3.2 is on a kernel.
---
.../{ = }/media/dvb/frontends/mb86a20s.c | 332
++--
Hmm... unfortunately, your emailer broke the patch. It made a total mess
with whitespaces. Could you please resend it in a way that whitespaces
won't be damaged? Otherwise, patch tool won't apply it.
Cheers,
Mauro
GR
I send attached, I hope it will not break this time.
This time it arrived fine, thanks!
Btw, those changes at mb86a20s are required for it to work, or just alters
somewhat the tuning?
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
Re: mb86a20s and cx23885
Hi El 01/08/13 15:48, Mauro Carvalho Chehab escribió: This time it arrived fine, thanks! Btw, those changes at mb86a20s are required for it to work, or just alters somewhat the tuning? Regards, Mauro Without these changes do not work. With the original controller I get: mb86a20s: mb86a20s_read_status: val = 9, status = 0x1f but not video, not sound. That is the reason why I tested with kernel 3.2. Those changes I got to sniff the i2c traffic under windows. I have all traffic from i2c until obtaining image(I did it as the more repetitive than 10 samples). If it helps something I put on the list. Also I use modprobe cx23885 debug = 3, but I saw nothing significant Thanks, Alfredo -- 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 El 17/07/13 16:23, Mauro Carvalho Chehab escribió: No. You'll need to clone the entire kernel tree (either Linus one or mine). The build system at the Kernel will rebuild an entire Kernel image. You'll then need to boot that new image. That takes some machine time, but, after the first compilation, the subsequent compilations are faster. I recommend you to use a minimal .config file for the compilation, as this speeds up a lot the time to compile the Kernel. Here, I use this small script to produce such mini-kernel: http://ftp.suse.com/pub/people/tiwai/misc/diet-kconfig After running it (and using the default for whatever question it asks me), I do a make menuconfig, to be sure that the media drivers and options I want are there. In summary, what I suggest is: $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git $ git checkout v3.2 $ git bisect good $ diet-kconfig $ make menuconfig select what is missed at media stuff $ make make modules install make install reboot after reboot check if everything is ok $ git bisect bad v3.4 repeat: $ make make modules install make install reboot it will likely ask you about some new drivers = it is generally safe to just let the default - just be more careful with the media menuconfig items test the kernel: if OK: $ git bisect good if BAD: $ git bisect bad if git bisect answers that there are xxx bisects left, then goto repeat After running the above, git bisect will put its fingers on the broken patch. Cheers, Mauro -- I found the patch that affects the X8507 board is: commit a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb alfredo@linux-puon:/usr/src/git/linux git stash Saved working directory and index state WIP on (no branch): c6f56e7 [media] dvb: don't use DVBv3 bandwidth macros HEAD is now at c6f56e7 [media] dvb: don't use DVBv3 bandwidth macros alfredo@linux-puon:/usr/src/git/linux git bisect good a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb is the first bad commit commit a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb Author: Mauro Carvalho Chehab mche...@redhat.com Date: Mon Dec 26 20:48:54 2011 -0300 [media] cx23885-dvb: Remove a dirty hack that would require DVBv3 The cx23885-dvb driver has a dirty hack: 1) it hooks the DVBv3 legacy call to FE_SET_FRONTEND; 2) it uses internally the DVBv3 struct to decide some configs. Replace it by a change during the gate control. This will likely work, but requires testing. Anyway, the current way will break, as soon as we stop copying data for DVBv3 for pure DVBv5 calls. Compile-tested only. Cc: Michael Krufky mkru...@linuxtv.org Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com :04 04 6d0695eb9e59b837425ed64d4e2be6625864b609 89700b867069ec0ad2713367e607763e91798e98 M drivers I manually removed the patch, then the TV card works. Unfortunately my lack of knowledge prevents me fix it. I test new code with pleasure :) ! Thanks, Alfredo -- 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 As was a compilation error, I used git bisect skip. From what I've come up with something that I think is not what I'm looking for. Is it advisable to do it again? and where you get an error trying to git bisect bad and see where it arrived and then git bisec good again. what I got was: ... alfredo@linux-puon:/usr/src/git/linux git stash Saved working directory and index state WIP on (no branch): a08d2c7 [media] pwc: Remove driver specific ioctls HEAD is now at a08d2c7 [media] pwc: Remove driver specific ioctls alfredo@linux-puon:/usr/src/git/linux git bisect bad Bisecting: 92 revisions left to test after this (roughly 7 steps) [38e3d7ce41cff58bacebb2bcecf7d386c60b954b] [media] cx23885: Ensure the MPEG encoder height is configured from the norm alfredo@linux-puon:/usr/src/git/linux ... alfredo@linux-puon:/usr/src/git/linux git stash Saved working directory and index state WIP on (no branch): 38e3d7c [media] cx23885: Ensure the MPEG encoder height is configured from the norm HEAD is now at 38e3d7c [media] cx23885: Ensure the MPEG encoder height is configured from the norm alfredo@linux-puon:/usr/src/git/linux git bisect bad Bisecting: 45 revisions left to test after this (roughly 6 steps) [f9e54512fd16379812bcff86d95d0a7d78028b20] [media] af9005-fe: convert set_fontend to use DVBv5 parameters alfredo@linux-puon:/usr/src/git/linux ... alfredo@linux-puon:/usr/src/git/linux git stash Saved working directory and index state WIP on (no branch): f9e5451 [media] af9005-fe: convert set_fontend to use DVBv5 parameters HEAD is now at f9e5451 [media] af9005-fe: convert set_fontend to use DVBv5 parameters alfredo@linux-puon:/usr/src/git/linux git bisect good Bisecting: 22 revisions left to test after this (roughly 5 steps) [8de8594a79ae43b08d115c94f09373f6c673f202] [media] dvb-core: be sure that drivers won't use DVBv3 internally alfredo@linux-puon:/usr/src/git/linux ... alfredo@linux-puon:/usr/src/git/linux make CHK include/linux/version.h CHK include/generated/utsrelease.h CALLscripts/checksyscalls.sh CHK include/generated/compile.h CHK kernel/config_data.h CC fs/compat_ioctl.o fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345:1: error: array type has incomplete element type fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345:1: error: array type has incomplete element type fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345:1: error: array type has incomplete element type fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346:1: error: array type has incomplete element type fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346:1: error: array type has incomplete element type fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346:1: error: array type has incomplete element type fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1347:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’ fs/compat_ioctl.c:1347:1: error: array type has incomplete element type fs/compat_ioctl.c:1347:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct
Re: mb86a20s and cx23885
Hi I forgot, in this section I put BAD because not have picture or sound, but if signal. alfredo@linux-puon:/usr/src/git/linux git stash Saved working directory and index state WIP on (no branch): 2827e1f [media] tlg2300: convert set_fontend to use DVBv5 parameters HEAD is now at 2827e1f [media] tlg2300: convert set_fontend to use DVBv5 parameters alfredo@linux-puon:/usr/src/git/linux git bisect bad /*apear tunner, but not tunner*/ Bisecting: 4 revisions left to test after this (roughly 3 steps) [4fa102d5cc5b412fa3bc7cc8c24e4d9052e4f693] [media] vp702x-fe: convert set_fontend to use DVBv5 parameters Is there a way to return to after with bisect without compile all? Thanks, Alfredo -- 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 It has given me the following error: alfredo@linux-puon:/usr/src/git/linux git stash Saved working directory and index state WIP on (no branch): f9e5451 [media] af9005-fe: convert set_fontend to use DVBv5 parameters HEAD is now at f9e5451 [media] af9005-fe: convert set_fontend to use DVBv5 parameters alfredo@linux-puon:/usr/src/git/linux git bisect good Bisecting: 22 revisions left to test after this (roughly 5 steps) [8de8594a79ae43b08d115c94f09373f6c673f202] [media] dvb-core: be sure that drivers won't use DVBv3 internally alfredo@linux-puon:/usr/src/git/linux make CHK include/linux/version.h CHK include/generated/utsrelease.h CALLscripts/checksyscalls.sh CHK include/generated/compile.h CHK kernel/config_data.h CC fs/compat_ioctl.o fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345:1: error: array type has incomplete element type fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345:1: error: array type has incomplete element type fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345:1: error: array type has incomplete element type fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346:1: error: array type has incomplete element type fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346:1: error: array type has incomplete element type fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346:1: error: array type has incomplete element type fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1347:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’ fs/compat_ioctl.c:1347:1: error: array type has incomplete element type fs/compat_ioctl.c:1347:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’ fs/compat_ioctl.c:1347:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’ fs/compat_ioctl.c:1347:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’ fs/compat_ioctl.c:1347:1: error: array type has incomplete element type fs/compat_ioctl.c:1347:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’ fs/compat_ioctl.c:1347:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’ fs/compat_ioctl.c:1347:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’ fs/compat_ioctl.c:1347:1: error: array type has incomplete element type fs/compat_ioctl.c:1347:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’ fs/compat_ioctl.c:1347:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’ make[1]: *** [fs/compat_ioctl.o] Error 1 make: *** [fs] Error 2 alfredo@linux-puon:/usr/src/git/linux --- What should I do now? I do not want experiment, since bisect is a very long process. Thank you, Alfredo -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a
Re: mb86a20s and cx23885
Hi all El 17/07/13 16:23, Mauro Carvalho Chehab escribió: No. You'll need to clone the entire kernel tree (either Linus one or mine). The build system at the Kernel will rebuild an entire Kernel image. You'll then need to boot that new image. That takes some machine time, but, after the first compilation, the subsequent compilations are faster. I recommend you to use a minimal .config file for the compilation, as this speeds up a lot the time to compile the Kernel. Here, I use this small script to produce such mini-kernel: http://ftp.suse.com/pub/people/tiwai/misc/diet-kconfig After running it (and using the default for whatever question it asks me), I do a make menuconfig, to be sure that the media drivers and options I want are there. In summary, what I suggest is: $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git $ git checkout v3.2 $ git bisect good $ diet-kconfig $ make menuconfig select what is missed at media stuff $ make make modules install make install reboot after reboot check if everything is ok $ git bisect bad v3.4 repeat: $ make make modules install make install reboot it will likely ask you about some new drivers = it is generally safe to just let the default - just be more careful with the media menuconfig items test the kernel: if OK: $ git bisect good if BAD: $ git bisect bad if git bisect answers that there are xxx bisects left, then goto repeat After running the above, git bisect will put its fingers on the broken patch. Thank you very much Mauro. A very clear explanation. Without it I do not think I could do well. When finished, I report back what I found Again, thank you very much, Alfredo -- 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 all El 15/07/13 17:30, Mauro Carvalho Chehab escribió: Em Mon, 15 Jul 2013 16:30:18 -0300 Alfredo Jesús Delaiti alfredodela...@netscape.net escreveu: Hi all After some time trying to see what the problem is, I have found it is not come the RF signal. I've gone back using a 3.2 kernel, after doing a couple of tests, the board works :-) When I try to apply these changes to a 3.4 or later kernel does not tune plate. Between 3.2 and 3.4 kernel there are several changes to the drivers: CX23885, xc5000 and mb86a20s. I tried to cancel several of them on a 3.4 kernel, but I can not make the card tune. If you know already that the breakage happened between 3.2 and 3.4, the better is to use git bisect to discover what patch broke it. Mauro Thanks for the suggestion. This weekend I have some time and I'll study how to implement it. I guess it's do something similar to: ~ $ git clone git://linuxtv.org/media_build.git ~ $ cd media_build ~/media_build $./build --main-git ~/media_build $ cd media ~/media $ gedit drivers/media/video/foo.c ~/media $ make -C ../v4l ~/media $ make -C ../ install ~/media $ make -C .. rmmod ~/media $ modprobe foo You can do (using Linus git tree): git checkout v3.4 git bisect bad git checkout good v3.2 Where is the git tree of Linus in git://git.kernel.org/ or git://linuxtv.org/? Thanks again, Alfredo git bisect will then do a binary search between those two kernels. All you have to do is to recompile the Kernel and test it. Then you'll tag the changeset as bad or good, until the end of the search. In general, you'll discover the changeset responsible for the breakage after a few (8-10) interactions. For more reference, you can take a look, for example, at: http://git-scm.com/book/en/Git-Tools-Debugging-with-Git Regards, Mauro PS.: Someone should fix our wiki, as it is still pointing to hg bisect, instead of pointing to git bisect. The changes I have applied to kernel 3.2 are: -- 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 Wed, 17 Jul 2013 10:54:19 -0300 Alfredo Jesús Delaiti alfredodela...@netscape.net escreveu: Hi all El 15/07/13 17:30, Mauro Carvalho Chehab escribió: Em Mon, 15 Jul 2013 16:30:18 -0300 Alfredo Jesús Delaiti alfredodela...@netscape.net escreveu: Hi all After some time trying to see what the problem is, I have found it is not come the RF signal. I've gone back using a 3.2 kernel, after doing a couple of tests, the board works :-) When I try to apply these changes to a 3.4 or later kernel does not tune plate. Between 3.2 and 3.4 kernel there are several changes to the drivers: CX23885, xc5000 and mb86a20s. I tried to cancel several of them on a 3.4 kernel, but I can not make the card tune. If you know already that the breakage happened between 3.2 and 3.4, the better is to use git bisect to discover what patch broke it. Mauro Thanks for the suggestion. This weekend I have some time and I'll study how to implement it. I guess it's do something similar to: ~ $ git clone git://linuxtv.org/media_build.git ~ $ cd media_build ~/media_build $./build --main-git ~/media_build $ cd media ~/media $ gedit drivers/media/video/foo.c ~/media $ make -C ../v4l ~/media $ make -C ../ install ~/media $ make -C .. rmmod ~/media $ modprobe foo No. You'll need to clone the entire kernel tree (either Linus one or mine). The build system at the Kernel will rebuild an entire Kernel image. You'll then need to boot that new image. That takes some machine time, but, after the first compilation, the subsequent compilations are faster. I recommend you to use a minimal .config file for the compilation, as this speeds up a lot the time to compile the Kernel. Here, I use this small script to produce such mini-kernel: http://ftp.suse.com/pub/people/tiwai/misc/diet-kconfig After running it (and using the default for whatever question it asks me), I do a make menuconfig, to be sure that the media drivers and options I want are there. In summary, what I suggest is: $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git $ git checkout v3.2 $ git bisect good $ diet-kconfig $ make menuconfig select what is missed at media stuff $ make make modules install make install reboot after reboot check if everything is ok $ git bisect bad v3.4 repeat: $ make make modules install make install reboot it will likely ask you about some new drivers = it is generally safe to just let the default - just be more careful with the media menuconfig items test the kernel: if OK: $ git bisect good if BAD: $ git bisect bad if git bisect answers that there are xxx bisects left, then goto repeat After running the above, git bisect will put its fingers on the broken patch. You can do (using Linus git tree): git checkout v3.4 git bisect bad git checkout good v3.2 Where is the git tree of Linus in git://git.kernel.org/ or git://linuxtv.org/? Thanks again, Alfredo git bisect will then do a binary search between those two kernels. All you have to do is to recompile the Kernel and test it. Then you'll tag the changeset as bad or good, until the end of the search. In general, you'll discover the changeset responsible for the breakage after a few (8-10) interactions. For more reference, you can take a look, for example, at: http://git-scm.com/book/en/Git-Tools-Debugging-with-Git Regards, Mauro PS.: Someone should fix our wiki, as it is still pointing to hg bisect, instead of pointing to git bisect. The changes I have applied to kernel 3.2 are: Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mb86a20s and cx23885
Hi all
After some time trying to see what the problem is, I have found it is
not come the RF signal.
I've gone back using a 3.2 kernel, after doing a couple of tests, the
board works :-)
When I try to apply these changes to a 3.4 or later kernel does not tune
plate.
Between 3.2 and 3.4 kernel there are several changes to the drivers:
CX23885, xc5000 and mb86a20s. I tried to cancel several of them on a 3.4
kernel, but I can not make the card tune.
The changes I have applied to kernel 3.2 are:
In mb86a20s.c, I replaced the table mb86a20s_init for which I got from
windows and linux last.
With the two works, although it seems better that I got from Windows, I
have to experiment a bit more.
Also in Does a binary search to get RF strength I replaced 0x04 for 0x05.
On cx23885-card.c
.name = Mygica X8507,
.tuner_type = TUNER_XC5000,
.tuner_addr = 0x61,
.tuner_bus = 1,
.porta = CX23885_ANALOG_VIDEO,
+.portb= CX23885_MPEG_DVB,
.input = {
case CX23885_BOARD_MYGICA_X8506:
case CX23885_BOARD_MAGICPRO_PROHDTVE2:
+case CX23885_BOARD_MYGICA_X8507:
ts1-gen_ctrl_val = 0x5; /* Parallel */
ts1-ts_clk_en_val = 0x1; /* Enable TS_CLK */
ts1-src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
break;
On cx23885-dvb.c
#include stv0367.h
+#include mb86a20s.h
+static struct mb86a20s_config mygica_x8507_mb86a20s_config = {
+.demod_address = 0x10,
+};
+
+static struct xc5000_config mygica_x8507_xc5000_config = {
+.i2c_address = 0x61,
+.if_khz = 4000,
+};
case CX23885_BOARD_MYGICA_X8506:
case CX23885_BOARD_MAGICPRO_PROHDTVE2:
+case CX23885_BOARD_MYGICA_X8507:
/* Select Digital TV */
cx23885_gpio_set(dev, GPIO_0);
break;
+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);
+}
+break;
With kernel 3.4 or greater (I also tried with the latest drivers from
git) looking i2c bus traffic of mb86a20s I get:
0x20 0x0a 0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x07 0x20 0x04 0x20 0x20 0x05 0xff 0x20 0x02
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x03 0x20 0x04 0x20 0x20 0x05 0xff 0x20 0x02
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x01 0x20 0x04 0x20 0x20 0x05 0xff 0x20 0x02
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0xff 0x20 0x02
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x7f 0x20 0x04
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x3f 0x20 0x02
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x1f 0x20 0x02
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x0f 0x20 0x02
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x07 0x20 0x02
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x03 0x20 0x02
0x21 0x0a
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x05 0x20 0x02
0x21 0x0a
0x20 0x0a 0x21 0x02
and the kernel 3.2 and windows
0x20 0x02 0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x03 0x20 0x04 0x20 0x20 0x05 0xff 0x20 0x02
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x01 0x20 0x04 0x20 0x20 0x05 0xff 0x20 0x02
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0xff 0x20 0x02
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x7f 0x20 0x02
0x21 0x0a
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0xbf 0x20 0x02
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x9f 0x20 0x02
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x3c 0x40 0x04
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x87 0x20 0x02
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x83 0x20 0x02
0x21 0x0a
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x85 0x20 0x02
0x21 0x02
Appear not arrived RF signal.
From my limited knowledge I can not understand which of the changes
between 3.2 and 3.4 kernel affect this.
As with kernel 3.2 works, discard configuration problems of: GPIO,
signal strength, direction i2c bus and demodulator and intermediate
frequency. I am right?
Any suggestions or help is very welcome.
Thanks in advance,
Alfredo
--
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 Mon, 15 Jul 2013 16:30:18 -0300
Alfredo Jesús Delaiti alfredodela...@netscape.net escreveu:
Hi all
After some time trying to see what the problem is, I have found it is
not come the RF signal.
I've gone back using a 3.2 kernel, after doing a couple of tests, the
board works :-)
When I try to apply these changes to a 3.4 or later kernel does not tune
plate.
Between 3.2 and 3.4 kernel there are several changes to the drivers:
CX23885, xc5000 and mb86a20s. I tried to cancel several of them on a 3.4
kernel, but I can not make the card tune.
If you know already that the breakage happened between 3.2 and 3.4, the better
is to use git bisect to discover what patch broke it.
You can do (using Linus git tree):
git checkout v3.4
git bisect bad
git checkout good v3.2
git bisect will then do a binary search between those two kernels. All you
have to do is to recompile the Kernel and test it. Then you'll tag the
changeset as bad or good, until the end of the search. In general, you'll
discover the changeset responsible for the breakage after a few (8-10)
interactions.
For more reference, you can take a look, for example, at:
http://git-scm.com/book/en/Git-Tools-Debugging-with-Git
Regards,
Mauro
PS.: Someone should fix our wiki, as it is still pointing to hg bisect,
instead of pointing to git bisect.
The changes I have applied to kernel 3.2 are:
In mb86a20s.c, I replaced the table mb86a20s_init for which I got from
windows and linux last.
With the two works, although it seems better that I got from Windows, I
have to experiment a bit more.
Also in Does a binary search to get RF strength I replaced 0x04 for 0x05.
On cx23885-card.c
.name = Mygica X8507,
.tuner_type = TUNER_XC5000,
.tuner_addr = 0x61,
.tuner_bus = 1,
.porta = CX23885_ANALOG_VIDEO,
+.portb= CX23885_MPEG_DVB,
.input = {
case CX23885_BOARD_MYGICA_X8506:
case CX23885_BOARD_MAGICPRO_PROHDTVE2:
+case CX23885_BOARD_MYGICA_X8507:
ts1-gen_ctrl_val = 0x5; /* Parallel */
ts1-ts_clk_en_val = 0x1; /* Enable TS_CLK */
ts1-src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
break;
On cx23885-dvb.c
#include stv0367.h
+#include mb86a20s.h
+static struct mb86a20s_config mygica_x8507_mb86a20s_config = {
+.demod_address = 0x10,
+};
+
+static struct xc5000_config mygica_x8507_xc5000_config = {
+.i2c_address = 0x61,
+.if_khz = 4000,
+};
case CX23885_BOARD_MYGICA_X8506:
case CX23885_BOARD_MAGICPRO_PROHDTVE2:
+case CX23885_BOARD_MYGICA_X8507:
/* Select Digital TV */
cx23885_gpio_set(dev, GPIO_0);
break;
+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);
+}
+break;
With kernel 3.4 or greater (I also tried with the latest drivers from
git) looking i2c bus traffic of mb86a20s I get:
0x20 0x0a 0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x07 0x20 0x04 0x20 0x20 0x05 0xff 0x20 0x02
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x03 0x20 0x04 0x20 0x20 0x05 0xff 0x20 0x02
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x01 0x20 0x04 0x20 0x20 0x05 0xff 0x20 0x02
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0xff 0x20 0x02
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x7f 0x20 0x04
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x3f 0x20 0x02
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x1f 0x20 0x02
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x0f 0x20 0x02
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x07 0x20 0x02
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x03 0x20 0x02
0x21 0x0a
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x05 0x20 0x02
0x21 0x0a
0x20 0x0a 0x21 0x02
and the kernel 3.2 and windows
0x20 0x02 0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x03 0x20 0x04 0x20 0x20 0x05 0xff 0x20 0x02
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x01 0x20 0x04 0x20 0x20 0x05 0xff 0x20 0x02
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0xff 0x20 0x02
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x7f 0x20 0x02
0x21 0x0a
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0xbf 0x20 0x02
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x9f 0x20 0x02
0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x3c 0x40
Re: mb86a20s and cx23885
Hi all
After analyzing 15 samples (took me many days),I obtained the table
underneath.
{ 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 },
{ 0x04, 0x0f }, { 0x05, 0x32 },
{ 0x04, 0x0b }, { 0x05, 0x78 },
{ 0x04, 0x00 }, { 0x05, 0x00 },
{ 0x04, 0x01 }, { 0x05, 0x1e },
{ 0x04, 0x02 }, { 0x05, 0x07 },
{ 0x04, 0x03 }, { 0x05, 0xd0 },
{ 0x04, 0x09 }, { 0x05, 0x00 },
{ 0x04, 0x0a }, { 0x05, 0xff },
{ 0x04, 0x27 }, { 0x05, 0x00 },
{ 0x04, 0x28 }, { 0x05, 0x00 },
{ 0x04, 0x1e }, { 0x05, 0x00 },
{ 0x04, 0x29 }, { 0x05, 0x64 },
{ 0x04, 0x32 }, { 0x05, 0x64 },
{ 0x04, 0x14 }, { 0x05, 0x02 },
{ 0x04, 0x04 }, { 0x05, 0x00 },
{ 0x04, 0x05 }, { 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, 0xff },
{ 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 },
{ 0x50, 0xdf }, { 0x51, 0xff },
{ 0x50, 0xe0 }, { 0x51, 0x3f },
{ 0x50, 0xe1 }, { 0x51, 0xff },
{ 0x50, 0xb0 }, { 0x51, 0x07 },
{ 0x50, 0xb2 }, { 0x51, 0x3f },
{ 0x50, 0xb3 }, { 0x51, 0xff },
{ 0x50, 0xb4 }, { 0x51, 0x3f },
{ 0x50, 0xb5 }, { 0x51, 0xff },
{ 0x50, 0xb6 }, { 0x51, 0x3f },
{ 0x50, 0xb7 }, { 0x51, 0xff },
{ 0x50, 0x51 }, { 0x51, 0x04 },
{ 0x50, 0x50 }, { 0x51, 0x02 },
{ 0x45, 0x04 },
{ 0x48, 0x04 },
{ 0x50, 0xd5 }, { 0x51, 0x00 },
{ 0x50, 0xd6 }, { 0x51, 0x1f },
{ 0x50, 0xd2 }, { 0x51, 0x03 },
{ 0x50, 0xd7 }, { 0x51, 0x3f },
{ 0x28, 0x74 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0xff },
{ 0x28, 0x46 }, { 0x29, 0x00 }, { 0x2a, 0x1a }, { 0x2b, 0x0c },
{ 0x04, 0x40 }, { 0x05, 0x00 },
{ 0x28, 0x00 }, { 0x2b, 0x08 },
{ 0x28, 0x05 }, { 0x2b, 0x00 },
{ 0x1c, 0x01 },
{ 0x28, 0x06 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x1f },
{ 0x28, 0x07 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x18 },
{ 0x28, 0x08 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x12 },
{ 0x28, 0x09 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x30 },
{ 0x28, 0x0a }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x37 },
{ 0x28, 0x0b }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x02 },
{ 0x28, 0x0c }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x09 },
{ 0x28, 0x0d }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x06 },
{ 0x28, 0x0e }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x7b },
{ 0x28, 0x0f }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x76 },
{ 0x28, 0x10 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x7d },
{ 0x28, 0x11 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x08 },
{ 0x28, 0x12 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x0b },
{ 0x28, 0x13 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x00 },
{ 0x28, 0x14 }, { 0x29, 0x00 }, { 0x2a, 0x01 }, { 0x2b, 0xf2 },
{ 0x28, 0x15 }, { 0x29, 0x00 }, { 0x2a, 0x01 }, { 0x2b, 0xf3 },
{ 0x28, 0x16 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x05 },
{ 0x28, 0x17 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x16 },
{ 0x28, 0x18 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x0f },
{ 0x28, 0x19 }, { 0x29, 0x00 }, { 0x2a, 0x07 }, { 0x2b, 0xef },
{ 0x28, 0x1a }, { 0x29, 0x00 }, { 0x2a, 0x07 }, { 0x2b, 0xd8 },
{ 0x28, 0x1b }, { 0x29, 0x00 }, { 0x2a, 0x07 }, { 0x2b, 0xf1 },
{ 0x28, 0x1c }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x3d },
{ 0x28, 0x1d }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x94 },
{ 0x28, 0x1e }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0xba },
{ 0x50, 0x1e }, { 0x51, 0x5d },
{ 0x50, 0x22 }, { 0x51, 0x00 },
{ 0x50, 0x23 }, { 0x51, 0xc8 },
{ 0x50, 0x24 }, { 0x51, 0x00 },
{ 0x50, 0x25 }, { 0x51, 0xf0 },
{ 0x50, 0x26 }, { 0x51, 0x00 },
{ 0x50, 0x27 }, { 0x51, 0xc3 },
{ 0x50, 0x39 }, { 0x51, 0x02 },
It has very few changes from the one that comes with the controller, but
when trying to use it I get the following:
{ 0x70, 0x0f },
{ 0x70, 0xff },
{ 0x09, 0x3a },
{ 0x50, 0xd1 }, { 0x51, 0x22 },
{ 0x09, 0x3e }, /* This line is inserted alone. Initialize
the frontend? */
{ 0x39, 0x01 }, /* This line is inserted alone. Initialize
the frontend? */
{ 0x71,
Re: mb86a20s and cx23885
Hi all Sorry for late reply, it's because only I can do during my free time. El 04/03/13 23:30, Mauro Carvalho Chehab escribió: I test, but not work. Before the latest patches, obtained as follows, for example: dmesg [ 397.076641] mb86a20s: mb86a20s_read_status: [ 397.077129] mb86a20s: mb86a20s_read_status: val = X, status = 0xXX I did a cleanup at the printk messages. Also, the debug ones now use dynamic_printk. That means that they're disabled by default. They can be enabled in runtime (and per-line). If you want to enable all messages, you can do: To enable all debug messages on mb86a20s: echo file drivers/media/dvb-frontends/mb86a20s.c +p /sys/kernel/debug/dynamic_debug/control To clean all debug messages echo -p /sys/kernel/debug/dynamic_debug/control I think I made something wrong, because I only get this: /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:2089 [mb86a20s]mb86a20s_attach =_ %s called.\012 /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:2117 [mb86a20s]mb86a20s_attach =_ Frontend revision %d is unknown - aborting.\012 /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:1970 [mb86a20s]mb86a20s_read_status_and_stats =_ %s called.\012 /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:327 [mb86a20s]mb86a20s_read_status =_ %s: Status = 0x%02x (state = %d)\012 /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:381 [mb86a20s]mb86a20s_read_signal_strength =_ %s: signal strength = %d (%d RF=%d %d)\012 /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:526 [mb86a20s]mb86a20s_reset_frontend_cache =_ %s called.\012 /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:653 [mb86a20s]mb86a20s_get_frontend =_ %s called.\012 /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:671 [mb86a20s]mb86a20s_get_frontend =_ %s: getting data for layer %c.\012 /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:688 [mb86a20s]mb86a20s_get_frontend =_ %s: modulation %d.\012 /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:694 [mb86a20s]mb86a20s_get_frontend =_ %s: FEC %d.\012 /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:700 [mb86a20s]mb86a20s_get_frontend =_ %s: interleaving %d.\012 /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:503 [mb86a20s]mb86a20s_get_segment_count =_ %s called.\012 /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:516 [mb86a20s]mb86a20s_get_segment_count =_ %s: segments: %d.\012 /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:641 [mb86a20s]mb86a20s_layer_bitrate =_ %s: layer %c bitrate: %d kbps; counter = %d (0x%06x)\012 /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:1605 [mb86a20s]mb86a20s_get_stats =_ %s called.\012 /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:1419 [mb86a20s]mb86a20s_get_main_CNR =_ %s: CNR is not available yet.\012 /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:1441 [mb86a20s]mb86a20s_get_main_CNR =_ %s: CNR is %d.%03d dB (%d)\012 /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:1461 [mb86a20s]mb86a20s_get_blk_error_layer_CNR =_ %s called.\012 /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:1474 [mb86a20s]mb86a20s_get_blk_error_layer_CNR =_ %s: MER measures aren't available yet.\012 /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:1530 [mb86a20s]mb86a20s_get_blk_error_layer_CNR =_ %s: CNR for layer %c is %d.%03d dB (MER = %d).\012 /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:829 [mb86a20s]mb86a20s_get_pre_ber =_ %s called.\012 /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:843 [mb86a20s]mb86a20s_get_pre_ber =_ %s: preBER for layer %c is not available yet.\012 /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:863 [mb86a20s]mb86a20s_get_pre_ber =_ %s: bit error before Viterbi for layer %c: %d.\012 /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:890 [mb86a20s]mb86a20s_get_pre_ber =_ %s: bit count before Viterbi for layer %c: %d.\012 /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:904 [mb86a20s]mb86a20s_get_pre_ber =_ %s: updating layer %c preBER counter to %d.\012 /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:963 [mb86a20s]mb86a20s_get_post_ber =_ %s called.\012 /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:977 [mb86a20s]mb86a20s_get_post_ber =_ %s: post BER for layer %c is not available yet.\012 /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:997 [mb86a20s]mb86a20s_get_post_ber =_ %s: post bit error for layer %c: %d.\012 /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:1018 [mb86a20s]mb86a20s_get_post_ber =_ %s: post bit count for layer %c: %d.\012 /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:1038 [mb86a20s]mb86a20s_get_post_ber =_ %s: updating postBER counter on layer %c
Re: mb86a20s and cx23885
Em Sun, 3 Mar 2013 13:40:51 -0300
Mauro Carvalho Chehab mche...@redhat.com escreveu:
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.
It controls inversion. I just pushed a patch that will let it handle
both normal and inverted spectrum. The DVB core will automatically
switch inversion during device tuning.
{ 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.
I also added a patch that allows using a different XTAL frequency.
You can use the calculus there to convert from 0x00fdc8 into the XTAL
frequency, if you have the IF set by xc5000.
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
Re: mb86a20s and cx23885
Hi Mauro and others
El 03/03/13 13:15, Mauro Carvalho Chehab escribió:
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,
Yes, logic analyzer said:
Write to PCF8574 at address 0
and IC that not have name on TV card have the form and number of pin
that pcf8574
also EEPROM FM24C02
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.
I tested all patches (those of yesterday and today), but it did not work.
I have not yet seen the changes with the logic analyzer.
/*
* 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?
Not yet.
Below I put two different early (on Windows 7)
-
0.178147 - Start
0.262532 - b0011 - 0x21 - 33
0.271909 - ACK
0.356294 - b00010011 - 0x13 - 19
0.367545 - NACK
0.517564 - b - 0x00 - 0
0.528815 - ACK
0.613201 - b1110 - 0xe0 - 224
0.622577 - ACK
0.703212 - b0000 - 0x1e - 30
0.718214 - Stop
0.84573 - b0010 - 0x20 - 32
0.856981 - ACK
0.941366 - b0111 - 0x70 - 112
0.950743 - ACK
1.03888 - b - 0xff - 255
1.04825 - ACK
1.16077 - b0010 - 0x20 - 32
1.17202 - ACK
1.25828 - b1001 - 0x09 - 9
1.26766 - ACK
1.35017 - b00111010 - 0x3a - 58
1.36142 - ACK
1.50206 - b0010 - 0x20 - 32
1.51331 - ACK
1.59957 - b0101 - 0x50 - 80
1.61082 - ACK
1.79085 - Write to PCF8574 at address 0
1.79085 - b0100 - 0x40 - 64
1.80022 - ACK
1.88461 - b10100010 - 0xa2 - 162
1.89398 - ACK
1.98024 - b01000100 - 0x44 - 68
1.99525 - Error
2.029 - Start
2.12089 -
Re: mb86a20s and cx23885
Hi all
El 04/03/13 16:42, Mauro Carvalho Chehab escribió:
Em Sun, 3 Mar 2013 13:40:51 -0300
Mauro Carvalho Chehab mche...@redhat.com escreveu:
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.
It controls inversion. I just pushed a patch that will let it handle
both normal and inverted spectrum. The DVB core will automatically
switch inversion during device tuning.
I test, but not work.
Before the latest patches, obtained as follows, for example:
dmesg
[ 397.076641] mb86a20s: mb86a20s_read_status:
[ 397.077129] mb86a20s: mb86a20s_read_status: val = X, status = 0xXX
and now, I don't get anything. But if I use VLC I get this:
dtvdebug: frontend status: 0x00
dtvdebug: frontend status: 0x03
dtvdebug: frontend status: 0x07
dtvdebug: frontend status: 0x01
Before only got:
dtvdebug: frontend status: 0x00
dtvdebug: frontend status: 0x01
{ 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.
I also added a patch that allows using a different XTAL frequency.
You can use the calculus there to convert from 0x00fdc8 into the XTAL
frequency, if you have the IF set by xc5000.
I don't have the IF. How I can know the intermediate frequency?
Xtal near of xc5000 is 32.000MHz. Perhaps 32/8=4 --IF
There are other 2 xtal of 16.000MHz and other of 28.636MHz.
Xtal of mb86a20s is 32.571MHz.
In total there are 4 xtal.
With mb86a20s changes made, the logs (i2c traffic) obtained are
different from those obtained with Windows
I have yet to thoroughly analyze 24 samples I took with the logic
analyzer and try to see your logic. This is going to take some time.
Again thank you very much,
Alfredo
--
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 Mon, 04 Mar 2013 21:00:17 -0300
Alfredo Jesús Delaiti alfredodela...@netscape.net escreveu:
Hi all
El 04/03/13 16:42, Mauro Carvalho Chehab escribió:
Em Sun, 3 Mar 2013 13:40:51 -0300
Mauro Carvalho Chehab mche...@redhat.com escreveu:
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.
It controls inversion. I just pushed a patch that will let it handle
both normal and inverted spectrum. The DVB core will automatically
switch inversion during device tuning.
I test, but not work.
Before the latest patches, obtained as follows, for example:
dmesg
[ 397.076641] mb86a20s: mb86a20s_read_status:
[ 397.077129] mb86a20s: mb86a20s_read_status: val = X, status = 0xXX
I did a cleanup at the printk messages. Also, the debug ones now use
dynamic_printk. That means that they're disabled by default. They can
be enabled in runtime (and per-line). If you want to enable all messages,
you can do:
To enable all debug messages on mb86a20s:
echo file drivers/media/dvb-frontends/mb86a20s.c +p
/sys/kernel/debug/dynamic_debug/control
To clean all debug messages
echo -p /sys/kernel/debug/dynamic_debug/control
To enable just the *ber* or *BER* ones:
for i in $(cat /sys/kernel/debug/dynamic_debug/control|grep
mb86a20s.c|grep -i ber|cut -d' ' -f 1|cut -d: -f2); do
echo file drivers/media/dvb-frontends/mb86a20s.c line $i +p
/sys/kernel/debug/dynamic_debug/control
done
and now, I don't get anything. But if I use VLC I get this:
dtvdebug: frontend status: 0x00
dtvdebug: frontend status: 0x03
dtvdebug: frontend status: 0x07
dtvdebug: frontend status: 0x01
Ok, that means that it is trying to sync Viterbi. You're better served if you
use dvbv5-scan[1], instead, as it will provide you more information (eventually
CNR - if it can keep status = 0x07 for a while, or if you have a zap file:
$ dvbv5-zap -I zap -c ~/isdb_channel.conf globo 1seg
using demux '/dev/dvb/adapter0/demux0'
reading channels from file '/home/mchehab/isdb_channel.conf'
tuning to 485142857 Hz
video pid 529
dvb_set_pesfilter 529
audio pid 530
dvb_set_pesfilter 530
RF (0x01) Signal= 0.00%
RF (0x01) Signal= 0.00%
RF (0x01) Signal= 0.00%
Carrier(0x03) Signal= 0.00%
RF (0x01) Signal= 0.00%
RF (0x01) Signal= 0.00%
Lock (0x1f) Quality= Poor Signal= 6.25% C/N= 15.57dB UCB= 96965 postBER= 0
preBER= 3.08x10^-3 PER= 1.00
Layer A: Quality= Poor C/N= 15.52dB UCB= 4064 postBER= 0 preBER=
3.08x10^-3 PER= 1.00
Layer B: C/N= 30.00dB
I think I asked it already, but eventually, it is just antenna.
[1]
http://git.linuxtv.org/v4l-utils.git/blob/192d27e53f09924e9ec3150ae146df86da178f02:/utils/dvb/dvbv5-scan.c
{ 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.
I also added a patch that allows using a different XTAL frequency.
You can use the calculus there to convert from 0x00fdc8 into the XTAL
frequency, if you have the IF set by xc5000.
I don't have the IF. How I can know the intermediate frequency?
Xtal near of xc5000 is 32.000MHz. Perhaps 32/8=4 --IF
The easiest way to discover is to enable the mb86a20s debug:
[ 1443.564782] i2c i2c-3: mb86a20s_initfe: fclk=32571428, IF=400, clock
reg=0x00ff80
[ 1443.566781] i2c i2c-3: mb86a20s_initfe: IF=400, IF reg=0x3ee08f
The IF here come from the tuner, via ops.get_if_frequency().
There are other 2 xtal of 16.000MHz and other of 28.636MHz.
Xtal of mb86a20s is 32.571MHz.
That seems to be the standard xtal.
In total there are 4 xtal.
With mb86a20s changes made, the logs (i2c traffic) obtained are
different from those obtained with Windows
I have yet to thoroughly analyze 24 samples I took with the logic
analyzer and try to see your logic. This is going to take some time.
Again thank you very much,
Alfredo
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at
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: 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
Re: mb86a20s and cx23885
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:
http://git.linuxtv.org/v4l-utils.git/tree/HEAD:/contrib/pci_traffic
I documented what it was needed to sniff the traffic at:
