linux-kernel - Re: [PATCH] gma500: Skip bogus LVDS VBT mode and check for LVDS before adding backlight (try 2)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BANLkTi=tB+22Xen9StHkCdoEa8A2hqA2aA@mail.gmail.com>
Date:	Mon, 23 May 2011 15:03:00 +0200
From:	Patrik Jakobsson <patrik.r.jakobsson@...il.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	alan@...ux.intel.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] gma500: Skip bogus LVDS VBT mode and check for LVDS
 before adding backlight (try 2)

On Wed, May 11, 2011 at 11:55 PM, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
> On Wed, 11 May 2011 22:46:09 +0200
> Patrik Jakobsson <patrik.r.jakobsson@...il.com> wrote:
>
>> On the Fit-PC2 the VBT reports an invalid fixed panel mode for LVDS, this gets
>> in the way for SDVO. This patch makes VBT parsing skip the invalid mode. When
>> there is no LVDS output the backlight support crashes so the patch also checks
>> for this before enabling it.
>>
>> Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@...il.com>
>
> Looks good to me. I'll add that to the pile.
>
> Alan
>

Thanks Alan

Will it go into 2.6.40-rc1?

Now that output it somewhat working on the Fit-PC2 I've been looking
deeper into the SDVO code trying to understand why I'm not getting
proper modes for my display. At the moment it just defaults to
standard modes like 1024x768, 800x600 etc...

The issue is that I'm not getting any EDID from the display. Could be
the GMBus getting in the way or that the SDVO IO mapping isn't set up
properly before sending the SDVO_CMD_SET_CONTROL_BUS_SWITCH command.
I've been fiddling quite a lot with it but nothing seems to work, so
instead I took the current SDVO code (and large parts of the output
handling) from the i915 driver and crammed it into gma500. That did
the trick (though it's not currently talking to crtc abstraction
properly).

So my question is, do you think we should incorporate the new and more
feature complete output handling from the i915 into gma500? We might
even start sharing that code between gma500 and i915. If that is
something you like to avoid we can of course keep working on our
current output code.

Thanks
Patrik Jakobsson
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/