We rely on VBT DDI port info for eDP detection on GEN9 platforms and
above. This breaks GEN9 platforms which don't have VBT because port A
eDP now defaults to false. Fix this by defaulting to true when VBT is
missing.
Fixes: commit a98d9c1d7e9b ("drm/i915/ddi: Rely on VBT DDI port info for eDP detection")
Signed-off-by: Thomas Preston <[email protected]>
---
drivers/gpu/drm/i915/intel_bios.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios.c
index 1faa494e2bc9..efbbfb64b55f 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1629,6 +1629,7 @@ init_vbt_missing_defaults(struct drm_i915_private *dev_priv)
info->supports_dvi = (port != PORT_A && port != PORT_E);
info->supports_hdmi = info->supports_dvi;
info->supports_dp = (port != PORT_E);
+ info->supports_edp = (port == PORT_A);
}
}
--
2.11.0
The subject should probably have "drm/i915/bios" or "drm/i915/vbt".
On Wed, 06 Mar 2019, Thomas Preston <[email protected]> wrote:
> We rely on VBT DDI port info for eDP detection on GEN9 platforms and
> above. This breaks GEN9 platforms which don't have VBT because port A
> eDP now defaults to false. Fix this by defaulting to true when VBT is
> missing.
Please include more details about the machine that doesn't have VBT. Why
don't you have VBT?
Personally I think it was a mistake originally to make guesses about the
outputs in absence of VBT on DDI platforms, because we can never get the
generic guesses right across all ports and all products. And for the
record, that was the result of an easy choice to enable developers way
back when, and forgotten.
Certainly eDP is more likely than something else on port A. But this
will break any outlier products without VBT that have a non-eDP output
on port A. I guess it's a risk we have to take, and handle the fallout
later.
Acked-by: Jani Nikula <[email protected]>
> Fixes: commit a98d9c1d7e9b ("drm/i915/ddi: Rely on VBT DDI port info for eDP detection")
The Fixes: format does *not* include "commit" text.
BR,
Jani.
> Signed-off-by: Thomas Preston <[email protected]>
> ---
> drivers/gpu/drm/i915/intel_bios.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios.c
> index 1faa494e2bc9..efbbfb64b55f 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1629,6 +1629,7 @@ init_vbt_missing_defaults(struct drm_i915_private *dev_priv)
> info->supports_dvi = (port != PORT_A && port != PORT_E);
> info->supports_hdmi = info->supports_dvi;
> info->supports_dp = (port != PORT_E);
> + info->supports_edp = (port == PORT_A);
> }
> }
--
Jani Nikula, Intel Open Source Graphics Center
Hi,
Thanks for looking at this.
On 07/03/2019 08:18, Jani Nikula wrote:
>
> The subject should probably have "drm/i915/bios" or "drm/i915/vbt".
>
Noted
> On Wed, 06 Mar 2019, Thomas Preston <[email protected]> wrote:
>> We rely on VBT DDI port info for eDP detection on GEN9 platforms and
>> above. This breaks GEN9 platforms which don't have VBT because port A
>> eDP now defaults to false. Fix this by defaulting to true when VBT is
>> missing.
>
> Please include more details about the machine that doesn't have VBT. Why
> don't you have VBT?
>
We have upgraded from an earlier kernel version (an Intel BSP on v4.1)
which did not require VBT and so our BIOS isn't set up correctly. The
BIOS doesn't set ASLS and fails to find ACPI OpRegion:
[ 9.368433] [drm:intel_opregion_setup [i915]] graphic opregion physical addr: 0x0
[ 9.368490] [drm:intel_opregion_setup [i915]] ACPI OpRegion not supported!
So now our port A is DP instead of eDP. I was hoping a return to "default"
values would remedy this, but I think it's pretty clear now that we should
focus on fixing VBT.
I've found a default VBT in the BSP but not sure how to get it into BIOS.
If you could point me in the right direction here that would be really
useful!
> Personally I think it was a mistake originally to make guesses about the
> outputs in absence of VBT on DDI platforms, because we can never get the
> generic guesses right across all ports and all products. And for the
> record, that was the result of an easy choice to enable developers way
> back when, and forgotten.
>
> Certainly eDP is more likely than something else on port A. But this
> will break any outlier products without VBT that have a non-eDP output
> on port A. I guess it's a risk we have to take, and handle the fallout
> later.
>
> Acked-by: Jani Nikula <[email protected]>
>
>> Fixes: commit a98d9c1d7e9b ("drm/i915/ddi: Rely on VBT DDI port info for eDP detection")
>
> The Fixes: format does *not* include "commit" text.
>
I got that from scripts/checkpatch.pl but noted, thanks.
Kind regards,
Tom
On Thu, 07 Mar 2019, Thomas Preston <[email protected]> wrote:
> Hi,
> Thanks for looking at this.
>
> On 07/03/2019 08:18, Jani Nikula wrote:
>>
>> The subject should probably have "drm/i915/bios" or "drm/i915/vbt".
>>
>
> Noted
>
>> On Wed, 06 Mar 2019, Thomas Preston <[email protected]> wrote:
>>> We rely on VBT DDI port info for eDP detection on GEN9 platforms and
>>> above. This breaks GEN9 platforms which don't have VBT because port A
>>> eDP now defaults to false. Fix this by defaulting to true when VBT is
>>> missing.
>>
>> Please include more details about the machine that doesn't have VBT. Why
>> don't you have VBT?
>>
>
> We have upgraded from an earlier kernel version (an Intel BSP on v4.1)
> which did not require VBT and so our BIOS isn't set up correctly. The
> BIOS doesn't set ASLS and fails to find ACPI OpRegion:
>
> [ 9.368433] [drm:intel_opregion_setup [i915]] graphic opregion physical addr: 0x0
> [ 9.368490] [drm:intel_opregion_setup [i915]] ACPI OpRegion not supported!
>
> So now our port A is DP instead of eDP. I was hoping a return to "default"
> values would remedy this, but I think it's pretty clear now that we should
> focus on fixing VBT.
In the long run you'll have better control of what your specific product
does by using a VBT. However, I think we'll probably have to take the
patch anyway.
> I've found a default VBT in the BSP but not sure how to get it into BIOS.
> If you could point me in the right direction here that would be really
> useful!
There are dangers with default VBTs too. They might contain incorrect
information about the specific board you have. You'll also have to set
up the opregion, not just VBT.
I'm afraid I can't help you there. You already know where to look to see
how the kernel side expects things to work.
For testing, the i915.vbt_firmware module parameter is helpful, so you
don't need to change your BIOS to change the VBT.
BR,
Jani.
>
>> Personally I think it was a mistake originally to make guesses about the
>> outputs in absence of VBT on DDI platforms, because we can never get the
>> generic guesses right across all ports and all products. And for the
>> record, that was the result of an easy choice to enable developers way
>> back when, and forgotten.
>>
>> Certainly eDP is more likely than something else on port A. But this
>> will break any outlier products without VBT that have a non-eDP output
>> on port A. I guess it's a risk we have to take, and handle the fallout
>> later.
>>
>> Acked-by: Jani Nikula <[email protected]>
>>
>>> Fixes: commit a98d9c1d7e9b ("drm/i915/ddi: Rely on VBT DDI port info for eDP detection")
>>
>> The Fixes: format does *not* include "commit" text.
>>
>
> I got that from scripts/checkpatch.pl but noted, thanks.
>
> Kind regards,
> Tom
--
Jani Nikula, Intel Open Source Graphics Center
On 07/03/2019 10:34, Jani Nikula wrote:
>>> On Wed, 06 Mar 2019, Thomas Preston <[email protected]> wrote:
>>>> We rely on VBT DDI port info for eDP detection on GEN9 platforms and
>>>> above. This breaks GEN9 platforms which don't have VBT because port A
>>>> eDP now defaults to false. Fix this by defaulting to true when VBT is
>>>> missing.
>>>
>>> Please include more details about the machine that doesn't have VBT. Why
>>> don't you have VBT?
>>>
>>
>> We have upgraded from an earlier kernel version (an Intel BSP on v4.1)
>> which did not require VBT and so our BIOS isn't set up correctly. The
>> BIOS doesn't set ASLS and fails to find ACPI OpRegion:
>>
>> [ 9.368433] [drm:intel_opregion_setup [i915]] graphic opregion physical addr: 0x0
>> [ 9.368490] [drm:intel_opregion_setup [i915]] ACPI OpRegion not supported!
>>
>> So now our port A is DP instead of eDP. I was hoping a return to "default"
>> values would remedy this, but I think it's pretty clear now that we should
>> focus on fixing VBT.
>
> In the long run you'll have better control of what your specific product
> does by using a VBT. However, I think we'll probably have to take the
> patch anyway.
>
Would you like me to resubmit with the suggested changes?
>> I've found a default VBT in the BSP but not sure how to get it into BIOS.
>> If you could point me in the right direction here that would be really
>> useful!
>
> There are dangers with default VBTs too. They might contain incorrect
> information about the specific board you have. You'll also have to set
> up the opregion, not just VBT.
>
I believe OpRegion is being set up correctly with ACPI tables, but ASLS=0
(points to OpRegion) is quite suspicious. I need to do more digging around
how our BIOS is set up.
> I'm afraid I can't help you there. You already know where to look to see
> how the kernel side expects things to work.
>
> For testing, the i915.vbt_firmware module parameter is helpful, so you
> don't need to change your BIOS to change the VBT.
>
That's great thanks, I will work on VBT using this for now.
On Thu, 07 Mar 2019, Thomas Preston <[email protected]> wrote:
> Would you like me to resubmit with the suggested changes?
Nah, we can tweak the commit message while applying.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
On 07/03/2019 10:34, Jani Nikula wrote:
> There are dangers with default VBTs too. They might contain incorrect
> information about the specific board you have. You'll also have to set
> up the opregion, not just VBT.
>
> I'm afraid I can't help you there. You already know where to look to see
> how the kernel side expects things to work.
>
> For testing, the i915.vbt_firmware module parameter is helpful, so you
> don't need to change your BIOS to change the VBT.
Just to clarify, I couldn't get i915.vbt_firmware working with a broken
ACPI OpRegion as intel_opregion_setup() bails out before it reaches
intel_load_vbt_firmware(). I worked around it by moving the fw load but
this isn't a long-term solution.
I need to fix ACPI OpRegion / my BIOS before any of this will work.
diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_opregion.c
index 1d946240e55f..128a285a5337 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -971,6 +971,9 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
BUILD_BUG_ON(sizeof(struct opregion_asle) != 0x100);
BUILD_BUG_ON(sizeof(struct opregion_asle_ext) != 0x400);
+ if (intel_load_vbt_firmware(dev_priv) == 0)
+ goto out;
+
pci_read_config_dword(pdev, ASLS, &asls);
DRM_DEBUG_DRIVER("graphic opregion physical addr: 0x%x\n", asls);
if (asls == 0) {
@@ -1016,9 +1019,6 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
if (mboxes & MBOX_ASLE_EXT)
DRM_DEBUG_DRIVER("ASLE extension supported\n");
- if (intel_load_vbt_firmware(dev_priv) == 0)
- goto out;
-
if (dmi_check_system(intel_no_opregion_vbt))
goto out;
On Thu, 07 Mar 2019, Jani Nikula <[email protected]> wrote:
> On Thu, 07 Mar 2019, Thomas Preston <[email protected]> wrote:
>> Would you like me to resubmit with the suggested changes?
>
> Nah, we can tweak the commit message while applying.
Pushed to dinq, thanks for the patch.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center