All of 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

WARNING: multiple messages have this Message-ID (diff)
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>,
	Suraj Kandpal <suraj.kandpal@intel.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Arun R Murthy <arun.r.murthy@intel.com>
Subject: Re: [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: 25+ 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 ` Jani Nikula
2022-10-05 10:51 ` [Intel-gfx] [RFC 1/2] drm/connector: add connector list iteration " Jani Nikula
2022-10-05 10:51   ` Jani Nikula
2022-11-28  7:40   ` [Intel-gfx] " Laurent Pinchart
2022-11-28  7:40     ` Laurent Pinchart
2022-12-15 10:55   ` [Intel-gfx] " Daniel Vetter
2022-12-15 10:55     ` Daniel Vetter
2023-01-23 12:34     ` [Intel-gfx] " Jani Nikula
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 10:51   ` 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 12:19   ` Jani Nikula
2022-11-25 15:00 ` [Intel-gfx] " Harry Wentland
2022-11-25 15:00   ` Harry Wentland
2022-11-29  9:29   ` Jani Nikula [this message]
2022-11-29  9:29     ` Jani Nikula
2022-11-29 10:24     ` [Intel-gfx] " Laurent Pinchart
2022-11-29 10:24       ` Laurent Pinchart
2022-12-07  9:55       ` [Intel-gfx] " Jani Nikula
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 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.