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?
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?
Franklin Meng wrote: > 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. This happens on several designs. In general, the gpio sequence will turn off either the analog or the digital part of the device, in order to save power and to avoid overheating the device. > I tried leaving both the digital and analog interfaces enabled by setting the > GPIO to 7c but then the LG demod does not initialize. Don't do that. You may burn your device. > Either way it looks like I will have to reinitialize the device after > switching between interfaces. The em28xx driver calls em28xx_set_mode(dev, EM28XX_ANALOG_MODE); when the device is opened in analog mode. It seems that we'll need some code there to also call the analog demod to re-initiate the device, after sending the gpio commands. > > 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. In suspend state, it will be cooler than when in normal state. It is better to keep the suspend state to increase the lifetime of the device. > > 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 -- 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?
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
Re: Kworld 315U and SAA7113?
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. -- 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?
On Thu, Jan 14, 2010 at 1:54 PM, Franklin Meng wrote: > 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).. If there is no difference, it might make sense to just pick one. If you could measure the power draw though, you might gain some insight regarding the difference. > 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. You would obviously need to retest. The cases where having the digital GPIO do an actual reset were exposed when performing multiple tuning attempts without closing the DVB device in between attempts. > 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. I'm more worried about it interfering with other devices that use some other bridge, regardless of whether that device has a demodulator. Implementing power management on any chip is likely to expose bugs in neighboring components like the bridge. >> >> 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 don't trust the operating system when it comes to that sort of thing. I cut up an old USB cable and put an ammeter in-line. Has helped alot in finding all sorts of power management bugs both in drivers and in the v4l-dvb core. 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, > > 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?
On Sat, Jan 9, 2010 at 2:30 PM, 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. Hello Franklin, 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? 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). 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. 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. Did you actually do any power analysis to confirm that the suspend functionality is working properly? 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. 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?
wer, 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);
>
> 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 Sat Jan 09 11:29:27 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)
> +
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
