From: Sam Ravnborg <sam@ravnborg.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: dri-devel@lists.freedesktop.org,
Andrzej Hajda <andrzej.hajda@intel.com>,
Chun-Kuang Hu <chunkuang.hu@kernel.org>,
Dafna Hirschfeld <dafna.hirschfeld@collabora.com>,
Daniel Vetter <daniel@ffwll.ch>, David Airlie <airlied@linux.ie>,
Enric Balletbo i Serra <enric.balletbo@collabora.com>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Jitao Shi <jitao.shi@mediatek.com>,
Jonas Karlman <jonas@kwiboo.se>,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
Maxime Ripard <mripard@kernel.org>,
Neil Armstrong <narmstrong@baylibre.com>,
Philip Chen <philipchen@chromium.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
Robert Foss <robert.foss@linaro.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
Maxime Ripard <maxime@cerno.tech>,
Andrzej Hajda <a.hajda@samsung.com>
Subject: Re: [PATCH v2 1/7] drm/bridge: ps8640: Use atomic variants of drm_bridge_funcs
Date: Fri, 22 Oct 2021 18:53:02 +0200 [thread overview]
Message-ID: <YXLsbp+IwiRYfY2a@ravnborg.org> (raw)
In-Reply-To: <YXLHlaLfPD4wI7R7@pendragon.ideasonboard.com>
Hi Laurent,
> > @@ -508,8 +510,8 @@ static const struct drm_bridge_funcs ps8640_bridge_funcs = {
> > .attach = ps8640_bridge_attach,
> > .detach = ps8640_bridge_detach,
> > .get_edid = ps8640_bridge_get_edid,
> > - .post_disable = ps8640_post_disable,
> > - .pre_enable = ps8640_pre_enable,
> > + .atomic_post_disable = ps8640_atomic_post_disable,
> > + .atomic_pre_enable = ps8640_atomic_pre_enable,
>
> Don't you also need to implement .atomic_duplicate_state(),
> .atomic_destroy_state() and .atomic_reset() to use the atomic API ?
What I think happens is that the atomic drivers uses the bridges and
the implementation in drm_bridge has fall-backs to the non-atomic
variants.
So for example drm_atomic_bridge_chain_pre_enable() will call
atomic_pre_enable() if it exists, and if not it will call pre_enable()
if it exists.
With this patch-set I show that the non-atomic versions of several of
the drm_bridge helper functions are almost not used and easy to drop.
So based on this I concluded that the bridge drivers were used
in a way so we only would need to implement the atomic variants
of the functions.
That said I did not consider .atomic_duplicate_state(),
.atomic_destroy_state(), or .atomic_reset().
From a quick look only cadence/cdns-mhdp8546 subclass
drm_bridge_state and I wonder if the right thing to do would be to
implement fallback to the helpers if the bridge driver do not set
any of the .atomic_duplicate_state(), .atomic_destroy_state(), or .atomic_reset().
That would drop the following from a few bridges:
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
.atomic_reset = drm_atomic_helper_bridge_reset,
And new bridges (or bridges we convert to use the atomic operations)
would not have to specify them.
I would prefer implementing the fallback - rather than adding the above
to this driver.
Sam
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
WARNING: multiple messages have this Message-ID (diff)
From: Sam Ravnborg <sam@ravnborg.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: dri-devel@lists.freedesktop.org,
Andrzej Hajda <andrzej.hajda@intel.com>,
Chun-Kuang Hu <chunkuang.hu@kernel.org>,
Dafna Hirschfeld <dafna.hirschfeld@collabora.com>,
Daniel Vetter <daniel@ffwll.ch>, David Airlie <airlied@linux.ie>,
Enric Balletbo i Serra <enric.balletbo@collabora.com>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Jitao Shi <jitao.shi@mediatek.com>,
Jonas Karlman <jonas@kwiboo.se>,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
Maxime Ripard <mripard@kernel.org>,
Neil Armstrong <narmstrong@baylibre.com>,
Philip Chen <philipchen@chromium.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
Robert Foss <robert.foss@linaro.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
Maxime Ripard <maxime@cerno.tech>,
Andrzej Hajda <a.hajda@samsung.com>
Subject: Re: [PATCH v2 1/7] drm/bridge: ps8640: Use atomic variants of drm_bridge_funcs
Date: Fri, 22 Oct 2021 18:53:02 +0200 [thread overview]
Message-ID: <YXLsbp+IwiRYfY2a@ravnborg.org> (raw)
In-Reply-To: <YXLHlaLfPD4wI7R7@pendragon.ideasonboard.com>
Hi Laurent,
> > @@ -508,8 +510,8 @@ static const struct drm_bridge_funcs ps8640_bridge_funcs = {
> > .attach = ps8640_bridge_attach,
> > .detach = ps8640_bridge_detach,
> > .get_edid = ps8640_bridge_get_edid,
> > - .post_disable = ps8640_post_disable,
> > - .pre_enable = ps8640_pre_enable,
> > + .atomic_post_disable = ps8640_atomic_post_disable,
> > + .atomic_pre_enable = ps8640_atomic_pre_enable,
>
> Don't you also need to implement .atomic_duplicate_state(),
> .atomic_destroy_state() and .atomic_reset() to use the atomic API ?
What I think happens is that the atomic drivers uses the bridges and
the implementation in drm_bridge has fall-backs to the non-atomic
variants.
So for example drm_atomic_bridge_chain_pre_enable() will call
atomic_pre_enable() if it exists, and if not it will call pre_enable()
if it exists.
With this patch-set I show that the non-atomic versions of several of
the drm_bridge helper functions are almost not used and easy to drop.
So based on this I concluded that the bridge drivers were used
in a way so we only would need to implement the atomic variants
of the functions.
That said I did not consider .atomic_duplicate_state(),
.atomic_destroy_state(), or .atomic_reset().
From a quick look only cadence/cdns-mhdp8546 subclass
drm_bridge_state and I wonder if the right thing to do would be to
implement fallback to the helpers if the bridge driver do not set
any of the .atomic_duplicate_state(), .atomic_destroy_state(), or .atomic_reset().
That would drop the following from a few bridges:
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
.atomic_reset = drm_atomic_helper_bridge_reset,
And new bridges (or bridges we convert to use the atomic operations)
would not have to specify them.
I would prefer implementing the fallback - rather than adding the above
to this driver.
Sam
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Sam Ravnborg <sam@ravnborg.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: dri-devel@lists.freedesktop.org,
Andrzej Hajda <andrzej.hajda@intel.com>,
Chun-Kuang Hu <chunkuang.hu@kernel.org>,
Dafna Hirschfeld <dafna.hirschfeld@collabora.com>,
Daniel Vetter <daniel@ffwll.ch>, David Airlie <airlied@linux.ie>,
Enric Balletbo i Serra <enric.balletbo@collabora.com>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Jitao Shi <jitao.shi@mediatek.com>,
Jonas Karlman <jonas@kwiboo.se>,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
Maxime Ripard <mripard@kernel.org>,
Neil Armstrong <narmstrong@baylibre.com>,
Philip Chen <philipchen@chromium.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
Robert Foss <robert.foss@linaro.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
Maxime Ripard <maxime@cerno.tech>,
Andrzej Hajda <a.hajda@samsung.com>
Subject: Re: [PATCH v2 1/7] drm/bridge: ps8640: Use atomic variants of drm_bridge_funcs
Date: Fri, 22 Oct 2021 18:53:02 +0200 [thread overview]
Message-ID: <YXLsbp+IwiRYfY2a@ravnborg.org> (raw)
In-Reply-To: <YXLHlaLfPD4wI7R7@pendragon.ideasonboard.com>
Hi Laurent,
> > @@ -508,8 +510,8 @@ static const struct drm_bridge_funcs ps8640_bridge_funcs = {
> > .attach = ps8640_bridge_attach,
> > .detach = ps8640_bridge_detach,
> > .get_edid = ps8640_bridge_get_edid,
> > - .post_disable = ps8640_post_disable,
> > - .pre_enable = ps8640_pre_enable,
> > + .atomic_post_disable = ps8640_atomic_post_disable,
> > + .atomic_pre_enable = ps8640_atomic_pre_enable,
>
> Don't you also need to implement .atomic_duplicate_state(),
> .atomic_destroy_state() and .atomic_reset() to use the atomic API ?
What I think happens is that the atomic drivers uses the bridges and
the implementation in drm_bridge has fall-backs to the non-atomic
variants.
So for example drm_atomic_bridge_chain_pre_enable() will call
atomic_pre_enable() if it exists, and if not it will call pre_enable()
if it exists.
With this patch-set I show that the non-atomic versions of several of
the drm_bridge helper functions are almost not used and easy to drop.
So based on this I concluded that the bridge drivers were used
in a way so we only would need to implement the atomic variants
of the functions.
That said I did not consider .atomic_duplicate_state(),
.atomic_destroy_state(), or .atomic_reset().
From a quick look only cadence/cdns-mhdp8546 subclass
drm_bridge_state and I wonder if the right thing to do would be to
implement fallback to the helpers if the bridge driver do not set
any of the .atomic_duplicate_state(), .atomic_destroy_state(), or .atomic_reset().
That would drop the following from a few bridges:
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
.atomic_reset = drm_atomic_helper_bridge_reset,
And new bridges (or bridges we convert to use the atomic operations)
would not have to specify them.
I would prefer implementing the fallback - rather than adding the above
to this driver.
Sam
next prev parent reply other threads:[~2021-10-22 16:53 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-20 18:18 PATCH [v2 0/7] drm/bridge: Drop deprecated functions Sam Ravnborg
2021-10-20 18:18 ` Sam Ravnborg
2021-10-20 18:18 ` Sam Ravnborg
2021-10-20 18:18 ` [PATCH v2 1/7] drm/bridge: ps8640: Use atomic variants of drm_bridge_funcs Sam Ravnborg
2021-10-20 18:18 ` Sam Ravnborg
2021-10-20 18:18 ` Sam Ravnborg
2021-10-22 14:15 ` Laurent Pinchart
2021-10-22 14:15 ` Laurent Pinchart
2021-10-22 14:15 ` Laurent Pinchart
2021-10-22 16:53 ` Sam Ravnborg [this message]
2021-10-22 16:53 ` Sam Ravnborg
2021-10-22 16:53 ` Sam Ravnborg
2021-10-22 17:13 ` Sam Ravnborg
2021-10-22 17:13 ` Sam Ravnborg
2021-10-22 17:13 ` Sam Ravnborg
2021-10-22 18:42 ` Laurent Pinchart
2021-10-22 18:42 ` Laurent Pinchart
2021-10-22 18:42 ` Laurent Pinchart
2021-10-22 19:32 ` Sam Ravnborg
2021-10-22 19:32 ` Sam Ravnborg
2021-10-22 19:32 ` Sam Ravnborg
2021-10-22 19:46 ` Laurent Pinchart
2021-10-22 19:46 ` Laurent Pinchart
2021-10-22 19:46 ` Laurent Pinchart
2021-10-20 18:18 ` [PATCH v2 2/7] drm/bridge: Drop unused drm_bridge_chain functions Sam Ravnborg
2021-10-20 18:18 ` Sam Ravnborg
2021-10-20 18:18 ` Sam Ravnborg
2021-10-20 18:18 ` [PATCH v2 3/7] drm/bridge: Add drm_atomic_get_new_crtc_for_bridge() helper Sam Ravnborg
2021-10-20 18:18 ` Sam Ravnborg
2021-10-20 18:18 ` Sam Ravnborg
2021-10-22 11:03 ` Maxime Ripard
2021-10-22 11:03 ` Maxime Ripard
2021-10-22 11:03 ` Maxime Ripard
2021-10-22 19:33 ` Sam Ravnborg
2021-10-22 19:33 ` Sam Ravnborg
2021-10-22 19:33 ` Sam Ravnborg
2021-10-20 18:18 ` [PATCH v2 4/7] drm/bridge: lontium-lt9611: Use atomic variants of drm_bridge_funcs Sam Ravnborg
2021-10-20 18:18 ` Sam Ravnborg
2021-10-20 18:18 ` Sam Ravnborg
2021-10-20 18:18 ` [PATCH v2 5/7] drm/mediatek: Drop chain_mode_fixup call in mode_valid() Sam Ravnborg
2021-10-20 18:18 ` Sam Ravnborg
2021-10-20 18:18 ` Sam Ravnborg
2021-10-20 18:19 ` [PATCH v2 6/7] drm/bridge: Drop drm_bridge_chain_mode_fixup Sam Ravnborg
2021-10-20 18:19 ` Sam Ravnborg
2021-10-20 18:19 ` Sam Ravnborg
2021-10-20 18:19 ` [PATCH v2 7/7] drm/todo: Add bridge related todo items Sam Ravnborg
2021-10-20 18:19 ` Sam Ravnborg
2021-10-20 18:19 ` Sam Ravnborg
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=YXLsbp+IwiRYfY2a@ravnborg.org \
--to=sam@ravnborg.org \
--cc=a.hajda@samsung.com \
--cc=airlied@linux.ie \
--cc=andrzej.hajda@intel.com \
--cc=chunkuang.hu@kernel.org \
--cc=dafna.hirschfeld@collabora.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=enric.balletbo@collabora.com \
--cc=jernej.skrabec@gmail.com \
--cc=jitao.shi@mediatek.com \
--cc=jonas@kwiboo.se \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=matthias.bgg@gmail.com \
--cc=maxime@cerno.tech \
--cc=mripard@kernel.org \
--cc=narmstrong@baylibre.com \
--cc=p.zabel@pengutronix.de \
--cc=philipchen@chromium.org \
--cc=robert.foss@linaro.org \
--cc=tzimmermann@suse.de \
/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.