Manu Abraham wrote:
> Hi Marko,
>
> On 8/4/07, Marko Ristola <[EMAIL PROTECTED]> wrote:
>
>> Hi Manu and all
>>
>> I have done small improvements into Mantis drivers:
>> I have fixed the insmod/rmmod problem and I have implemented
>> suspend/resume for cu1216.
>> It does in mantis_dvb.c "power off"/ "power on" if no application
>> uses the frontend.
>>
>
>
> Normally we handle this in the frontend. ie in this case cu1216
> You can put the CU1216 into STANDBY using Reg:0x00 Bit:7
>
>
I have tested only S2DISK, so the PCI and all other hardware
loses all power.
I tried to implement both S2DISK and S2MEM initially, but
problem solving was too difficult and then I dropped S2MEM.
Maybe it is easier then to add S2MEM and hibernate support,
when S2DISK works.
>
>> So with my suspend/resume and with non-USB sound output,
>> I am able to suspend to disk and back so that Kaffeine will
>> continue displaying the TV channel.
>> I use now 2.6.22.1-41.fc7 kernel.
>>
>> cu1216 needed only small changes with the current version.
>> Most changes went into dvb/mantis directory.
>>
>
>
> You will need 2 callbacks, one for suspend, one for resume: both
> handling the power control to the frontend/tuner. This will control
> power ON/OFF from the PCI interface POV, to the entire frontend,
> rather than a STANDBY.
>
>
>
I used mantis_dvb.c's implementation of tuner power on/off.
I used cu1216_init (cu1216_init_none called it)
for fe->ops.init to reinitialize cu1216 on resume after S2DISK.
>> resume uses fe->opt.init for cu1216, so it must do something.
>>
>
>
> Probably, a tune again with the cached params would be all that's
> needed, since init is empty.
>
> The init should start by setting Reg:0x00 Bit:7, such that the
> frontend resumes from Standby.
>
> (A bit confused with all the different suspends, is this S2RAM or
> S2DISK or Hibernate ? The suspend folks were discussing on how to
> create a memory snapshot: wondering whether our memory states for the
> previous successful states would be there)
>
>
With your help, the implementation might become a bit simpler
and a lot better and fine-grained.
>
>> resume uses fe->opt.set_frontend(fe,NULL) currently, meaning
>> "please set the previous tuning values".
>>
>
>
> yeah, that would be a quick way to handle it, though it could be a
> problem when the frontend_params is "really" null in a normal case.
>
> A better way would be: from the resume callback, pass the cached
> parameter straight away
> to cu1216_set_parameters(). That way you wouldn't need to handle the
> problem when params=NULL
>
Within mantis_dvb.c I tried to do on suspend
cu1216:get_parameters(fe, ¶ms), but that locked up almost always
and S2DISK didn't save it's state into swap space.
Thus I decided to not call get_parameters and used the NULL workaround
to inform cu1216_set_parameters() to do the previous tuning.
Currently I do set_parameters() only if DMA transfer was going on during
suspend.
So I did power up on mantis_dvb.c and then called cu1216.c init
and then called cu1216_set_parameters() to tune into the correct
frequency and then called mantis_dma_start() to restore DMA transfer.
I didn't have to wait for a lock to start the DMA transfer. Thus the resume
code is rather simple.
Of course I had to do all PCI stuff and Mantis init and internal Mantis
IRQ restore after computer
power off state.
> You will have the last cached state in params:
>
> struct cu1216_state {
> struct i2c_adapter *i2c;
> struct dvb_frontend_ops ops;
>
> /* config settings */
> const struct cu1216_config *config;
> struct dvb_frontend frontend;
>
> u8 pwm;
> u8 reg0;
>
> struct dvb_frontend_parameters params;
> };
>
>
>
>
>> I need to collect the patches and clean them up before sending them for you.
>>
>
>
> Cool. The last update from my side is at: http://jusst.de/hg/v4l-dvb/
>
>
Thankyou. I downloaded it. It takes some time to make the patches.
> Thanks,
> Manu
>
>
Thanks,
Marko
_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
