Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Jani Nikula <jani.nikula@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, 2 Feb 2022 15:26:06 +0200	[thread overview]
Message-ID: <YfqGbqQQz5vrDaLI@pendragon.ideasonboard.com> (raw)
In-Reply-To: <87y22ts948.fsf@intel.com>

Hi Jani,

On Wed, Feb 02, 2022 at 03:15:03PM +0200, Jani Nikula wrote:
> On Wed, 02 Feb 2022, Laurent Pinchart wrote:
> > 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.

Nobody said inheritance is bad.

> 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.

Are you sure it's not a coincidence ? :-)

The encoder and especially connector created by drm_writeback_connector
are there only because KMS requires a drm_encoder and a drm_connector to
be exposed to userspace (and I could argue that using a connector for
writeback is a hack, but that won't change). The connector is "virtual",
I still fail to see why i915 or any other driver would need to wrap it
into something else. The whole point of the drm_writeback_connector
abstraction is that drivers do not have to manage the writeback
drm_connector manually, they shouldn't touch it at all.

> 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.
> 
> > 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;
> >>  

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2022-02-02 13:26 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-02  8:54 [Intel-gfx] [PATCH 0/6] drm writeback connector changes Kandpal Suraj
2022-02-02  8:54 ` [Intel-gfx] [PATCH 1/6] drm: add writeback pointers to drm_connector Kandpal Suraj
2022-02-02 10:28   ` Dmitry Baryshkov
2022-02-03  8:46     ` Kandpal, Suraj
2022-02-02 11:17   ` kernel test robot
2022-02-02 20:07   ` kernel test robot
2022-02-02  8:54 ` [Intel-gfx] [PATCH 2/6] drm/arm/komeda : change driver to use drm_writeback_connector.base pointer Kandpal Suraj
2022-02-02  8:54 ` [Intel-gfx] [PATCH 3/6] drm/vkms: change vkms " Kandpal Suraj
2022-02-02  8:54 ` [Intel-gfx] [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] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes Kandpal Suraj
2022-02-02 12:42   ` Laurent Pinchart
2022-02-02 13:15     ` Jani Nikula
2022-02-02 13:26       ` Laurent Pinchart [this message]
2022-02-02 15:38         ` Jani Nikula
2022-02-26 18:27           ` Rob Clark
2022-02-28  8:03             ` Laurent Pinchart
2022-02-28 12:09               ` Jani Nikula
2022-02-28 12:28                 ` Laurent Pinchart
2022-02-28 13:42                   ` Laurent Pinchart
2022-03-02 18:28                     ` Abhinav Kumar
2022-03-02 18:31                       ` Laurent Pinchart
2022-03-03 17:32                         ` Abhinav Kumar
2022-03-04  9:56                           ` Kandpal, Suraj
2022-03-04 10:39                             ` Dmitry Baryshkov
2022-03-04 10:47                               ` Kandpal, Suraj
2022-03-04 11:25                                 ` Dmitry Baryshkov
2022-03-04 14:16                                   ` Kandpal, Suraj
2022-03-04 20:47                                     ` Abhinav Kumar
2022-03-08 14:30                                       ` Kandpal, Suraj
2022-03-08 19:44                                         ` Abhinav Kumar
2022-02-06 23:32         ` Dmitry Baryshkov
2022-02-07  7:20           ` Abhinav Kumar
2022-02-10  1:40             ` Abhinav Kumar
2022-02-10  4:58               ` Laurent Pinchart
2022-02-22  3:32                 ` Dmitry Baryshkov
2022-02-22  7:34                   ` Laurent Pinchart
2022-02-24  0:27                     ` Abhinav Kumar
2022-02-02 13:34       ` Ville Syrjälä
2022-02-02 13:40       ` Dmitry Baryshkov
2022-02-02 15:57         ` Jani Nikula
2022-02-23  6:17           ` Kandpal, Suraj
2022-02-25 23:26             ` Abhinav Kumar
2022-02-26  5:10               ` Kandpal, Suraj
2022-02-28  8:00                 ` Laurent Pinchart
2022-02-28  8:07                   ` Dmitry Baryshkov
2022-02-28  8:28                     ` Laurent Pinchart
2022-02-02  8:54 ` [Intel-gfx] [PATCH 6/6] drm/arm: changes to malidp " 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=YfqGbqQQz5vrDaLI@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox