Intel-GFX Archive on 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: [RFC 00/15] VBT read Cleanup
Date: Wed, 10 Jan 2024 14:33:53 +0200	[thread overview]
Message-ID: <87wmshv03y.fsf@intel.com> (raw)
In-Reply-To: <20240108230517.1497504-1-radhakrishna.sripada@intel.com>

On Mon, 08 Jan 2024, Radhakrishna Sripada <radhakrishna.sripada@intel.com> wrote:
> This series does the VBT read cleanup. The series introduces new
> intel_vbt structure to cache and collate vbt related info. Vbt
> read from different sources viz. firmware/opregion/spi/oprom
> needs to be cached for debug purposes and handled accordingly
> during cleanup.

Mixed feelings. I think the goal is good, not convinced by the
implementation.

First, i915->display.vbt.data.foo is just too much depth. It was
borderline too much before, but now it definitely is.

Second, whichever place allocates some stuff should also be responsible
for freeing it. I don't like the idea that you have different places
allocating and then you have a combined cleanup to take care of the
alternatives.

Possibly the first thing to do would be to put intel_bios_init() in
charge of picking the VBT. Stop looking at opregion directly in
intel_bios.c, and instead abstract that away. Also move firmware EDID
loading there. Move debugfs there. Etc.

The opregion code could still figure out what its idea of VBT is, but
intel_bios_init() would the place to ask opregion code about it only if
needed.


BR,
Jani.





>
> Radhakrishna Sripada (15):
>   drm/i915: Extract display->vbt_data to a new vbt structure
>   drm/i915: Move vbt fields from opregion to its own structure
>   drm/i915: Cache opregion asls pointer
>   drm/i915: Extract opregion vbt capture to its own function
>   drm/i915: Init vbt fields when read from oprom/spi
>   drm/i915: Classify vbt type based on its residence
>   drm/i915: Collate vbt cleanup for different types
>   drm/i915: Make intel_bios_init operate on intel_vbt
>   drm/i915: Move vbt load from opregion to bios init
>   drm/i915: Move vbt firmware load into intel_bios_init
>   drm/i915: Make oprom_get_vbt operate on intel_vbt
>   drm/i915: Make spi_oprom_get_vbt operate on intel_vbt
>   drm/i915: Make intel_load_vbt_firmware operate on intel_vbt
>   drm/i915: Kill reduntant vbt_firmware from intel_vbt
>   drm/i915: Use vbt type to determine its validity
>
>  drivers/gpu/drm/i915/display/intel_bios.c     | 348 +++++++++++-------
>  drivers/gpu/drm/i915/display/intel_crt.c      |   2 +-
>  drivers/gpu/drm/i915/display/intel_display.c  |  10 +-
>  .../gpu/drm/i915/display/intel_display_core.h |  16 +-
>  .../drm/i915/display/intel_display_debugfs.c  |   6 +-
>  drivers/gpu/drm/i915/display/intel_dp.c       |   2 +-
>  drivers/gpu/drm/i915/display/intel_dpll.c     |  16 +-
>  drivers/gpu/drm/i915/display/intel_dpll_mgr.c |  19 +-
>  drivers/gpu/drm/i915/display/intel_dsi.c      |   2 +-
>  drivers/gpu/drm/i915/display/intel_lvds.c     |   4 +-
>  drivers/gpu/drm/i915/display/intel_opregion.c | 165 ++++-----
>  drivers/gpu/drm/i915/display/intel_opregion.h |  13 +-
>  drivers/gpu/drm/i915/display/intel_panel.c    |   2 +-
>  .../gpu/drm/i915/display/intel_pch_refclk.c   |   2 +-
>  drivers/gpu/drm/i915/display/intel_sdvo.c     |  18 +-
>  drivers/gpu/drm/i915/intel_clock_gating.c     |   2 +-
>  16 files changed, 348 insertions(+), 279 deletions(-)

-- 
Jani Nikula, Intel

  parent reply	other threads:[~2024-01-10 12:34 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-08 23:05 [RFC 00/15] VBT read Cleanup Radhakrishna Sripada
2024-01-08 23:05 ` [RFC 01/15] drm/i915: Extract display->vbt_data to a new vbt structure Radhakrishna Sripada
2024-01-08 23:05 ` [RFC 02/15] drm/i915: Move vbt fields from opregion to its own structure Radhakrishna Sripada
2024-01-08 23:05 ` [RFC 03/15] drm/i915: Cache opregion asls pointer Radhakrishna Sripada
2024-01-08 23:05 ` [RFC 04/15] drm/i915: Extract opregion vbt capture to its own function Radhakrishna Sripada
2024-01-08 23:05 ` [RFC 05/15] drm/i915: Init vbt fields when read from oprom/spi Radhakrishna Sripada
2024-01-08 23:05 ` [RFC 06/15] drm/i915: Classify vbt type based on its residence Radhakrishna Sripada
2024-01-08 23:05 ` [RFC 07/15] drm/i915: Collate vbt cleanup for different types Radhakrishna Sripada
2024-01-08 23:05 ` [RFC 08/15] drm/i915: Make intel_bios_init operate on intel_vbt Radhakrishna Sripada
2024-01-08 23:05 ` [RFC 09/15] drm/i915: Move vbt load from opregion to bios init Radhakrishna Sripada
2024-01-08 23:05 ` [RFC 10/15] drm/i915: Move vbt firmware load into intel_bios_init Radhakrishna Sripada
2024-01-08 23:05 ` [RFC 11/15] drm/i915: Make oprom_get_vbt operate on intel_vbt Radhakrishna Sripada
2024-01-08 23:05 ` [RFC 12/15] drm/i915: Make spi_oprom_get_vbt " Radhakrishna Sripada
2024-01-08 23:05 ` [RFC 13/15] drm/i915: Make intel_load_vbt_firmware " Radhakrishna Sripada
2024-01-08 23:05 ` [RFC 14/15] drm/i915: Kill reduntant vbt_firmware from intel_vbt Radhakrishna Sripada
2024-01-08 23:05 ` [RFC 15/15] drm/i915: Use vbt type to determine its validity Radhakrishna Sripada
2024-01-09  1:58 ` ✗ Fi.CI.SPARSE: warning for VBT read Cleanup Patchwork
2024-01-09  2:17 ` ✓ Fi.CI.BAT: success " Patchwork
2024-01-09 11:57 ` ✗ Fi.CI.IGT: failure " Patchwork
2024-01-10 12:33 ` Jani Nikula [this message]
2024-01-11 22:46   ` [RFC 00/15] " 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=87wmshv03y.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox