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: [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 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.