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]>
---
diff --git a/drivers/staging/gma500/psb_drv.c b/drivers/staging/gma500/psb_drv.c
index 46ab028..dbc6e4f 100644
--- a/drivers/staging/gma500/psb_drv.c
+++ b/drivers/staging/gma500/psb_drv.c
@@ -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
diff --git a/drivers/staging/gma500/psb_intel_bios.c b/drivers/staging/gma500/psb_intel_bios.c
index 48ac8ba..417965d 100644
--- a/drivers/staging/gma500/psb_intel_bios.c
+++ b/drivers/staging/gma500/psb_intel_bios.c
@@ -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;
}
On Wed, 11 May 2011 22:46:09 +0200
Patrik Jakobsson <[email protected]> wrote:
> 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
On Wed, May 11, 2011 at 11:55 PM, Alan Cox <[email protected]> wrote:
> On Wed, 11 May 2011 22:46:09 +0200
> Patrik Jakobsson <[email protected]> wrote:
>
>> 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
>
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
> Will it go into 2.6.40-rc1?
I hope so.
> 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
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.
> 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.
> 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
On Mon, May 23, 2011 at 3:41 PM, Alan Cox <[email protected]> wrote:
>> 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
>
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