TI OMAP4 fixing patches
Ricardo Salveti de Araujo
ricardo.salveti at canonical.com
Sat Sep 4 06:46:37 UTC 2010
On Sat, 2010-09-04 at 14:21 +0800, Bryan Wu wrote:
> Hiya,
>
> I got 10+ bug fixing patches from Sebastien, which are looks good to
> me. And it is necessary for our ti-omap4, since it fixed several bugs.
> My git tree is here:
> http://kernel.ubuntu.com/git?p=roc/ubuntu-maverick.git;a=shortlog;h=refs/heads/ti-omap4
> git://kernel.ubuntu.com/roc/ubuntu-maverick ti-omap4
>
> And the cross compiled kernel is here:
> http://people.canonical.com/~roc/kernel/omap4/
>
> Please help to test on ES2.0 board.
Today I rebased my tree with the same patches and was able to test with
both ES2 6 and 8 layer boards.
Seems to be working fine, but I got a regression while detecting my
monitor. The change from "Fix detection loop issue on some monitors" to
"OMAP4:DSS:HDMI: don't handle DISCONNECT if we've already got a
CONNECT" (better patch) made my monitor to disconnect/connect while
detecting the monitor. As a side effect it changed the resolution to
640x480 and then to 1920x1080, confusing the X server.
After talking with Rob Clark he said the old patch fixed the
disconnect/connect for some monitors but broke others, that's why he
created this new attempt to have a better fix for this issue.
http://www.flickr.com/photos/rsalveti/4932601965/ shows the bug, and it
happens because when X11 starts, the resolution is still 640x480, but
gets changed later on. Restarting X11 makes my screen behaves normally
again.
While I agree this could be fixed by implementing dynamic X11 resolution
at the fbdev driver, the issue is also related with the kernel and needs
to be fixed.
Besides the screen issue I also got a weird bus error while using 1gb
and trying to build the kernel with both boards:
/home/ubuntu/kernel/ubuntu-maverick/include/linux/page-flags.h:256:
internal compiler error: Bus error
[3513.993927] Unhandled fault: imprecise external abort (0x1406) at
0x00065028
Sebastien confirmed that this issue doesn't happen when using just
mem=460M at the kernel cmdline, indicating that the bug could be related
with highmem support (1gb).
Cheers,
--
Ricardo Salveti de Araujo
More information about the kernel-team
mailing list