boot delay with drm_kms_helper.edid_firmware

[Jani Nikula]

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