[Intel-gfx] _PIXEL_CLOCK define in edid.h (GM45 chipset)

[Jesse Barnes]

The driver should get _PIXEL_CLOCK from an X server include.  Maybe
you don't have the X server development headers installed?

Jesse

On Sun, 28 Feb 2010 19:46:28 -0800 (PST)
Alan DuBoff <aland at softorchestra.com> wrote:

> Can't anyone at Intel answer this question for me?
> 
> The client I'm trying to get this working for is partnering on 
> this device with another company, Innovative, and I need to get 
> this working. It has both an Intel CPU and Graphics (GM45), and 
> we need MontaVista Linux 6 running on this device.
> 
> Please tell me which edid.h you used to compile, in the source 
> file it is quoted, implying that it was pulled from a local 
> directory, but it is not in the source tarball...
> 
> I really would appreciate some help on this so I can get this 
> going, and the 2.6.0 intel x driver seems like it could work.
> 
> If you have any questions or need more information, please feel 
> free to ask. I will be at the client tomorrow to try and get 
> this working, any help would be appreciated.
> 
> I will cc my email at the client, Silicon Valley Medical
> Instruments, who partnered with Innovative for this device used 
> in the medical industry. We need to have OpenGL support, and the 
> 2.4.2 module just hangs with a black screen if I load both glx 
> and dri.
> 
> Regards,
> Alan
> 
> On Fri, 26 Feb 2010, Alan DuBoff wrote:
> 
> > I have an odd problem in trying to build an xorg intel_drv.so
> > driver to support the GM45 which is on an embedded device.
> >
> > I'm trying to get MontaVisa Linux 6 working on a device, which is
> > not really an embedded device per se, it has 4gig of memory and a
> > solid state hard drive, but the company has asked me to get MVL 6
> > running on it. This requires that I cross compile with the Monta
> > Vista tools in order to support their libraries.
> >
> > MVL 6 ships with version 2.6.28r10 of the Linux kernel. On the
> > distribution, Xorg is at 1.5.3, and the Intel module version =
> > 2.4.2.
> >
> > If I load the glx and dri driver on this, I get the exact same
> > symptoms that Keith Packard describes at the following link, a
> > black screen that appears to hang the system. It is not completly
> > hung, I can ssh into the device and get the Xorg log.
> >
> > https://kerneltrap.org/mailarchive/linux-kernel/2008/10/20/3727534/thread
> >
> > This is the exactly erro I get in the Xorg.0.log with both glx and
> > dri loaded with the 2.4.2 module.
> >
> > --------------
> >
> > (II) intel(0): [DRI] installation complete
> > (II) intel(0): xf86BindGARTMemory: bind key 0 at 0x01f7f000
> > (pgoffset 8063) (WW) intel(0): xf86BindGARTMemory: binding of gart
> > memory with key 0 at offset 0x1f7f000 failed (Invalid argument)
> >
> > Fatal server error:
> > Couldn't bind memory for HW status
> >
> >
> > Backtrace:
> > 0: /usr/bin/X(xorg_backtrace+0x38) [0x8131428]
> >
> > FatalError re-entered, aborting
> > Caught signal 11.  Server aborting
> >
> > --------------
> >
> > Through some searching, I found on the intelgraphics site, there is
> > a version 2.6.0 which looks to have several fixes, and it seems it
> > will run on the Linux kernel 2.6.28r6+. This is from the Q42008
> > drop.
> >
> > I was able to cross compile libdrm at 2.4.4, but when I try to get
> > the xf86-video-intel-2.6.0 package compiled, I seem to be missing
> > _PIXEL_CLOCK in edid.h. In fact, the versions of edid.h I have are
> > very sparce, both on MVL6, OpenSuSE 11.1, and Debian Lenny (stable).
> >
> > Yet, I find this version of edid.h when googling on the web, which
> > appears to be Apple's version of it, and it does in fact have
> > _PIXEL_CLOCK defined.
> >
> > http://www.opensource.apple.com/source/X11server/X11server-85/Xquartz/xorg-server-1.4.2-apple45/hw/xfree86/ddc/edid.h
> >
> > Is Intel expecting to pick up that define from edid.h?
> >
> > Or what is the proper way to get the driver compiled so that I can
> > run it on MVL6?
> >
> > As an additional piece of data, I can load the glx without dri (no 
> > accelleration) and not hang the X server, but that doesn't help us
> > much as we would end up with a non-accellerated driver. The problem
> > seems to be memory related to the dri driver.
> >
> > --
> >
> > Alan DuBoff - Software Orchestration
> > http://www.softorchestra.com:8080/roller/blog/
> >
> >
> >
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> 
> --
> 
> Alan DuBoff - Software Orchestration
> http://www.softorchestra.com:8080/roller/blog/
> 
> 
> 
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 


-- 
Jesse Barnes, Intel Open Source Technology Center