Intel i915GM with SDVO CH7021A support?

[Will .]

>From: Eric Anholt <eric at anholt.net>
>To: will <nodenet at hotmail.com>
>CC: xorg at lists.freedesktop.org
>Subject: Re: Intel i915GM with SDVO CH7021A support?
>Date: Mon, 13 Nov 2006 13:51:06 -0800
>
>On Mon, 2006-11-13 at 15:28 +0000, will wrote:
> > Hi,
> >
> > A few months ago I got a version of the mode setting Intel 915 driver 
>from a
> > git tree posted on airlied's live journal. With a bit of fiddling and
> > tweaking this has been working very well and I can get very close to the
> > refresh rates required for video etc.
> >
> > I've had no success with the CH7021A SDVO support under linux at all.
> > Chrontel refuse to supply any details about how to program the chip. I 
>did
> > manage to get the DVI working with the IEGD binary driver but it 
>wouldn't
> > recognise or work the CH7021A at all. I'd really like to get the CH7021A
> > working as it supports HDTV, SCART out and exact TV refresh rates and 
>spec
> > etc etc. Without proper support it's impossible to adjust the internal
> > parameters as it is with the Windows driver.
> >
> > If any one has any suggestion or can help me it would be appreciated. 
>I'm
> > quite happy to try any experimental code or hack something together if 
>there
> > is a bit of detail about how to get the 7021 to respond available. I
> > understand it may be possible to snoop the I2C bus and potentially work 
>out
> > what is going on with the SDVO. Would this be a viable method or would I
> > just be wasting my time trying? I should probably know the answer to 
>this
> > but it would help if someone could confirm this... Once the PC has 
>booted up
> > is it possible to switch the SDVO 7021A TV out on using a BIOS call, I 
>had a
> > brief look in the VESA spec but I could easily have missed this. 
>Presumably
> > if a BIOS call is available presumably the snooping method will work...
> > otherwise would it be possible / practical to snoop the I2C bus at 
>bootup
> > using some sort of TSR when the TV Out is enabled?
> >
> > Thanks for any help anyone can provide
>
>You're probably going to have minimal luck trying to get the BIOS to do
>anything special.  While we haven't done any TV development in the
>modesetting branch of xf86-video-intel git, it has the continuation of
>the work that airlied started, and I'd love to help integrate any
>appropriate code for TV support.  If you can get the master branch to
>turn your TV on at all, you may be able to use the BIOS tracing tools
>that are floating around to figure out what the BIOS is doing and
>replicate it.
>
>Unfortunately, I don't think I'll have any time to work on SDVO TV
>support directly any time soon.
>
>--
>Eric Anholt                             anholt at FreeBSD.org
>eric at anholt.net                         eric.anholt at intel.com

Thanks for the feedback, I've had a few attempts at getting the TV to turn 
on using the master branch from a while ago (1.4.1.3) and havent been 
succesful. To be honest I seem to remember that the only way I've ever been 
able to get the TV out on is to plug it in and boot up without anything else 
attached. I may have another play with this and see if I get lucky. My 
thoughts now turn to a more extreme (and probably more stupid) :)))... 
method Ideally I'd like to do the I2C snooping under windows (with the 
working driver) but I'm not sure that trying to do that with existing 
software that I wouldnt be giving myself a very BIG headache (i.e. would I 
just be getting myself down a bit of a blind alley). I've seen a simple I2C 
snooper that runs on the parrallel port which I guess is far too slow to 
snoop SDVO, however I was wondering just how fast it would have to be to do 
it in the real world i.e. if I got the snooper to work under USB would I be 
cooking on gas or is that still way too slow? I have a sneaky suspiscion 
that this is not enough alone... do I really need to trap the writes to the 
other registers as well? I'd give the kernel debugger or something similar a 
go if I thought it would work?? If I put a breakpoint on the offset of the 
I2C read write functions relative to the base address of the appropriate DLL 
(assuming I can even work all the out) I should be able to trace back the 
calling parameters? Jeez I got a headache just typing all that is it 
completly implausable or is it vaguely plausable (best I can hope for) .... 
and where does this stick of dynamite fit in? (or is that where I've been 
going wrong before)

Will Wiseman

_________________________________________________________________
Windows Live™ Messenger has arrived. Click here to download it for free! 
http://imagine-msn.com/messenger/launch80/?locale=en-gb