EDID modes unavailable when no connector/crtc available at boot

EDID modes unavailable when no connector/crtc available at boot

[Tony Prisk]

I am working on the HDMI driver for the i.MX6 as part of the larger DRM 
driver written by Sascha Hauer and need a little advice. I seem to be 
missing one important part of the subsystem that I haven't been able to 
resolve.

In my testing, powering on the system with only a HDMI cable connected 
works perfectly. Resolution is set to 1920x1080 as requested (with the 
framebuffer console at the same resolution).

If I boot up the system without an HDMI cable connected (or any other 
cable), I get the expected:
[    1.470273] imx_hdmi_connector_detect
[    1.470276] returned cable DISCONNECTED
[    1.470289] imx-drm imx-drm: No connectors reported connected with modes
[    1.470297] [drm] Cannot find any crtc or sizes - going 1024x768

When I connect the cable at a later time, all EDID detected modes are 
'truncated' to '<= 1024x768', but because I have a video=xxx in 
bootargs, the driver still seems to initialize to 1920x1080, but with a 
framebuffer of 1024x768.

I assume this is a mistake on my part, but I don't know what I'm missing 
that would cause it.

I see in drm_crtc_helper.c:drm_helper_mode_fill_fb_struct that the 
width/height are set to the initialized mode.
Later in drm_fb_helper.c:drm_fb_helper_hotplug_event, max_width if set 
to fb->width.

This is what causes the modes to be truncated when the HDMI connector is 
finally connected (max_width is now limited to 1024).


Suggestions appreciated.

Regards
Tony Prisk

Re: EDID modes unavailable when no connector/crtc available at boot

[Dave Airlie]

On Sun, Aug 11, 2013 at 2:41 PM, Tony Prisk <linux@prisktech.co.nz> wrote:
> I am working on the HDMI driver for the i.MX6 as part of the larger DRM
> driver written by Sascha Hauer and need a little advice. I seem to be
> missing one important part of the subsystem that I haven't been able to
> resolve.
>

fbcon is limited by boot sizes as at least with dynamic memory
management and how fbdev works resizing the allocation is nearly
impossible to do race free, since fbdev will hand out mmaps to
userspace and that stops you from ever moving anything once the device
is open.

But this is only for the fbdev emulation, a real kms application
should be able to use a larger size no problems.

Dave.

Re: EDID modes unavailable when no connector/crtc available at boot

[Tony Prisk]

On 11/08/13 20:42, Dave Airlie wrote:
> On Sun, Aug 11, 2013 at 2:41 PM, Tony Prisk <linux@prisktech.co.nz> wrote:
>> I am working on the HDMI driver for the i.MX6 as part of the larger DRM
>> driver written by Sascha Hauer and need a little advice. I seem to be
>> missing one important part of the subsystem that I haven't been able to
>> resolve.
>>
> fbcon is limited by boot sizes as at least with dynamic memory
> management and how fbdev works resizing the allocation is nearly
> impossible to do race free, since fbdev will hand out mmaps to
> userspace and that stops you from ever moving anything once the device
> is open.
>
> But this is only for the fbdev emulation, a real kms application
> should be able to use a larger size no problems.
>
> Dave.
It seems to be worse than just a fbcon issue as far as I can tell.

I am making an assumption, but I believe 
'/sys/class/drm/card0-HDMI-A-1/modes' should list all the supported 
modes of the connector (regardless of fbcon).
Using 'cat /sys/class/drm/card0-HDMI-A-1/modes', it appears the 
supported modes are being limited by fbcon

1) HDMI Cable connected at bootup (fb @ 1920x1080)
cat /sys/class/drm/card0-HDMI-A-1/modes
1920x1080
1280x720
1280x720
720x576
720x480
640x480

2) HDMI Cable NOT connected at bootup (fb @ 1024x768), cable is then 
connected after userspace has started (still in console)
cat /sys/class/drm/card0-HDMI-A-1/modes
720x576
720x480
640x480


Following back through the source:

static struct drm_connector_funcs imx_hdmi_connector_funcs = {
     .fill_modes = drm_helper_probe_single_connector_modes,
     ...
};

static struct drm_connector_helper_funcs imx_hdmi_connector_helper_funcs = {
     .get_modes = imx_hdmi_connector_get_modes,
     .mode_valid = imx_hdmi_connector_mode_valid,
     ...
};


It appears that only drm_helper_probe_single_connector_modes() calls 
.get_modes() and .mode_valid()
.fill_modes() is called from drm_fb_helper_probe_connector_modes(), 
which is called from drm_fb_helper_hotplug_event()
drm_fb_helper_hotplug_event() sets max_width to fb_helper->fb->width, 
and max_height to fb_helper->fb->height.
fb->width is 1024 if booted without the cable connected, hence the 
clipping of the values.

Regards
Tony Prisk

Re: EDID modes unavailable when no connector/crtc available at boot

[Dave Airlie]

On Sun, Aug 11, 2013 at 7:42 PM, Tony Prisk <linux@prisktech.co.nz> wrote:
> On 11/08/13 20:42, Dave Airlie wrote:
>>
>> On Sun, Aug 11, 2013 at 2:41 PM, Tony Prisk <linux@prisktech.co.nz> wrote:
>>>
>>> I am working on the HDMI driver for the i.MX6 as part of the larger DRM
>>> driver written by Sascha Hauer and need a little advice. I seem to be
>>> missing one important part of the subsystem that I haven't been able to
>>> resolve.
>>>
>> fbcon is limited by boot sizes as at least with dynamic memory
>> management and how fbdev works resizing the allocation is nearly
>> impossible to do race free, since fbdev will hand out mmaps to
>> userspace and that stops you from ever moving anything once the device
>> is open.
>>
>> But this is only for the fbdev emulation, a real kms application
>> should be able to use a larger size no problems.
>>
>> Dave.
>
> It seems to be worse than just a fbcon issue as far as I can tell.
>
> I am making an assumption, but I believe
> '/sys/class/drm/card0-HDMI-A-1/modes' should list all the supported modes of
> the connector (regardless of fbcon).
> Using 'cat /sys/class/drm/card0-HDMI-A-1/modes', it appears the supported
> modes are being limited by fbcon
>
> 1) HDMI Cable connected at bootup (fb @ 1920x1080)
> cat /sys/class/drm/card0-HDMI-A-1/modes
> 1920x1080
> 1280x720
> 1280x720
> 720x576
> 720x480
> 640x480
>
> 2) HDMI Cable NOT connected at bootup (fb @ 1024x768), cable is then
> connected after userspace has started (still in console)
> cat /sys/class/drm/card0-HDMI-A-1/modes
> 720x576
> 720x480
> 640x480
>
>
> Following back through the source:
>
> static struct drm_connector_funcs imx_hdmi_connector_funcs = {
>     .fill_modes = drm_helper_probe_single_connector_modes,
>     ...
> };
>
> static struct drm_connector_helper_funcs imx_hdmi_connector_helper_funcs = {
>     .get_modes = imx_hdmi_connector_get_modes,
>     .mode_valid = imx_hdmi_connector_mode_valid,
>     ...
> };
>
>
> It appears that only drm_helper_probe_single_connector_modes() calls
> .get_modes() and .mode_valid()
> .fill_modes() is called from drm_fb_helper_probe_connector_modes(), which is
> called from drm_fb_helper_hotplug_event()
> drm_fb_helper_hotplug_event() sets max_width to fb_helper->fb->width, and
> max_height to fb_helper->fb->height.
> fb->width is 1024 if booted without the cable connected, hence the clipping
> of the values.

fill_modes is also called from the drm_crtc.c userspace interface, all
the functions in drm_fb_helper are for fbdev/con use, the fact sysfs
is wrong is only a side effect.

Userspace should get a full list of modes, try using the modetest
application which I think should work.

Dave.