From: Tony Prisk <linux@prisktech.co.nz>
To: Dave Airlie <airlied@gmail.com>
Cc: "linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
dri-devel@lists.freedesktop.org
Subject: Re: EDID modes unavailable when no connector/crtc available at boot
Date: Sun, 11 Aug 2013 09:42:54 +0000 [thread overview]
Message-ID: <52075C9E.6040901@prisktech.co.nz> (raw)
In-Reply-To: <CAPM=9tzShWxZ-f=641r+-uc21JkY3kTeM2K=tsiB+OotNCnrQA@mail.gmail.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Tony Prisk <linux@prisktech.co.nz>
To: Dave Airlie <airlied@gmail.com>
Cc: "linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
dri-devel@lists.freedesktop.org
Subject: Re: EDID modes unavailable when no connector/crtc available at boot
Date: Sun, 11 Aug 2013 21:42:54 +1200 [thread overview]
Message-ID: <52075C9E.6040901@prisktech.co.nz> (raw)
In-Reply-To: <CAPM=9tzShWxZ-f=641r+-uc21JkY3kTeM2K=tsiB+OotNCnrQA@mail.gmail.com>
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
next prev parent reply other threads:[~2013-08-11 9:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-11 4:41 EDID modes unavailable when no connector/crtc available at boot Tony Prisk
2013-08-11 4:41 ` Tony Prisk
2013-08-11 8:42 ` Dave Airlie
2013-08-11 8:42 ` Dave Airlie
2013-08-11 9:42 ` Tony Prisk [this message]
2013-08-11 9:42 ` Tony Prisk
2013-08-11 10:06 ` Dave Airlie
2013-08-11 10:06 ` Dave Airlie
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=52075C9E.6040901@prisktech.co.nz \
--to=linux@prisktech.co.nz \
--cc=airlied@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-fbdev@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.