(no subject)

[roman]

Hi,

I've found your discussion about a gma500 Atom E6xx graphics device with PCI
ID 0x4108. I'm currently working on such a box, too.

There are two variants of my hardware, one with LVDS output for smaller
panels, and one with a Chrontel 7308 SDVO->LVDS converter for larger ones. My
HW developer says the platform is called "Little Bay" and similar to Queens
Bay.

Anyway, the small LVDS one works fine so far, at least when I hardcode the
panel resolution (there's no VBT etc. in BIOS yet). However, the SDVO one
stays black. No wonder, as there's no SDVO code in the Oaktrail part of the
driver.

So I tried to add this... and simply started with adding a call to
psb_intel_sdvo_init() in oaktrail_output_init(), to see what happens. The
result: it doesn't find anything :-( I could track problems down to the point
that the SDVO i2c registers seem to be the wrong ones.

At the known offsets for i2c regs (0x5100 and on) I see only 0xffffffff, so
probably these registers are not present or somewhere else on my platform.

Does anybody of you have any infos on this? How can I get further?
Thanks for any help in advance!

Roman


PS: Please keep me in Cc:, I'm not subscribed to LKML.

Re:

[Alan Cox]

> Anyway, the small LVDS one works fine so far, at least when I hardcode the
> panel resolution (there's no VBT etc. in BIOS yet). However, the SDVO one
> stays black. No wonder, as there's no SDVO code in the Oaktrail part of the
> driver.

Indeed - the Oaktrail processors don't have SDVO support. E6xx happens
to be very similar to Oaktrail so the LVDS works. No idea about HDMI.

> So I tried to add this... and simply started with adding a call to
> psb_intel_sdvo_init() in oaktrail_output_init(), to see what happens. The
> result: it doesn't find anything :-( I could track problems down to the point
> that the SDVO i2c registers seem to be the wrong ones.
> 
> At the known offsets for i2c regs (0x5100 and on) I see only 0xffffffff, so
> probably these registers are not present or somewhere else on my platform.
> 
> Does anybody of you have any infos on this? How can I get further?
> Thanks for any help in advance!

There is an Intel driver with open kernel code and proprietary userspace
for the Imagination 3D engine (EMGD) although only for an out of
maintenance Fedora and for Meego and in both cases for ancient kernels.

The fully open driver is built by extracting the relevant information and
code from these releases.

http://www.intel.com/p/en_US/embedded/hwsw/software/emgd#download


If you unpack that it contains a tar ball which you can unpack which
contains the driver.

emgd/pal/sdvo 

looks kind of promising.

Re: SDVO on E6xx

[roman]

Hi Alan,

> There is an Intel driver with open kernel code and proprietary userspace for
> the Imagination 3D engine (EMGD) although only for an out of maintenance
> Fedora and for Meego and in both cases for ancient kernels.

I knew about EMGD, but not that there's code available for parts of it.

> The fully open driver is built by extracting the relevant information and
> code from these releases.

Ah, ok. Then I'll try to extract even a bit more ;-) Thanks very much for that
hint!

> If you unpack that it contains a tar ball which you can unpack which
> contains the driver.
>
> emgd/pal/sdvo
>
> looks kind of promising.

Got it now (it's common/drm/emgd_drm.tgz). 

I started to look around there, and emgd/display/pi/tnc/i2c_gmbus_tnc.c looks
as a good source of infos. At least it mentions E6xx quite often, and it uses
functions read/write_mmio_reg_tnc on TunnelCreek.

>From there I got to an interesting comment:

#ifdef CONFIG_TNC
/* Based on display port determine which mmio base to use:
 *       port_type == SDVO ==> use 0:3:0 device mmio
 *       port_type == LVDS ==> use 0:2:0 device mmio
 *       port_type == LPC  ==> use 0:31:0 device mmio
 */

Indeed, I have those additional PCI devices, and the BARs of 0:03.0 look much
like those of 0:02.0. It has PCI ID 8086:8182 and class 0x0400
(multimedia/video). And in BAR 0 at offset 0x5100 there are values that look
more like GMBUS...
(0:1f.0 exists, it declares itself as ISA bridge, and it has no BARs
assigned.)

Ok, I'll go down that road, poke around a bit there, and we'll see how far I
can get!

Roman