On Tue, Feb 23, 2021 at 03:34:51PM +0200, Jani Nikula wrote:
On Wed, 17 Feb 2021, Lucas De Marchi <lucas.demarchi@xxxxxxxxx> wrote:
On Wed, Feb 17, 2021 at 09:49:57PM +0200, Jani Nikula wrote:
On Wed, 17 Feb 2021, Lucas De Marchi <lucas.demarchi@xxxxxxxxx> wrote:
On Wed, Feb 17, 2021 at 09:23:00AM -0800, Lucas De Marchi wrote:
On Wed, Feb 17, 2021 at 07:03:34PM +0200, Jani Nikula wrote:
With the defaults limited to non-TypeC ports in commit 828ccb31cf41
("drm/i915/icl: Add TypeC ports only if VBT is present"), this should be
a no-op, but clarifies the code and prepares for subsequent changes.
Cc: Lucas De Marchi <lucas.demarchi@xxxxxxxxx>
Cc: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
Signed-off-by: Jani Nikula <jani.nikula@xxxxxxxxx>
---
drivers/gpu/drm/i915/display/intel_bios.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c b/drivers/gpu/drm/i915/display/intel_bios.c
index e9cb15aa2f5a..b9d99324d66d 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -2057,11 +2057,12 @@ static void
init_vbt_missing_defaults(struct drm_i915_private *i915)
{
enum port port;
+ int ports = PORT_A | PORT_B | PORT_C | PORT_D | PORT_E | PORT_F;
I'd not spread the knowledge of what port uses tc phy like this.
It's painful to maintain.
Umm, this wasn't meant to have anything to do with tc, really. Granted,
the commit message is misleading.
ok, makes more sense now. I don't want us to keep updating this function
when the ports change on new platforms.
Agreed.
also, not sure how this clarifies things if PORT_TC1 aliases PORT_D,
so I'd just drop this patch
The point is that I'd like to reduce the number of ports set up by
default, perhaps even further than this. It's a bit silly to generate 9
dummy child devices on certain platforms when there's no VBT.
ok. So what would be the devices without vbt? I remember relying on this
for e.g. dg1 before we could read it.
If it were just for enabling, I'd start some igt tool to generate a
basic VBT to use with i915.vbt_firmware and the firmware loader. It's
the existing products that ended up depending on the defaults that are
the real issue I think.
What other platforms should we care about? And for those, should we
really care about ports E and F or could we reduce it to, say the first
4?
IIRC they were some Haswell or Broadwell era Chromebooks. They probably
don't use very many ports, but in theory it could be A-D,F on DDI
platforms (E requires VBT child device). On gen 11 it could be A-E, with
F requiring VBT child device.
A-F covers all cases, but does not try to create G-I or any further
future ports.
ok, thanks for confirming.
Reviewed-by: Lucas De Marchi <lucas.demarchi@xxxxxxxxx>
Lucas De Marchi
BR,
Jani.
thanks
Lucas De Marchi
BR,
Jani.
Lucas De Marchi
Lucas De Marchi
if (!HAS_DDI(i915) && !IS_CHERRYVIEW(i915))
return;
- for_each_port(port) {
+ for_each_port_masked(port, ports) {
struct ddi_vbt_port_info *info =
&i915->vbt.ddi_port_info[port];
enum phy phy = intel_port_to_phy(i915, port);
--
2.20.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Graphics Center
--
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
