All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Radhakrishna Sripada <radhakrishna.sripada@intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2 0/4] TC phy check cleanup
Date: Thu, 21 Dec 2023 12:04:23 +0200	[thread overview]
Message-ID: <87y1dnswgo.fsf@intel.com> (raw)
In-Reply-To: <20231220221341.3248508-1-radhakrishna.sripada@intel.com>

On Wed, 20 Dec 2023, Radhakrishna Sripada <radhakrishna.sripada@intel.com> wrote:
> We are relying on end-less if-else ladders for a type-c phy
> capabilities check. Though it made sense when platforms supported
> legacy type-c support, modern platforms rely on the information
> passed by vbt. This cleanup restricts the if-else ladder to the
> platforms supporting legacy type-c phys and relies on vbt info
> for modern client and discrete platforms.

This series is moving the vbt handling in the wrong direction.

We want to *avoid* new lookups. The idea is that you do the lookup
*once* when initializing the encoder, and after that you use
encoder->devdata.

If you look at the intel_phy_is_tc() call sites, you'll observe that
almost all of the places have the encoder (or devdata) already
available. They get the port from encoder->port, and the phy from
intel_port_to_phy().

So this throws away the information that's already available, and then
goes to look it up again in the worst possible way.

You should convert intel_phy_is_tc() to something like
intel_encoder_is_tc(), and pass encoder to it instead of phy. Similarly,
intel_port_to_tc() should be converted to intel_encoder_to_tc().

There are a couple of special cases that only have devdata or phy. But
we can handle the special cases after making the common case
straightforward.


BR,
Jani.


>
> v2: Move cleanup vbt later to handle safe encoder removal
>
> Radhakrishna Sripada (4):
>   drm/i915: Move intel_bios_driver_remove later
>   drm/i915: Rename intel_bios_encoder_data_lookup as a port variant
>   drm/i915: Introduce intel_encoder_phy_data_lookup
>   drm/i915: Separate tc check for legacy and non legacy tc phys
>
>  drivers/gpu/drm/i915/display/g4x_dp.c         |  2 +-
>  drivers/gpu/drm/i915/display/g4x_hdmi.c       |  2 +-
>  drivers/gpu/drm/i915/display/intel_bios.c     | 15 +++++++++-
>  drivers/gpu/drm/i915/display/intel_bios.h     |  5 +++-
>  drivers/gpu/drm/i915/display/intel_ddi.c      |  2 +-
>  drivers/gpu/drm/i915/display/intel_display.c  | 29 ++++++++++++-------
>  .../drm/i915/display/intel_display_device.h   |  1 +
>  .../drm/i915/display/intel_display_driver.c   |  4 +--
>  drivers/gpu/drm/i915/display/intel_dp.c       |  2 +-
>  9 files changed, 44 insertions(+), 18 deletions(-)

-- 
Jani Nikula, Intel

  parent reply	other threads:[~2023-12-21 10:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-20 22:13 [PATCH v2 0/4] TC phy check cleanup Radhakrishna Sripada
2023-12-20 22:13 ` [PATCH v2 1/4] drm/i915: Move intel_bios_driver_remove later Radhakrishna Sripada
2023-12-20 22:13 ` [PATCH v2 2/4] drm/i915: Rename intel_bios_encoder_data_lookup as a port variant Radhakrishna Sripada
2023-12-20 22:13 ` [PATCH v2 3/4] drm/i915: Introduce intel_encoder_phy_data_lookup Radhakrishna Sripada
2023-12-20 22:13 ` [PATCH v2 4/4] drm/i915: Separate tc check for legacy and non legacy tc phys Radhakrishna Sripada
2023-12-22 11:43   ` Imre Deak
2023-12-22 19:47     ` Sripada, Radhakrishna
2024-01-03 16:50       ` Imre Deak
2024-01-04  0:03         ` Sripada, Radhakrishna
2023-12-21 10:04 ` Jani Nikula [this message]
2023-12-22  6:53   ` [PATCH v2 0/4] TC phy check cleanup Sripada, Radhakrishna
2023-12-22 10:03     ` Jani Nikula
2024-01-04  0:07       ` Sripada, Radhakrishna

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=87y1dnswgo.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=radhakrishna.sripada@intel.com \
    /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.