All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Kandpal Suraj <suraj.kandpal@intel.com>
Cc: carsten.haitzler@arm.com, intel-gfx@lists.freedesktop.org,
	quic_abhinavk@quicinc.com, dri-devel@lists.freedesktop.org,
	dmitry.baryshkov@linaro.org, arun.r.murthy@intel.com
Subject: Re: [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
Date: Wed, 02 Feb 2022 15:15:03 +0200	[thread overview]
Message-ID: <87y22ts948.fsf@intel.com> (raw)
In-Reply-To: <Yfp8Q6OFqTAvESOi@pendragon.ideasonboard.com>

On Wed, 02 Feb 2022, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> Hi Kandpal,
>
> Thank you for the patch.
>
> On Wed, Feb 02, 2022 at 02:24:28PM +0530, Kandpal Suraj wrote:
>> Changing rcar_du driver to accomadate the change of
>> drm_writeback_connector.base and drm_writeback_connector.encoder
>> to a pointer the reason for which is explained in the
>> Patch(drm: add writeback pointers to drm_connector).
>> 
>> Signed-off-by: Kandpal Suraj <suraj.kandpal@intel.com>
>> ---
>>  drivers/gpu/drm/rcar-du/rcar_du_crtc.h      | 2 ++
>>  drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 8 +++++---
>>  2 files changed, 7 insertions(+), 3 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> index 66e8839db708..68f387a04502 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> @@ -72,6 +72,8 @@ struct rcar_du_crtc {
>>  	const char *const *sources;
>>  	unsigned int sources_count;
>>  
>> +	struct drm_connector connector;
>> +	struct drm_encoder encoder;
>
> Those fields are, at best, poorly named. Furthermore, there's no need in
> this driver or in other drivers using drm_writeback_connector to create
> an encoder or connector manually. Let's not polute all drivers because
> i915 doesn't have its abstractions right.

i915 uses the quite common model for struct inheritance:

	struct intel_connector {
		struct drm_connector base;
		/* ... */
	}

Same with at least amd, ast, fsl-dcu, hisilicon, mga200, msm, nouveau,
radeon, tilcdc, and vboxvideo.

We could argue about the relative merits of that abstraction, but I
think the bottom line is that it's popular and the drivers using it are
not going to be persuaded to move away from it.

It's no coincidence that the drivers who've implemented writeback so far
(komeda, mali, rcar-du, vc4, and vkms) do not use the abstraction,
because the drm_writeback_connector midlayer does, forcing the issue.

So I think drm_writeback_connector should *not* use the inheritance
abstraction because it's a midlayer that should leave that option to the
drivers. I think drm_writeback_connector needs to be changed to
accommodate that, and, unfortunately, it means current writeback users
need to be changed as well.

I am not sure, however, if the series at hand is the right
approach. Perhaps writeback can be modified to allocate the stuff for
you if you prefer it that way, as long as the drm_connector is not
embedded in struct drm_writeback_connector.


BR,
Jani.


>
> Nack.
>
>>  	struct drm_writeback_connector writeback;
>>  };
>>  
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
>> index c79d1259e49b..5b1e83380c47 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
>> @@ -200,8 +200,10 @@ int rcar_du_writeback_init(struct rcar_du_device *rcdu,
>>  {
>>  	struct drm_writeback_connector *wb_conn = &rcrtc->writeback;
>>  
>> -	wb_conn->encoder.possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
>> -	drm_connector_helper_add(&wb_conn->base,
>> +	wb_conn->base = &rcrtc->connector;
>> +	wb_conn->encoder = &rcrtc->encoder;
>> +	wb_conn->encoder->possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
>> +	drm_connector_helper_add(wb_conn->base,
>>  				 &rcar_du_wb_conn_helper_funcs);
>>  
>>  	return drm_writeback_connector_init(&rcdu->ddev, wb_conn,
>> @@ -220,7 +222,7 @@ void rcar_du_writeback_setup(struct rcar_du_crtc *rcrtc,
>>  	struct drm_framebuffer *fb;
>>  	unsigned int i;
>>  
>> -	state = rcrtc->writeback.base.state;
>> +	state = rcrtc->writeback.base->state;
>>  	if (!state || !state->writeback_job)
>>  		return;
>>  

-- 
Jani Nikula, Intel Open Source Graphics Center

WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@intel.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Kandpal Suraj <suraj.kandpal@intel.com>
Cc: carsten.haitzler@arm.com, intel-gfx@lists.freedesktop.org,
	quic_abhinavk@quicinc.com, dri-devel@lists.freedesktop.org,
	dmitry.baryshkov@linaro.org
Subject: Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
Date: Wed, 02 Feb 2022 15:15:03 +0200	[thread overview]
Message-ID: <87y22ts948.fsf@intel.com> (raw)
In-Reply-To: <Yfp8Q6OFqTAvESOi@pendragon.ideasonboard.com>

On Wed, 02 Feb 2022, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> Hi Kandpal,
>
> Thank you for the patch.
>
> On Wed, Feb 02, 2022 at 02:24:28PM +0530, Kandpal Suraj wrote:
>> Changing rcar_du driver to accomadate the change of
>> drm_writeback_connector.base and drm_writeback_connector.encoder
>> to a pointer the reason for which is explained in the
>> Patch(drm: add writeback pointers to drm_connector).
>> 
>> Signed-off-by: Kandpal Suraj <suraj.kandpal@intel.com>
>> ---
>>  drivers/gpu/drm/rcar-du/rcar_du_crtc.h      | 2 ++
>>  drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 8 +++++---
>>  2 files changed, 7 insertions(+), 3 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> index 66e8839db708..68f387a04502 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> @@ -72,6 +72,8 @@ struct rcar_du_crtc {
>>  	const char *const *sources;
>>  	unsigned int sources_count;
>>  
>> +	struct drm_connector connector;
>> +	struct drm_encoder encoder;
>
> Those fields are, at best, poorly named. Furthermore, there's no need in
> this driver or in other drivers using drm_writeback_connector to create
> an encoder or connector manually. Let's not polute all drivers because
> i915 doesn't have its abstractions right.

i915 uses the quite common model for struct inheritance:

	struct intel_connector {
		struct drm_connector base;
		/* ... */
	}

Same with at least amd, ast, fsl-dcu, hisilicon, mga200, msm, nouveau,
radeon, tilcdc, and vboxvideo.

We could argue about the relative merits of that abstraction, but I
think the bottom line is that it's popular and the drivers using it are
not going to be persuaded to move away from it.

It's no coincidence that the drivers who've implemented writeback so far
(komeda, mali, rcar-du, vc4, and vkms) do not use the abstraction,
because the drm_writeback_connector midlayer does, forcing the issue.

So I think drm_writeback_connector should *not* use the inheritance
abstraction because it's a midlayer that should leave that option to the
drivers. I think drm_writeback_connector needs to be changed to
accommodate that, and, unfortunately, it means current writeback users
need to be changed as well.

I am not sure, however, if the series at hand is the right
approach. Perhaps writeback can be modified to allocate the stuff for
you if you prefer it that way, as long as the drm_connector is not
embedded in struct drm_writeback_connector.


BR,
Jani.


>
> Nack.
>
>>  	struct drm_writeback_connector writeback;
>>  };
>>  
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
>> index c79d1259e49b..5b1e83380c47 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
>> @@ -200,8 +200,10 @@ int rcar_du_writeback_init(struct rcar_du_device *rcdu,
>>  {
>>  	struct drm_writeback_connector *wb_conn = &rcrtc->writeback;
>>  
>> -	wb_conn->encoder.possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
>> -	drm_connector_helper_add(&wb_conn->base,
>> +	wb_conn->base = &rcrtc->connector;
>> +	wb_conn->encoder = &rcrtc->encoder;
>> +	wb_conn->encoder->possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
>> +	drm_connector_helper_add(wb_conn->base,
>>  				 &rcar_du_wb_conn_helper_funcs);
>>  
>>  	return drm_writeback_connector_init(&rcdu->ddev, wb_conn,
>> @@ -220,7 +222,7 @@ void rcar_du_writeback_setup(struct rcar_du_crtc *rcrtc,
>>  	struct drm_framebuffer *fb;
>>  	unsigned int i;
>>  
>> -	state = rcrtc->writeback.base.state;
>> +	state = rcrtc->writeback.base->state;
>>  	if (!state || !state->writeback_job)
>>  		return;
>>  

-- 
Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2022-02-02 13:15 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
2022-02-03  8:46       ` [Intel-gfx] " 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 [this message]
2022-02-02 13:15       ` 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=87y22ts948.fsf@intel.com \
    --to=jani.nikula@intel.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=laurent.pinchart@ideasonboard.com \
    --cc=quic_abhinavk@quicinc.com \
    --cc=suraj.kandpal@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.