Intel i915GM with SDVO CH7021A support?
airlied at gmail.com
Mon Nov 13 16:23:17 PST 2006
> > >
> > > 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
> > > manage to get the DVI working with the IEGD binary driver but it
> > > 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
> > > 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.
> > > quite happy to try any experimental code or hack something together if
> > > 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
> > > 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
> > > 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.
> > > if a BIOS call is available presumably the snooping method will work...
> > > otherwise would it be possible / practical to snoop the I2C bus at
> > > 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 (220.127.116.11) 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)
You might not need to write an actual i2c or sdvo snooper, you might
be able to just write an SDVO test app for Windows that talks to the
chip by bitbanging and reads back the current status, there is lots of
info on SDVO control registers in the modesetting branch (lots more
than when I spent hours staring at it and finally guessed what the
register formats were)...
or if you can get vbetool to set a tv-mode somehow, you could use my
BIOS tracing "hack"
you need to build it, run it, find the io registers it uses, change
the values in thunk.c, do stuff, watch dumps... rinse, tear hair out,
More information about the xorg