gma500: Skip bogus LVDS VBT mode and check for LVDS before adding backlight (try 2)
PATCH 1/1 gma500: Skip bogus LVDS VBT mode and check for LVDS before adding backlight (try 2)
On the Fit-PC2 the VBT reports an invalid fixed panel mode for LVDS, this gets in the way for SDVO. This patch makes VBT parsing skip the invalid mode. When there is no LVDS output the backlight support crashes so the patch also checks for this before enabling it.
---
drivers/staging/gma500/psb_drv.c +17 -1
@@ -542,6 +542,8 @@ static int psb_driver_load(struct drm_device *dev, unsigned long chipset)unsigned long irqflags;int ret = -ENOMEM ;uint32_t tt_pages; +struct drm_connector *connector; +struct psb_intel_output *psb_intel_output; dev_priv =kzalloc (sizeof (*dev_priv),GFP_KERNEL );if (dev_priv ==NULL )
@@ -663,7 +665,21 @@ static int psb_driver_load(struct drm_device *dev, unsigned long chipset)drm_kms_helper_poll_init (dev); } - ret =psb_backlight_init (dev); +/* Only add backlight support if we have LVDS output +* +* FIXME: Handle turning on LVDS at runtime +*/ +list_for_each_entry (connector, &dev->mode_config.connector_list, + head) { + psb_intel_output =to_psb_intel_output (connector); + +switch (psb_intel_output->type) { +case INTEL_OUTPUT_LVDS : + ret =psb_backlight_init (dev); +break ; + } + } +if (ret)return ret;#if 0
drivers/staging/gma500/psb_intel_bios.c +9 -4
@@ -154,10 +154,15 @@ static void parse_lfp_panel_data(struct drm_psb_private *dev_priv,fill_detail_timing_data (panel_fixed_mode, dvo_timing); - dev_priv->lfp_lvds_vbt_mode = panel_fixed_mode; - -DRM_DEBUG ("Found panel mode in BIOS VBT tables:\n" ); -drm_mode_debug_printmodeline (panel_fixed_mode); +if (panel_fixed_mode->htotal >0 && panel_fixed_mode->vtotal >0 ) { + dev_priv->lfp_lvds_vbt_mode = panel_fixed_mode; +DRM_DEBUG ("Found panel mode in BIOS VBT tables:\n" ); +drm_mode_debug_printmodeline (panel_fixed_mode); + }else { +DRM_DEBUG ("Ignoring bogus LVDS VBT mode.\n" ); + dev_priv->lvds_vbt =0 ; +kfree (panel_fixed_mode); + }return ; }
Quoted 6 lines · On Wed, 11 May 2011 22:46:09 +0200 Patrik Jakobsson…
On the Fit-PC2 the VBT reports an invalid fixed panel mode for LVDS, this gets in the way for SDVO. This patch makes VBT parsing skip the invalid mode. When there is no LVDS output the backlight support crashes so the patch also checks for this before enabling it.
Signed-off-by Patrik Jakobsson <[email protected]>
Looks good to me. I'll add that to the pile.
Alan
Quoted 8 lines · Alan Cox
Quoted 5 lines · On Wed, 11 May 2011 22:46:09 +0200 Patrik Jakobsson…
On the Fit-PC2 the VBT reports an invalid fixed panel mode for LVDS, this gets in the way for SDVO. This patch makes VBT parsing skip the invalid mode. When there is no LVDS output the backlight support crashes so the patch also checks for this before enabling it.
Quoted 6 lines
Quoted 1 line
Signed-off-by Patrik Jakobsson <[email protected]>Looks good to me. I'll add that to the pile.
Alan
Thanks Alan
Will it go into 2.6.40-rc1?
Now that output it somewhat working on the Fit-PC2 I've been looking deeper into the SDVO code trying to understand why I'm not getting proper modes for my display. At the moment it just defaults to standard modes like 1024x768, 800x600 etc...
The issue is that I'm not getting any EDID from the display. Could be the GMBus getting in the way or that the SDVO IO mapping isn't set up properly before sending the SDVO_CMD_SET_CONTROL_BUS_SWITCH command. I've been fiddling quite a lot with it but nothing seems to work, so instead I took the current SDVO code (and large parts of the output handling) from the i915 driver and crammed it into gma500. That did the trick (though it's not currently talking to crtc abstraction properly).
So my question is, do you think we should incorporate the new and more feature complete output handling from the i915 into gma500? We might even start sharing that code between gma500 and i915. If that is something you like to avoid we can of course keep working on our current output code.
Thanks
Patrik Jakobsson
Quoted 1 line
Will it go into 2.6.40-rc1?
I hope so.
Quoted 4 lines
The issue is that I'm not getting any EDID from the display. Could be the GMBus getting in the way or that the SDVO IO mapping isn't set up properly before sending the
SDVO_CMD_SET_CONTROL_BUS_SWITCHcommand. I've been fiddling quite a lot with it but nothing seems to work, so
I'm also not clear if the i²c mapping is always the same. Certainly this is a problem on Moorestown/Oaktrail in some cases.
Quoted 4 lines
instead I took the current SDVO code (and large parts of the output handling) from the i915 driver and crammed it into gma500. That did the trick (though it's not currently talking to crtc abstraction properly).
Interesting.
Quoted 5 lines
So my question is, do you think we should incorporate the new and more feature complete output handling from the i915 into gma500? We might even start sharing that code between gma500 and i915. If that is something you like to avoid we can of course keep working on our current output code.
Importing the code seems reasonable. KeithP didn't want it shared when I asked him, but importing it and having the same code in many areas is the first step to sharing anyway.
Alan
Quoted 6 lines · Alan Cox
Quoted 5 lines
So my question is, do you think we should incorporate the new and more feature complete output handling from the i915 into gma500? We might even start sharing that code between gma500 and i915. If that is something you like to avoid we can of course keep working on our current output code.
Quoted 6 lines
Importing the code seems reasonable. KeithP didn't want it shared when I asked him, but importing it and having the same code in many areas is the first step to sharing anyway.
Alan
Ok, I'll get back to you (probably after the weekend) when I've had some more time to work on this.
Anyone who would like to look more closely on the LVDS parts of gma500 vs i915 are free to join in.
Thanks
Patrik Jakobsson