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
next prev parent 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