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
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.
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
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
- HDMI Cable connected at bootup (fb @ 1920x1080)
cat /sys/class/drm/card0-HDMI-A-1/modes 1920x1080 1280x720 1280x720 720x576 720x480 640x480
- 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.
dri-devel@lists.freedesktop.org
-
Dave Airlie -
Tony Prisk