From: Heiko Stuebner <heiko@sntech.de>
To: Andrzej Hajda <a.hajda@samsung.com>
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
briannorris@chromium.org, hoegsberg@gmail.com,
philippe.cornu@st.com, dri-devel@lists.freedesktop.org,
yannick.fertre@st.com, linux-rockchip@lists.infradead.org,
nickey.yang@rock-chips.com, robh+dt@kernel.org,
thierry.reding@gmail.com, laurent.pinchart@ideasonboard.com,
seanpaul@chromium.org, mka@chromium.org
Subject: Re: [PATCH v4 3/8] drm/bridge/synopsys: dsi: add ability to have glue-specific attach and detach
Date: Tue, 21 Aug 2018 15:49:31 +0200 [thread overview]
Message-ID: <2394974.Lru8Xtrb0a@phil> (raw)
In-Reply-To: <20180820103439eucas1p24d5507784cab3b79161f6cd61fada54c~MkUCMQTJD0184001840eucas1p2U@eucas1p2.samsung.com>
Hi,
Am Montag, 20. August 2018, 12:34:37 CEST schrieb Andrzej Hajda:
> On 14.08.2018 12:26, Heiko Stuebner wrote:
> > With the regular means of adding the dsi-component in probe it creates
> > a race condition with the panel probing, as the panel device only gets
> > created after the dsi-bus got created.
> >
> > When the panel-driver is build as a module it currently fails hard as the
> > panel cannot be probed directly:
> >
> > dw_mipi_dsi_bind()
> > __dw_mipi_dsi_probe()
> > creates dsi bus
> > creates panel device
> > triggers panel module load
> > panel not probed (module not loaded or panel probe slow)
> > drm_bridge_attach
> > fails with -EINVAL due to empty panel_bridge
> >
> > Additionally the panel probing can run concurrently with dsi bringup
> > making it possible that the panel can already be found but dsi-attach
> > hasn't finished running.
> >
> > To solve that cleanly we may want to only create the component after
> > the panel has finished probing, by calling component_add from the
> > host-attach dsi callback.
> >
> > As that is specific to glue drivers, add a new struct for host_ops
> > so that glue drivers can tell the bridge to call specific functions
> > after the common host-attach and before the common host-detach run.
>
> Sometimes I have an impression that core/glue driver architecture with
> callbacks to glue drivers is quite complicated, and smells mid-layer
> mistake :), I wonder if simple bunch of helpers with some base object
> wouldn't be better, but this is subject for other discussion.
>
> >
> > Suggested-by: Andrzej Hajda <a.hajda@samsung.com>
> > Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> > @@ -300,6 +301,12 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host *host,
> >
> > drm_bridge_add(&dsi->bridge);
> >
> > + if (pdata->host_ops && pdata->host_ops->attach) {
> > + ret = pdata->host_ops->attach(pdata->priv_data, device);
> > + if (ret < 0)
> > + return ret;
>
> It could be replaced by:
> return pdata->host_ops->attach(pdata->priv_data, device);
>
> But no strong feelings. With or without the change:
I'll keep it the way it is then ;-) .
My rationale is that the "return 0" below is the last line of this
function and returns the success.
The specialized attach is only called in a fraction of instances, so
having a return on success in there, might be surprising if later on
additional code gets added between the attach call and the return below
and might be missed to modify in that case, possibly causing breakage.
> > + }
> > +
> > return 0;
> > }
Heiko
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-08-21 13:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-14 10:26 [PATCH v4 0/8] drm/rockchip: migrate to common dw-mipi-dsi bridge and dual-dsi Heiko Stuebner
[not found] ` <20180814102654.29113-1-heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
2018-08-14 10:26 ` [PATCH v4 1/8] drm/bridge/synopsys: dsi: move mipi_dsi_host_unregister to __dw_mipi_dsi_remove Heiko Stuebner
2018-08-14 10:26 ` [PATCH v4 3/8] drm/bridge/synopsys: dsi: add ability to have glue-specific attach and detach Heiko Stuebner
[not found] ` <20180814102654.29113-4-heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
2018-08-20 10:34 ` Andrzej Hajda
2018-08-21 13:49 ` Heiko Stuebner [this message]
2018-08-14 10:26 ` [PATCH v4 2/8] drm/bridge/synopsys: dsi: don't call __dw_mipi_dsi_probe from dw_mipi_dsi_bind Heiko Stuebner
2018-08-14 10:26 ` [PATCH v4 4/8] dt-bindings: display: rockchip: update DSI controller Heiko Stuebner
2018-08-14 10:26 ` [PATCH v4 5/8] drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge driver Heiko Stuebner
[not found] ` <20180814102654.29113-6-heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
2018-08-20 11:01 ` Andrzej Hajda
2018-08-14 10:26 ` [PATCH v4 6/8] drm/dsi: add helper function to find the second host in a dual-dsi setup Heiko Stuebner
2018-08-20 11:37 ` Andrzej Hajda
2018-08-21 13:56 ` Heiko Stuebner
2018-08-14 10:26 ` [PATCH v4 7/8] drm/bridge/synopsys: dsi: add dual-dsi support Heiko Stuebner
2018-08-14 10:26 ` [PATCH v4 8/8] drm/rockchip: dsi: add dual mipi support Heiko Stuebner
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=2394974.Lru8Xtrb0a@phil \
--to=heiko@sntech.de \
--cc=a.hajda@samsung.com \
--cc=briannorris@chromium.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=hoegsberg@gmail.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-rockchip@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=mka@chromium.org \
--cc=nickey.yang@rock-chips.com \
--cc=philippe.cornu@st.com \
--cc=robh+dt@kernel.org \
--cc=seanpaul@chromium.org \
--cc=thierry.reding@gmail.com \
--cc=yannick.fertre@st.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;
as well as URLs for NNTP newsgroup(s).