From: "Kandpal, Suraj" <suraj.kandpal@intel.com>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: "carsten.haitzler@arm.com" <carsten.haitzler@arm.com>,
"Nikula, Jani" <jani.nikula@intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"quic_abhinavk@quicinc.com" <quic_abhinavk@quicinc.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"Laurent.pinchart@ideasonboard.com"
<Laurent.pinchart@ideasonboard.com>,
"Murthy, Arun R" <arun.r.murthy@intel.com>
Subject: RE: [PATCH 1/6] drm: add writeback pointers to drm_connector
Date: Thu, 3 Feb 2022 08:46:40 +0000 [thread overview]
Message-ID: <CY4PR11MB135245B0AD8668F04DC02549E3289@CY4PR11MB1352.namprd11.prod.outlook.com> (raw)
In-Reply-To: <CAA8EJppf5XL5+NSD+oksW9Zo1DKboPT5KBZwLmyF44q61wkxQA@mail.gmail.com>
Hi Dmitry,
Thanks for your comments
> Could you please clarify, why do you want to use intel_connector for the
> writeback connector?
> I can see a usecase for sharing an encoder between the display and writback
> pipelines (and if I'm not mistaken, this is the case for Abhinav's case).
> However, sharing the hardware-backed connector and writeback connector
> sounds like a sign of a loose abstraction for me.
>
> Please correct me if I'm wrong and Intel driver would really benefit from
> reusing intel_connector as a base for drm_writeback_connector.
>
The thing is drm_writeback_connector contains drm_connector and drm_encoder fields
which get initialized when we call drm_writeback_connector_init adding the connector
to the list of connectors for the drm_device.
Now if I decide not to wrap drm_writeback_connector with intel_connector the issue
is I'll have to add a lot of checks all over the driver to see if the drm_connector is actually
present inside intel_connector or not. I don’t see the point of not having drm_writeback_
connector as even though it’s a faux connector we still treat is as a connector and it would
be better for us to use intel_connector for writeback_connector.
Also the current drm_writeback_connector structure kind of restricts drivers consequently
dictating how they implement their writeback functionality, as a midlayer I don't feel that
would be the right approach as drivers should have the freedom to develop their own flow
to implement the functionality and use the midlayer as a helper to get that done.
Best Regards,
Suraj Kandpal
WARNING: multiple messages have this Message-ID (diff)
From: "Kandpal, Suraj" <suraj.kandpal@intel.com>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: "carsten.haitzler@arm.com" <carsten.haitzler@arm.com>,
"Nikula, Jani" <jani.nikula@intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"quic_abhinavk@quicinc.com" <quic_abhinavk@quicinc.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"Laurent.pinchart@ideasonboard.com"
<Laurent.pinchart@ideasonboard.com>
Subject: Re: [Intel-gfx] [PATCH 1/6] drm: add writeback pointers to drm_connector
Date: Thu, 3 Feb 2022 08:46:40 +0000 [thread overview]
Message-ID: <CY4PR11MB135245B0AD8668F04DC02549E3289@CY4PR11MB1352.namprd11.prod.outlook.com> (raw)
In-Reply-To: <CAA8EJppf5XL5+NSD+oksW9Zo1DKboPT5KBZwLmyF44q61wkxQA@mail.gmail.com>
Hi Dmitry,
Thanks for your comments
> Could you please clarify, why do you want to use intel_connector for the
> writeback connector?
> I can see a usecase for sharing an encoder between the display and writback
> pipelines (and if I'm not mistaken, this is the case for Abhinav's case).
> However, sharing the hardware-backed connector and writeback connector
> sounds like a sign of a loose abstraction for me.
>
> Please correct me if I'm wrong and Intel driver would really benefit from
> reusing intel_connector as a base for drm_writeback_connector.
>
The thing is drm_writeback_connector contains drm_connector and drm_encoder fields
which get initialized when we call drm_writeback_connector_init adding the connector
to the list of connectors for the drm_device.
Now if I decide not to wrap drm_writeback_connector with intel_connector the issue
is I'll have to add a lot of checks all over the driver to see if the drm_connector is actually
present inside intel_connector or not. I don’t see the point of not having drm_writeback_
connector as even though it’s a faux connector we still treat is as a connector and it would
be better for us to use intel_connector for writeback_connector.
Also the current drm_writeback_connector structure kind of restricts drivers consequently
dictating how they implement their writeback functionality, as a midlayer I don't feel that
would be the right approach as drivers should have the freedom to develop their own flow
to implement the functionality and use the midlayer as a helper to get that done.
Best Regards,
Suraj Kandpal
next prev parent reply other threads:[~2022-02-03 8:46 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-02 8:54 [PATCH 0/6] drm writeback connector changes Kandpal Suraj
2022-02-02 8:54 ` [Intel-gfx] " Kandpal Suraj
2022-02-02 8:54 ` [PATCH 1/6] drm: add writeback pointers to drm_connector Kandpal Suraj
2022-02-02 8:54 ` [Intel-gfx] " Kandpal Suraj
2022-02-02 10:28 ` Dmitry Baryshkov
2022-02-02 10:28 ` [Intel-gfx] " Dmitry Baryshkov
2022-02-03 8:46 ` Kandpal, Suraj [this message]
2022-02-03 8:46 ` Kandpal, Suraj
2022-02-02 11:17 ` kernel test robot
2022-02-02 11:17 ` kernel test robot
2022-02-02 20:07 ` kernel test robot
2022-02-02 20:07 ` kernel test robot
2022-02-02 20:07 ` kernel test robot
2022-02-02 8:54 ` [PATCH 2/6] drm/arm/komeda : change driver to use drm_writeback_connector.base pointer Kandpal Suraj
2022-02-02 8:54 ` [Intel-gfx] " Kandpal Suraj
2022-02-02 8:54 ` [PATCH 3/6] drm/vkms: change vkms " Kandpal Suraj
2022-02-02 8:54 ` [Intel-gfx] " Kandpal Suraj
2022-02-02 8:54 ` [PATCH 4/6] drm/vc4: vc4 driver changes to accommodate changes done in drm_writeback_connector structure Kandpal Suraj
2022-02-02 8:54 ` [Intel-gfx] " Kandpal Suraj
2022-02-02 8:54 ` [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes Kandpal Suraj
2022-02-02 8:54 ` [Intel-gfx] " Kandpal Suraj
2022-02-02 12:42 ` Laurent Pinchart
2022-02-02 12:42 ` [Intel-gfx] " Laurent Pinchart
2022-02-02 13:15 ` Jani Nikula
2022-02-02 13:15 ` [Intel-gfx] " Jani Nikula
2022-02-02 13:26 ` Laurent Pinchart
2022-02-02 13:26 ` [Intel-gfx] " Laurent Pinchart
2022-02-02 15:38 ` Jani Nikula
2022-02-02 15:38 ` [Intel-gfx] " Jani Nikula
2022-02-26 18:27 ` Rob Clark
2022-02-26 18:27 ` [Intel-gfx] " Rob Clark
2022-02-28 8:03 ` Laurent Pinchart
2022-02-28 8:03 ` [Intel-gfx] " Laurent Pinchart
2022-02-28 12:09 ` Jani Nikula
2022-02-28 12:09 ` [Intel-gfx] " Jani Nikula
2022-02-28 12:28 ` Laurent Pinchart
2022-02-28 12:28 ` [Intel-gfx] " Laurent Pinchart
2022-02-28 13:42 ` Laurent Pinchart
2022-02-28 13:42 ` [Intel-gfx] " Laurent Pinchart
2022-03-02 18:28 ` Abhinav Kumar
2022-03-02 18:28 ` [Intel-gfx] " Abhinav Kumar
2022-03-02 18:31 ` Laurent Pinchart
2022-03-02 18:31 ` [Intel-gfx] " Laurent Pinchart
2022-03-03 17:32 ` Abhinav Kumar
2022-03-03 17:32 ` [Intel-gfx] " Abhinav Kumar
2022-03-04 9:56 ` Kandpal, Suraj
2022-03-04 9:56 ` [Intel-gfx] " Kandpal, Suraj
2022-03-04 10:39 ` Dmitry Baryshkov
2022-03-04 10:39 ` [Intel-gfx] " Dmitry Baryshkov
2022-03-04 10:47 ` Kandpal, Suraj
2022-03-04 10:47 ` [Intel-gfx] " Kandpal, Suraj
2022-03-04 11:25 ` Dmitry Baryshkov
2022-03-04 11:25 ` [Intel-gfx] " Dmitry Baryshkov
2022-03-04 14:16 ` Kandpal, Suraj
2022-03-04 14:16 ` [Intel-gfx] " Kandpal, Suraj
2022-03-04 20:47 ` Abhinav Kumar
2022-03-04 20:47 ` [Intel-gfx] " Abhinav Kumar
2022-03-08 14:30 ` Kandpal, Suraj
2022-03-08 14:30 ` [Intel-gfx] " Kandpal, Suraj
2022-03-08 19:44 ` Abhinav Kumar
2022-03-08 19:44 ` [Intel-gfx] " Abhinav Kumar
2022-02-06 23:32 ` Dmitry Baryshkov
2022-02-06 23:32 ` [Intel-gfx] " Dmitry Baryshkov
2022-02-07 7:20 ` Abhinav Kumar
2022-02-07 7:20 ` [Intel-gfx] " Abhinav Kumar
2022-02-10 1:40 ` Abhinav Kumar
2022-02-10 1:40 ` [Intel-gfx] " Abhinav Kumar
2022-02-10 4:58 ` Laurent Pinchart
2022-02-10 4:58 ` [Intel-gfx] " Laurent Pinchart
2022-02-22 3:32 ` Dmitry Baryshkov
2022-02-22 3:32 ` [Intel-gfx] " Dmitry Baryshkov
2022-02-22 7:34 ` Laurent Pinchart
2022-02-22 7:34 ` [Intel-gfx] " Laurent Pinchart
2022-02-24 0:27 ` Abhinav Kumar
2022-02-24 0:27 ` [Intel-gfx] " Abhinav Kumar
2022-02-02 13:34 ` Ville Syrjälä
2022-02-02 13:34 ` [Intel-gfx] " Ville Syrjälä
2022-02-02 13:40 ` Dmitry Baryshkov
2022-02-02 13:40 ` [Intel-gfx] " Dmitry Baryshkov
2022-02-02 15:57 ` Jani Nikula
2022-02-02 15:57 ` [Intel-gfx] " Jani Nikula
2022-02-23 6:17 ` Kandpal, Suraj
2022-02-23 6:17 ` [Intel-gfx] " Kandpal, Suraj
2022-02-25 23:26 ` Abhinav Kumar
2022-02-25 23:26 ` [Intel-gfx] " Abhinav Kumar
2022-02-26 5:10 ` Kandpal, Suraj
2022-02-26 5:10 ` [Intel-gfx] " Kandpal, Suraj
2022-02-28 8:00 ` Laurent Pinchart
2022-02-28 8:00 ` [Intel-gfx] " Laurent Pinchart
2022-02-28 8:07 ` Dmitry Baryshkov
2022-02-28 8:07 ` [Intel-gfx] " Dmitry Baryshkov
2022-02-28 8:28 ` Laurent Pinchart
2022-02-28 8:28 ` [Intel-gfx] " Laurent Pinchart
2022-02-02 8:54 ` [PATCH 6/6] drm/arm: changes to malidp " Kandpal Suraj
2022-02-02 8:54 ` [Intel-gfx] " Kandpal Suraj
2022-02-02 10:01 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm writeback connector changes Patchwork
2022-02-02 10:27 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-02-02 12:22 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
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=CY4PR11MB135245B0AD8668F04DC02549E3289@CY4PR11MB1352.namprd11.prod.outlook.com \
--to=suraj.kandpal@intel.com \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=arun.r.murthy@intel.com \
--cc=carsten.haitzler@arm.com \
--cc=dmitry.baryshkov@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=quic_abhinavk@quicinc.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.