From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: hamohammed.sa@gmail.com, suraj.kandpal@intel.com,
emma@anholt.net, rodrigosiqueiramelo@gmail.com,
jani.nikula@intel.com, liviu.dudau@arm.com,
Abhinav Kumar <quic_abhinavk@quicinc.com>,
dri-devel@lists.freedesktop.org, swboyd@chromium.org,
melissa.srw@gmail.com, nganji@codeaurora.org,
seanpaul@chromium.org, james.qian.wang@arm.com,
quic_aravindh@quicinc.com, mihail.atanassov@arm.com,
freedreno@lists.freedesktop.org
Subject: Re: [PATCH 1/6] drm: allow real encoder to be passed for drm_writeback_connector
Date: Fri, 11 Mar 2022 10:05:53 +0200 [thread overview]
Message-ID: <YisC4cY8EZADarG6@pendragon.ideasonboard.com> (raw)
In-Reply-To: <CAA8EJpqnC=crWaSrXLNLBX5WsZ6LDzG0aNUu7RmqhDPTvP8tFQ@mail.gmail.com>
On Fri, Mar 11, 2022 at 10:46:13AM +0300, Dmitry Baryshkov wrote:
> On Fri, 11 Mar 2022 at 04:50, Abhinav Kumar <quic_abhinavk@quicinc.com> wrote:
> >
> > For some vendor driver implementations, display hardware can
> > be shared between the encoder used for writeback and the physical
> > display.
> >
> > In addition resources such as clocks and interrupts can
> > also be shared between writeback and the real encoder.
> >
> > To accommodate such vendor drivers and hardware, allow
> > real encoder to be passed for drm_writeback_connector.
> >
> > Co-developed-by: Kandpal Suraj <suraj.kandpal@intel.com>
> > Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
> > ---
> > drivers/gpu/drm/drm_writeback.c | 8 ++++----
> > include/drm/drm_writeback.h | 13 +++++++++++--
> > 2 files changed, 15 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
> > index dccf4504..4dad687 100644
> > --- a/drivers/gpu/drm/drm_writeback.c
> > +++ b/drivers/gpu/drm/drm_writeback.c
> > @@ -189,8 +189,8 @@ int drm_writeback_connector_init(struct drm_device *dev,
> > if (IS_ERR(blob))
> > return PTR_ERR(blob);
> >
> > - drm_encoder_helper_add(&wb_connector->encoder, enc_helper_funcs);
> > - ret = drm_encoder_init(dev, &wb_connector->encoder,
> > + drm_encoder_helper_add(wb_connector->encoder, enc_helper_funcs);
> > + ret = drm_encoder_init(dev, wb_connector->encoder,
> > &drm_writeback_encoder_funcs,
> > DRM_MODE_ENCODER_VIRTUAL, NULL);
>
> If the encoder is provided by a separate driver, it might use a
> different set of encoder funcs.
More than that, if the encoder is provided externally but doesn't have
custom operations, I don't really see the point of having an external
encoder in the first place.
Has this series been tested with a driver that needs to provide an
encoder, to make sure it fits the purpose ?
> I'd suggest checking whether the wb_connector->encoder is NULL here.
> If it is, allocate one using drmm_kzalloc and init it.
> If it is not NULL, assume that it has been initialized already, so
> skip the drm_encoder_init() and just call the drm_encoder_helper_add()
>
> > if (ret)
> > @@ -204,7 +204,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
> > goto connector_fail;
> >
> > ret = drm_connector_attach_encoder(connector,
> > - &wb_connector->encoder);
> > + wb_connector->encoder);
> > if (ret)
> > goto attach_fail;
> >
> > @@ -233,7 +233,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
> > attach_fail:
> > drm_connector_cleanup(connector);
> > connector_fail:
> > - drm_encoder_cleanup(&wb_connector->encoder);
> > + drm_encoder_cleanup(wb_connector->encoder);
> > fail:
> > drm_property_blob_put(blob);
> > return ret;
> > diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
> > index 9697d27..0ba266e 100644
> > --- a/include/drm/drm_writeback.h
> > +++ b/include/drm/drm_writeback.h
> > @@ -25,13 +25,22 @@ struct drm_writeback_connector {
> > struct drm_connector base;
> >
> > /**
> > - * @encoder: Internal encoder used by the connector to fulfill
> > + * @encoder: handle to drm_encoder used by the connector to fulfill
> > * the DRM framework requirements. The users of the
> > * @drm_writeback_connector control the behaviour of the @encoder
> > * by passing the @enc_funcs parameter to drm_writeback_connector_init()
> > * function.
> > + *
> > + * For some vendor drivers, the hardware resources are shared between
> > + * writeback encoder and rest of the display pipeline.
> > + * To accommodate such cases, encoder is a handle to the real encoder
> > + * hardware.
> > + *
> > + * For current existing writeback users, this shall continue to be the
> > + * embedded encoder for the writeback connector.
> > + *
> > */
> > - struct drm_encoder encoder;
> > + struct drm_encoder *encoder;
> >
> > /**
> > * @pixel_formats_blob_ptr:
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2022-03-11 8:06 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-11 1:49 [PATCH 0/6] Allow drm_writeback_connector to accept pointer to drm_encoder Abhinav Kumar
2022-03-11 1:49 ` [PATCH 1/6] drm: allow real encoder to be passed for drm_writeback_connector Abhinav Kumar
2022-03-11 7:46 ` Dmitry Baryshkov
2022-03-11 8:05 ` Laurent Pinchart [this message]
2022-03-11 17:09 ` Abhinav Kumar
2022-03-11 18:11 ` Dmitry Baryshkov
2022-03-17 10:01 ` Daniel Vetter
2022-03-17 17:36 ` Abhinav Kumar
2022-03-11 1:49 ` [PATCH 2/6] drm/komeda: use drm_encoder pointer " Abhinav Kumar
2022-03-11 1:49 ` [PATCH 3/6] drm/vkms: " Abhinav Kumar
2022-03-11 1:49 ` [PATCH 4/6] drm/vc4: " Abhinav Kumar
2022-03-11 1:49 ` [PATCH 5/6] drm/rcar_du: " Abhinav Kumar
2022-03-11 7:28 ` Laurent Pinchart
2022-03-11 17:47 ` Abhinav Kumar
2022-03-13 14:50 ` Laurent Pinchart
2022-03-15 23:13 ` Abhinav Kumar
2022-03-11 1:50 ` [PATCH 6/6] drm/malidp: " Abhinav Kumar
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=YisC4cY8EZADarG6@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=dmitry.baryshkov@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=emma@anholt.net \
--cc=freedreno@lists.freedesktop.org \
--cc=hamohammed.sa@gmail.com \
--cc=james.qian.wang@arm.com \
--cc=jani.nikula@intel.com \
--cc=liviu.dudau@arm.com \
--cc=melissa.srw@gmail.com \
--cc=mihail.atanassov@arm.com \
--cc=nganji@codeaurora.org \
--cc=quic_abhinavk@quicinc.com \
--cc=quic_aravindh@quicinc.com \
--cc=rodrigosiqueiramelo@gmail.com \
--cc=seanpaul@chromium.org \
--cc=suraj.kandpal@intel.com \
--cc=swboyd@chromium.org \
/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.