linux-kernel - Re: gma500: Cannot find any crtc or sizes

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]

Date:	Wed, 13 Jun 2012 11:25:03 +0200
From:	Christian Gmeiner <christian.gmeiner@...il.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Patrik Jakobsson <patrik.r.jakobsson@...il.com>,
	linux-kernel@...r.kernel.org, Greg Kroah-Hartman <greg@...ah.com>
Subject: Re: gma500: Cannot find any crtc or sizes - going 1024x768

2012/6/12 Christian Gmeiner <christian.gmeiner@...il.com>:
> 2012/6/12 Alan Cox <alan@...rguk.ukuu.org.uk>:
>>> Was there a special reason for 0x4108 to be left out in the IS_MRST macro?
>>> To me it looks like the bitmask should have been updated in commit:
>>>
>>> gma500: Add the E6xx PCI identifier we are missing
>>> 56125db1eecf8d34d84f7925686110d90724edf0
>>>
>>> If this is the case, I'll send a proper patch since this also applies to
>>> stable 3.3.x and 3.4.x
>>
>> Firstly it should never matter - there are no Moorestown devices in
>> circulation. E600T is very similar to Oaktrail.
>>
>> So the real question here seems to be why does the IS_MRST macro matter.
>> What weird firmware is involved here ?
>
> My company is using these cpu bords for our products:
> http://www.congatec.com/en/products/qseven/dView/conga-qa6.html
>
> With firmware you mean BIOS or VBios or ...? If you tell me what you need, I may
> ask our supplier for more informations. I can tell you that the
> following options can be
> changed in the BIOS regarding gfx - see
> https://www.dropbox.com/s/btlciurz0ih4fhu/IMG_20120612_143431.jpg
>

Here are some more informations. There seems to be a scaling problem.
If i compare gma500 and the vesa framebuffer driver I see that gma500 shows
the desktop "scaled" up --> not the whole desktop is on the screen. It
gets better
if i remove the video="..." parameter from kernel cmdline, but it
still is too big for
the screen.

I really would love to get this beast up an running... so I will
provide as much informations
as needed - just ask :)

---
Christian Gmeiner, MSc
--
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/