Hopefully others will start picking up on the fact that you've
placed an initial stab at driver code up on CVS at r-engine.sf.net.
I'm Cc'ing this to the r-engine-developers list to see if it sparks
Peter McNeil wrote:
>On Tue, 2005-06-21 at 21:38, Doug Scoular wrote:
> Leave the DMA bit out altogether just insmod mb86393 then you'll just
>get an error in dmesg about no saa7113.
Okay, I've got the same result now, so we are on the same
page I guess.
A while back you said:
> >OK Just pulled appart my PCG-C1MT to see what the video input processor
> >was as this is important for the driver. Looks like they use the
> >SAA7114H from philips
> >(http://www.semiconductors.philips.com/pip/SAA7114H.html) which is very
> >similar to the Triumph driver code we have, cool, looks like the
> >driver might work with a couple of small tweaks.
Does that mean we should be initialising the SAA7114H rather
than attempting to send initialisations for an SAA7113 to an
SAA7114H... or are both present ?
Looking at the intialisation... they do seem to differ, for example
the mb86393 code is setting 0x0e to 0x09, that's setting
"Chrominance Control" to 0x09 but on from looking at the current
SAA7114H driver in drivers/media/video/saa7114.c it appears that
it has the following settings. Which looks to my ignorant eye like
it initialises 0x0e to 0x84:
0x0e, 0x84, /* 0e - CDTO, CSTD2 to 0, DCVF, FCTC,
* CCOMB; depends from video standard */
Where the video standard settings are:
0x89 = NTSC M
0x81 = PAL B, D, G, H and I
0xD0 = SECAM
I've no idea what 0x84 is, perhaps plain ol NTSC... I also
think I see the code set it to 0x85 in saa7114.c so now I'm
really confused. I think I'm missing something fundamental
about low-level hardware programming.
Anyway, just thought I'd give you my, probably useless 2