[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 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
[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
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
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 wrote:
> From: Mauro Carvalho Chehab
> Subject: Re: [Patch] Kworld 315U remote support
> To: "Franklin Meng"
> Cc: "Douglas Schilling" , "maillist"
>
> 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] 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
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 wrote: > From: Devin Heitmueller > Subject: Re: Any saa711x users out there? > To: "Andy Walls" > Cc: "Linux Media Mailing List" > Date: Thursday, February 4, 2010, 8:34 PM > Hey Andy, > > On Thu, Feb 4, 2010 at 11:15 PM, Andy Walls > 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 wrote:
> From: Mauro Carvalho Chehab
> Subject: Re: [Patch 3/3] Kworld 315U
> To: "Franklin Meng"
> Cc: linux-media@vger.kernel.org, "Douglas Schilling Landgraf"
>
> 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 Meng
> >
> > 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
[Patch 3/3] Kworld 315U
Patch to bring device out of power saving mode.
Signed-off-by: Franklin Meng
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
[Patch 2/3] Kworld 315U
Patch with updated GPIOs and enable analog inputs for the Kworld 315U
Signed-off-by: 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 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 1/3] Kworld 315U
Patch to add the s_power function to the saa7115.c code.
Signed-off-by: Franklin Meng
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_regi
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 wrote: > From: Devin Heitmueller > Subject: Re: Kworld 315U and SAA7113? > To: "Franklin Meng" > 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 > 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
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?
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 wrote: > From: Devin Heitmueller > Subject: Re: Kworld 315U and SAA7113? > To: "CityK" > Cc: "Franklin Meng" , linux-media@vger.kernel.org > Date: Thursday, January 14, 2010, 2:09 PM > On Thu, Jan 14, 2010 at 5:00 PM, > CityK > 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?
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?
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 wrote:
> From: Mauro Carvalho Chehab
> Subject: Re: Kworld 315U and SAA7113?
> To: "Franklin Meng"
> 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 */
Re: Kworld 315U and SAA7113?
+ 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,
Thanks,
Franklin Meng
--- On Thu, 1/7/10, Franklin Meng wrote:
> From: Franklin Meng
> 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 p
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 wrote:
> From: Franklin Meng
> 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_analog
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?
Here are the files since I forgot to attach them in my last e-mail. Thanks, Franklin Meng decode.tar.gz Description: application/gzip
Re: Kworld 315U help?
Devin,
> c4 and c6 are probably also the tuner. I know that
> K-World makes some
> products with the same name but different regions. Is
> your version of
> the 315U an ATSC hybrid tuner? If so, then one of
> those addresses is
> probably the demod.
I believe the device I have is a hybrid tuner since it does both digital and
analog.
>
> Also, the trace you sent is just an excerpt, but it's
> possible that
> the driver is probing for devices and the requests are
> failing because
> the hardware isn't present (the Windows driver supports a
> variety of
> different hardware combinations). Usually you can
> tell by looking for
> a read from register 0x05 immediately after the i2c
> read. If register
> 0x05 is nonzero, then the i2c read operation failed.
This is good information to know. Here are the list of components that are on
the board along with the address..
1. LG LGDT3303 - 0x1c
2. Lattice ISP2032VE - ?? don't know the address
3. Phillips SAA7113H - 0x4a
4. Empia EMP202
5. Empia EM2882
6. Thomson DTT 7611A - 0xc2
In addition there is a TDA at 0x86 and we also know the eeprom is at 0xa0.
I'm attaching the output that I parsed the using the updated
parse1b_sniffusb2.pl script as well as the output from a slightly modified
parse_em28xx.pl. I modified the parse_em28xx.pl to output the stuff it did not
decode.
In the tar ball are 2 files. emparse1new.out (obtained using parse_em28xx.pl)
and newlog.out (obtained using the updated script)
These traces are for the component inputs of the kworld 315U device. I have
other traces as well for the TV and Svideo inputs. You can find pictures of
the device here.. http://www.linuxtv.org/wiki/index.php/KWorld_ATSC_315U
In the source this I added this information that has been commented out. I
believe this is how the the board is configured according to what I decoded out
of the traces some time ago.
/* Analog mode - still not ready */
/*.input= { {
.type = EM28XX_VMUX_TELEVISION,
.vmux = SAA7115_COMPOSITE2,
.amux = EM28XX_AMUX_VIDEO,
.gpio = em2882_kworld_315u_analog,
.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,
.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,
.aout = EM28XX_AOUT_PCM_IN | EM28XX_AOUT_PCM_STEREO,
} }, */
can you double check this to see if I got things correct? I think all I need
is the correct GPIO sequence but I am not sure.
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 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 wrote: > From: Franklin Meng > Subject: Re: Kworld 315U help? > To: "Devin Heitmueller" > 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 > wrote: > > > From: Devin Heitmueller > > Subject: Re: Kworld 315U help? > > To: "Franklin Meng" > > 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 > > 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?
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 wrote: > From: Devin Heitmueller > Subject: Re: Kworld 315U help? > To: "Franklin Meng" > 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 > 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
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
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
# 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() {
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);
}
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 wrote: > From: Douglas Schilling Landgraf > Subject: [PULL] http://linuxtv.org/hg/~dougsland/em28xx/ > To: linux-media@vger.kernel.org > Cc: "Mauro Carvalho Chehab" , 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
Re: Kworld 315U help?
Douglas, I can't take credit for creating the page. Someone else put that together. All I did was add the Thomson Tuner chip to the existing page. I appreciate the help and I have also updated the thread with the changes I made in the driver. Thanks, Franklin --- On Sun, 1/4/09, Douglas Schilling Landgraf wrote: > From: Douglas Schilling Landgraf > Subject: Re: Kworld 315U help? > To: fmeng2...@yahoo.com > Cc: video4linux-l...@redhat.com, "linux-media" > Date: Sunday, January 4, 2009, 2:26 PM > Hello Franklin, > > On Sun, 4 Jan 2009 14:04:16 -0800 (PST) > Franklin Meng wrote: > > > I was wondering if someone can help me get the Kworld > 315U supported > > under linux? Information about the device is located > here: > > http://linuxtv.org/wiki/index.php/KWorld_ATSC_315U > > Sure, thank for creating such page in linuxtv wiki. > > > I have spent some time modifying the driver though I > haven't gotten > > anything working yet. If someone can give me some > pointers or help > > it would be greatly appreciated. I think I have all > the chips of > > interest detected but I don't know what to do now. > > > > > Here's an output of my kernel logs showing the > device. Hopefully I'm > > on the right track. > > > > [ 569.663960] Linux video capture interface: > > v2.00 [ 569.717312] em28xx: New device USB 2883 > Device @ 480 Mbps > > (eb1a:a313, interface 0, class 0) [ 569.719319] > em28xx #0: > > Identified as KWorld ATSC 315U HDTV TV Box (card=62) [ > 569.719407] > > em28xx #0: chip ID is em2882/em2883 [ 569.846878] > em28xx #0: i2c > > eeprom 00: 1a eb 67 95 1a eb 13 a3 d0 13 5a 03 6a 22 > 00 00 > > [ 569.846911] em28xx #0: i2c eeprom 10: 00 00 04 57 > 4e 07 01 00 00 > > 00 00 00 00 00 00 00 [ 569.846942] em28xx #0: i2c > eeprom 20: 46 00 > > 01 00 f0 10 01 00 00 00 00 00 5b 1c 00 00 [ > 569.846971] em28xx #0: > > i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 00 > 00 00 00 > > [ 569.847000] em28xx #0: i2c eeprom 40: 00 00 00 00 > 00 00 00 00 00 > > 00 00 00 00 00 00 00 [ 569.847028] em28xx #0: i2c > eeprom 50: 00 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ > 569.847056] em28xx #0: > > i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 22 03 55 > 00 53 00 > > [ 569.847086] em28xx #0: i2c eeprom 70: 42 00 20 00 > 32 00 38 00 38 > > 00 33 00 20 00 44 00 [ 569.847116] em28xx #0: i2c > eeprom 80: 65 00 > > 76 00 69 00 63 00 65 00 00 00 00 00 00 00 [ > 569.847145] em28xx #0: > > i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 > > [ 569.847173] em28xx #0: i2c eeprom a0: 00 00 00 00 > 00 00 00 00 00 > > 00 00 00 00 00 00 00 [ 569.847202] em28xx #0: i2c > eeprom b0: 00 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ > 569.847230] em28xx #0: > > i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 > > [ 569.847259] em28xx #0: i2c eeprom d0: 00 00 00 00 > 00 00 00 00 00 > > 00 00 00 00 00 00 00 [ 569.847288] em28xx #0: i2c > eeprom e0: 00 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ > 569.847317] em28xx #0: > > i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 > > [ 569.847348] em28xx #0: EEPROM ID= 0x9567eb1a, > EEPROM hash = > > 0x98330201 [ 569.847353] em28xx #0: EEPROM info: [ > 569.847357] > > em28xx #0: AC97 audio (5 sample rates) [ > 569.847362] em28xx > > #0: 500mA max power [ 569.847367] em28xx #0: >Table at > > 0x04, strings=0x226a, 0x, 0x [ 569.847373] > em28xx #0: > > [ 569.847376] [ 569.847382] em28xx #0: The support > for this board > > weren't valid yet. [ 569.847387] em28xx #0: > Please send a report of > > having this working [ 569.847393] em28xx #0: not to > V4L mailing list > > (and/or to other addresses) [ 569.847396] [ > 569.882876] saa7115' > > 0-0025: saa7113 found (1f7113d0e10) @ 0x4a (em28xx > #0) > > [ 569.955345] tuner' 0-0043: chip found @ 0x86 > (em28xx #0) > > [ 569.979876] tda9887 0-0043: creating new instance [ > 569.979894] > > tda9887 0-0043: tda988[5/6/7] found [ 569.980772] > tda9887 0-0043: > > destroying instance [ 569.980993] tda9887 0-0043: > creating new > > instance [ 569.980999] tda9887 0-0043: tda988[5/6/7] > found > > [ 569.983857] tuner' 0-0061: chip found @ 0xc2 > (em28xx #0) > > [ 570.018607] tuner-simple 0-0061: creating new > instance > > [ 570.018622] tuner-simple 0-0061: type set to 60 > (Thomson DTT 761X > > (ATSC/NTSC)) [ 570.025349] e
