Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: Harry Wentland <harry.wentland@amd.com>,
	dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org
Cc: "Mahfooz, Hamza" <Hamza.Mahfooz@amd.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [Intel-gfx] [RFC 0/2] drm/connector: connector iterator with filtering
Date: Tue, 29 Nov 2022 11:29:45 +0200	[thread overview]
Message-ID: <87iliy3y7q.fsf@intel.com> (raw)
In-Reply-To: <7af346ec-8473-2a37-0fb4-220a42529a1e@amd.com>

On Fri, 25 Nov 2022, Harry Wentland <harry.wentland@amd.com> wrote:
> On 10/5/22 06:51, Jani Nikula wrote:
>> Currently i915 assumes all drm_connectors it encounters are embedded in
>> intel_connectors that i915 allocated. The drm_writeback_connector forces
>> a design where this is not the case; we can't provide our own connector,
>> and writeback embeds the drm_connector it initializes itself.
>> 
>> To use drm writeback, none of the i915 connector iteration could assume
>> the drm connector is embedded in intel_connector. Checking this is
>> tedious, and would require an intermediate step with
>> drm_connector. Here's an idea I came up with; filtering at the drm
>> connector iterator level with a caller supplied function. Not too much
>> code, and could be used for other things as well.
>> 
>
> We've been trying to hook up drm_writeback_connector in amdgpu and
> this would be really helpful. I've had to do liberal sprinkling
> of "!= DRM_MODE_CONNECTOR_WRITEBACK" all over the place.
>
>> Mind you, we'd still much rather modify drm writeback to allow passing
>> the connector i915 allocated, instead of the current midlayer design
>> that forces drivers to a certain model. Working around this is a bunch
>> of error prone and tedious code that we really could do without.
>> 
>
> I think this would be even better but also be much more work and impact
> every driver that implements writeback. FWIW, there was no way for me
> to add writeback connector handling without KASAN. Interpreting the
> connector wrong in one place leads to memory corruption and
> undefined behavior and is almost impossible to spot without KASAN.

Laurent, I once again plead - could we please reconsider this and give
drivers the option to allocate and provide the drm_connector to
writeback themselves?

All things considered I think that would be the safer option.


BR,
Jani.

>
> This series is
> Acked-by: Harry Wentland <harry.wentland@amd.com>
>
> Harry
>
>> 
>> BR,
>> Jani.
>> 
>> 
>> Cc: Arun R Murthy <arun.r.murthy@intel.com>
>> Cc: Dave Airlie <airlied@gmail.com>
>> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>> Cc: Suraj Kandpal <suraj.kandpal@intel.com>
>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> 
>> Jani Nikula (2):
>>   drm/connector: add connector list iteration with filtering
>>   drm/i915: iterate intel_connectors only
>> 
>>  drivers/gpu/drm/drm_connector.c               | 57 +++++++++++++++----
>>  drivers/gpu/drm/i915/display/intel_display.c  |  3 +-
>>  .../drm/i915/display/intel_display_types.h    |  7 +++
>>  drivers/gpu/drm/i915/display/intel_dp.c       |  6 +-
>>  drivers/gpu/drm/i915/display/intel_dp_mst.c   |  3 +-
>>  drivers/gpu/drm/i915/display/intel_hdcp.c     |  3 +-
>>  drivers/gpu/drm/i915/display/intel_hotplug.c  | 12 ++--
>>  .../drm/i915/display/intel_modeset_setup.c    |  6 +-
>>  drivers/gpu/drm/i915/display/intel_opregion.c |  9 ++-
>>  include/drm/drm_connector.h                   |  9 +++
>>  10 files changed, 89 insertions(+), 26 deletions(-)
>> 
>

-- 
Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2022-11-29  9:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-05 10:51 [Intel-gfx] [RFC 0/2] drm/connector: connector iterator with filtering Jani Nikula
2022-10-05 10:51 ` [Intel-gfx] [RFC 1/2] drm/connector: add connector list iteration " Jani Nikula
2022-11-28  7:40   ` Laurent Pinchart
2022-12-15 10:55   ` Daniel Vetter
2023-01-23 12:34     ` Jani Nikula
2022-10-05 10:51 ` [Intel-gfx] [RFC 2/2] drm/i915: iterate intel_connectors only Jani Nikula
2022-10-05 11:39 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/connector: connector iterator with filtering Patchwork
2022-10-05 12:00 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-10-05 22:03 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-11-25 12:19 ` [Intel-gfx] [RFC 0/2] " Jani Nikula
2022-11-25 15:00 ` Harry Wentland
2022-11-29  9:29   ` Jani Nikula [this message]
2022-11-29 10:24     ` Laurent Pinchart
2022-12-07  9:55       ` Jani Nikula

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=87iliy3y7q.fsf@intel.com \
    --to=jani.nikula@intel.com \
    --cc=Hamza.Mahfooz@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=harry.wentland@amd.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=laurent.pinchart@ideasonboard.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