On Sat, 2008-10-18 at 15:48 +0200, Hans Verkuil wrote:
> On Saturday 18 October 2008 15:06:28 Andy Walls wrote:
> > Hans,
> >
> > cx18_probe() calls cx18_init_memory() twice to init the DDR.  I
> > suspect I should remove the second instance, since that one is called
> > after cx18_init_scb().  Or do both need to stay for some reason?
> >
> > Regards,
> > Andy
> 
> Yes, there is a reason: the memory settings depend on the card type. But 
> for Hauppauge cards the card type is derived from the eeprom. That 
> requires a working i2c bus. So you cannot set the correct memory 
> settings until after init_cx18_i2c() and cx18_process_eeprom().
> 
> Now from what I remember some of the functions leading up to 
> init_cx18_i2c() use scb (or at least require it to be non-NULL). And 
> before you can call cx18_init_scb() you need to setup the memory.
> 
> At the time I just put in a cx_init_memory() call so that I could setup 
> scb. Of course, this is just a hack. The real solution would be to 
> structure the driver so that you can setup the i2c bus without having 
> to setup memory/scb.
> 
> In any case, the second cx18_init_memory is certainly correct, since 
> cx18_process_eeprom() might discover that it is really a different card 
> with different timings.
> 
> The first init_memory/init_scb pair basically just works around a 
> different bug: someone using scb too early. I guess that should be 
> cleaned up. Try removing the first init_memory and moving the init_scb 
> to after the second init_memory and see what happens. Perhaps it is no 
> longer an issue after all the changes done since I wrote that code.

Ah, I didn't get an appreciation for all the subtleties.  I thought the
early init may have been linked to early i2c use - but I didn't hunt
down where it might be needed.

I'll leave this one alone for now.  I was going to ask Mauro to pull a
few minor cleanups before I'm away from my setup for a few weeks.  I
noticed this and thought it may be an easy one to include - I guess not.

Thanks.

Andy

> Regards,
> 
>       Hans



_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Reply via email to