Linaro images should utilize EDID

Bug #660604 reported by Tom Gall
28
This bug affects 2 people
Affects Status Importance Assigned to Milestone
linaro-landing-team-ti
Triaged
Low
Unassigned

Bug Description

For driving displays linaro images should utilize EDID (Extended Display Information Data) to determine what resolution to use.

On the kernel command line there is :

console=tty0 console=ttyS2,115200n8 earlyprintk fixrtc nocompcache root=UUID=b
422caa0-f6ce-4de0-ab3e-41e8bfa76b01 rootwait ro vram=12M omapfb.debug=y omapfb.m
ode=dvi:1280x720MR-16@60

On linaro-alip for instance on my 1280x1024 LCD panels, the 1280x720 resolution looks kinda awful as a result.

Tags: linaro
Revision history for this message
Steve Langasek (vorlon) wrote :

AIUI this is a limitation of the omapfb driver; assigning to the kernel.

affects: linaro → linux-linaro
Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

https://blueprints.edge.launchpad.net/ubuntu/+spec/mobile-m-omap-edid-autodetection looks relevant; sadly mostly postponed but suggests rsalveti is the man to talk to :-)

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

The status appears to be that rsalveti has grotty code that works (http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=shortlog;h=refs/heads/omap3-edid-parsing) but is too busy working on omap4 stuff to work on this currently.

Changed in linux-linaro:
status: New → Triaged
importance: Undecided → Low
tags: added: linaro
Revision history for this message
Mounir Bsaibes (mounir-bsaibes) wrote :

Nico, assigning this one to you, as Tom said it needs patches applied. Tom does not know which patches at the moment.

Changed in linux-linaro:
assignee: nobody → Nicolas Pitre (npitre)
Changed in linux-linaro:
assignee: Nicolas Pitre (npitre) → John Rigby (jcrigby)
Revision history for this message
Far McKon (far-mckon) wrote :

Related code from BugLabs may be of useful as a reference as well.

Raw:
https://github.com/buglabs/bug20-2.6.35-linaro/raw/fmck_video/drivers/bmi/pims/video/bmi_video.c

Git interface:
https://github.com/buglabs/bug20-2.6.35-linaro/blob/fmck_video/drivers/bmi/pims/video/bmi_video.c

Functions bmi_video_probe and enable_dvi may be of interest.

Revision history for this message
Ricardo Salveti (rsalveti) wrote :

I ported the DRM driver from OMAP 4 and improved the DVI EDID detection, can find the patches at:
http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-natty.git;a=shortlog;h=refs/heads/omap3-drm

Currently I'm using the Ubuntu tree as base, but should be quite easy to integrate the patches into Linaro's tree.

With this kernel I'm now able to get 1400x900@60-32bpp with my full hd monitor (omap 3 pixel clock can't support a lot more than that).

You can also find the deb files at http://people.canonical.com/~rsalveti/omap3-drm/

Please give it a try and see if it works fine, then I can send the pull request to Linaro.

Revision history for this message
Ricardo Salveti (rsalveti) wrote :

Bug requesting inclusion at Ubuntu's kernel: bug 753071

John Rigby (jcrigby)
Changed in linux-linaro:
assignee: John Rigby (jcrigby) → nobody
Revision history for this message
Andy Doan (doanac) wrote :

I just took Ricardo's changes and rebased them onto the current Linaro 2.6.38 tree. The HEAD of that tree is currently:

   7b4af25469a8a4b19feb2549777fed3120a4978f
   ARM: 6868/1: Preserve the VFP state during fork

The changes are in my branch:
  git://git.linaro.org/people/doanac/linux-linaro-2.6.38.git omap-edid

I added a fix for a NULL pointer issue I was hitting and support for Overo. It appears to be working pretty well on my Overo.

I don't know this area of code well, so I can't really speculate on whether or not its in shape to be included upstream

Revision history for this message
Ricardo Salveti (rsalveti) wrote : Re: [Bug 660604] Re: Linaro images should utilize EDID

On Wed, Apr 13, 2011 at 9:58 PM, Andy Doan <email address hidden> wrote:
> I just took Ricardo's changes and rebased them onto the current Linaro 2.6.38 tree. The HEAD of that tree is currently:
>
>   7b4af25469a8a4b19feb2549777fed3120a4978f
>   ARM: 6868/1: Preserve the VFP state during fork
>
> The changes are in my branch:
>  git://git.linaro.org/people/doanac/linux-linaro-2.6.38.git  omap-edid
>
> I added a fix for a NULL pointer issue I was hitting and support for
> Overo. It appears to be working pretty well on my Overo.
>
> I don't know this area of code well, so I can't really speculate on
> whether or not its in shape to be included upstream

The driver is not that complex, but I'd say it probably needs some
more love before sending upstream.

Will try to generate a simpler patch series, to have just the edid
part implemented, so we can start trying send them upstream to get
more feedback.

Nice to know it also worked fine for your Overo.

Fathi Boudra (fboudra)
Changed in linux-linaro:
assignee: nobody → Ricardo Salveti (rsalveti)
Revision history for this message
Ricardo Salveti (rsalveti) wrote :

The new DRM driver is already included at npitre's tree, also packaged by John and available at https://launchpad.net/~linaro-maintainers/+archive/kernel (2.6.38-1003.4~ppa2). It should work for both OMAP 3 and OMAP 4.

This bug says to include EDID support at the Linaro images, not specifying for which board. Should we change this but to be OMAP specific or simply opening it against each supported kernel flavor by linux-linaro package?

Revision history for this message
Tom Gall (tom-gall) wrote :

I would advocate all boards as best can. I can't think of a situation where hard coded display resolutions would be considered acceptable save for during bringup activities.

Revision history for this message
Linus Walleij (triad) wrote :

Moving to TI landing team.

affects: linux-linaro → linaro-landing-team-ti
Revision history for this message
warmcat (andy-warmcat) wrote :

Hello Linus.... there is no TI Landing Team any more.

Please let whoever had the great idea to send these bugs to a nonexistent team know.

Changed in linaro-landing-team-ti:
assignee: Ricardo Salveti (rsalveti) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.