[Patch] Kworld 315U remote support part2
Here is the rest of the patch for the Kworld remote support. Hopefully I got all the formatting correct this time. Signed-off-by: Franklin Meng fmeng2...@yahoo.com diff -r 14021dfc00f3 linux/drivers/media/video/em28xx/em28xx-cards.c --- a/linux/drivers/media/video/em28xx/em28xx-cards.c Thu Feb 11 23:11:30 2010 -0200 +++ b/linux/drivers/media/video/em28xx/em28xx-cards.c Fri Feb 12 21:31:41 2010 -0800 @@ -1329,6 +1329,7 @@ .decoder= EM28XX_SAA711X, .has_dvb= 1, .dvb_gpio = em2882_kworld_315u_digital, + .ir_codes = ir_codes_kworld_315u_table, .xclk = EM28XX_XCLK_FREQUENCY_12MHZ, .i2c_speed = EM28XX_I2C_CLK_WAIT_ENABLE, /* Analog mode - still not ready */ diff -r 14021dfc00f3 linux/include/media/ir-common.h --- a/linux/include/media/ir-common.h Thu Feb 11 23:11:30 2010 -0200 +++ b/linux/include/media/ir-common.h Fri Feb 12 21:31:41 2010 -0800 @@ -163,4 +163,5 @@ extern struct ir_scancode_table ir_codes_gadmei_rm008z_table; extern struct ir_scancode_table ir_codes_nec_terratec_cinergy_xs_table; extern struct ir_scancode_table ir_codes_winfast_usbii_deluxe_table; +extern struct ir_scancode_table ir_codes_kworld_315u_table; #endif -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch/Resend] Kworld 315U remote support
Mauro Carvalho Chehab wrote: Well, it is not a resend, since changes were made ;) Yup I guess that is true.. It also looks like I forgot to include the patch to actually enable the remote for the Kworld 315U device. I should have some time tonight to get that one line change sent out. Thanks, Franklin Meng -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch] Kworld 315U remote support
Mauro,
I tried out the ir_type change to the code and when I set it to IR_TYPE_NEC, I
see messages in the log indicating that the key was not recognized. Using
IR_TYPE_OTHER seems to work ok.
My guess is that if I modify the keycodes IR_TYPE_NEC will work as well. Can I
just use IR_TYPE_OTHER? That seems like the most straight forward approach
with the least amount of changes.
Thanks,
Franklin Meng
--- On Mon, 2/8/10, Mauro Carvalho Chehab mauroche...@gmail.com wrote:
From: Mauro Carvalho Chehab mauroche...@gmail.com
Subject: Re: [Patch] Kworld 315U remote support
To: Franklin Meng fmeng2...@yahoo.com
Cc: Douglas Schilling dougsl...@gmail.com, maillist
linux-media@vger.kernel.org
Date: Monday, February 8, 2010, 5:13 AM
Franklin Meng wrote:
This patch adds remote support for the Kworld 315U
device
Note: I believe I got most of the mappings
correct. Though the
source and shutdown button probably could be mapped to
something
better.
To be done: Still need to get the Kworld analog patch
resubmitted.
There are still some stuff I want to test with the
analog patch before
I resubmit it. Hopefully this patch will work
ok.
Please let me know if there are any issues applying
the patch
Hi Franklin,
Could you please add a table with the full scan code?
There are currently two examples of such tables:
ir_codes_rc5_hauppauge_new_table - for
RC5 keycodes
ir_codes_nec_terratec_cinergy_xs_table -
for NEC keycodes
Basically, a full scan code has a 2-byte code instead of
1-byte,
and you need to specify the protocol at the table, like:
struct ir_scancode_table
ir_codes_nec_terratec_cinergy_xs_table = {
.scan =
ir_codes_nec_terratec_cinergy_xs,
.size =
ARRAY_SIZE(ir_codes_nec_terratec_cinergy_xs),
.ir_type = IR_TYPE_NEC,
};
The em28xx is already prepared to properly handle the
protocol.
the advantage of using a full table is that it is easy to
replace
the keytable and even the protocol if someone wants to use
a different
Remote Controller to control the device.
As you've declared this xclk:
.xclk =
EM28XX_XCLK_FREQUENCY_12MHZ,
I suspect that your keycode is of the type NEC.
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
--
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/Resend] Kworld 315U remote support
This patch adds remote support for the Kworld 315U device
I have added the change for the IR_TYPE_NEC that Mauro suggested.
Note: I believe I got most of the mappings correct. Though the
source and shutdown button probably could be mapped to something
better.
To be done: Still need to get the Kworld analog patch resubmitted.
There are still some stuff I want to test with the analog patch before
I resubmit it. Hopefully this patch will work ok.
Please let me know if there are any issues applying the patch
Signed-off-by: Franklin Meng fmeng2...@yahoo.com
diff -r 28f5eca12bb0 linux/drivers/media/IR/ir-keymaps.c
--- a/linux/drivers/media/IR/ir-keymaps.c Sat Feb 06 23:49:31 2010 -0200
+++ b/linux/drivers/media/IR/ir-keymaps.c Wed Feb 10 21:43:49 2010 -0800
@@ -3501,3 +3501,53 @@
.size = ARRAY_SIZE(ir_codes_winfast_usbii_deluxe),
};
EXPORT_SYMBOL_GPL(ir_codes_winfast_usbii_deluxe_table);
+
+/* Kworld 315U
+*/
+static struct ir_scancode ir_codes_kworld_315u[] = {
+ { 0x6143, KEY_POWER },
+ { 0x6101, KEY_TUNER }, /* source */
+ { 0x610b, KEY_ZOOM },
+ { 0x6103, KEY_POWER2 }, /* shutdown */
+
+ { 0x6104, KEY_1 },
+ { 0x6108, KEY_2 },
+ { 0x6102, KEY_3 },
+ { 0x6109, KEY_CHANNELUP },
+
+ { 0x610f, KEY_4 },
+ { 0x6105, KEY_5 },
+ { 0x6106, KEY_6 },
+ { 0x6107, KEY_CHANNELDOWN },
+
+ { 0x610c, KEY_7 },
+ { 0x610d, KEY_8 },
+ { 0x610a, KEY_9 },
+ { 0x610e, KEY_VOLUMEUP },
+
+ { 0x6110, KEY_LAST },
+ { 0x6111, KEY_0 },
+ { 0x6112, KEY_ENTER },
+ { 0x6113, KEY_VOLUMEDOWN },
+
+ { 0x6114, KEY_RECORD },
+ { 0x6115, KEY_STOP },
+ { 0x6116, KEY_PLAY },
+ { 0x6117, KEY_MUTE },
+
+ { 0x6118, KEY_UP },
+ { 0x6119, KEY_DOWN },
+ { 0x611a, KEY_LEFT },
+ { 0x611b, KEY_RIGHT },
+
+ { 0x611c, KEY_RED },
+ { 0x611d, KEY_GREEN },
+ { 0x611e, KEY_YELLOW },
+ { 0x611f, KEY_BLUE },
+};
+struct ir_scancode_table ir_codes_kworld_315u_table = {
+ .scan = ir_codes_kworld_315u,
+ .size = ARRAY_SIZE(ir_codes_kworld_315u),
+ .ir_type = IR_TYPE_NEC,
+};
+EXPORT_SYMBOL_GPL(ir_codes_kworld_315u_table);
--
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] Kworld 315U remote support
This patch adds remote support for the Kworld 315U device
Note: I believe I got most of the mappings correct. Though the
source and shutdown button probably could be mapped to something
better.
To be done: Still need to get the Kworld analog patch resubmitted.
There are still some stuff I want to test with the analog patch before
I resubmit it. Hopefully this patch will work ok.
Please let me know if there are any issues applying the patch
Signed-off-by: Franklin Meng fmeng2...@yahoo.com
diff -r 28f5eca12bb0 linux/drivers/media/IR/ir-keymaps.c
--- a/linux/drivers/media/IR/ir-keymaps.c Sat Feb 06 23:49:31 2010 -0200
+++ b/linux/drivers/media/IR/ir-keymaps.c Sun Feb 07 11:35:39 2010 -0800
@@ -3501,3 +3501,52 @@
.size = ARRAY_SIZE(ir_codes_winfast_usbii_deluxe),
};
EXPORT_SYMBOL_GPL(ir_codes_winfast_usbii_deluxe_table);
+
+/* Kworld 315U
+*/
+static struct ir_scancode ir_codes_kworld_315u[] = {
+ { 0x43, KEY_POWER },
+ { 0x01, KEY_TUNER },/* source */
+ { 0x0b, KEY_ZOOM },
+ { 0x03, KEY_POWER2 }, /* shutdown */
+
+ { 0x04, KEY_1 },
+ { 0x08, KEY_2 },
+ { 0x02, KEY_3 },
+ { 0x09, KEY_CHANNELUP },
+
+ { 0x0f, KEY_4 },
+ { 0x05, KEY_5 },
+ { 0x06, KEY_6 },
+ { 0x07, KEY_CHANNELDOWN },
+
+ { 0x0c, KEY_7 },
+ { 0x0d, KEY_8 },
+ { 0x0a, KEY_9 },
+ { 0x0e, KEY_VOLUMEUP },
+
+ { 0x10, KEY_LAST },
+ { 0x11, KEY_0 },
+ { 0x12, KEY_ENTER },
+ { 0x13, KEY_VOLUMEDOWN },
+
+ { 0x14, KEY_RECORD },
+ { 0x15, KEY_STOP },
+ { 0x16, KEY_PLAY },
+ { 0x17, KEY_MUTE },
+
+ { 0x18, KEY_UP },
+ { 0x19, KEY_DOWN },
+ { 0x1a, KEY_LEFT },
+ { 0x1b, KEY_RIGHT },
+
+ { 0x1c, KEY_RED },
+ { 0x1d, KEY_GREEN },
+ { 0x1e, KEY_YELLOW },
+ { 0x1f, KEY_BLUE },
+};
+struct ir_scancode_table ir_codes_kworld_315u_table = {
+ .scan = ir_codes_kworld_315u,
+ .size = ARRAY_SIZE(ir_codes_kworld_315u),
+};
+EXPORT_SYMBOL_GPL(ir_codes_kworld_315u_table);
diff -r 28f5eca12bb0 linux/drivers/media/video/em28xx/em28xx-cards.c
--- a/linux/drivers/media/video/em28xx/em28xx-cards.c Sat Feb 06 23:49:31
2010 -0200
+++ b/linux/drivers/media/video/em28xx/em28xx-cards.c Sun Feb 07 11:35:39
2010 -0800
@@ -1322,6 +1322,7 @@
.tda9887_conf = TDA9887_PRESENT,
.decoder= EM28XX_SAA711X,
.has_dvb= 1,
+ .ir_codes = ir_codes_kworld_315u_table,
.dvb_gpio = em2882_kworld_315u_digital,
.xclk = EM28XX_XCLK_FREQUENCY_12MHZ,
.i2c_speed = EM28XX_I2C_CLK_WAIT_ENABLE,
diff -r 28f5eca12bb0 linux/include/media/ir-common.h
--- a/linux/include/media/ir-common.h Sat Feb 06 23:49:31 2010 -0200
+++ b/linux/include/media/ir-common.h Sun Feb 07 11:35:39 2010 -0800
@@ -163,4 +163,5 @@
extern struct ir_scancode_table ir_codes_gadmei_rm008z_table;
extern struct ir_scancode_table ir_codes_nec_terratec_cinergy_xs_table;
extern struct ir_scancode_table ir_codes_winfast_usbii_deluxe_table;
+extern struct ir_scancode_table ir_codes_kworld_315u_table;
#endif
--
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: Any saa711x users out there?
I also have a device that has the SAA7113 chip in it. Kworld 315U. I suggested a patch to add a an s_power function to the code but it looks like the patch didn't work. I have to do some cleanup to it and resubmit it. Franklin Meng --- On Thu, 2/4/10, Devin Heitmueller dheitmuel...@kernellabs.com wrote: From: Devin Heitmueller dheitmuel...@kernellabs.com Subject: Re: Any saa711x users out there? To: Andy Walls awa...@radix.net Cc: Linux Media Mailing List linux-media@vger.kernel.org Date: Thursday, February 4, 2010, 8:34 PM Hey Andy, On Thu, Feb 4, 2010 at 11:15 PM, Andy Walls awa...@radix.net wrote: Hmmm. The AGC (or static gain level?) of the amplifier in the SAA7113 before the anti-alias filter may be set too high causing the clipping (intermods) there. It may be worth looking at the gain setting for that amp. It's possible. One thing I did as a test though was I did a capture of the i2c traffic under Windows (using the same reference video source), and then compared the register programming (via some scripts I whipped up). There were some other registers that were different, but the only one that made *any* visible difference in the output was the AA flag. The visible effects of the anti-alais filter could possibly be: 1. Less range of color, if high freqs of the color get attenuated. (Most people likely will not perceive this as most people are not that sensitive to small color variations.) 2. Loss of rapid variations in Luma - softer edges between light and dark areas on a scan line - if higher freqs of the Luma get attenuated. but given that the anti-alais filter is essentially flat out to about 5.6 MHz and has a slow rolloff (only 3 dB down at about 6.9 MHz), I doubt anyone would ever notice it is on with NTSC. To give you a better idea of what I'm talking about, look at this image: http://imagebin.org/83458 The above image was taken with the generator via the s-video input (ruling out the possibility that it's any sort of product of intermodulation). For the sake of comparison, here's the exact same signal source against an a similar em28xx design but with the tvp5150. http://imagebin.org/83459 Since you have a signal generator, you should run experiments with PAL-D and SECAM-D with a grid containing vertical lines since those both have a 6.0 MHz video bandwidth. SECAM also has FM color, so you might see the greatest affect of an antialias filter on color on the Cyan color bar in SECAM-D. Believe it or not, I'm actually having trouble with the generator right now with anything but NTSC. I'm going back and forth with Promax on repair options. So I cannot do any PAL or SECAM testing right now. On a separate note, I really should look at extending the v4l2 capture-example to a version that let's me do a direct capture of the YUYV frame and convert the output into a zero-loss RGB format. It's too easy to be mislead by things the applications are doing like deinterlacing, rescaling, blending, and compression of the screenshot when saving to a file. 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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch 3/3] Kworld 315U
Do you need me to resubmit the patches as a file attachment?
Thanks,
Franklin Meng
--- On Mon, 1/25/10, Mauro Carvalho Chehab mche...@infradead.org wrote:
From: Mauro Carvalho Chehab mche...@infradead.org
Subject: Re: [Patch 3/3] Kworld 315U
To: Franklin Meng fmeng2...@yahoo.com
Cc: linux-media@vger.kernel.org, Douglas Schilling Landgraf
dougsl...@gmail.com
Date: Monday, January 25, 2010, 6:13 AM
Franklin Meng wrote:
Also complained about line-wrapping.
Cheers,
Mauro
Patch to bring device out of power saving mode.
Signed-off-by: Franklin Mengfmeng2...@yahoo.com
diff -r b6b82258cf5e
linux/drivers/media/video/em28xx/em28xx-core.c
---
a/linux/drivers/media/video/em28xx/em28xx-core.c
Thu Dec 31 19:14:54 2009 -0200
+++
b/linux/drivers/media/video/em28xx/em28xx-core.c
Sun Jan 17 22:54:21 2010 -0800
@@ -1132,6 +1132,7 @@
*/
void em28xx_wake_i2c(struct em28xx *dev)
{
+
v4l2_device_call_all(dev-v4l2_dev,
0, core, s_power, 1);
v4l2_device_call_all(dev-v4l2_dev,
0, core, reset, 0);
v4l2_device_call_all(dev-v4l2_dev,
0, video, s_routing,
INPUT(dev-ctl_input)-vmux, 0,
0);
--
To unsubscribe from this list: send the line
unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe
linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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: Kworld 315U and SAA7113?
OK.. I guess that was a misunderstanding on my part. I will split up the patch and re submit. Thanks, Franklin --- On Sun, 1/17/10, Devin Heitmueller dheitmuel...@kernellabs.com wrote: From: Devin Heitmueller dheitmuel...@kernellabs.com Subject: Re: Kworld 315U and SAA7113? To: Franklin Meng fmeng2...@yahoo.com Cc: linux-media@vger.kernel.org Date: Sunday, January 17, 2010, 8:28 AM On Sun, Jan 17, 2010 at 2:05 AM, Franklin Meng fmeng2...@yahoo.com wrote: I retested my device and tried several different GPIO sequences but so far every time I change between the Analog and digital interface, the SAA7113 needs to be reinitialized. I tried leaving both the digital and analog interfaces enabled by setting the GPIO to 7c but then the LG demod does not initialize. Either way it looks like I will have to reinitialize the device after switching between interfaces. Other than that do you want me to remove the suspend GPIO? Since I don't have the equipment to measure the power, I don't know for a fact if the device really has been put in a suspend state or not. Hello Franklin, Just to be clear, I'm not proposing that you remove the suspend logic. I was suggesting that you should be breaking the change into three separate patches, so that if a problem arises we can isolate whether it is a result of the power management changes. Having a separate patch is especially valuable because you are touching other drivers which are shared by other products. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch 1/3] Kworld 315U
Patch to add the s_power function to the saa7115.c code.
Signed-off-by: Franklin Mengfmeng2...@yahoo.com
diff -r b6b82258cf5e linux/drivers/media/video/saa7115.c
--- a/linux/drivers/media/video/saa7115.c Thu Dec 31 19:14:54 2009 -0200
+++ b/linux/drivers/media/video/saa7115.c Sun Jan 17 22:54:21 2010 -0800
@@ -1338,6 +1338,59 @@
return 0;
}
+static int saa711x_s_power(struct v4l2_subdev *sd, int val)
+{
+ struct saa711x_state *state = to_state(sd);
+
+ if(val 1 || val 0)
+ return -EINVAL;
+
+ /* There really isn't a way to put the chip into power saving
+ other than by pulling CE to ground so all we do is return
+ out of this function
+ */
+ if(val == 0)
+ return 0;
+
+ /* When enabling the chip again we need to reinitialize the
+ all the values
+ */
+ state-input = -1;
+ state-output = SAA7115_IPORT_ON;
+ state-enable = 1;
+ state-radio = 0;
+ state-bright = 128;
+ state-contrast = 64;
+ state-hue = 0;
+ state-sat = 64;
+
+ state-audclk_freq = 48000;
+
+ v4l2_dbg(1, debug, sd, writing init values s_power\n);
+
+ /* init to 60hz/48khz */
+ state-crystal_freq = SAA7115_FREQ_24_576_MHZ;
+ switch (state-ident) {
+ case V4L2_IDENT_SAA7111:
+ saa711x_writeregs(sd, saa7111_init);
+ break;
+ case V4L2_IDENT_SAA7113:
+ saa711x_writeregs(sd, saa7113_init);
+ break;
+ default:
+ state-crystal_freq = SAA7115_FREQ_32_11_MHZ;
+ saa711x_writeregs(sd, saa7115_init_auto_input);
+ }
+ if (state-ident != V4L2_IDENT_SAA7111)
+ saa711x_writeregs(sd, saa7115_init_misc);
+ saa711x_set_v4lstd(sd, V4L2_STD_NTSC);
+
+ v4l2_dbg(1, debug, sd, status: (1E) 0x%02x, (1F) 0x%02x\n,
+ saa711x_read(sd, R_1E_STATUS_BYTE_1_VD_DEC),
+ saa711x_read(sd, R_1F_STATUS_BYTE_2_VD_DEC));
+ return 0;
+}
+
static int saa711x_reset(struct v4l2_subdev *sd, u32 val)
{
v4l2_dbg(1, debug, sd, decoder RESET\n);
@@ -1513,6 +1566,7 @@
.s_std = saa711x_s_std,
.reset = saa711x_reset,
.s_gpio = saa711x_s_gpio,
+ .s_power = saa711x_s_power,
#ifdef CONFIG_VIDEO_ADV_DEBUG
.g_register = saa711x_g_register,
.s_register = saa711x_s_register,
--
To unsubscribe from this list: send
[Patch 2/3] Kworld 315U
Patch with updated GPIOs and enable analog inputs for the Kworld 315U
Signed-off-by: Franklin Mengfmeng2...@yahoo.com
diff -r b6b82258cf5e linux/drivers/media/video/em28xx/em28xx-cards.c
--- a/linux/drivers/media/video/em28xx/em28xx-cards.c Thu Dec 31 19:14:54
2009 -0200
+++ b/linux/drivers/media/video/em28xx/em28xx-cards.c Sun Jan 17 22:54:21
2010 -0800
@@ -122,13 +122,31 @@
};
#endif
+/* Kworld 315U
+ GPIO0 - Enable digital power (lgdt3303) - low to enable
+ GPIO1 - Enable analog power (saa7113/emp202) - low to enable
+ GPIO7 - enables something ?
+ GOP2 - ?? some sort of reset ?
+ GOP3 - lgdt3303 reset
+ */
/* Board - EM2882 Kworld 315U digital */
static struct em28xx_reg_seq em2882_kworld_315u_digital[] = {
- {EM28XX_R08_GPIO, 0xff, 0xff, 10},
- {EM28XX_R08_GPIO, 0xfe, 0xff, 10},
+ {EM28XX_R08_GPIO, 0x7e, 0xff, 10},
{EM2880_R04_GPO,0x04, 0xff, 10},
{EM2880_R04_GPO,0x0c, 0xff, 10},
- {EM28XX_R08_GPIO, 0x7e, 0xff, 10},
+ { -1, -1, -1, -1},
+};
+
+/* Board - EM2882 Kworld 315U analog1 analog tv */
+static struct em28xx_reg_seq em2882_kworld_315u_analog1[] = {
+ {EM28XX_R08_GPIO, 0xfd, 0xff, 10},
+ {EM28XX_R08_GPIO, 0x7d, 0xff, 10},
+ { -1, -1, -1, -1},
+};
+
+/* Board - EM2882 Kworld 315U analog2 component/svideo */
+static struct em28xx_reg_seq em2882_kworld_315u_analog2[] = {
+ {EM28XX_R08_GPIO, 0xfd, 0xff, 10},
{ -1, -1, -1, -1},
};
@@ -140,6 +158,14 @@
{ -1, -1, -1, -1},
};
+/* Board - EM2882 Kworld 315U suspend */
+static struct em28xx_reg_seq em2882_kworld_315u_suspend[] = {
+ {EM28XX_R08_GPIO, 0xff, 0xff, 10},
+ {EM2880_R04_GPO,0x08, 0xff, 10},
+ {EM2880_R04_GPO,0x0c, 0xff, 10},
+ { -1, -1, -1, -1},
+};
+
static struct em28xx_reg_seq kworld_330u_analog[] = {
{EM28XX_R08_GPIO, 0x6d, ~EM_GPIO_4, 10},
{EM2880_R04_GPO,0x00, 0xff, 10},
@@ -1314,28 +1340,28 @@
.decoder= EM28XX_SAA711X,
.has_dvb= 1,
[Patch 3/3] Kworld 315U
Patch to bring device out of power saving mode.
Signed-off-by: Franklin Mengfmeng2...@yahoo.com
diff -r b6b82258cf5e linux/drivers/media/video/em28xx/em28xx-core.c
--- a/linux/drivers/media/video/em28xx/em28xx-core.c Thu Dec 31 19:14:54
2009 -0200
+++ b/linux/drivers/media/video/em28xx/em28xx-core.c Sun Jan 17 22:54:21
2010 -0800
@@ -1132,6 +1132,7 @@
*/
void em28xx_wake_i2c(struct em28xx *dev)
{
+ v4l2_device_call_all(dev-v4l2_dev, 0, core, s_power, 1);
v4l2_device_call_all(dev-v4l2_dev, 0, core, reset, 0);
v4l2_device_call_all(dev-v4l2_dev, 0, video, s_routing,
INPUT(dev-ctl_input)-vmux, 0, 0);
--
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: Kworld 315U and SAA7113?
Devin, I'm actually not really concerned about it's interaction with a demod. I'm more worried about other products that have saa711[345] that use a bridge other than em28xx. The introduction of power management could always expose bugs in those bridges (I had this problem in several different cases where I had to fix problems in other drivers because of the introduction of power management). I retested my device and tried several different GPIO sequences but so far every time I change between the Analog and digital interface, the SAA7113 needs to be reinitialized. I tried leaving both the digital and analog interfaces enabled by setting the GPIO to 7c but then the LG demod does not initialize. Either way it looks like I will have to reinitialize the device after switching between interfaces. Other than that do you want me to remove the suspend GPIO? Since I don't have the equipment to measure the power, I don't know for a fact if the device really has been put in a suspend state or not. Thanks, Franklin Meng -- 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: Kworld 315U and SAA7113?
Mario,
Thank you for taking a look at this.. I'll resubmit the patches.
Thanks,
Franklin Meng
--- On Wed, 1/13/10, Mauro Carvalho Chehab mche...@redhat.com wrote:
From: Mauro Carvalho Chehab mche...@redhat.com
Subject: Re: Kworld 315U and SAA7113?
To: Franklin Meng fmeng2...@yahoo.com
Cc: linux-media@vger.kernel.org
Date: Wednesday, January 13, 2010, 1:10 PM
Hi Franklin,
I have no Kworld 315U here for testing, but your patch
looked sane on my eyes.
In order to merge this upstream, it would be better if you
could submit it as two
separate patches: the first one with the saa7115 changes to
support re-energizing
the device, and the second one with the em28xx changes.
Please send your Signed-off-by: on the patches.
Cheers,
Mauro.
Franklin Meng wrote:
I tweaked the GPIO's a bit more for the Kworld 315U
and switching between analog and digital signals is more
reliable now. Attached is an updated diff.
diff -r b6b82258cf5e
linux/drivers/media/video/em28xx/em28xx-cards.c
---
a/linux/drivers/media/video/em28xx/em28xx-cards.c Thu
Dec 31 19:14:54 2009 -0200
+++
b/linux/drivers/media/video/em28xx/em28xx-cards.c Sat
Jan 09 11:29:27 2010 -0800
@@ -122,13 +122,31 @@
};
#endif
+/* Kworld 315U
+ GPIO0 - Enable digital power
(lgdt3303) - low to enable
+ GPIO1 - Enable analog power
(saa7113/emp202) - low to enable
+ GPIO7 - enables something ?
+ GOP2 - ?? some sort of reset
?
+ GOP3 - lgdt3303 reset
+ */
/* Board - EM2882 Kworld 315U digital */
static struct em28xx_reg_seq
em2882_kworld_315u_digital[] = {
-
{EM28XX_R08_GPIO,
0xff, 0xff,
10},
-
{EM28XX_R08_GPIO,
0xfe, 0xff,
10},
+
{EM28XX_R08_GPIO,
0x7e, 0xff,
10},
{EM2880_R04_GPO,
0x04, 0xff,
10},
{EM2880_R04_GPO,
0x0c, 0xff,
10},
-
{EM28XX_R08_GPIO,
0x7e, 0xff,
10},
+ { -1,
-1, -1,
-1},
+};
+
+/* Board - EM2882 Kworld 315U analog1 analog tv
*/
+static struct em28xx_reg_seq
em2882_kworld_315u_analog1[] = {
+
{EM28XX_R08_GPIO,
0xfd, 0xff,
10},
+
{EM28XX_R08_GPIO,
0x7d, 0xff,
10},
+ { -1,
-1, -1,
-1},
+};
+
+/* Board - EM2882 Kworld 315U analog2
component/svideo */
+static struct em28xx_reg_seq
em2882_kworld_315u_analog2[] = {
+
{EM28XX_R08_GPIO,
0xfd, 0xff,
10},
{
-1,
-1, -1,
-1},
};
@@ -140,6 +158,14 @@
{
-1,
-1, -1,
-1},
};
+/* Board - EM2882 Kworld 315U suspend */
+static struct em28xx_reg_seq
em2882_kworld_315u_suspend
Re: Kworld 315U and SAA7113?
Devin, This is pretty good stuff. A few questions/comments about your patch: The code has different GPIO configurations for the two analog modes. This is a bit unusual for an em28xx design. Do you know what the difference is in terms of what GPIO7 controls? Unfortunately, I do not know the difference. I thought it might be to do something to the tuner but I am not quite sure. If I remember correctly, the traces that I obtained also showed a difference between the analog modes. I do know that if I leave the bit on it does not cause any adverse affects (other than maybe more power is being drawn).. The digital GPIO block strobes GPO3 to reset the lgdt3303. While I generally believe that it's good to explicitly strobe the reset low, this could cause problems with em28xx devices. This is because the em28xx calls the digital GPIO whenever starting streaming. Hence, you could end up with the chip being reset without the demod driver's init() routine being called, resulting in the chip's register state not being in sync with the driver's state info. In fact, we have this issue with one of the Terratec boards where the zl10353 driver state gets out of sync with the hardware (I still need to submit a patch upstream for that case). Your code at this point should probably only ensure the 3303 is not in reset (by setting the GPIO pin high). I might try leaving the GPIO pin high.. I had lots of issues switching between analog and digital modes so changing this bit may cause one or the other to not work. For example if I leave both pins for the SAA/EM202 and the demod high, the analog doesn't seem to work correctly. I'm guessing that there probably isn't enough power to keep both devices operational. I'll try it out some more to see what happens. It's not surprising that you would uncover an issue with the suspend logic. Despite the fact that the em28xx driver provides a suspend method it is not actually used today in any of the board profiles. I saw it was available so I decided to use it. I actually also implemented a suspend state for the AC97 chip (the EM202 I believe) though I wasn't fully happy with the code so I didn't include it this time around. The saa7115 stuff looks pretty reasonable at first glance, although I am a bit worried about the possibility that it could cause a regression in other products that use that decoder. As far as I can tell, the Kworld 315U is the only board that uses this combination of parts.. Thomson tuner, LG demod, and SAA7113. I don't think any other device has used the SAA7113 together with a digital demod. Most products seem to only have the SAA711X on an analog only board. Since I don't have any other USB adapters with the SAA chip I was unable to do any further testing on the SAA code changes. Did you actually do any power analysis to confirm that the suspend functionality is working properly? Humm.. I did not actually do this. Though, maybe I can figure this out by seeing how much power draw is on the USB bus. I don't recall if there is a way to figure this out or not from within Linux. I do remember Windows having such a feature.. I probably need to do a comparison between both OS's to make sure I get things are correct.. Is there a way to get information on how much power draw is happening on the USB bus in Linux? I agree with Mauro though that this should be split into multiple patches. In fact, I would seriously consider three patches instead of two - the first patch adds the basic functionality to get the board working, the second adds the saa7115 code, and the third adds the suspend GPIO changes. This will make it easier for others who have problems to isolate whether any problems are a basic issue with the board not working or whether it is related to the suspend and power management changes. Well basic functionality of the board is already included (digital only). Douglas helped me get those changes in earlier. I'll see if I can split up the patches better. Last thing is that my responses may be kind of slow since I had a new addition to the family not too long ago. :) Thanks, Franklin -- 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: Kworld 315U and SAA7113?
Actually I was a bit short sighted here. I was referring to devices in the em28xx tree. In the case of the SAA7113 device, there really is no power saving feature unless a hardware pin is pulled down (or up I don't remember). The pin will basically reset the device. From my testing it seems like the power on defaults don't fully enable the device which is why I added the reinitialization to the s_power routine. Thanks, Franklin Meng --- On Thu, 1/14/10, Devin Heitmueller dheitmuel...@kernellabs.com wrote: From: Devin Heitmueller dheitmuel...@kernellabs.com Subject: Re: Kworld 315U and SAA7113? To: CityK ci...@rogers.com Cc: Franklin Meng fmeng2...@yahoo.com, linux-media@vger.kernel.org Date: Thursday, January 14, 2010, 2:09 PM On Thu, Jan 14, 2010 at 5:00 PM, CityK ci...@rogers.com wrote: Franklin Meng wrote: As far as I can tell, the Kworld 315U is the only board that uses this combination of parts.. Thomson tuner, LG demod, and SAA7113. I don't think any other device has used the SAA7113 together with a digital demod. Most products seem to only have the SAA711X on an analog only board. Since I don't have any other USB adapters with the SAA chip I was unable to do any further testing on the SAA code changes. IIRC, a couple of the Sasem/OnAir devices use a saa7113 together with a digital demod. I seem to also recall something else, though maybe I'm mistaken. I'm actually not really concerned about it's interaction with a demod. I'm more worried about other products that have saa711[345] that use a bridge other than em28xx. The introduction of power management could always expose bugs in those bridges (I had this problem in several different cases where I had to fix problems in other drivers because of the introduction of power management). 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 -- 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: Kworld 315U and SAA7113?
Attached is an updated diff for the Kworld 315U TV. I believe all the bugs
have been worked out. I haven't figured out the remote control stuff and
hopefully I will be able to get around to it some time.
The sound issue was because I didn't have the right mplayer config so that is
fixed as well.
Other than that, the LED light on the front of the box doesn't shut off after I
start and stop the stream. It's probably a GPIO setting that I need to tweak.
And I wanted to say thank you to Douglas and Devin for the tips they provided
me.
Thanks,
Franklin Meng
--- On Thu, 1/7/10, Franklin Meng fmeng2...@yahoo.com wrote:
From: Franklin Meng fmeng2...@yahoo.com
Subject: Kworld 315U and SAA7113?
To: linux-media@vger.kernel.org
Date: Thursday, January 7, 2010, 7:48 PM
After some work I have finally gotten
the analog inputs to work with the Kworld 315U device. I
have attached the changes/updates to the em28xx driver.
Note: I still don't have analog sound working yet..
I am hoping someone can comment on the changes in
saa7115.c. I added a s_power routine to reinitialize the
device. The reason I am reinitializing this device is
because
1. I cannot keep both the LG demod and the SAA powered on
at the same time for my device
2. The SAA datasheet seems to suggest that after a
reset/power-on the chip needs to be reinitialized.
3. Reinitializing causes the analog inputs to work
correctly.
Here's what is says in the SAA7113 datasheet..
Status after power-on
control sequence
VPO7 to VPO0, RTCO, RTS0 and RTS1
are held in high-impedance state
after power-on (reset
sequence) a complete
I2C-bus transmission is
required
...
The above is really suppose to be arranged horizontally in
3 columns. Anyways, the last part describes that a
complete I2C bus transmission is required This is why
I think the chip needs to be reinitialized.
Last thing is that the initialization routing uses these
defaults:
state-bright = 128;
state-contrast = 64;
state-hue = 0;
state-sat = 64;
I was wondering if we should just read the back the values
that were initialized by the initialization routine and use
those values instead.The reason is because it seems like the
different SAA's use slightly different values when
initializing.
Thanks,
Franklin Meng
diff -r b6b82258cf5e linux/drivers/media/video/em28xx/em28xx-cards.c
--- a/linux/drivers/media/video/em28xx/em28xx-cards.c Thu Dec 31 19:14:54 2009 -0200
+++ b/linux/drivers/media/video/em28xx/em28xx-cards.c Sat Jan 09 00:21:39 2010 -0800
@@ -122,13 +122,31 @@
};
#endif
+/* Kworld 315U
+ GPIO0 - Enable digital power (lgdt3303) - low to enable
+ GPIO1 - Enable analog power (saa7113/emp202) - low to enable
+ GPIO7 - enables something ?
+ GOP2 - ?? some sort of reset ?
+ GOP3 - lgdt3303 reset
+ */
/* Board - EM2882 Kworld 315U digital */
static struct em28xx_reg_seq em2882_kworld_315u_digital[] = {
- {EM28XX_R08_GPIO, 0xff, 0xff, 10},
{EM28XX_R08_GPIO, 0xfe, 0xff, 10},
{EM2880_R04_GPO, 0x04, 0xff, 10},
{EM2880_R04_GPO, 0x0c, 0xff, 10},
- {EM28XX_R08_GPIO, 0x7e, 0xff, 10},
+ { -1, -1, -1, -1},
+};
+
+/* Board - EM2882 Kworld 315U analog1 analog tv */
+static struct em28xx_reg_seq em2882_kworld_315u_analog1[] = {
+ {EM28XX_R08_GPIO, 0xfd, 0xff, 10},
+ {EM28XX_R08_GPIO, 0x7d, 0xff, 10},
+ { -1, -1, -1, -1},
+};
+
+/* Board - EM2882 Kworld 315U analog2 component/svideo */
+static struct em28xx_reg_seq em2882_kworld_315u_analog2[] = {
+ {EM28XX_R08_GPIO, 0xfd, 0xff, 10},
{ -1, -1, -1, -1},
};
@@ -140,6 +158,12 @@
{ -1, -1, -1, -1},
};
+/* Board - EM2882 Kworld 315U suspend */
+static struct em28xx_reg_seq em2882_kworld_315u_suspend[] = {
+ {EM28XX_R08_GPIO, 0xff, 0xff, 10},
+ { -1, -1, -1, -1},
+};
+
static struct em28xx_reg_seq kworld_330u_analog[] = {
{EM28XX_R08_GPIO, 0x6d, ~EM_GPIO_4, 10},
{EM2880_R04_GPO, 0x00, 0xff, 10},
@@ -1314,28 +1338,28 @@
.decoder = EM28XX_SAA711X,
.has_dvb = 1,
.dvb_gpio = em2882_kworld_315u_digital,
+ .suspend_gpio = em2882_kworld_315u_suspend,
.xclk = EM28XX_XCLK_FREQUENCY_12MHZ,
.i2c_speed = EM28XX_I2C_CLK_WAIT_ENABLE,
- /* Analog mode - still not ready */
- /*.input= { {
+ .input= { {
.type = EM28XX_VMUX_TELEVISION,
.vmux = SAA7115_COMPOSITE2,
.amux = EM28XX_AMUX_VIDEO,
- .gpio = em2882_kworld_315u_analog,
+ .gpio = em2882_kworld_315u_analog1,
.aout = EM28XX_AOUT_PCM_IN | EM28XX_AOUT_PCM_STEREO,
}, {
.type = EM28XX_VMUX_COMPOSITE1,
.vmux = SAA7115_COMPOSITE0,
.amux = EM28XX_AMUX_LINE_IN,
- .gpio = em2882_kworld_315u_analog1,
+ .gpio = em2882_kworld_315u_analog2,
.aout = EM28XX_AOUT_PCM_IN | EM28XX_AOUT_PCM_STEREO,
}, {
.type = EM28XX_VMUX_SVIDEO,
.vmux = SAA7115_SVIDEO3,
.amux = EM28XX_AMUX_LINE_IN,
- .gpio = em2882_kworld_315u_analog1,
+ .gpio
Re: Kworld 315U and SAA7113?
;
+
+ /* There really isn't a way to put the chip into power saving
+ other than by pulling CE to ground so all we do is return
+ out of this function
+ */
+ if(val == 0)
+ return 0;
+
+ /* When enabling the chip again we need to reinitialize the
+ all the values
+ */
+ state-input = -1;
+ state-output = SAA7115_IPORT_ON;
+ state-enable = 1;
+ state-radio = 0;
+ state-bright = 128;
+ state-contrast = 64;
+ state-hue = 0;
+ state-sat = 64;
+
+ state-audclk_freq = 48000;
+
+ v4l2_dbg(1, debug, sd, writing init values s_power\n);
+
+ /* init to 60hz/48khz */
+ state-crystal_freq = SAA7115_FREQ_24_576_MHZ;
+ switch (state-ident) {
+ case V4L2_IDENT_SAA7111:
+ saa711x_writeregs(sd, saa7111_init);
+ break;
+ case V4L2_IDENT_SAA7113:
+ saa711x_writeregs(sd, saa7113_init);
+ break;
+ default:
+ state-crystal_freq = SAA7115_FREQ_32_11_MHZ;
+ saa711x_writeregs(sd, saa7115_init_auto_input);
+ }
+ if (state-ident != V4L2_IDENT_SAA7111)
+ saa711x_writeregs(sd, saa7115_init_misc);
+ saa711x_set_v4lstd(sd, V4L2_STD_NTSC);
+
+ v4l2_dbg(1, debug, sd, status: (1E) 0x%02x, (1F) 0x%02x\n,
+ saa711x_read(sd, R_1E_STATUS_BYTE_1_VD_DEC),
+ saa711x_read(sd, R_1F_STATUS_BYTE_2_VD_DEC));
+ return 0;
+}
+
static int saa711x_reset(struct v4l2_subdev *sd, u32 val)
{
v4l2_dbg(1, debug, sd, decoder RESET\n);
@@ -1513,6 +1566,7 @@
.s_std = saa711x_s_std,
.reset = saa711x_reset,
.s_gpio = saa711x_s_gpio,
+ .s_power = saa711x_s_power,
#ifdef CONFIG_VIDEO_ADV_DEBUG
.g_register = saa711x_g_register,
.s_register = saa711x_s_register,
Thanks,
Franklin Meng
--- On Thu, 1/7/10, Franklin Meng fmeng2...@yahoo.com wrote:
From: Franklin Meng fmeng2...@yahoo.com
Subject: Kworld 315U and SAA7113?
To: linux-media@vger.kernel.org
Date: Thursday, January 7, 2010, 7:48 PM
After some work I have finally gotten
the analog inputs to work with the Kworld 315U device. I
have attached the changes/updates to the em28xx driver.
Note: I still don't have analog sound working yet..
I am hoping someone can comment on the changes in
saa7115.c. I added a s_power routine to reinitialize the
device. The reason I am reinitializing this device is
because
1. I cannot keep both the LG demod and the SAA powered on
at the same time for my device
2. The SAA datasheet seems to suggest that after a
reset/power-on the chip needs to be reinitialized.
3. Reinitializing causes the analog inputs to work
correctly.
Here's what is says in the SAA7113 datasheet..
Status after power-on
control sequence
VPO7 to VPO0, RTCO, RTS0 and RTS1
are held in high-impedance state
after power-on (reset
sequence) a complete
I2C-bus transmission is
required
...
The above is really suppose to be arranged horizontally in
3 columns. Anyways, the last part describes that a
complete I2C bus transmission is required This is why
I think
Kworld 315U and SAA7113?
After some work I have finally gotten the analog inputs to work with the Kworld 315U device. I have attached the changes/updates to the em28xx driver. Note: I still don't have analog sound working yet.. I am hoping someone can comment on the changes in saa7115.c. I added a s_power routine to reinitialize the device. The reason I am reinitializing this device is because 1. I cannot keep both the LG demod and the SAA powered on at the same time for my device 2. The SAA datasheet seems to suggest that after a reset/power-on the chip needs to be reinitialized. 3. Reinitializing causes the analog inputs to work correctly. Here's what is says in the SAA7113 datasheet.. Status after power-on control sequence VPO7 to VPO0, RTCO, RTS0 and RTS1 are held in high-impedance state after power-on (reset sequence) a complete I2C-bus transmission is required ... The above is really suppose to be arranged horizontally in 3 columns. Anyways, the last part describes that a complete I2C bus transmission is required This is why I think the chip needs to be reinitialized. Last thing is that the initialization routing uses these defaults: state-bright = 128; state-contrast = 64; state-hue = 0; state-sat = 64; I was wondering if we should just read the back the values that were initialized by the initialization routine and use those values instead.The reason is because it seems like the different SAA's use slightly different values when initializing. Thanks, Franklin Meng mydiff1 Description: Binary data
Re: Kworld 315U help?
Devin, Thanks for the info.. Should the parse_em28xx.pl script be updated to reflect this? I'm assuming other em28xx boards also have the eeprom at address 0xa0. There are a couple more entries that I am unsure about.. I'll post those when I get home tonight. Are you interested in looking at some traces? I am pretty sure I have most of the analog and input stuff figured out though I probably don't have the GPIO sequence correct. Anyways, if your interested I can send you what I know. Thanks Franklin Meng --- On Wed, 10/21/09, Devin Heitmueller dheitmuel...@kernellabs.com wrote: From: Devin Heitmueller dheitmuel...@kernellabs.com Subject: Re: Kworld 315U help? To: Franklin Meng fmeng2...@yahoo.com Cc: linux-media@vger.kernel.org Date: Wednesday, October 21, 2009, 5:55 AM On Wed, Oct 21, 2009 at 1:35 AM, Franklin Meng fmeng2...@yahoo.com wrote: I was wondering if someone would be able to help me with getting the analog and inputs for the Kworld 315U working. I was able to get the digital part working with help from Douglas Schilling and wanted to get the remaining portions of the device working. I have traces but have not made much progress. In addition I also have some questions about the information that the parse_em28xx.pl skips and does not decode. For example here is some of the data that doesn't seem to be decoded.. unknown: 40 03 00 00 a0 00 01 00 08 unknown: c0 02 00 00 a0 00 01 00 d0 unknown: 40 03 00 00 a0 00 01 00 08 unknown: c0 02 00 00 a0 00 01 00 d0 unknown: 40 03 00 00 a0 00 01 00 22 unknown: c0 02 00 00 a0 00 01 00 01 unknown: 40 03 00 00 a0 00 01 00 04 unknown: c0 02 00 00 a0 00 02 00 1a eb unknown: 40 03 00 00 a0 00 01 00 20 unknown: c0 02 00 00 a0 00 01 00 46 unknown: 40 03 00 00 a0 00 01 00 14 unknown: c0 02 00 00 a0 00 04 00 4e 07 01 00 Anyways, any help that can be provided is appreciated. Those look like i2c commands to the onboard eeprom, which is at i2c address 0xa0. For example: unknown: 40 03 00 00 a0 00 01 00 04 // set eeprom read offset to 0x04 unknown: c0 02 00 00 a0 00 02 00 1a eb // read two bytes back from eeprom Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: Kworld 315U help?
Here are some more stuff in the trace that was not decoded by the parse_em28xx script.. So what we know from this list of unknowns... 0xa0 is the eeprom 0x4a is the SAA 0x42 ??. 0xd0 ?? 0x20 ?? 0xc6 ?? 0xc4 ?? 0xc2 Thomson tuner. unknown: c0 02 00 00 42 00 01 00 fd unknown: c0 02 00 00 4a 00 01 00 11 unknown: 40 03 00 00 a0 00 01 00 2d unknown: c0 02 00 00 a0 00 01 00 1c unknown: c0 02 00 00 20 00 01 00 fe unknown: c0 02 00 00 d0 00 01 00 10 unknown: 40 03 00 00 a0 00 01 00 0a unknown: c0 02 00 00 a0 00 01 00 5a unknown: 40 03 00 00 a0 00 01 00 2e unknown: c0 02 00 00 a0 00 01 00 00 unknown: 40 03 00 00 a0 00 01 00 0a unknown: c0 02 00 00 a0 00 01 00 5a unknown: c0 02 00 00 c6 00 01 00 00 unknown: c0 02 00 00 c4 00 01 00 10 unknown: c0 02 00 00 c2 00 01 00 b4 Anyone know what are at the other addresses? I don't know if they are important or not. Thanks, Franklin Meng --- On Wed, 10/21/09, Franklin Meng fmeng2...@yahoo.com wrote: From: Franklin Meng fmeng2...@yahoo.com Subject: Re: Kworld 315U help? To: Devin Heitmueller dheitmuel...@kernellabs.com Cc: linux-media@vger.kernel.org Date: Wednesday, October 21, 2009, 8:06 AM Devin, Thanks for the info.. Should the parse_em28xx.pl script be updated to reflect this? I'm assuming other em28xx boards also have the eeprom at address 0xa0. There are a couple more entries that I am unsure about.. I'll post those when I get home tonight. Are you interested in looking at some traces? I am pretty sure I have most of the analog and input stuff figured out though I probably don't have the GPIO sequence correct. Anyways, if your interested I can send you what I know. Thanks Franklin Meng --- On Wed, 10/21/09, Devin Heitmueller dheitmuel...@kernellabs.com wrote: From: Devin Heitmueller dheitmuel...@kernellabs.com Subject: Re: Kworld 315U help? To: Franklin Meng fmeng2...@yahoo.com Cc: linux-media@vger.kernel.org Date: Wednesday, October 21, 2009, 5:55 AM On Wed, Oct 21, 2009 at 1:35 AM, Franklin Meng fmeng2...@yahoo.com wrote: I was wondering if someone would be able to help me with getting the analog and inputs for the Kworld 315U working. I was able to get the digital part working with help from Douglas Schilling and wanted to get the remaining portions of the device working. I have traces but have not made much progress. In addition I also have some questions about the information that the parse_em28xx.pl skips and does not decode. For example here is some of the data that doesn't seem to be decoded.. unknown: 40 03 00 00 a0 00 01 00 08 unknown: c0 02 00 00 a0 00 01 00 d0 unknown: 40 03 00 00 a0 00 01 00 08 unknown: c0 02 00 00 a0 00 01 00 d0 unknown: 40 03 00 00 a0 00 01 00 22 unknown: c0 02 00 00 a0 00 01 00 01 unknown: 40 03 00 00 a0 00 01 00 04 unknown: c0 02 00 00 a0 00 02 00 1a eb unknown: 40 03 00 00 a0 00 01 00 20 unknown: c0 02 00 00 a0 00 01 00 46 unknown: 40 03 00 00 a0 00 01 00 14 unknown: c0 02 00 00 a0 00 04 00 4e 07 01 00 Anyways, any help that can be provided is appreciated. Those look like i2c commands to the onboard eeprom, which is at i2c address 0xa0. For example: unknown: 40 03 00 00 a0 00 01 00 04 // set eeprom read offset to 0x04 unknown: c0 02 00 00 a0 00 02 00 1a eb // read two bytes back from eeprom Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kworld 315U help?
Here are the files since I forgot to attach them in my last e-mail. Thanks, Franklin Meng decode.tar.gz Description: application/gzip
parse-sniffusb2.pl update
I have updated/rewrote parts of the parse-sniffusb2.pl script since I noticed
some minor errors that I had in the previous version. I believe everything
should be correct now. Attached is a newer version for review with the name
parse1b-sniffusb2.pl
Thanks,
Franklin Meng
#!/usr/bin/perl
#
# Author: Franklin Meng fmeng2...@yahoo.com
# Parser for USB snoops captured from SniffUSB 2.0.
#
use strict;
use warnings;
use Data::Dumper;
my $urbhash;
foreach my $curfile (@ARGV) {
parsefile($curfile);
#we can only process 1 file
exit;
}
sub parsefile {
my $curfile = shift;
my $s1 = 0;
my $t1 = 0;
my $tmp1 = ;
my $printurb = 0;
my $cururb = 0;
open(FD, $curfile) || die(Error: $!\n);
while(FD) {
chomp;
if (/URB\s+(\d+)\s+going\s+down/) {
# print previous urb if available
if($printurb != 0 exists($urbhash-{$printurb}-{'SetupPacket'})) {
print $urbhash-{$printurb}-{'SetupPacket'} $urbhash-{$printurb}-{'Direction'} $urbhash-{$printurb}-{'TransferBufferMDL'}\n;
## delete urb information
#delete($urbhash-{$printurb});
}
# delete urb information
delete($urbhash-{$printurb});
$printurb = 0; #reset here
$tmp1 = ;
$s1 = 0;
$t1 = 0;
# store next urb info here
$cururb = $1;
$urbhash-{$1} = undef;
next;
} elsif (/URB\s+(\d+)\s+coming\s+back/) {
# print previous urb if available
if($printurb != 0 exists($urbhash-{$printurb}-{'SetupPacket'})) {
print $urbhash-{$printurb}-{'SetupPacket'} $urbhash-{$printurb}-{'Direction'} $urbhash-{$printurb}-{'TransferBufferMDL'}\n;
## delete urb information
#delete($urbhash-{$printurb});
}
# delete urb information
delete($urbhash-{$printurb});
$printurb = 0; #reset here
$tmp1 = ;
$s1 = 0;
$t1 = 0;
# flag next urb for print out
if(exists($urbhash-{$1})) {
$printurb = $1;
} else {
die Error: cannot match urb!!\n;
}
$cururb = $1;
next;
} elsif (/\-{2}\s+(URB_FUN.+)\:/) { # store urb function (used for debugging)
if(!exists($urbhash-{$cururb}-{'Function'})) {
$urbhash-{$cururb}-{'Function'} = $1;
}
next;
} elsif (/USBD_TRANSFER_DIRECTION_IN/) { #store in direction
#check if we already stored a value
if(!exists($urbhash-{$cururb}-{'Direction'})) {
$urbhash-{$cururb}-{'Direction'} = ;
}
next;
} elsif (/USBD_TRANSFER_DIRECTION_OUT/) { #store out direction
#check if we already stored a value
if(!exists($urbhash-{$cururb}-{'Direction'})) {
$urbhash-{$cururb}-{'Direction'} = ;
}
next;
} elsif (/TransferBufferMDL\s+=\s+/) { #flag data packet
$t1 = 1;
next;
} elsif (/SetupPacket\s+=/) { #flag setup packet
$s1 = 1;
next;
} elsif (/(.+\s+\=|ms\])/ ($s1 || $t1)) { #save data packet and reset
if($s1 ($tmp1 ne )) {
$tmp1 =~ s/^\s+//;
$urbhash-{$cururb}-{'SetupPacket'} = $tmp1;
} elsif($t1 ($tmp1 ne )) {
$tmp1 =~ s/^\s+//;
$urbhash-{$cururb}-{'TransferBufferMDL'} = $tmp1
}
$tmp1 = ;
$s1 = 0;
$t1 = 0;
next;
} elsif (/^\s+\d+\:(.+)/ ($s1 || $t1)) { #capture packet
$tmp1 = $tmp1 . $1;
}
}
# print remaining URB
if($printurb != 0 exists($urbhash-{$printurb}-{'SetupPacket'})) {
print $urbhash-{$printurb}-{'SetupPacket'} $urbhash-{$printurb}-{'Direction'} $urbhash-{$printurb}-{'TransferBufferMDL'}\n;
# # delete urb information
# delete($urbhash-{$printurb});
}
# delete urb information
delete($urbhash-{$printurb});
# Maybe we should warn for the URB's that did not have matches?
# print out stuff remaining in the hash for debugging
#print Dumper($urbhash);
}
Kworld 315U help?
I was wondering if someone would be able to help me with getting the analog and inputs for the Kworld 315U working. I was able to get the digital part working with help from Douglas Schilling and wanted to get the remaining portions of the device working. I have traces but have not made much progress. In addition I also have some questions about the information that the parse_em28xx.pl skips and does not decode. For example here is some of the data that doesn't seem to be decoded.. unknown: 40 03 00 00 a0 00 01 00 08 unknown: c0 02 00 00 a0 00 01 00 d0 unknown: 40 03 00 00 a0 00 01 00 08 unknown: c0 02 00 00 a0 00 01 00 d0 unknown: 40 03 00 00 a0 00 01 00 22 unknown: c0 02 00 00 a0 00 01 00 01 unknown: 40 03 00 00 a0 00 01 00 04 unknown: c0 02 00 00 a0 00 02 00 1a eb unknown: 40 03 00 00 a0 00 01 00 20 unknown: c0 02 00 00 a0 00 01 00 46 unknown: 40 03 00 00 a0 00 01 00 14 unknown: c0 02 00 00 a0 00 04 00 4e 07 01 00 Anyways, any help that can be provided is appreciated. Thanks, Franklin Meng -- 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: [PULL] http://linuxtv.org/hg/~dougsland/em28xx/
Just wanted to thank Douglas Landgraf for the help he provided me with getting the em28xx driver working with the Kworld 315U tuner device (digital only at this time). As time permits, I hope to get the analog inputs and tuner to work too (if anyone want to help please let me know). Thanks, Franklin Meng --- On Sat, 6/6/09, Douglas Schilling Landgraf dougsl...@gmail.com wrote: From: Douglas Schilling Landgraf dougsl...@gmail.com Subject: [PULL] http://linuxtv.org/hg/~dougsland/em28xx/ To: linux-media@vger.kernel.org Cc: Mauro Carvalho Chehab mche...@infradead.org, fmeng2...@yahoo.com Date: Saturday, June 6, 2009, 1:11 PM Hello Mauro, Please pull from http://www.linuxtv.org/hg/~dougsland/em28xx for the following: - em28xx: Add Kworld 315 entry - em28xx: set up tda9887_conf in em28xx_card_setup() Thanks, Douglas -- 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
