Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner

2011-07-07 Thread Marko Ristola
Hi. IMO, your thoughts about core resource locking mechanism sound good. I say here some thoughts and examples how the resource locking mechanism might work. IMHO, It's good enough now if we are heading to a solution. At least I would not alone find a proper concept. 07.07.2011 18:14, Mauro Ca

Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner

2011-07-07 Thread Mauro Carvalho Chehab
Em 06-07-2011 16:59, Marko Ristola escreveu: > 06.07.2011 21:17, Devin Heitmueller kirjoitti: >> On Wed, Jul 6, 2011 at 1:53 PM, Marko Ristola >> wrote: >>> >> >> All that said, I believe that you are correct in that the business >> logic needs to ultimately be decided by the bridge driver, rathe

Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner

2011-07-06 Thread Marko Ristola
06.07.2011 21:17, Devin Heitmueller kirjoitti: > On Wed, Jul 6, 2011 at 1:53 PM, Marko Ristola > wrote: >> > > All that said, I believe that you are correct in that the business > logic needs to ultimately be decided by the bridge driver, rather than > having the dvb/tuner core blindly calling t

Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner

2011-07-06 Thread Devin Heitmueller
On Wed, Jul 6, 2011 at 1:53 PM, Marko Ristola wrote: > > Hi. > > I think that you could reuse lots of code with smart suspend / resume. > > What do you think about this DVB power saving case (about the concept, don't > look at details, please): > > - One device has responsibility to do the power

Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner

2011-07-06 Thread Marko Ristola
Hi. I think that you could reuse lots of code with smart suspend / resume. What do you think about this DVB power saving case (about the concept, don't look at details, please): - One device has responsibility to do the power off when it can be done (mantis_core.ko) - In my case there is only

Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner

2011-06-16 Thread Devin Heitmueller
On Thu, Jun 16, 2011 at 7:14 AM, Mauro Carvalho Chehab wrote: > One possible logic that would solve the scripting would be to use a watchdog > to monitor ioctl activities. If not used for a while, it could send a s_power > to put the device to sleep, but this may not solve all our problems. > > So

Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner

2011-06-16 Thread Mauro Carvalho Chehab
Em 16-06-2011 03:21, Hans Verkuil escreveu: > On Wednesday, June 15, 2011 22:49:39 Devin Heitmueller wrote: >> On Wed, Jun 15, 2011 at 4:37 PM, Hans Verkuil wrote: >>> But the driver has that information, so it should act accordingly. >>> >>> So on first open you can check whether the current inpu

Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner

2011-06-15 Thread Hans Verkuil
On Wednesday, June 15, 2011 22:49:39 Devin Heitmueller wrote: > On Wed, Jun 15, 2011 at 4:37 PM, Hans Verkuil wrote: > > But the driver has that information, so it should act accordingly. > > > > So on first open you can check whether the current input has a tuner and > > power on the tuner in tha

Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner

2011-06-15 Thread Devin Heitmueller
On Wed, Jun 15, 2011 at 4:37 PM, Hans Verkuil wrote: > But the driver has that information, so it should act accordingly. > > So on first open you can check whether the current input has a tuner and > power on the tuner in that case. On S_INPUT you can also poweron/off > accordingly > (bit iffy a

Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner

2011-06-15 Thread Hans Verkuil
On Wednesday, June 15, 2011 22:09:45 Devin Heitmueller wrote: > On Wed, Jun 15, 2011 at 3:55 PM, Hans Verkuil wrote: > > Why would that violate the spec? If the last filehandle is closed, then > > you can safely poweroff the tuner. The only exception is when you have a > > radio > > tuner whose a

Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner

2011-06-15 Thread Devin Heitmueller
On Wed, Jun 15, 2011 at 3:55 PM, Hans Verkuil wrote: > Why would that violate the spec? If the last filehandle is closed, then > you can safely poweroff the tuner. The only exception is when you have a radio > tuner whose audio output is hooked up to some line-in: there you can't power > off > th

Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner

2011-06-15 Thread Hans Verkuil
On Saturday, June 11, 2011 19:08:04 Devin Heitmueller wrote: > On Sat, Jun 11, 2011 at 1:02 PM, Hans Verkuil wrote: > > OK, but how do you get it into standby in the first place? (I must be > > missing > > something here...) > > The tuner core puts the chip into standby when the last V4L filehan

Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner

2011-06-11 Thread Devin Heitmueller
On Sat, Jun 11, 2011 at 1:02 PM, Hans Verkuil wrote: > OK, but how do you get it into standby in the first place? (I must be missing > something here...) The tuner core puts the chip into standby when the last V4L filehandle is closed. Yes, I realize this violates the V4L spec since you should b

Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner

2011-06-11 Thread Hans Verkuil
On Saturday, June 11, 2011 18:57:16 Devin Heitmueller wrote: > On Sat, Jun 11, 2011 at 12:06 PM, Andy Walls wrote: > > Devin, > > > > I think I have a Gotview or compro card with an xc2028. Is that tuner > > capable of standby? Would the cx18 or ivtv driver need to actively support > > using s

Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner

2011-06-11 Thread Devin Heitmueller
On Sat, Jun 11, 2011 at 11:53 AM, Hans Verkuil wrote: > Do you happen to know not-too-expensive cards that you can buy that have > this sort of tuners? It may be useful to be able to test this myself. Anything with an xc3028 or xc5000 would have this issue. I don't really keep close track of cur

Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner

2011-06-11 Thread Devin Heitmueller
On Sat, Jun 11, 2011 at 12:06 PM, Andy Walls wrote: > Devin, > > I think I have a Gotview or compro card with an xc2028.  Is that tuner > capable of standby?  Would the cx18 or ivtv driver need to actively support > using stand by? An xc2028/xc3028 should be fine, as that does support standby.

Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner

2011-06-11 Thread Andy Walls
Hans Verkuil wrote: >On Saturday, June 11, 2011 17:32:10 Devin Heitmueller wrote: >> On Sat, Jun 11, 2011 at 11:05 AM, Hans Verkuil >wrote: >> > Second version of this patch series. >> > >> > It's the same as RFCv1, except that I dropped the g_frequency and >> > g_tuner/s_tuner patches (patch 3,

Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner

2011-06-11 Thread Andy Walls
Devin Heitmueller wrote: >On Sat, Jun 11, 2011 at 11:05 AM, Hans Verkuil >wrote: >> Second version of this patch series. >> >> It's the same as RFCv1, except that I dropped the g_frequency and >> g_tuner/s_tuner patches (patch 3, 6 and 7 in the original patch >series) >> because I need to think

Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner

2011-06-11 Thread Hans Verkuil
On Saturday, June 11, 2011 17:32:10 Devin Heitmueller wrote: > On Sat, Jun 11, 2011 at 11:05 AM, Hans Verkuil wrote: > > Second version of this patch series. > > > > It's the same as RFCv1, except that I dropped the g_frequency and > > g_tuner/s_tuner patches (patch 3, 6 and 7 in the original patc

Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner

2011-06-11 Thread Devin Heitmueller
On Sat, Jun 11, 2011 at 11:05 AM, Hans Verkuil wrote: > Second version of this patch series. > > It's the same as RFCv1, except that I dropped the g_frequency and > g_tuner/s_tuner patches (patch 3, 6 and 7 in the original patch series) > because I need to think more on those, and I added a new fi

[RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner

2011-06-11 Thread Hans Verkuil
Second version of this patch series. It's the same as RFCv1, except that I dropped the g_frequency and g_tuner/s_tuner patches (patch 3, 6 and 7 in the original patch series) because I need to think more on those, and I added a new fix for tuner_resume which was broken as well. Regards,