From: Peter Jones <pjones@redhat.com>
To: Brian Maly <bmaly@redhat.com>
Cc: mouli@linux.intel.com, adaplas@pol.net,
mm-commits@vger.kernel.org, ying.huang@intel.com,
linux-fbdev-devel@lists.sourceforge.net,
akpm@linux-foundation.org
Subject: Re: + efifb-dmi-set-video-type.patch added to -mm tree
Date: Tue, 31 Mar 2009 09:57:21 -0400 [thread overview]
Message-ID: <49D22141.3090804@redhat.com> (raw)
In-Reply-To: <49D159C7.2070503@redhat.com>
On 03/30/2009 07:46 PM, Brian Maly wrote:
> Adding linux-fbdev-devel and Antonino Daplas to the CC list...
>
Looks good to me.
Signed-of-by: Peter Jones <pjones@redhat.com>
> Brian
>
> akpm@linux-foundation.org wrote:
>> The patch titled
>> efifb: dmi set video type
>> has been added to the -mm tree. Its filename is
>> efifb-dmi-set-video-type.patch
>>
>> Before you just go and hit "reply", please:
>> a) Consider who else should be cc'ed
>> b) Prefer to cc a suitable mailing list as well
>> c) Ideally: find the original patch on the mailing list and do a
>> reply-to-all to that, adding suitable additional cc's
>>
>> *** Remember to use Documentation/SubmitChecklist when testing your
>> code ***
>>
>> See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
>> out what to do about this
>>
>> The current -mm tree may be found at
>> http://userweb.kernel.org/~akpm/mmotm/
>>
>> ------------------------------------------------------
>> Subject: efifb: dmi set video type
>> From: Brian Maly <bmaly@redhat.com>
>>
>> The current logic for dmi matching in efifb does not allow efifb to load
>> on all hardware that we can dmi match for.
>>
>> For a real world example, boot with elilo (3.7 or 3.8 vanilla) and on a
>> Apple (MacBook) and EFI framebuffer driver will not load (you will
>> have no
>> video). This specific hardware is efi v1.10, so we have UGA and not
>> GOP. Without special bootloader magic (i.e. extra elilo patches for UGA
>> graphics detection) no screen info will be passed to the kernel and as a
>> result efifb will not load.
>>
>> This patch allows the dmi match to happen by moving it to earlier in
>> efifb_init, and sets the video type (in set_system) so that efifb can
>> load
>> when we have a valid dmi match and already know the specifics of the
>> hardware.
>>
>> Without this patch the efifb driver will fail to load in the event screen
>> info is not found and passed in by the bootloader, being that we will
>> never get to look for a dmi match. A primary reason for matching with
>> dmi
>> is because not all bootloaders detect the video info properly. The
>> solution is that in the event of a dmi match, we should set
>> screen_info.orig_video_isVGA. Most bootloaders fail to set screen
>> info on
>> Apple hardware, and this is a big problem for people who use Apple
>> hardware.
>>
>> Tested on a MacBook SantaRosa with elilo-3.8 (vanilla) and resolves the
>> issue, the dmi match now works, EFI framebuffer now loads and video
>> works.
>>
>> Signed-off-by: Brian Maly <bmaly@redhat.com>
>> Acked-by: Huang Ying <ying.huang@intel.com>
>> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
>> Cc: Chandramouli Narayanan <mouli@linux.intel.com>
>> Cc: Peter Jones <pjones@redhat.com>
>> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>> ---
>>
>> drivers/video/efifb.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff -puN drivers/video/efifb.c~efifb-dmi-set-video-type
>> drivers/video/efifb.c
>> --- a/drivers/video/efifb.c~efifb-dmi-set-video-type
>> +++ a/drivers/video/efifb.c
>> @@ -129,6 +129,8 @@ static int set_system(const struct dmi_s
>> screen_info.lfb_width = info->width;
>> if (screen_info.lfb_height == 0)
>> screen_info.lfb_height = info->height;
>> + if (screen_info.orig_video_isVGA == 0)
>> + screen_info.orig_video_isVGA = VIDEO_TYPE_EFI;
>>
>> return 0;
>> }
>> @@ -374,9 +376,10 @@ static int __init efifb_init(void)
>> int ret;
>> char *option = NULL;
>>
>> + dmi_check_system(dmi_system_table);
>> +
>> if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
>> return -ENODEV;
>> - dmi_check_system(dmi_system_table);
>>
>> if (fb_get_options("efifb", &option))
>> return -ENODEV;
>> _
>>
>> Patches currently in -mm which might be from bmaly@redhat.com are
>>
>> efifb-dmi-set-video-type.patch
>>
>>
------------------------------------------------------------------------------
prev parent reply other threads:[~2009-03-31 14:00 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200903302249.n2UMn89O012955@imap1.linux-foundation.org>
2009-03-30 23:46 ` + efifb-dmi-set-video-type.patch added to -mm tree Brian Maly
2009-03-31 13:57 ` Peter Jones [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49D22141.3090804@redhat.com \
--to=pjones@redhat.com \
--cc=adaplas@pol.net \
--cc=akpm@linux-foundation.org \
--cc=bmaly@redhat.com \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=mm-commits@vger.kernel.org \
--cc=mouli@linux.intel.com \
--cc=ying.huang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).