boot delay with drm_kms_helper.edid_firmware

Robert Kuhn robert at ku.hn
Wed Jan 14 07:21:21 PST 2015


Hi,

thanks for the answer. I believe I got it. I did not know that there are
already some edids build into the kernel. What I did try to achieve is that
my edid placed in the file system (under /lib/firmware/edid/) is loaded on
boot. I named my special edid file also 1024x786.bin so I never noticed
that my file wasn't loaded. Instead the edid build into the kernel was
used. Got it.

For testing I renamed my edid to myedid.bin. Now I got (of course):
[    0.767201] pinctrl-single 44e10800.pinmux: pin 44e10854 already
requested by 44e10800.pinmux; cannot claim for gpio-leds.8
[    0.778895] pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.8) status
-22
[    0.786166] pinctrl-single 44e10800.pinmux: could not request pin 21 on
device pinctrl-single
[   61.001555] [drm:edid_load] *ERROR* Requesting EDID firmware
"edid/myedid.bin" failed (err=-2)

But there is the file:
debian at beaglebone:~$ ls  -ls /lib/firmware/edid/
total 4
4 -rw-r--r-- 1 debian debian 128 Feb 17  2014 myedid.bin


So with 3.8. its not possible to tell the kernel to load the buildin first?
Okay, then I will try the v3.18.x branch for Beaglebone.

Thanks!


2015-01-14 14:32 GMT+01:00 Jani Nikula <jani.nikula at linux.intel.com>:

> On Wed, 14 Jan 2015, Robert Kuhn <spamhalde2 at fastmail.fm> wrote:
> > Hi,
> >
> > thanks for the answer. This is my kernel config:
> >
> >     developer at ubuntu:~/beaglebone/debian-fw/bb-kernel/KERNEL$ grep
> > FW_LOADER_USER_HELPER .config
>
> Ah, you wouldn't have that since it's been added in v3.9.
>
> >     developer at ubuntu:~/beaglebone/debian-fw/bb-kernel/KERNEL$ grep DRM
> > .config
> >     CONFIG_DRM=y
> >     CONFIG_DRM_KMS_HELPER=y
> >     CONFIG_DRM_LOAD_EDID_FIRMWARE=y
> >     CONFIG_DRM_GEM_CMA_HELPER=y
> >     CONFIG_DRM_KMS_CMA_HELPER=y
> >     # CONFIG_DRM_I2C_CH7006 is not set
> >     # CONFIG_DRM_I2C_SIL164 is not set
> >     CONFIG_DRM_I2C_NXP_TDA998X=y
> >     # CONFIG_DRM_UDL is not set
> >     CONFIG_DRM_TILCDC=y
> >     # CONFIG_DRM_OMAP is not set
> >
> >
> > I am quite sure that in the end kernel finds firmware because otherwise
> the
> > display isn't working. I only get a image on the display if my edid file
> is
> > used.
>
> Okay, got it:
>
> [   62.751321] [drm] Got built-in EDID base block and 0 extensions from
> "edid/1024x768.bin" for connector "HDMI-A-1"
>
> the "built-in" here tells us the the EDID is embedded in the
> drm_kms_helper module (drivers/gpu/drm/drm_edid_load.c). But first the
> v3.8 kernel attempts to load the EDID from the filesystem, and fails,
> then delegates to the (now deprecated) user mode helper, which fails
> after a timeout. This is the delay you see. (See abb139e75c2c firmware:
> teach the kernel to load firmware files directly from the filesystem.)
>
> Starting from v3.13 the EDID firmware loader tries the built-in ones
> first, bypassing the regular firmware loader completely if one is
> found. (See 9066f83c055e drm: Try loading builtin EDIDs first.)
>
> Your options are upgrading to at least v3.13 (but hey, why not go all
> the way to v3.18 or later while at it?! ;) or making sure you have the
> EDID firmware in the filesystem so that the kernel can load it
> directly. The path is a concatenation of one of the below (from
> drivers/base/firmware_class.c; fw_path_para comes from
> firmware_class.path module parameter) and the firmware name, i.e.
> drm_kms_helper.edid_firmware in this case:
>
> static const char * const fw_path[] = {
>         fw_path_para,
>         "/lib/firmware/updates/" UTS_RELEASE,
>         "/lib/firmware/updates",
>         "/lib/firmware/" UTS_RELEASE,
>         "/lib/firmware"
> };
>
> Just put your edid to, say, /lib/firmware/path/to/edid and add module
> parameter drm_kms_helper.edid_firmware=path/to/edid.
>
> And thus concludes today's lesson in Linux archeology. Thank you for
> your attention. ;)
>
> BR,
> Jani.
>
>
> >
> > Robert
> >
> >
> > 2015-01-14 11:40 GMT+01:00 Jani Nikula <jani.nikula at linux.intel.com>:
> >
> >> On Wed, 14 Jan 2015, Robert Kuhn <spamhalde2 at fastmail.fm> wrote:
> >> > using drm_kms_helper.edid_firmware the boot time is much longer
> (~1min)
> >> > than without it. I attach the boot log ("drm.debug=0x06"), one time
> >> > with drm_kms_helper.edid_firmware, one time without.
> >> >
> >> > What could be the problem?
> >> >
> >> > I am using Kernel 3.8.13-bone69 on a Beaglebone black. I
> >> > used drm_kms_helper.edid_firmware before and never saw this issue.
> >>
> >> Just a guess, kernel doesn't find the firmware and you fallback to user
> >> mode helper, which is no longer supported by udev.
> >>
> >> Try ensuring you have the path right, and disable FW_LOADER_USER_HELPER
> >> kernel config option.
> >>
> >> HTH,
> >> Jani.
> >>
> >> --
> >> Jani Nikula, Intel Open Source Technology Center
> >>
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Jani Nikula, Intel Open Source Technology Center
>



-- 
Mit freundlichen Grüßen
Robert W. Kuhn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150114/1df41c95/attachment-0001.html>


More information about the dri-devel mailing list