Re: Issue with a SOYO monitor and Trimslice

[Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 3528 bytes --]

On Mon, Nov 11, 2013 at 05:49:42AM -0600, Steev Klimaszewski wrote:
> On Mon, Nov 11, 2013 at 3:46 AM, Thierry Reding
> <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Sun, Sep 22, 2013 at 06:26:11AM -0500, Steev Klimaszewski wrote:
> > Hi Steev,
> >
> > I just remembered this thread from a while ago. There were some patches
> > to fix DVI support that will be merged into 3.13. You can find them in
> > the drm/for-next branch here:
> >
> >         http://cgit.freedesktop.org/tegra/linux
> >
> > Specifically:
> >
> >         http://cgit.freedesktop.org/tegra/linux/commit/?h=drm/for-next&id=9f1591231aa72edd2cdad507520ad4088682262a
> >
> > I'm not sure if it fixes the issue that you were seeing, but it might be
> > worth a try.
> >
> > Thierry
> 
> Hi Thierry,
> 
> Sadly, it doesn't seem to have changed anything.  What I did here was:
> 
> git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> cd linux
> git remote add nvidia git://anongit.freedesktop.org/tegra/linux
> git fetch --all
> git merge nvidia/drm/for-next
> Edited the files that had conflicts which were all in i915 so for this
> use case, i'm pretty sure it's fine that I ignored what the proper
> solution should be
> make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- tegra_defconfig
> make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j8
> ... modules_install to the root partition of the sdcard
> copied the dtb and zImage to boot partition of the sdcard
> popped the sdcard in to the Trimslice
> 
> my boot.scr file looks like:
> 
> setenv bootargs rootfstype=ext4 drm.debug=0xf root=/dev/mmcblk0p2
> rootwait console=ttyS0,115200n8;
> ext2load mmc 0:1 ${loadaddr} zImage;
> ext2load mmc 0:1 ${fdt_high} tegra20-trimslice.dtb;
> bootz ${loadaddr} - ${fdt_high}

That all looks good.

> and dmesg | grep drm is:
[...]
> 23:"1680x1050" 60 146200 1680 1784 1960 2240 1050 1053 1059 1089 0x48
> 0xa
> [    1.132767] [drm:drm_crtc_helper_set_mode], [CRTC:3]
> [    1.152805] [drm:drm_vblank_get], enabling vblank on crtc 0, ret: 0
> [    1.152811] [drm:drm_update_vblank_count], enabling vblank
> interrupts on crtc 0, missed 0
> [    1.154849] [drm:tegra_crtc_setup_clk], rate: 292000000, div: 1

I certainly looks like the clock is properly set up here. The rate here
should be double that of the required frequency of the mode (146 MHz).

> And Out of Range still shows up on the screen.
> 
> This is with an HDMI -> DVI cable plugged in to the HDMI port.

I can't make heads or tails of it. I remember seeing out-of-range when
the pixel clock wasn't running at the proper rate, or sometimes even
when the AVI infoframes were wrong... I don't think either of those
should be a problem, though.

> When plugged in to the DVI-D port, the drm subsystem doesn't even see it.
> 
> Are there any plans to enable the actual DVI-D port on the Trimslice?

It's currently not hooked up in the device tree. I vaguely remember
someone (me?!) posting untested patches to make that work, but I can't
find them. Judging by the TrimSlice vendor kernel it seems like there's
no hotplug detect for DVI-D and there's a GPIO that controls whether or
not the DVI transceiver is enabled (GPIO P5). There's no way to control
that GPIO from the driver currently, but wiring up the DDC and the RGB
node should be simple.

The variant of the TrimSlice that I have doesn't come with the DVI
connector, so I can't test this unfortunately.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]