Re: [PATCH v3 4/6] drm: lcdif: Check consistent bus format and flags across first bridges
Hi Liu,
thanks for the update.
Am Montag, 13. Februar 2023, 09:56:10 CET schrieb Liu Ying:
> The single LCDIF embedded in i.MX93 SoC may drive multiple displays
> simultaneously. Check bus format and flags across first bridges in
> ->atomic_check() to ensure they are consistent. This is a preparation
> for adding i.MX93 LCDIF support.
>
> Signed-off-by: Liu Ying
> ---
> v2->v3:
> * No change.
>
> v1->v2:
> * Split from patch 2/2 in v1. (Marek, Alexander)
> * Drop a comment about bridge input bus format from
> lcdif_crtc_atomic_check().
>
> drivers/gpu/drm/mxsfb/lcdif_drv.c | 2 -
> drivers/gpu/drm/mxsfb/lcdif_drv.h | 1 -
> drivers/gpu/drm/mxsfb/lcdif_kms.c | 76 ++-
> 3 files changed, 55 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c
> b/drivers/gpu/drm/mxsfb/lcdif_drv.c index cc2ceb301b96..b5b9a8e273c6 100644
> --- a/drivers/gpu/drm/mxsfb/lcdif_drv.c
> +++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c
> @@ -52,8 +52,6 @@ static int lcdif_attach_bridge(struct lcdif_drm_private
> *lcdif) if (ret)
> return dev_err_probe(drm->dev, ret, "Failed to attach
bridge\n");
>
> - lcdif->bridge = bridge;
> -
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.h
> b/drivers/gpu/drm/mxsfb/lcdif_drv.h index 6cdba6e20c02..aa6d099a1897 100644
> --- a/drivers/gpu/drm/mxsfb/lcdif_drv.h
> +++ b/drivers/gpu/drm/mxsfb/lcdif_drv.h
> @@ -31,7 +31,6 @@ struct lcdif_drm_private {
> } planes;
> struct drm_crtc crtc;
> struct drm_encoder encoder;
> - struct drm_bridge *bridge;
> };
>
> static inline struct lcdif_drm_private *
> diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> b/drivers/gpu/drm/mxsfb/lcdif_kms.c index 294cecdf5439..4ea3d2b2cf61 100644
> --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> +++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -424,15 +425,19 @@ static int lcdif_crtc_atomic_check(struct drm_crtc
> *crtc, struct drm_atomic_state *state)
> {
> struct drm_device *drm = crtc->dev;
> - struct lcdif_drm_private *lcdif = to_lcdif_drm_private(drm);
> struct drm_crtc_state *crtc_state =
drm_atomic_get_new_crtc_state(state,
>
crtc);
> struct lcdif_crtc_state *lcdif_crtc_state =
> to_lcdif_crtc_state(crtc_state); bool has_primary = crtc_state->plane_mask
> &
> drm_plane_mask(crtc->primary);
> + struct drm_connector_state *connector_state;
> + struct drm_connector *connector;
> + struct drm_encoder *encoder;
> struct drm_bridge_state *bridge_state;
> - struct drm_bridge *bridge = lcdif->bridge;
> - int ret;
> + struct drm_bridge *bridge;
> + u32 bus_format, bus_flags;
> + bool format_set = false, flags_set = false;
> + int ret, i;
>
> /* The primary plane has to be enabled when the CRTC is active. */
> if (crtc_state->active && !has_primary)
> @@ -442,26 +447,55 @@ static int lcdif_crtc_atomic_check(struct drm_crtc
> *crtc, if (ret)
> return ret;
>
> - bridge_state = drm_atomic_get_new_bridge_state(state, bridge);
> - if (!bridge_state)
> - lcdif_crtc_state->bus_format = MEDIA_BUS_FMT_FIXED;
> - else
> - lcdif_crtc_state->bus_format = bridge_state-
>input_bus_cfg.format;
> -
> - if (lcdif_crtc_state->bus_format == MEDIA_BUS_FMT_FIXED) {
> - dev_warn_once(drm->dev,
> - "Bridge does not provide bus format,
assuming
> MEDIA_BUS_FMT_RGB888_1X24.\n" - "Please fix
bridge driver by
> handling atomic_get_input_bus_fmts.\n"); -lcdif_crtc_state-
>bus_format =
> MEDIA_BUS_FMT_RGB888_1X24;
> + /* Try to find consistent bus format and flags across first bridges.
*/
> + for_each_new_connector_in_state(state, connector, connector_state,
i) {
> + if (!connector_state->crtc)
> + continue;
> +
> + encoder = connector_state->best_encoder;
> +
> + bridge = drm_bridge_chain_get_first_bridge(encoder);
> + if (!bridge)
> + continue;
> +
> + bridge_state = drm_atomic_get_new_bridge_state(state,
bridge);
> + if (!bridge_state)
> + bus_format = MEDIA_BUS_FMT_FIXED;
> + else
> + bus_format = bridge_state->input_bus_cfg.format;
> +
> + if (bus_format == MEDIA_BUS_FMT_FIXED) {
> + dev_warn(drm->dev,
> + "[ENCODER:%d:%s]'s bridge does not
provide bus format, assuming
> MEDIA_BUS_FMT_RGB888_1X24.\n" +
"Please fix bridge driver by handling
> atomic_get_input_bus_fmts.\n", +
encoder->bas
Re: [PATCH v3 6/6] drm: lcdif: Add i.MX93 LCDIF compatible string
Hi Liu,
thanks for the update.
Am Montag, 13. Februar 2023, 09:56:12 CET schrieb Liu Ying:
> With all previous preparations done to make it possible for the
> single LCDIF embedded in i.MX93 SoC to drive multiple displays
> simultaneously, add i.MX93 LCDIF compatible string as the last
> step of adding i.MX93 LCDIF support.
>
> Signed-off-by: Liu Ying
> ---
> v2->v3:
> * Fix a trivial typo in commit message.
>
> v1->v2:
> * Split from patch 2/2 in v1. (Marek, Alexander)
>
> drivers/gpu/drm/mxsfb/lcdif_drv.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c
> b/drivers/gpu/drm/mxsfb/lcdif_drv.c index eb6c265fa2fe..48c43b273a4a 100644
> --- a/drivers/gpu/drm/mxsfb/lcdif_drv.c
> +++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c
> @@ -249,6 +249,7 @@ static const struct drm_driver lcdif_driver = {
>
> static const struct of_device_id lcdif_dt_ids[] = {
> { .compatible = "fsl,imx8mp-lcdif" },
> + { .compatible = "fsl,imx93-lcdif" },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, lcdif_dt_ids);
Reviewed-by: Alexander Stein
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
Re: [PATCH v3 5/6] drm: lcdif: Add multiple encoders and first bridges support
Hi Liu,
thanks for the update.
Am Montag, 13. Februar 2023, 09:56:11 CET schrieb Liu Ying:
> The single LCDIF embedded in i.MX93 SoC may drive multiple displays
> simultaneously. Look at LCDIF output port's remote port parents to
> find all enabled first bridges. Add an encoder for each found bridge
> and attach the bridge to the encoder. This is a preparation for
> adding i.MX93 LCDIF support.
>
> Signed-off-by: Liu Ying
> ---
> v2->v3:
> * No change.
>
> v1->v2:
> * Split from patch 2/2 in v1. (Marek, Alexander)
> * Drop '!remote ||' from lcdif_attach_bridge(). (Lothar)
> * Drop unneeded 'bridges' member from lcdif_drm_private structure.
>
> drivers/gpu/drm/mxsfb/lcdif_drv.c | 68 +++
> drivers/gpu/drm/mxsfb/lcdif_drv.h | 4 +-
> drivers/gpu/drm/mxsfb/lcdif_kms.c | 21 ++
> 3 files changed, 66 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c
> b/drivers/gpu/drm/mxsfb/lcdif_drv.c index b5b9a8e273c6..eb6c265fa2fe 100644
> --- a/drivers/gpu/drm/mxsfb/lcdif_drv.c
> +++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c
> @@ -9,13 +9,16 @@
> #include
> #include
> #include
> +#include
> #include
> +#include
> #include
> #include
>
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -38,19 +41,68 @@ static const struct drm_mode_config_helper_funcs
> lcdif_mode_config_helpers = { .atomic_commit_tail =
> drm_atomic_helper_commit_tail_rpm,
> };
>
> +static const struct drm_encoder_funcs lcdif_encoder_funcs = {
> + .destroy = drm_encoder_cleanup,
> +};
> +
> static int lcdif_attach_bridge(struct lcdif_drm_private *lcdif)
> {
> - struct drm_device *drm = lcdif->drm;
> + struct device *dev = lcdif->drm->dev;
> + struct device_node *ep;
> struct drm_bridge *bridge;
> int ret;
>
> - bridge = devm_drm_of_get_bridge(drm->dev, drm->dev->of_node, 0, 0);
> - if (IS_ERR(bridge))
> - return PTR_ERR(bridge);
> -
> - ret = drm_bridge_attach(&lcdif->encoder, bridge, NULL, 0);
> - if (ret)
> - return dev_err_probe(drm->dev, ret, "Failed to attach
bridge\n");
> + for_each_endpoint_of_node(dev->of_node, ep) {
> + struct device_node *remote;
> + struct of_endpoint of_ep;
> + struct drm_encoder *encoder;
> +
> + remote = of_graph_get_remote_port_parent(ep);
Is it possible for remote to be NULL?
> + if (!of_device_is_available(remote)) {
> + of_node_put(remote);
> + continue;
> + }
> + of_node_put(remote);
> +
> + ret = of_graph_parse_endpoint(ep, &of_ep);
> + if (ret < 0) {
> + dev_err(dev, "Failed to parse endpoint %pOF\n",
ep);
> + of_node_put(ep);
> + return ret;
> + }
> +
> + if (of_ep.id >= MAX_DISPLAYS) {
> + dev_warn(dev, "invalid endpoint id %u\n",
of_ep.id);
I would write
dev_warn(dev, "ignoring invalid endpoint id %u\n", of_ep.id);
just because the parsing continues but this one is skipped.
> + continue;
> + }
> +
> + bridge = devm_drm_of_get_bridge(dev, dev->of_node, 0,
of_ep.id);
> + if (IS_ERR(bridge)) {
> + of_node_put(ep);
> + return dev_err_probe(dev, PTR_ERR(bridge),
> + "Failed to get bridge
for endpoint%u\n",
> + of_ep.id);
> + }
> +
> + encoder = &lcdif->encoders[of_ep.id];
> + encoder->possible_crtcs = drm_crtc_mask(&lcdif->crtc);
> + ret = drm_encoder_init(lcdif->drm, encoder,
&lcdif_encoder_funcs,
> +DRM_MODE_ENCODER_NONE, NULL);
> + if (ret) {
> + dev_err(dev, "Failed to initialize encoder for
endpoint%u: %d\n",
> + of_ep.id, ret);
> + of_node_put(ep);
> + return ret;
> + }
> +
> + ret = drm_bridge_attach(encoder, bridge, NULL, 0);
> + if (ret) {
> + of_node_put(ep);
> + return dev_err_probe(dev, ret,
> + "Failed to attach
bridge for endpoint%u\n",
> + of_ep.id);
> + }
Admittedly I'm not used to the drm API, but do we need to some manual cleanup/
revert if some endpoints is e.g. deferred, but previous endpoints already have
been successfully added? e.g. endpoint 0 is added, but adding endpoint 1
fails.
Best regards,
Alexander
> + }
>
> return 0;
> }
> diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.h
> b/drivers/gpu/drm/mxsfb/lcdif_drv.h index aa6d099a1897..c7400bd9bbd9 100644
> --- a/drivers/gpu/drm/mxsfb/lcdif_drv.h
Re: [PATCH v3 1/6] dt-bindings: lcdif: Add i.MX93 LCDIF support
On Wed, 2023-02-15 at 08:26 +0100, Alexander Stein wrote:
> Hi Liu,
Hi Alexander,
>
> thanks for the update.
Thanks for the review.
>
> Am Montag, 13. Februar 2023, 09:56:07 CET schrieb Liu Ying:
> > There is one LCDIF embedded in i.MX93 SoC to connect with
> > MIPI DSI controller through LCDIF cross line pattern(controlled
> > by mediamix blk-ctrl) or connect with LVDS display bridge(LDB)
> > directly or connect with a parallel display through parallel
> > display format(also controlled by mediamix blk-ctrl). i.MX93
> > LCDIF IP is essentially the same to i.MX8MP LCDIF IP. Add device
> > tree binding for i.MX93 LCDIF.
> >
> > Acked-by: Krzysztof Kozlowski
> > Reviewed-by: Marek Vasut
> > Signed-off-by: Liu Ying
> > ---
> > v2->v3:
> > * No change.
> >
> > v1->v2:
> > * Add Krzysztof's A-b and Marek's R-b tags on patch 1/6.
> >
> > Documentation/devicetree/bindings/display/fsl,lcdif.yaml | 7
> > ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> > b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml index
> > 75b4efd70ba8..fc11ab5fc465 100644
> > --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> > +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> > @@ -21,6 +21,7 @@ properties:
> >- fsl,imx28-lcdif
> >- fsl,imx6sx-lcdif
> >- fsl,imx8mp-lcdif
> > + - fsl,imx93-lcdif
> >- items:
> >- enum:
> >- fsl,imx6sl-lcdif
> > @@ -88,7 +89,9 @@ allOf:
> >properties:
> > compatible:
> >contains:
> > -const: fsl,imx8mp-lcdif
> > +enum:
> > + - fsl,imx8mp-lcdif
> > + - fsl,imx93-lcdif
> > then:
> >properties:
> > clocks:
> > @@ -107,6 +110,7 @@ allOf:
> >enum:
> > - fsl,imx6sx-lcdif
> > - fsl,imx8mp-lcdif
> > +- fsl,imx93-lcdif
> > then:
> >properties:
> > clocks:
> > @@ -123,6 +127,7 @@ allOf:
> >- fsl,imx8mm-lcdif
> >- fsl,imx8mn-lcdif
> >- fsl,imx8mp-lcdif
> > + - fsl,imx93-lcdif
> > then:
> >required:
> > - power-domains
>
> I would have expected that fsl,imx93-lcdif supports up to 3 endpoints
> (MIPI
> DSI, LVDS, and parallel) in a 'ports' subnode. But this binding only
> supports
> a single 'port' sub-node. Also an example for this case might be very
> helpful.
The port node allows multiple endpoints(See graph.yaml[1]). It's
enough to use the existing port node instead of using ports node.
For i.MX93 LCDIF, the port node will be something like this:
8<--
port {
#address-cells = <1>;
#size-cells = <0>;
lcdif_to_pdfc: endpoint@0 {
reg = <0>;
};
lcdif_to_ldb: endpoint@1 {
reg = <1>;
};
lcdif_to_cross_line_pattern: endpoint@2 {
reg = <2>;
};
};
8<--
Looks like it's not necessary to add a specifc example for i.MX93
LCDIF.
[1]
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/graph.yaml#L48
Regards,
Liu Ying
Re: [PATCH v3 1/6] dt-bindings: lcdif: Add i.MX93 LCDIF support
Hi Liu, thanks for the update. Am Montag, 13. Februar 2023, 09:56:07 CET schrieb Liu Ying: > There is one LCDIF embedded in i.MX93 SoC to connect with > MIPI DSI controller through LCDIF cross line pattern(controlled > by mediamix blk-ctrl) or connect with LVDS display bridge(LDB) > directly or connect with a parallel display through parallel > display format(also controlled by mediamix blk-ctrl). i.MX93 > LCDIF IP is essentially the same to i.MX8MP LCDIF IP. Add device > tree binding for i.MX93 LCDIF. > > Acked-by: Krzysztof Kozlowski > Reviewed-by: Marek Vasut > Signed-off-by: Liu Ying > --- > v2->v3: > * No change. > > v1->v2: > * Add Krzysztof's A-b and Marek's R-b tags on patch 1/6. > > Documentation/devicetree/bindings/display/fsl,lcdif.yaml | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml > b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml index > 75b4efd70ba8..fc11ab5fc465 100644 > --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml > +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml > @@ -21,6 +21,7 @@ properties: >- fsl,imx28-lcdif >- fsl,imx6sx-lcdif >- fsl,imx8mp-lcdif > + - fsl,imx93-lcdif >- items: >- enum: >- fsl,imx6sl-lcdif > @@ -88,7 +89,9 @@ allOf: >properties: > compatible: >contains: > -const: fsl,imx8mp-lcdif > +enum: > + - fsl,imx8mp-lcdif > + - fsl,imx93-lcdif > then: >properties: > clocks: > @@ -107,6 +110,7 @@ allOf: >enum: > - fsl,imx6sx-lcdif > - fsl,imx8mp-lcdif > +- fsl,imx93-lcdif > then: >properties: > clocks: > @@ -123,6 +127,7 @@ allOf: >- fsl,imx8mm-lcdif >- fsl,imx8mn-lcdif >- fsl,imx8mp-lcdif > + - fsl,imx93-lcdif > then: >required: > - power-domains I would have expected that fsl,imx93-lcdif supports up to 3 endpoints (MIPI DSI, LVDS, and parallel) in a 'ports' subnode. But this binding only supports a single 'port' sub-node. Also an example for this case might be very helpful. Best regards, Alexander -- TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany Amtsgericht München, HRB 105018 Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider http://www.tq-group.com/
Re: [PATCH 0/9] drm/i915: Replace kmap_atomic() with kmap_local_page()
On Tue, Feb 14, 2023 at 08:25:08PM -0800, Ira Weiny wrote: > Date: Tue, 14 Feb 2023 20:25:08 -0800 > From: Ira Weiny > Subject: Re: [PATCH 0/9] drm/i915: Replace kmap_atomic() with > kmap_local_page() > > Zhao Liu wrote: > > From: Zhao Liu > > > > The use of kmap_atomic() is being deprecated in favor of > > kmap_local_page()[1]. > > Zhao, > > Was there ever a v2 of this series? I'm not finding it on Lore. Sorry Ira, my delay is too long, I was busy with other patch work, I will refresh v2 soon, and push this forward! Best Regards, Zhao > > Thanks, > Ira > > > > > In the following patches, we can convert the calls of kmap_atomic() / > > kunmap_atomic() to kmap_local_page() / kunmap_local(), which can > > instead do the mapping / unmapping regardless of the context. > > > > With kmap_local_page(), the mapping is per thread, CPU local and not > > globally visible. > > > > [1]: https://lore.kernel.org/all/20220813220034.806698-1-ira.we...@intel.com > > --- > > Zhao Liu (9): > > drm/i915: Use kmap_local_page() in gem/i915_gem_object.c > > drm/i915: Use kmap_local_page() in gem/i915_gem_pyhs.c > > drm/i915: Use kmap_local_page() in gem/i915_gem_shmem.c > > drm/i915: Use kmap_local_page() in gem/selftests/huge_pages.c > > drm/i915: Use kmap_local_page() in gem/selftests/i915_gem_coherency.c > > drm/i915: Use kmap_local_page() in gem/selftests/i915_gem_context.c > > drm/i915: Use memcpy_from_page() in gt/uc/intel_uc_fw.c > > drm/i915: Use kmap_local_page() in i915_cmd_parser.c > > drm/i915: Use kmap_local_page() in gem/i915_gem_execbuffer.c > > > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 10 +- > > drivers/gpu/drm/i915/gem/i915_gem_object.c | 8 +++- > > drivers/gpu/drm/i915/gem/i915_gem_phys.c | 8 > > drivers/gpu/drm/i915/gem/i915_gem_shmem.c| 6 -- > > drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 6 +++--- > > .../gpu/drm/i915/gem/selftests/i915_gem_coherency.c | 12 > > .../gpu/drm/i915/gem/selftests/i915_gem_context.c| 8 > > drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 5 + > > drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++-- > > 9 files changed, 30 insertions(+), 37 deletions(-) > > > > -- > > 2.34.1 > > > >
Re: [PATCH 3/3] drm: rcar-du: lvds: Fix LVDS PLL disable on D3/E3
On 14/02/2023 02:37, Laurent Pinchart wrote:
On R-Car D3 and E3, the LVDS encoder provides the dot (pixel) clock to
the DU, regardless of whether the LVDS output is used or not. When using
the DPAD (RGB) output, the DU driver thus enables and disables the LVDS
PLL manually, while when using the LVDS output, it lets the LVDS bridge
driver handle the PLL configuration internally as part of the atomic
enable and disable operations.
This causes an issue when using the LVDS output. As bridges are disabled
before CRTCs, the current implementation violates the enable/disable
sequences documented in the hardware datasheet, which requires the dot
clock to be enabled before the CRTC is started and disabled after it
gets stopped.
Fix the problem by enabling/disabling the LVDS PLL manually from the DU
regardless of which output is used, and skipping the PLL handling in the
LVDS bridge atomic enable and disable operations.
This is however not enough. Disabling the LVDS encoder while leaving the
PLL on still results in a vertical blanking wait timeout when disabling
the DU. Investigation showed that the culprit is the LVEN bit. For an
unclear reason, clearing the bit when disabling the LVDS encoder blocks
vertical blanking interrupts. We thus have to delay disabling the whole
LVDS encoder, not just disabling the PLL, until the DU is disabled.
We could split the LVDS disable sequence by clearing the LVRES bit in
the LVDS bridge atomic disable handler, and delaying the rest of the
operations, in order to disable the LVDS output at bridge atomic disable
time, before stopping the CRTC. This would make the code more complex,
without a clear benefit, so keep the implementation simple(r).
The asymmetry of all this makes me grit my teeth, but SW has to do what
SW has to do... Just a minor comment below, other than that:
Reviewed-by: Tomi Valkeinen
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 18 ++--
drivers/gpu/drm/rcar-du/rcar_lvds.c| 114 +++--
drivers/gpu/drm/rcar-du/rcar_lvds.h| 12 ++-
3 files changed, 86 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 008e172ed43b..71e7fbace38d 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -749,16 +749,17 @@ static void rcar_du_crtc_atomic_enable(struct drm_crtc
*crtc,
/*
* On D3/E3 the dot clock is provided by the LVDS encoder attached to
-* the DU channel. We need to enable its clock output explicitly if
-* the LVDS output is disabled.
+* the DU channel. We need to enable its clock output explicitly before
+* starting the CRTC, as the bridge hasn't been enabled by the atomic
+* helpers yet.
*/
- if (rcdu->info->lvds_clk_mask & BIT(rcrtc->index) &&
- rstate->outputs == BIT(RCAR_DU_OUTPUT_DPAD0)) {
+ if (rcdu->info->lvds_clk_mask & BIT(rcrtc->index)) {
+ bool dot_clk_only = rstate->outputs ==
BIT(RCAR_DU_OUTPUT_DPAD0);
struct drm_bridge *bridge = rcdu->lvds[rcrtc->index];
const struct drm_display_mode *mode =
&crtc->state->adjusted_mode;
- rcar_lvds_pclk_enable(bridge, mode->clock * 1000);
+ rcar_lvds_pclk_enable(bridge, mode->clock * 1000, dot_clk_only);
}
/*
@@ -795,15 +796,15 @@ static void rcar_du_crtc_atomic_disable(struct drm_crtc
*crtc,
rcar_du_crtc_stop(rcrtc);
rcar_du_crtc_put(rcrtc);
- if (rcdu->info->lvds_clk_mask & BIT(rcrtc->index) &&
- rstate->outputs == BIT(RCAR_DU_OUTPUT_DPAD0)) {
+ if (rcdu->info->lvds_clk_mask & BIT(rcrtc->index)) {
+ bool dot_clk_only = rstate->outputs ==
BIT(RCAR_DU_OUTPUT_DPAD0);
struct drm_bridge *bridge = rcdu->lvds[rcrtc->index];
/*
* Disable the LVDS clock output, see
* rcar_du_crtc_atomic_enable().
*/
This could mention that when LVDS output is used, also the LVDS output
is disabled here.
- rcar_lvds_pclk_disable(bridge);
+ rcar_lvds_pclk_disable(bridge, dot_clk_only);
}
if ((rcdu->info->dsi_clk_mask & BIT(rcrtc->index)) &&
@@ -815,7 +816,6 @@ static void rcar_du_crtc_atomic_disable(struct drm_crtc
*crtc,
* Disable the DSI clock output, see
* rcar_du_crtc_atomic_enable().
*/
-
rcar_mipi_dsi_pclk_disable(bridge);
}
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 70cdd5ec64d5..ca215b588fd7 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -269,8 +269,8 @@ static void rcar_lvds_d3_e3_pll_calc(struct rcar_lvds
*lvds, struct clk *clk,
pll->pll_m, pll->pll_n, pll->pll_e, pll->div);
}
-
Re: [PATCH 2/3] drm: rcar-du: lvds: Move LVDS enable code to separate code section
On 14/02/2023 02:37, Laurent Pinchart wrote:
To prepare for a rework of the LVDS disable code, which will need to be
called from rcar_lvds_pclk_disable(), move the LVDS enable code,
currently stored in the __rcar_lvds_atomic_enable() function, to a
separate code section separate from bridge operations. It will be then
extended with the LVDS disable code.
As part of this rework the __rcar_lvds_atomic_enable() function is
renamed to rcar_lvds_enable() to more clearly indicate its purpose.
No functional change intended.
The desc is a bit confusing, as it talks about moving LVDS enable code,
but the diff shows you moving the lvds pclk enable/disable code. Other
than that:
Reviewed-by: Tomi Valkeinen
Tomi
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 97 +++--
1 file changed, 50 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 61de18af62e6..70cdd5ec64d5 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -311,46 +311,7 @@ static void rcar_lvds_pll_setup_d3_e3(struct rcar_lvds
*lvds, unsigned int freq)
}
/* -
- * Clock - D3/E3 only
- */
-
-int rcar_lvds_pclk_enable(struct drm_bridge *bridge, unsigned long freq)
-{
- struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);
- int ret;
-
- if (WARN_ON(!(lvds->info->quirks & RCAR_LVDS_QUIRK_EXT_PLL)))
- return -ENODEV;
-
- dev_dbg(lvds->dev, "enabling LVDS PLL, freq=%luHz\n", freq);
-
- ret = pm_runtime_resume_and_get(lvds->dev);
- if (ret)
- return ret;
-
- __rcar_lvds_pll_setup_d3_e3(lvds, freq, true);
-
- return 0;
-}
-EXPORT_SYMBOL_GPL(rcar_lvds_pclk_enable);
-
-void rcar_lvds_pclk_disable(struct drm_bridge *bridge)
-{
- struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);
-
- if (WARN_ON(!(lvds->info->quirks & RCAR_LVDS_QUIRK_EXT_PLL)))
- return;
-
- dev_dbg(lvds->dev, "disabling LVDS PLL\n");
-
- rcar_lvds_write(lvds, LVDPLLCR, 0);
-
- pm_runtime_put_sync(lvds->dev);
-}
-EXPORT_SYMBOL_GPL(rcar_lvds_pclk_disable);
-
-/*
-
- * Bridge
+ * Enable/disable
*/
static enum rcar_lvds_mode rcar_lvds_get_lvds_mode(struct rcar_lvds *lvds,
@@ -394,10 +355,10 @@ static enum rcar_lvds_mode rcar_lvds_get_lvds_mode(struct
rcar_lvds *lvds,
return mode;
}
-static void __rcar_lvds_atomic_enable(struct drm_bridge *bridge,
- struct drm_atomic_state *state,
- struct drm_crtc *crtc,
- struct drm_connector *connector)
+static void rcar_lvds_enable(struct drm_bridge *bridge,
+struct drm_atomic_state *state,
+struct drm_crtc *crtc,
+struct drm_connector *connector)
{
struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);
u32 lvdhcr;
@@ -410,8 +371,7 @@ static void __rcar_lvds_atomic_enable(struct drm_bridge
*bridge,
/* Enable the companion LVDS encoder in dual-link mode. */
if (lvds->link_type != RCAR_LVDS_SINGLE_LINK && lvds->companion)
- __rcar_lvds_atomic_enable(lvds->companion, state, crtc,
- connector);
+ rcar_lvds_enable(lvds->companion, state, crtc, connector);
/*
* Hardcode the channels and control signals routing for now.
@@ -531,6 +491,49 @@ static void __rcar_lvds_atomic_enable(struct drm_bridge
*bridge,
rcar_lvds_write(lvds, LVDCR0, lvdcr0);
}
+/* -
+ * Clock - D3/E3 only
+ */
+
+int rcar_lvds_pclk_enable(struct drm_bridge *bridge, unsigned long freq)
+{
+ struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);
+ int ret;
+
+ if (WARN_ON(!(lvds->info->quirks & RCAR_LVDS_QUIRK_EXT_PLL)))
+ return -ENODEV;
+
+ dev_dbg(lvds->dev, "enabling LVDS PLL, freq=%luHz\n", freq);
+
+ ret = pm_runtime_resume_and_get(lvds->dev);
+ if (ret)
+ return ret;
+
+ __rcar_lvds_pll_setup_d3_e3(lvds, freq, true);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(rcar_lvds_pclk_enable);
+
+void rcar_lvds_pclk_disable(struct drm_bridge *bridge)
+{
+ struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);
+
+ if (WARN_ON(!(lvds->info->quirks & RCAR_LVDS_QUIRK_EXT_PLL)))
+ return;
+
+ dev_dbg(lvds->dev, "disabling LVDS PLL\n");
+
+ rcar_lvds_write(lvds, LVDPLLCR, 0);
+
+ pm_runtime_put_sync(lvds->dev);
+}
+EXPORT_SYMBOL_GPL(rcar_lvds_pclk_disable);
+
+/*
---
Re: [PATCH 1/3] drm: rcar-du: lvds: Call function directly instead of through pointer
On 14/02/2023 02:37, Laurent Pinchart wrote: When disabling the companion bridge in rcar_lvds_atomic_disable(), there's no need to go through the bridge's operations to call .atomic_disable(). Call rcar_lvds_atomic_disable() on the companion directly. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/rcar-du/rcar_lvds.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c b/drivers/gpu/drm/rcar-du/rcar_lvds.c index 260ea5d8624e..61de18af62e6 100644 --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c @@ -582,8 +582,7 @@ static void rcar_lvds_atomic_disable(struct drm_bridge *bridge, /* Disable the companion LVDS encoder in dual-link mode. */ if (lvds->link_type != RCAR_LVDS_SINGLE_LINK && lvds->companion) - lvds->companion->funcs->atomic_disable(lvds->companion, - old_bridge_state); + rcar_lvds_atomic_disable(lvds->companion, old_bridge_state); pm_runtime_put_sync(lvds->dev); } Reviewed-by: Tomi Valkeinen Tomi
Re: [PATCH 13/19] arch/riscv: rename internal name __xchg to __arch_xchg
On Thu, 22 Dec 2022 03:46:29 PST (-0800), andrzej.ha...@intel.com wrote:
__xchg will be used for non-atomic xchg macro.
Signed-off-by: Andrzej Hajda
---
arch/riscv/include/asm/atomic.h | 2 +-
arch/riscv/include/asm/cmpxchg.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/riscv/include/asm/atomic.h b/arch/riscv/include/asm/atomic.h
index 0dfe9d857a762b..bba472928b5393 100644
--- a/arch/riscv/include/asm/atomic.h
+++ b/arch/riscv/include/asm/atomic.h
@@ -261,7 +261,7 @@ c_t arch_atomic##prefix##_xchg_release(atomic##prefix##_t
*v, c_t n)\
static __always_inline \
c_t arch_atomic##prefix##_xchg(atomic##prefix##_t *v, c_t n) \
{ \
- return __xchg(&(v->counter), n, size); \
+ return __arch_xchg(&(v->counter), n, size); \
} \
static __always_inline \
c_t arch_atomic##prefix##_cmpxchg_relaxed(atomic##prefix##_t *v, \
diff --git a/arch/riscv/include/asm/cmpxchg.h b/arch/riscv/include/asm/cmpxchg.h
index 12debce235e52d..2f4726d3cfcc25 100644
--- a/arch/riscv/include/asm/cmpxchg.h
+++ b/arch/riscv/include/asm/cmpxchg.h
@@ -114,7 +114,7 @@
_x_, sizeof(*(ptr))); \
})
-#define __xchg(ptr, new, size) \
+#define __arch_xchg(ptr, new, size)\
({ \
__typeof__(ptr) __ptr = (ptr); \
__typeof__(new) __new = (new); \
@@ -143,7 +143,7 @@
#define arch_xchg(ptr, x) \
({ \
__typeof__(*(ptr)) _x_ = (x); \
- (__typeof__(*(ptr))) __xchg((ptr), _x_, sizeof(*(ptr)));\
+ (__typeof__(*(ptr))) __arch_xchg((ptr), _x_, sizeof(*(ptr))); \
})
#define xchg32(ptr, x) \
Acked-by: Palmer Dabbelt
[PATCH] drm/i915: move a Kconfig symbol to unbreak the menu presentation
Inserting a Kconfig symbol that does not have a dependency (DRM_I915_GVT)
into a list of other symbols that do have a dependency (on DRM_I915)
breaks the driver menu presentation in 'make *config'.
Relocate the DRM_I915_GVT symbol so that it does not cause this
problem.
Fixes: 8b750bf74418 ("drm/i915/gvt: move the gvt code into kvmgt.ko")
Signed-off-by: Randy Dunlap
Cc: Christoph Hellwig
Cc: Zhi Wang
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: Zhenyu Wang
Cc: intel-...@lists.freedesktop.org
Cc: intel-gvt-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/i915/Kconfig |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff -- a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -118,9 +118,6 @@ config DRM_I915_USERPTR
If in doubt, say "Y".
-config DRM_I915_GVT
- bool
-
config DRM_I915_GVT_KVMGT
tristate "Enable KVM host support Intel GVT-g graphics virtualization"
depends on DRM_I915
@@ -172,3 +169,6 @@ menu "drm/i915 Unstable Evolution"
depends on DRM_I915
source "drivers/gpu/drm/i915/Kconfig.unstable"
endmenu
+
+config DRM_I915_GVT
+ bool
Re: [PATCH 0/9] drm/i915: Replace kmap_atomic() with kmap_local_page()
Zhao Liu wrote: > From: Zhao Liu > > The use of kmap_atomic() is being deprecated in favor of > kmap_local_page()[1]. Zhao, Was there ever a v2 of this series? I'm not finding it on Lore. Thanks, Ira > > In the following patches, we can convert the calls of kmap_atomic() / > kunmap_atomic() to kmap_local_page() / kunmap_local(), which can > instead do the mapping / unmapping regardless of the context. > > With kmap_local_page(), the mapping is per thread, CPU local and not > globally visible. > > [1]: https://lore.kernel.org/all/20220813220034.806698-1-ira.we...@intel.com > --- > Zhao Liu (9): > drm/i915: Use kmap_local_page() in gem/i915_gem_object.c > drm/i915: Use kmap_local_page() in gem/i915_gem_pyhs.c > drm/i915: Use kmap_local_page() in gem/i915_gem_shmem.c > drm/i915: Use kmap_local_page() in gem/selftests/huge_pages.c > drm/i915: Use kmap_local_page() in gem/selftests/i915_gem_coherency.c > drm/i915: Use kmap_local_page() in gem/selftests/i915_gem_context.c > drm/i915: Use memcpy_from_page() in gt/uc/intel_uc_fw.c > drm/i915: Use kmap_local_page() in i915_cmd_parser.c > drm/i915: Use kmap_local_page() in gem/i915_gem_execbuffer.c > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 10 +- > drivers/gpu/drm/i915/gem/i915_gem_object.c | 8 +++- > drivers/gpu/drm/i915/gem/i915_gem_phys.c | 8 > drivers/gpu/drm/i915/gem/i915_gem_shmem.c| 6 -- > drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 6 +++--- > .../gpu/drm/i915/gem/selftests/i915_gem_coherency.c | 12 > .../gpu/drm/i915/gem/selftests/i915_gem_context.c| 8 > drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 5 + > drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++-- > 9 files changed, 30 insertions(+), 37 deletions(-) > > -- > 2.34.1 >
Re: [PATCH] drm/amd/display: Remove duplicate/repeating expressions
Applied. Thanks!
Alex
On Fri, Feb 10, 2023 at 2:37 PM Harry Wentland wrote:
>
> On 2/10/23 05:00, Deepak R Varma wrote:
> > Remove duplicate or repeating expressions in the if condition
> > evaluation. Issue identified using doubletest.cocci Coccinelle semantic
> > patch.
> >
> > Signed-off-by: Deepak R Varma
>
> Reviewed-by: Harry Wentland
>
> Harry
>
> > ---
> > .../gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_32.c| 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_32.c
> > b/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_32.c
> > index 4b8f5fa0f0ad..ae89760d887d 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_32.c
> > +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_32.c
> > @@ -2335,8 +2335,7 @@ void
> > dml32_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_l
> >
> > if (mode_lib->vba.DSCEnable[k] &&
> > mode_lib->vba.ForcedOutputLinkBPP[k] != 0)
> > mode_lib->vba.DSCOnlyIfNecessaryWithBPP =
> > true;
> > - if ((mode_lib->vba.DSCEnable[k] ||
> > mode_lib->vba.DSCEnable[k])
> > - && mode_lib->vba.OutputFormat[k] ==
> > dm_n422
> > + if (mode_lib->vba.DSCEnable[k] &&
> > mode_lib->vba.OutputFormat[k] == dm_n422
> > && !mode_lib->vba.DSC422NativeSupport)
> > mode_lib->vba.DSC422NativeNotSupported = true;
> >
> > @@ -3639,7 +3638,6 @@ void
> > dml32_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_l
> > if (mode_lib->vba.SourcePixelFormat[k] != dm_444_64
> > && mode_lib->vba.SourcePixelFormat[k]
> > != dm_444_32
> > && mode_lib->vba.SourcePixelFormat[k]
> > != dm_444_16
> > - && mode_lib->vba.SourcePixelFormat[k]
> > != dm_444_16
> > && mode_lib->vba.SourcePixelFormat[k]
> > != dm_444_8
> > && mode_lib->vba.SourcePixelFormat[k]
> > != dm_rgbe) {
> > if (mode_lib->vba.ViewportWidthChroma[k] >
> > mode_lib->vba.SurfaceWidthC[k]
>
Re: [PATCH] drm/amd/display: Remove duplicate/repeating expression
Applied. Thanks!
On Fri, Feb 10, 2023 at 10:22 AM Harry Wentland wrote:
>
> On 2/10/23 05:11, Deepak R Varma wrote:
> > Remove duplicate or repeating expressions in the if condition
> > evaluation. Issue identified using doubletest.cocci Coccinelle semantic
> > patch.
> >
> > Signed-off-by: Deepak R Varma
>
> Reviewed-by: Harry Wentland
>
> Harry
>
> > ---
> > .../gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git
> > a/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c
> > b/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c
> > index 61ee9ba063a7..6576b897a512 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c
> > +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c
> > @@ -51,7 +51,7 @@ static bool CalculateBytePerPixelAnd256BBlockSizes(
> > *BytePerPixelDETC = 0;
> > *BytePerPixelY = 4;
> > *BytePerPixelC = 0;
> > - } else if (SourcePixelFormat == dm_444_16 || SourcePixelFormat ==
> > dm_444_16) {
> > + } else if (SourcePixelFormat == dm_444_16) {
> > *BytePerPixelDETY = 2;
> > *BytePerPixelDETC = 0;
> > *BytePerPixelY = 2;
>
Re: [PATCH v3 3/6] drm: lcdif: Determine bus format and flags in ->atomic_check()
On Tue, 2023-02-14 at 15:12 +0100, Alexander Stein wrote:
> Hi Liu,
Hi Alexander,
>
> thanks for the update.
Thanks for your review.
>
> Am Montag, 13. Februar 2023, 09:56:09 CET schrieb Liu Ying:
> > Instead of determining LCDIF output bus format and bus flags in
> > ->atomic_enable(), do that in ->atomic_check(). This is a
> > preparation for the upcoming patch to check consistent bus format
> > and bus flags across all first downstream bridges in
> > ->atomic_check().
> > New lcdif_crtc_state structure is introduced to cache bus format
> > and bus flags states in ->atomic_check() so that they can be read
> > in ->atomic_enable().
> >
> > Signed-off-by: Liu Ying
> > ---
> > v2->v3:
> > * No change.
> >
> > v1->v2:
> > * Split from patch 2/2 in v1. (Marek, Alexander)
> > * Add comment on the 'base' member of lcdif_crtc_state structure to
> > note it should always be the first member. (Lothar)
> >
> > drivers/gpu/drm/mxsfb/lcdif_kms.c | 138 ++--
> > --
> > 1 file changed, 100 insertions(+), 38 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > b/drivers/gpu/drm/mxsfb/lcdif_kms.c index
> > e54200a9fcb9..294cecdf5439 100644
> > --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > +++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > @@ -30,6 +30,18 @@
> > #include "lcdif_drv.h"
> > #include "lcdif_regs.h"
> >
> > +struct lcdif_crtc_state {
> > + struct drm_crtc_state base; /* always be the first
>
> member */
>
> Is it strictly necessary that base is the first member?
> to_lcdif_crtc_state()
> should be able to handle any position within the struct. I mean it's
> sensible
> to put it in first place. But the comment somehow bugs me.
The comment was added in v2 to make sure to_lcdif_crtc_state() work ok
when a NULL pointer is handed over to it. The NULL pointer worries
Lothar a bit as we can see Lothar's comment for v1.
>
> > + u32 bus_format;
> > + u32 bus_flags;
> > +};
> > +
> > +static inline struct lcdif_crtc_state *
> > +to_lcdif_crtc_state(struct drm_crtc_state *s)
> > +{
> > + return container_of(s, struct lcdif_crtc_state, base);
> > +}
> > +
> > /*
> > -
> > --
> > -- * CRTC
> > */
> > @@ -385,48 +397,72 @@ static void lcdif_reset_block(struct
> > lcdif_drm_private
> > *lcdif) readl(lcdif->base + LCDC_V8_CTRL);
> > }
> >
> > -static void lcdif_crtc_mode_set_nofb(struct lcdif_drm_private
> > *lcdif,
> > -struct drm_plane_state
>
> *plane_state,
> > -struct drm_bridge_state
>
> *bridge_state,
> > -const u32 bus_format)
> > +static void lcdif_crtc_mode_set_nofb(struct drm_crtc_state
> > *crtc_state,
> > +struct drm_plane_state
>
> *plane_state)
> > {
> > - struct drm_device *drm = lcdif->crtc.dev;
> > - struct drm_display_mode *m = &lcdif->crtc.state->adjusted_mode;
> > - u32 bus_flags = 0;
> > -
> > - if (lcdif->bridge->timings)
> > - bus_flags = lcdif->bridge->timings->input_bus_flags;
> > - else if (bridge_state)
> > - bus_flags = bridge_state->input_bus_cfg.flags;
> > + struct lcdif_crtc_state *lcdif_crtc_state =
> > to_lcdif_crtc_state(crtc_state); + struct drm_device *drm =
> > crtc_state->crtc->dev;
> > + struct lcdif_drm_private *lcdif = to_lcdif_drm_private(drm);
> > + struct drm_display_mode *m = &crtc_state->adjusted_mode;
> >
> > DRM_DEV_DEBUG_DRIVER(drm->dev, "Pixel clock: %dkHz (actual:
> > %dkHz)
>
> \n",
> > m->crtc_clock,
> > (int)(clk_get_rate(lcdif->clk) / 1000));
> > DRM_DEV_DEBUG_DRIVER(drm->dev, "Bridge bus_flags: 0x%08X\n",
> > -bus_flags);
> > +lcdif_crtc_state->bus_flags);
> > DRM_DEV_DEBUG_DRIVER(drm->dev, "Mode flags: 0x%08X\n", m-
> > >flags);
> >
> > /* Mandatory eLCDIF reset as per the Reference Manual */
> > lcdif_reset_block(lcdif);
> >
> > - lcdif_set_formats(lcdif, plane_state, bus_format);
> > + lcdif_set_formats(lcdif, plane_state, lcdif_crtc_state-
> > >bus_format);
> >
> > - lcdif_set_mode(lcdif, bus_flags);
> > + lcdif_set_mode(lcdif, lcdif_crtc_state->bus_flags);
> > }
> >
> > static int lcdif_crtc_atomic_check(struct drm_crtc *crtc,
> >struct drm_atomic_state *state)
> > {
> > + struct drm_device *drm = crtc->dev;
> > + struct lcdif_drm_private *lcdif = to_lcdif_drm_private(drm);
> > struct drm_crtc_state *crtc_state =
>
> drm_atomic_get_new_crtc_state(state,
> >
>
> crtc);
> > + struct lcdif_crtc_state *lcdif_crtc_state =
> > to_lcdif_crtc_state(crtc_state); bool has_primary = crtc_state-
> > >plane_mask
> > &
> >drm_plane_mask(crtc->primary);
>
Re: [PATCH 3/3] drm/i915/hwmon: Expose power1_max_enable
On Mon, 13 Feb 2023 22:16:44 -0800, Guenter Roeck wrote:
>
Hi Guenter,
> On 2/13/23 21:33, Ashutosh Dixit wrote:
> > On ATSM the PL1 power limit is disabled at power up. The previous uapi
> > assumed that the PL1 limit is always enabled and therefore did not have a
> > notion of a disabled PL1 limit. This results in erroneous PL1 limit values
> > when PL1 limit is disabled. For example at power up, the disabled ATSM PL1
> > limit is shown as 0 which means a low PL1 limit whereas the limit being
> > disabled actually implies a high effective PL1 limit value.
> >
> > To get round this problem, expose power1_max_enable as a custom hwmon
> > attribute. power1_max_enable can be used in conjunction with power1_max to
> > interpret power1_max (PL1 limit) values correctly. It can also be used to
> > enable/disable the PL1 power limit.
> >
> > Signed-off-by: Ashutosh Dixit
> > ---
> > .../ABI/testing/sysfs-driver-intel-i915-hwmon | 7 +++
> > drivers/gpu/drm/i915/i915_hwmon.c | 48 +--
> > 2 files changed, 51 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> > b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> > index 2d6a472eef885..edd94a44b4570 100644
> > --- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> > +++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> > @@ -18,6 +18,13 @@ Description: RW. Card reactive sustained (PL1/Tau)
> > power limit in microwatts.
> > Only supported for particular Intel i915 graphics
> > platforms.
> > +What:/sys/devices/.../hwmon/hwmon/power1_max_enable
>
> This is not a standard hwmon attribute. The standard attribute would be
> power1_enable.
>
> So from hwmon perspective this is a NACK.
Thanks for the feedback. I did consider power1_enable but decided to go
with the power1_max_enable custom attribute. Documentation for
power1_enable says it is to "Enable or disable the sensors" but in our case
we are not enabling/disabling sensors (which we don't have any ability to,
neither do we expose any power measurements, only energy from which power
can be derived) but enabling/disabling a "power limit" (a limit beyond
which HW takes steps to limit power).
As mentioned in the commit message, power1_max_enable is exposed to avoid
possible misinterpretations in measured energy in response to the set power
limit (something specific to our HW). We may have multiple such limits in
the future with similar issues and multiplexing enabling/disabling these
power limits via a single power1_enable file will not provide sufficient
granularity for our purposes.
Also, I had previously posted this patch:
https://patchwork.freedesktop.org/patch/522612/?series=113972&rev=1
which avoids the power1_max_enable file and instead uses a power1_max value
of -1 to indicate that the power1_max limit is disabled.
So in summary we have the following options:
1. Go with power1_max_enable (preferred, works well for us)
2. Go with -1 to indicate that the power1_max limit is disabled
(non-intuitive and also a little ugly)
3. Go with power1_enable (possible but confusing because multiple power
limits/entities are multiplexed via a single file)
If you still think we should not use power1_max_enable I think I might drop
this patch for now (I am trying to preempt future issues but in this case
it's better to wait till people actually complain rather than expose a
non-ideal uapi).
Even if drop we this patch now, it would be good to know your preference in
case we need to revisit this issue later.
Thanks and also sorry for the rather long winded email.
Ashutosh
> Guenter
>
> > +Date: May 2023
> > +KernelVersion: 6.3
> > +Contact: intel-...@lists.freedesktop.org
> > +Description: RW. Enable/disable the PL1 power limit (power1_max).
> > +
> > + Only supported for particular Intel i915 graphics platforms.
> > What: /sys/devices/.../hwmon/hwmon/power1_rated_max
> > Date: February 2023
> > KernelVersion:6.2
> > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> > b/drivers/gpu/drm/i915/i915_hwmon.c
> > index 7c20a6f47b92e..5665869d8602b 100644
> > --- a/drivers/gpu/drm/i915/i915_hwmon.c
> > +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> > @@ -230,13 +230,52 @@ hwm_power1_max_interval_store(struct device *dev,
> > PKG_PWR_LIM_1_TIME, rxy);
> > return count;
> > }
> > +static SENSOR_DEVICE_ATTR_RW(power1_max_interval, hwm_power1_max_interval,
> > 0);
> > -static SENSOR_DEVICE_ATTR(power1_max_interval, 0664,
> > - hwm_power1_max_interval_show,
> > - hwm_power1_max_interval_store, 0);
> > +static ssize_t
> > +hwm_power1_max_enable_show(struct device *dev, struct device_attribute
> > *attr, char *buf)
> > +{
> > + struct hwm_drvdata *ddat = dev_get_drvdata(dev);
> > + intel_wakeref_t wakeref;
> > +
Re: [Intel-gfx] [PATCH] drm/i915: Don't use stolen memory for ring buffers
On 2/14/2023 3:48 PM, john.c.harri...@intel.com wrote: From: John Harrison Direction from hardware is that stolen memory should never be used for ring buffer allocations. There are too many caching pitfalls due to the way stolen memory accesses are routed. So it is safest to just not use it. I'm wondering if this applies to machines in ringbuffer mode as well, as some of the caching stuff that according to the HW team may not work properly with stolen mem accesses from the CS (mocs, ppat) came with gen8/gen9. Maybe limit this change to gen8+, to avoid changing the behavior for very old platforms? Signed-off-by: John Harrison --- drivers/gpu/drm/i915/gt/intel_ring.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c b/drivers/gpu/drm/i915/gt/intel_ring.c index 15ec64d881c44..d1a47e1ae6452 100644 --- a/drivers/gpu/drm/i915/gt/intel_ring.c +++ b/drivers/gpu/drm/i915/gt/intel_ring.c @@ -116,8 +116,6 @@ static struct i915_vma *create_ring_vma(struct i915_ggtt *ggtt, int size) obj = i915_gem_object_create_lmem(i915, size, I915_BO_ALLOC_VOLATILE | I915_BO_ALLOC_PM_VOLATILE); - if (IS_ERR(obj) && i915_ggtt_has_aperture(ggtt)) - obj = i915_gem_object_create_stolen(i915, size); There is code in ring_pin/unpin() that only applies to rings in stolen memory, so you need to remove that as well if you drop stolen for rings on all platforms. Daniele if (IS_ERR(obj)) obj = i915_gem_object_create_internal(i915, size); if (IS_ERR(obj))
Re: [PATCH v2 10/14] drm/msm/a6xx: Fix up A6XX protected registers
On Tue, Feb 14, 2023 at 4:38 PM Konrad Dybcio wrote:
>
>
>
> On 15.02.2023 01:10, Dmitry Baryshkov wrote:
> > On 14/02/2023 23:56, Rob Clark wrote:
> >> On Tue, Feb 14, 2023 at 9:32 AM Konrad Dybcio
> >> wrote:
> >>>
> >>> One of the protected ranges was too small (compared to the data we
> >>> have downstream). Fix it.
> >>>
> >>> Fixes: 408434036958 ("drm/msm/a6xx: update/fix CP_PROTECT initialization")
> >>> Signed-off-by: Konrad Dybcio
> >>> ---
> >>> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> >>> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> >>> index 503c750216e6..d6b38bfdb3b4 100644
> >>> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> >>> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> >>> @@ -690,7 +690,7 @@ static const u32 a6xx_protect[] = {
> >>> A6XX_PROTECT_NORDWR(0x00800, 0x0082),
> >>> A6XX_PROTECT_NORDWR(0x008a0, 0x0008),
> >>> A6XX_PROTECT_NORDWR(0x008ab, 0x0024),
> >>> - A6XX_PROTECT_RDONLY(0x008de, 0x00ae),
> >>> + A6XX_PROTECT_RDONLY(0x008d0, 0x00bc),
> >>
> >> Nak, this is intentional, we need userspace to be able to configure
> >> the CP counters. Otherwise this would break fdperf, perfetto, etc
> >>
> >> (although maybe we should comment where we diverge from downstream)
> >
> > Yes, please. Otherwise it is extremely hard to understand the reason for
> > diversion between the vendor driver and our one.
> +1
>
> I am content with dropping this patch from this series, so long
> as you leave a clue for others to not scratch their heads on this!
Yeah, I admit it is kinda a trap as-is. And makes things less obvious
what to do when porting from downstream. When I get a few minutes
I'll double check that there weren't any other exceptions (I don't
think they were but it has been a while) and add some comments.
BR,
-R
> Konrad
> >
> >>
> >> BR,
> >> -R
> >>
> >>> A6XX_PROTECT_NORDWR(0x00900, 0x004d),
> >>> A6XX_PROTECT_NORDWR(0x0098d, 0x0272),
> >>> A6XX_PROTECT_NORDWR(0x00e00, 0x0001),
> >>> --
> >>> 2.39.1
> >>>
> >
[PATCH] drm/nouveau/led: explicitly include linux/leds.h
Instead of relying on an accidental, transitive inclusion of linux/leds.h
use it directly.
Also drop the forware definition of struct led_classdev that is now
provided by linux/leds.h.
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/nouveau/nouveau_led.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_led.h
b/drivers/gpu/drm/nouveau/nouveau_led.h
index 21a5775028cc..bc9bc7208da3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_led.h
+++ b/drivers/gpu/drm/nouveau/nouveau_led.h
@@ -27,7 +27,7 @@
#include "nouveau_drv.h"
-struct led_classdev;
+#include
struct nouveau_led {
struct drm_device *dev;
---
base-commit: e1c04510f521e853019afeca2a5991a5ef8d6a5b
change-id: 20230215-power_supply-leds-nouveau-ff4995ba0794
Best regards,
--
Thomas Weißschuh
Re: [PATCH v2 10/14] drm/msm/a6xx: Fix up A6XX protected registers
On 15.02.2023 01:10, Dmitry Baryshkov wrote:
> On 14/02/2023 23:56, Rob Clark wrote:
>> On Tue, Feb 14, 2023 at 9:32 AM Konrad Dybcio
>> wrote:
>>>
>>> One of the protected ranges was too small (compared to the data we
>>> have downstream). Fix it.
>>>
>>> Fixes: 408434036958 ("drm/msm/a6xx: update/fix CP_PROTECT initialization")
>>> Signed-off-by: Konrad Dybcio
>>> ---
>>> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
>>> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
>>> index 503c750216e6..d6b38bfdb3b4 100644
>>> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
>>> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
>>> @@ -690,7 +690,7 @@ static const u32 a6xx_protect[] = {
>>> A6XX_PROTECT_NORDWR(0x00800, 0x0082),
>>> A6XX_PROTECT_NORDWR(0x008a0, 0x0008),
>>> A6XX_PROTECT_NORDWR(0x008ab, 0x0024),
>>> - A6XX_PROTECT_RDONLY(0x008de, 0x00ae),
>>> + A6XX_PROTECT_RDONLY(0x008d0, 0x00bc),
>>
>> Nak, this is intentional, we need userspace to be able to configure
>> the CP counters. Otherwise this would break fdperf, perfetto, etc
>>
>> (although maybe we should comment where we diverge from downstream)
>
> Yes, please. Otherwise it is extremely hard to understand the reason for
> diversion between the vendor driver and our one.
+1
I am content with dropping this patch from this series, so long
as you leave a clue for others to not scratch their heads on this!
Konrad
>
>>
>> BR,
>> -R
>>
>>> A6XX_PROTECT_NORDWR(0x00900, 0x004d),
>>> A6XX_PROTECT_NORDWR(0x0098d, 0x0272),
>>> A6XX_PROTECT_NORDWR(0x00e00, 0x0001),
>>> --
>>> 2.39.1
>>>
>
Re: [PATCH v2 10/14] drm/msm/a6xx: Fix up A6XX protected registers
On 14/02/2023 23:56, Rob Clark wrote:
On Tue, Feb 14, 2023 at 9:32 AM Konrad Dybcio wrote:
One of the protected ranges was too small (compared to the data we
have downstream). Fix it.
Fixes: 408434036958 ("drm/msm/a6xx: update/fix CP_PROTECT initialization")
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 503c750216e6..d6b38bfdb3b4 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -690,7 +690,7 @@ static const u32 a6xx_protect[] = {
A6XX_PROTECT_NORDWR(0x00800, 0x0082),
A6XX_PROTECT_NORDWR(0x008a0, 0x0008),
A6XX_PROTECT_NORDWR(0x008ab, 0x0024),
- A6XX_PROTECT_RDONLY(0x008de, 0x00ae),
+ A6XX_PROTECT_RDONLY(0x008d0, 0x00bc),
Nak, this is intentional, we need userspace to be able to configure
the CP counters. Otherwise this would break fdperf, perfetto, etc
(although maybe we should comment where we diverge from downstream)
Yes, please. Otherwise it is extremely hard to understand the reason for
diversion between the vendor driver and our one.
BR,
-R
A6XX_PROTECT_NORDWR(0x00900, 0x004d),
A6XX_PROTECT_NORDWR(0x0098d, 0x0272),
A6XX_PROTECT_NORDWR(0x00e00, 0x0001),
--
2.39.1
--
With best wishes
Dmitry
Re: [PATCH v3 15/27] drm/msm/dpu: move the rest of plane checks to dpu_plane_atomic_check()
On 15/02/2023 01:25, Abhinav Kumar wrote:
Hi Dmitry
Sorry for the late response on this one.
On 2/3/2023 2:55 PM, Dmitry Baryshkov wrote:
On 04/02/2023 00:44, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Move plane state updates from dpu_crtc_atomic_check() to the function
where they belong: to dpu_plane_atomic_check().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 18 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 18 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 6 --
3 files changed, 11 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index b485234eefb2..bd09bb319a58 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1129,7 +1129,6 @@ static int dpu_crtc_atomic_check(struct
drm_crtc *crtc,
crtc);
struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc_state);
- struct dpu_kms *dpu_kms = _dpu_crtc_get_kms(crtc);
const struct drm_plane_state *pstate;
struct drm_plane *plane;
@@ -1161,11 +1160,10 @@ static int dpu_crtc_atomic_check(struct
drm_crtc *crtc,
crtc_rect.x2 = mode->hdisplay;
crtc_rect.y2 = mode->vdisplay;
- /* get plane state for all drm planes associated with crtc
state */
+ /* FIXME: move this to dpu_plane_atomic_check? */
drm_atomic_crtc_state_for_each_plane_state(plane, pstate,
crtc_state) {
struct dpu_plane_state *dpu_pstate =
to_dpu_plane_state(pstate);
struct drm_rect dst, clip = crtc_rect;
- int stage;
if (IS_ERR_OR_NULL(pstate)) {
rc = PTR_ERR(pstate);
@@ -1179,8 +1177,6 @@ static int dpu_crtc_atomic_check(struct
drm_crtc *crtc,
dpu_pstate->needs_dirtyfb = needs_dirtyfb;
- dpu_plane_clear_multirect(pstate);
-
dst = drm_plane_state_dest(pstate);
if (!drm_rect_intersect(&clip, &dst)) {
DPU_ERROR("invalid vertical/horizontal destination\n");
@@ -1189,18 +1185,6 @@ static int dpu_crtc_atomic_check(struct
drm_crtc *crtc,
DRM_RECT_ARG(&dst));
return -E2BIG;
}
-
- /* verify stage setting before using it */
- stage = DPU_STAGE_0 + pstate->normalized_zpos;
- if (stage >= dpu_kms->catalog->caps->max_mixer_blendstages) {
- DPU_ERROR("> %d plane stages assigned\n",
- dpu_kms->catalog->caps->max_mixer_blendstages -
DPU_STAGE_0);
- return -EINVAL;
- }
-
- to_dpu_plane_state(pstate)->stage = stage;
- DRM_DEBUG_ATOMIC("%s: stage %d\n", dpu_crtc->name, stage);
-
}
atomic_inc(&_dpu_crtc_get_kms(crtc)->bandwidth_ref);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 1b3033b15bfa..5aabf9694a53 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -733,14 +733,6 @@ static int _dpu_plane_color_fill(struct
dpu_plane *pdpu,
return 0;
}
-void dpu_plane_clear_multirect(const struct drm_plane_state
*drm_state)
-{
- struct dpu_plane_state *pstate = to_dpu_plane_state(drm_state);
-
- pstate->pipe.multirect_index = DPU_SSPP_RECT_SOLO;
- pstate->pipe.multirect_mode = DPU_SSPP_MULTIRECT_NONE;
-}
-
int dpu_plane_validate_multirect_v2(struct
dpu_multirect_plane_states *plane)
{
struct dpu_plane_state *pstate[R_MAX];
@@ -994,6 +986,16 @@ static int dpu_plane_atomic_check(struct
drm_plane *plane,
if (!new_plane_state->visible)
return 0;
+ pstate->pipe.multirect_index = DPU_SSPP_RECT_SOLO;
+ pstate->pipe.multirect_mode = DPU_SSPP_MULTIRECT_NONE;
+
But I am not sure if clearing the multirect belongs here and now I
want to clarify one thing about
https://patchwork.freedesktop.org/patch/521354/?series=99909&rev=4
which was R-bed in the v1 and carried fwd since then.
So prior to that change, we were only clearing the multirects of the
planes that were staged to the crtc and we were getting those from
the crtc state. But now we are clearing the multirect of all the planes.
Dont we have to keep that in the crtc_atomic_check() since we do that
on all the planes attached to a certain CRTC.
In that case shouldnt we keep this in the crtc_atomic_check() and
bring back pipe_staged[] without the multirect and source split cases
ofcourse.
What for? In other words, what would be the difference?
So, please correct my understanding here. drm_plane's atomic_check()
will be called for all the planes which are getting updated in this
atomic commit using for_each_oldnew_plane_in_state() and drm_crtc's
atomic_check() will be called for all the CRTC's in this atomic update
using for_each_new_crtc_in_state() >
If the plane is not c
Re: [PATCH 02/10] dt-bindings: display/msm: dsi-controller-main: Add SM6375
On Sat, 11 Feb 2023 13:26:48 +0100, Konrad Dybcio wrote: > Add the DSI host found on SM6375. > > Signed-off-by: Konrad Dybcio > --- > .../devicetree/bindings/display/msm/dsi-controller-main.yaml| 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Rob Herring
Re: [PATCH 01/10] dt-bindings: display/msm: dsi-controller-main: Add SM6350
On Sat, 11 Feb 2023 13:26:47 +0100, Konrad Dybcio wrote: > Add the DSI host found on SM6350. > > Signed-off-by: Konrad Dybcio > --- > .../devicetree/bindings/display/msm/dsi-controller-main.yaml| 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Rob Herring
[PATCH] drm/i915: Don't use stolen memory for ring buffers
From: John Harrison Direction from hardware is that stolen memory should never be used for ring buffer allocations. There are too many caching pitfalls due to the way stolen memory accesses are routed. So it is safest to just not use it. Signed-off-by: John Harrison --- drivers/gpu/drm/i915/gt/intel_ring.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c b/drivers/gpu/drm/i915/gt/intel_ring.c index 15ec64d881c44..d1a47e1ae6452 100644 --- a/drivers/gpu/drm/i915/gt/intel_ring.c +++ b/drivers/gpu/drm/i915/gt/intel_ring.c @@ -116,8 +116,6 @@ static struct i915_vma *create_ring_vma(struct i915_ggtt *ggtt, int size) obj = i915_gem_object_create_lmem(i915, size, I915_BO_ALLOC_VOLATILE | I915_BO_ALLOC_PM_VOLATILE); - if (IS_ERR(obj) && i915_ggtt_has_aperture(ggtt)) - obj = i915_gem_object_create_stolen(i915, size); if (IS_ERR(obj)) obj = i915_gem_object_create_internal(i915, size); if (IS_ERR(obj)) -- 2.39.1
Re: [PATCH v3 15/27] drm/msm/dpu: move the rest of plane checks to dpu_plane_atomic_check()
Hi Dmitry
Sorry for the late response on this one.
On 2/3/2023 2:55 PM, Dmitry Baryshkov wrote:
On 04/02/2023 00:44, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Move plane state updates from dpu_crtc_atomic_check() to the function
where they belong: to dpu_plane_atomic_check().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 18 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 18 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 6 --
3 files changed, 11 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index b485234eefb2..bd09bb319a58 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1129,7 +1129,6 @@ static int dpu_crtc_atomic_check(struct
drm_crtc *crtc,
crtc);
struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc_state);
- struct dpu_kms *dpu_kms = _dpu_crtc_get_kms(crtc);
const struct drm_plane_state *pstate;
struct drm_plane *plane;
@@ -1161,11 +1160,10 @@ static int dpu_crtc_atomic_check(struct
drm_crtc *crtc,
crtc_rect.x2 = mode->hdisplay;
crtc_rect.y2 = mode->vdisplay;
- /* get plane state for all drm planes associated with crtc
state */
+ /* FIXME: move this to dpu_plane_atomic_check? */
drm_atomic_crtc_state_for_each_plane_state(plane, pstate,
crtc_state) {
struct dpu_plane_state *dpu_pstate =
to_dpu_plane_state(pstate);
struct drm_rect dst, clip = crtc_rect;
- int stage;
if (IS_ERR_OR_NULL(pstate)) {
rc = PTR_ERR(pstate);
@@ -1179,8 +1177,6 @@ static int dpu_crtc_atomic_check(struct
drm_crtc *crtc,
dpu_pstate->needs_dirtyfb = needs_dirtyfb;
- dpu_plane_clear_multirect(pstate);
-
dst = drm_plane_state_dest(pstate);
if (!drm_rect_intersect(&clip, &dst)) {
DPU_ERROR("invalid vertical/horizontal destination\n");
@@ -1189,18 +1185,6 @@ static int dpu_crtc_atomic_check(struct
drm_crtc *crtc,
DRM_RECT_ARG(&dst));
return -E2BIG;
}
-
- /* verify stage setting before using it */
- stage = DPU_STAGE_0 + pstate->normalized_zpos;
- if (stage >= dpu_kms->catalog->caps->max_mixer_blendstages) {
- DPU_ERROR("> %d plane stages assigned\n",
- dpu_kms->catalog->caps->max_mixer_blendstages -
DPU_STAGE_0);
- return -EINVAL;
- }
-
- to_dpu_plane_state(pstate)->stage = stage;
- DRM_DEBUG_ATOMIC("%s: stage %d\n", dpu_crtc->name, stage);
-
}
atomic_inc(&_dpu_crtc_get_kms(crtc)->bandwidth_ref);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 1b3033b15bfa..5aabf9694a53 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -733,14 +733,6 @@ static int _dpu_plane_color_fill(struct
dpu_plane *pdpu,
return 0;
}
-void dpu_plane_clear_multirect(const struct drm_plane_state *drm_state)
-{
- struct dpu_plane_state *pstate = to_dpu_plane_state(drm_state);
-
- pstate->pipe.multirect_index = DPU_SSPP_RECT_SOLO;
- pstate->pipe.multirect_mode = DPU_SSPP_MULTIRECT_NONE;
-}
-
int dpu_plane_validate_multirect_v2(struct
dpu_multirect_plane_states *plane)
{
struct dpu_plane_state *pstate[R_MAX];
@@ -994,6 +986,16 @@ static int dpu_plane_atomic_check(struct
drm_plane *plane,
if (!new_plane_state->visible)
return 0;
+ pstate->pipe.multirect_index = DPU_SSPP_RECT_SOLO;
+ pstate->pipe.multirect_mode = DPU_SSPP_MULTIRECT_NONE;
+
But I am not sure if clearing the multirect belongs here and now I
want to clarify one thing about
https://patchwork.freedesktop.org/patch/521354/?series=99909&rev=4
which was R-bed in the v1 and carried fwd since then.
So prior to that change, we were only clearing the multirects of the
planes that were staged to the crtc and we were getting those from the
crtc state. But now we are clearing the multirect of all the planes.
Dont we have to keep that in the crtc_atomic_check() since we do that
on all the planes attached to a certain CRTC.
In that case shouldnt we keep this in the crtc_atomic_check() and
bring back pipe_staged[] without the multirect and source split cases
ofcourse.
What for? In other words, what would be the difference?
So, please correct my understanding here. drm_plane's atomic_check()
will be called for all the planes which are getting updated in this
atomic commit using for_each_oldnew_plane_in_state() and drm_crtc's
atomic_check() will be called for all the CRTC's in this atomic update
using for_each_new_crtc_in_state().
If the plane is not connected to any CRTC, why do we need to clea
Re: [PATCH v2 00/14] GMU-less A6xx support (A610, A619_holi)
+ Akhil On Tue, Feb 14, 2023 at 10:03 AM Konrad Dybcio wrote: > > > v1 -> v2: > - Fix A630 values in [2/14] > - Fix [6/14] for GMU-equipped GPUs > > Link to v1: > https://lore.kernel.org/linux-arm-msm/20230126151618.225127-1-konrad.dyb...@linaro.org/ > > This series concludes my couple-weeks-long suffering of figuring out > the ins and outs of the "non-standard" A6xx GPUs which feature no GMU. > > The GMU functionality is essentially emulated by parting out a > "GMU wrapper" region, which is essentially just a register space > within the GPU. It's modeled to be as similar to the actual GMU > as possible while staying as unnecessary as we can make it - there's > no IRQs, communicating with a microcontroller, no RPMh communication > etc. etc. I tried to reuse as much code as possible without making > a mess where every even line is used for GMU and every odd line is > used for GMU wrapper.. > > This series contains: > - plumbing for non-GMU operation, if-ing out GMU calls based on > GMU presence > - GMU wrapper support > - A610 support (w/ speedbin) > - A619 support (w/ speedbin) > - couple of minor fixes and improvements > - VDDCX/VDDGX scaling fix for non-GMU GPUs (concerns more than just > A6xx) > - Enablement of opp interconnect properties > > A619_holi works perfectly fine using the already-present A619 support > in mesa. A610 needs more work on that front, but can already replay > command traces captures on downstream. > > NOTE: the "drm/msm/a6xx: Add support for A619_holi" patch contains > two occurences of 0x18 used in place of a register #define, as it's > supposed to be RBBM_GPR0_CNTL, but that will only be present after > mesa-side changes are merged and headers are synced from there. > > Speedbin patches depend on: > https://lore.kernel.org/linux-arm-msm/20230120172233.1905761-1-konrad.dyb...@linaro.org/ > > > Konrad Dybcio (14): > drm/msm/a6xx: De-staticize sptprac en/disable functions > drm/msm/a6xx: Extend UBWC config > drm/msm/a6xx: Introduce GMU wrapper support > drm/msm/a6xx: Remove both GBIF and RBBM GBIF halt on hw init > drm/msm/adreno: Disable has_cached_coherent for A610/A619_holi > drm/msm/gpu: Use dev_pm_opp_set_rate for non-GMU GPUs > drm/msm/a6xx: Add support for A619_holi > drm/msm/a6xx: Add A610 support > drm/msm/a6xx: Fix some A619 tunables > drm/msm/a6xx: Fix up A6XX protected registers > drm/msm/a6xx: Enable optional icc voting from OPP tables > drm/msm/a6xx: Use "else if" in GPU speedbin rev matching > drm/msm/a6xx: Add A619_holi speedbin support > drm/msm/a6xx: Add A610 speedbin support > > drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 55 ++- > drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 2 + > drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 427 +--- > drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 1 + > drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 14 +- > drivers/gpu/drm/msm/adreno/adreno_device.c | 34 +- > drivers/gpu/drm/msm/adreno/adreno_gpu.c | 4 + > drivers/gpu/drm/msm/adreno/adreno_gpu.h | 19 +- > drivers/gpu/drm/msm/msm_gpu_devfreq.c | 2 +- > 9 files changed, 492 insertions(+), 66 deletions(-) > > -- > 2.39.1 >
Re: [PATCH v2 10/14] drm/msm/a6xx: Fix up A6XX protected registers
On Tue, Feb 14, 2023 at 9:32 AM Konrad Dybcio wrote:
>
> One of the protected ranges was too small (compared to the data we
> have downstream). Fix it.
>
> Fixes: 408434036958 ("drm/msm/a6xx: update/fix CP_PROTECT initialization")
> Signed-off-by: Konrad Dybcio
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index 503c750216e6..d6b38bfdb3b4 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -690,7 +690,7 @@ static const u32 a6xx_protect[] = {
> A6XX_PROTECT_NORDWR(0x00800, 0x0082),
> A6XX_PROTECT_NORDWR(0x008a0, 0x0008),
> A6XX_PROTECT_NORDWR(0x008ab, 0x0024),
> - A6XX_PROTECT_RDONLY(0x008de, 0x00ae),
> + A6XX_PROTECT_RDONLY(0x008d0, 0x00bc),
Nak, this is intentional, we need userspace to be able to configure
the CP counters. Otherwise this would break fdperf, perfetto, etc
(although maybe we should comment where we diverge from downstream)
BR,
-R
> A6XX_PROTECT_NORDWR(0x00900, 0x004d),
> A6XX_PROTECT_NORDWR(0x0098d, 0x0272),
> A6XX_PROTECT_NORDWR(0x00e00, 0x0001),
> --
> 2.39.1
>
[PATCH v5 1/8] drm/i915/pxp: Add GSC-CS back-end resource init and cleanup
For MTL, the PXP back-end transport uses the GSC engine to submit
HECI packets through the HW to the GSC firmware for PXP arb
session management. This submission uses a non-priveleged
batch buffer, a buffer for the command packet and of course
a context targeting the GSC-CS.
Thus for MTL, we need to allocate and free a set of execution
submission resources for the management of the arbitration session.
Lets start with the context creation first since that object and
its usage is very straight-forward. We'll add the buffer allocation
and freeing later when we introduce the gsccs' send-message function.
Do this one time allocation of gsccs specific resources in
a new gsccs source file with intel_pxp_gsccs_init / fini functions
and hook them up from the PXP front-end.
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp.c | 19 +--
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 61 ++
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h | 29 ++
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 2 -
drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 8 +++
6 files changed, 114 insertions(+), 6 deletions(-)
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 918470a04591..ec2f7d4ed638 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -332,6 +332,7 @@ i915-y += \
i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp_cmd.o \
pxp/intel_pxp_debugfs.o \
+ pxp/intel_pxp_gsccs.o \
pxp/intel_pxp_irq.o \
pxp/intel_pxp_pm.o \
pxp/intel_pxp_session.o
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 9d4c7724e98e..560d94d23114 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -12,6 +12,7 @@
#include "i915_drv.h"
#include "intel_pxp.h"
+#include "intel_pxp_gsccs.h"
#include "intel_pxp_irq.h"
#include "intel_pxp_session.h"
#include "intel_pxp_tee.h"
@@ -132,7 +133,10 @@ static void pxp_init_full(struct intel_pxp *pxp)
if (ret)
return;
- ret = intel_pxp_tee_component_init(pxp);
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+ ret = intel_pxp_gsccs_init(pxp);
+ else
+ ret = intel_pxp_tee_component_init(pxp);
if (ret)
goto out_context;
@@ -165,9 +169,11 @@ static struct intel_gt
*find_gt_for_required_protected_content(struct drm_i915_p
/*
* For MTL onwards, PXP-controller-GT needs to have a valid GSC engine
* on the media GT. NOTE: if we have a media-tile with a GSC-engine,
-* the VDBOX is already present so skip that check
+* the VDBOX is already present so skip that check. We also have to
+* ensure the GSC firmware is coming online
*/
- if (i915->media_gt && HAS_ENGINE(i915->media_gt, GSC0))
+ if (i915->media_gt && HAS_ENGINE(i915->media_gt, GSC0) &&
+ intel_uc_fw_is_loadable(&i915->media_gt->uc.gsc.fw))
return i915->media_gt;
/*
@@ -207,7 +213,9 @@ int intel_pxp_init(struct drm_i915_private *i915)
if (!i915->pxp)
return -ENOMEM;
+ /* init common info used by all feature-mode usages*/
i915->pxp->ctrl_gt = gt;
+ mutex_init(&i915->pxp->tee_mutex);
/*
* If full PXP feature is not available but HuC is loaded by GSC on
pre-MTL
@@ -229,7 +237,10 @@ void intel_pxp_fini(struct drm_i915_private *i915)
i915->pxp->arb_is_valid = false;
- intel_pxp_tee_component_fini(i915->pxp);
+ if (HAS_ENGINE(i915->pxp->ctrl_gt, GSC0))
+ intel_pxp_gsccs_fini(i915->pxp);
+ else
+ intel_pxp_tee_component_fini(i915->pxp);
destroy_vcs_context(i915->pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
new file mode 100644
index ..13693e78b57e
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -0,0 +1,61 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2023 Intel Corporation.
+ */
+
+#include "gem/i915_gem_internal.h"
+
+#include "gt/intel_context.h"
+
+#include "i915_drv.h"
+#include "intel_pxp_cmd_interface_43.h"
+#include "intel_pxp_gsccs.h"
+#include "intel_pxp_types.h"
+
+static void
+gsccs_destroy_execution_resource(struct intel_pxp *pxp)
+{
+ struct gsccs_session_resources *strm_res = &pxp->gsccs_res;
+
+ if (strm_res->ce)
+ intel_context_put(strm_res->ce);
+
+ memset(strm_res, 0, sizeof(*strm_res));
+}
+
+static int
+gsccs_allocate_execution_resource(struct intel_pxp *pxp)
+{
+ struct intel_gt *gt = pxp->ctrl_gt;
+ struct gsccs_session_resources *st
[PATCH v5 8/8] drm/i915/pxp: Enable PXP with MTL-GSC-CS
Enable PXP with MTL-GSC-CS: add the has_pxp into device info
and increase the timeouts for new GSC-CS + firmware specs.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/i915_pci.c | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index a8d942b16223..4ecf0f2ab6ec 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1150,6 +1150,7 @@ static const struct intel_device_info mtl_info = {
.has_guc_deprivilege = 1,
.has_mslice_steering = 0,
.has_snoop = 1,
+ .has_pxp = 1,
.__runtime.memory_regions = REGION_SMEM | REGION_STOLEN_LMEM,
.__runtime.platform_engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(CCS0),
.require_force_probe = 1,
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
index 4ddf2ee60222..03f006f9dc2e 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
@@ -44,7 +44,7 @@ static int pxp_wait_for_session_state(struct intel_pxp *pxp,
u32 id, bool in_pla
KCR_SIP(pxp->kcr_base),
mask,
in_play ? mask : 0,
- 100);
+ 250);
intel_runtime_pm_put(uncore->rpm, wakeref);
--
2.39.0
[PATCH v5 3/8] drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC
Add helper functions into a new file for heci-packet-submission.
The helpers will handle generating the MTL GSC-CS Memory-Header
and submission of the Heci-Cmd-Packet instructions to the engine.
NOTE1: These common functions for heci-packet-submission will be used
by different i915 callers:
1- GSC-SW-Proxy: This is pending upstream publication awaiting
a few remaining opens
2- MTL-HDCP: An equivalent patch has also been published at:
https://patchwork.freedesktop.org/series/111876/. (Patch 1)
3- PXP: This series.
NOTE2: A difference in this patch vs what is appearing is in bullet 2
above is that HDCP (and SW-Proxy) will be using priveleged submission
(GGTT and common gsc-uc-context) while PXP will be using non-priveleged
PPGTT, context and batch buffer. Therefore this patch will only slightly
overlap with the MTL-HDCP patches despite have very similar function
names (emit_foo vs emit_nonpriv_foo). This is because HECI_CMD_PKT
instructions require different flows and hw-specific code when done
via PPGTT based submission (not different from other engines). MTL-HDCP
contains the same intel_gsc_mtl_header_t structures as this but the
helpers there are different. Both add the same new file names.
NOTE3: Additional clarity about the heci-cmd-pkt layout and where the
common helpers come in:
- On MTL, when an i915 subsystem needs to send a command request
to the security firmware, it will send that via the GSC-
engine-command-streamer.
- However those commands, (lets call them "gsc_specific_fw_api"
calls), are not understood by the GSC command streamer hw.
- The GSC CS only looks at the GSC_HECI_CMD_PKT instruction and
passes it along to the GSC firmware.
- The GSC FW on the other hand needs additional metadata to know
which usage service is being called (PXP, HDCP, proxy, etc) along
with session specific info. Thus an extra header called GSC-CS
HECI Memory Header, (C) in below diagram is prepended before
the FW specific API, (D).
- Thus, the structural layout of the request submitted would
need to look like the diagram below (for non-priv PXP).
- In the diagram, the common helper for HDCP, (GSC-Sw-Proxy) and
PXP (i.e. new function intel_gsc_uc_heci_cmd_emit_mtl_header)
will populate blob (C) while additional helpers, different for
PPGGTT (this patch) vs GGTT (HDCP series) will populate
blobs (A) and (B) below.
___
(A) | MI_BATCH_BUFFER_START (ppgtt, batchbuff-addr, ...) |
| | |
|_| |
| (B)| GSC_HECI_CMD_PKT (pkt-addr-in, pkt-size-in,| |
|| pkt-addr-out, pkt-size-out) |
|| MI_BATCH_BUFFER_END| | |
||| | |
| | |
|_| |
|
-
|
\|/
__V___
| _|
|(C)| ||
| | struct intel_gsc_mtl_header { ||
| | validity marker ||
| | heci_clent_id ||
| | ... ||
| | }||
| |___||
|(D)| ||
| | struct gsc_fw_specific_api_foobar { ||
| | ... ||
| | For an example, see ||
| | 'struct pxp43_create_arb_in' at ||
| | intel_pxp_cmd_interface_43.h ||
| | ||
| | } ||
| | Struture depends on command type ||
| | struct gsc_fw_specific_api_foobar { ||
| |___||
||
That said, this patch provides basic helpers but leaves the
PXP subsystem (i.e. the caller) to handle (D) and everything
else such as input/output size verification or handling the
responses from security firmware (for example, requiring a retry).
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 2 +
.../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c | 108 +
[PATCH v5 6/8] drm/i915/pxp: MTL-KCR interrupt ctrl's are in GT-0
Despite KCR subsystem being in the media-tile (close to the
GSC-CS), the IRQ controls for it are on GT-0 with other global
IRQ controls. Thus, add a helper for KCR hw interrupt
enable/disable functions to get the correct gt structure (for
uncore) for MTL.
In the helper, we get GT-0's handle for uncore when touching
IRQ registers despite the pxp->ctrl_gt being the media-tile.
No difference for legacy of course.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 24 +---
drivers/gpu/drm/i915/pxp/intel_pxp_irq.h | 8 +++
3 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
index 4b8e70caa3ad..9f6e300486b4 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
@@ -44,7 +44,7 @@ static int pxp_terminate_get(void *data, u64 *val)
static int pxp_terminate_set(void *data, u64 val)
{
struct intel_pxp *pxp = data;
- struct intel_gt *gt = pxp->ctrl_gt;
+ struct intel_gt *gt = intel_pxp_get_irq_gt(pxp);
if (!intel_pxp_is_active(pxp))
return -ENODEV;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
index 91e9622c07d0..3a725397349f 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
@@ -4,10 +4,12 @@
*/
#include
+#include "gt/intel_gt.h"
#include "gt/intel_gt_irq.h"
#include "gt/intel_gt_regs.h"
#include "gt/intel_gt_types.h"
+#include "i915_drv.h"
#include "i915_irq.h"
#include "i915_reg.h"
@@ -17,6 +19,22 @@
#include "intel_pxp_types.h"
#include "intel_runtime_pm.h"
+/**
+ * intel_pxp_get_irq_gt - Find the correct GT that owns KCR interrupts
+ * @pxp: pointer to pxp struct
+ *
+ * For platforms with a single GT, we return the pxp->ctrl_gt (as expected)
+ * but for MTL+ that has a media-tile, although the KCR engine is in the
+ * media-tile (i.e. pxp->ctrl_gt), the IRQ controls are on the root tile.
+ * In the end, we don't use pxp->ctrl_gt for IRQ, we always return root gt.
+ */
+struct intel_gt *intel_pxp_get_irq_gt(struct intel_pxp *pxp)
+{
+ WARN_ON_ONCE(!pxp->ctrl_gt->i915->media_gt &&
!gt_is_root(pxp->ctrl_gt));
+
+ return to_gt(pxp->ctrl_gt->i915);
+}
+
/**
* intel_pxp_irq_handler - Handles PXP interrupts.
* @pxp: pointer to pxp struct
@@ -29,7 +47,7 @@ void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir)
if (GEM_WARN_ON(!intel_pxp_is_enabled(pxp)))
return;
- gt = pxp->ctrl_gt;
+ gt = intel_pxp_get_irq_gt(pxp);
lockdep_assert_held(gt->irq_lock);
@@ -68,7 +86,7 @@ static inline void pxp_irq_reset(struct intel_gt *gt)
void intel_pxp_irq_enable(struct intel_pxp *pxp)
{
- struct intel_gt *gt = pxp->ctrl_gt;
+ struct intel_gt *gt = intel_pxp_get_irq_gt(pxp);
spin_lock_irq(gt->irq_lock);
@@ -83,7 +101,7 @@ void intel_pxp_irq_enable(struct intel_pxp *pxp)
void intel_pxp_irq_disable(struct intel_pxp *pxp)
{
- struct intel_gt *gt = pxp->ctrl_gt;
+ struct intel_gt *gt = intel_pxp_get_irq_gt(pxp);
/*
* We always need to submit a global termination when we re-enable the
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
index 8c292dc86f68..eea87c9eb62b 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
@@ -9,6 +9,7 @@
#include
struct intel_pxp;
+struct intel_gt;
#define GEN12_DISPLAY_PXP_STATE_TERMINATED_INTERRUPT BIT(1)
#define GEN12_DISPLAY_APP_TERMINATED_PER_FW_REQ_INTERRUPT BIT(2)
@@ -23,6 +24,8 @@ struct intel_pxp;
void intel_pxp_irq_enable(struct intel_pxp *pxp);
void intel_pxp_irq_disable(struct intel_pxp *pxp);
void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir);
+struct intel_gt *intel_pxp_get_irq_gt(struct intel_pxp *pxp);
+
#else
static inline void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir)
{
@@ -35,6 +38,11 @@ static inline void intel_pxp_irq_enable(struct intel_pxp
*pxp)
static inline void intel_pxp_irq_disable(struct intel_pxp *pxp)
{
}
+
+static inline struct intel_gt *intel_pxp_get_irq_gt(struct intel_pxp *pxp)
+{
+ return NULL;
+}
#endif
#endif /* __INTEL_PXP_IRQ_H__ */
--
2.39.0
[PATCH v5 4/8] drm/i915/pxp: Add GSC-CS backend to send GSC fw messages
Add GSC engine based method for sending PXP firmware packets
to the GSC firmware for MTL (and future) products.
Use the newly added helpers to populate the GSC-CS memory
header and send the message packet to the FW by dispatching
the GSC_HECI_CMD_PKT instruction on the GSC engine.
We use non-priveleged batches for submission to GSC engine
and require two buffers for the request:
- a buffer for the HECI packet that contains PXP FW commands
- a batch-buffer that contains the engine instruction for
sending the HECI packet to the GSC firmware.
Thus, add the allocation and freeing of these buffers in gsccs
init and fini.
Signed-off-by: Alan Previn
---
.../drm/i915/pxp/intel_pxp_cmd_interface_43.h | 4 +
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 224 +-
drivers/gpu/drm/i915/pxp/intel_pxp_types.h| 6 +
3 files changed, 232 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
index ad67e3f49c20..b2523d6918c7 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
@@ -12,6 +12,10 @@
/* PXP-Cmd-Op definitions */
#define PXP43_CMDID_START_HUC_AUTH 0x003A
+/* PXP-Packet sizes for MTL's GSCCS-HECI instruction */
+#define PXP43_MAX_HECI_IN_SIZE (SZ_32K)
+#define PXP43_MAX_HECI_OUT_SIZE (SZ_32K)
+
/* PXP-Input-Packet: HUC-Authentication */
struct pxp43_start_huc_auth_in {
struct pxp_cmd_header header;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
index 13693e78b57e..3cd28db830c1 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -6,19 +6,211 @@
#include "gem/i915_gem_internal.h"
#include "gt/intel_context.h"
+#include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
#include "i915_drv.h"
#include "intel_pxp_cmd_interface_43.h"
#include "intel_pxp_gsccs.h"
#include "intel_pxp_types.h"
+static int gsccs_send_message(struct intel_pxp *pxp,
+ void *msg_in, size_t msg_in_size,
+ void *msg_out, size_t msg_out_size_max,
+ size_t *msg_out_len,
+ u64 *gsc_msg_handle_retry)
+{
+ struct intel_gt *gt = pxp->ctrl_gt;
+ struct drm_i915_private *i915 = gt->i915;
+ struct gsccs_session_resources *exec = &pxp->gsccs_res;
+ struct intel_gsc_mtl_header *header = exec->pkt_vaddr;
+ struct intel_gsc_heci_non_priv_pkt pkt;
+ bool null_pkt = !msg_in && !msg_out;
+ size_t max_msg_size;
+ u32 reply_size;
+ int ret;
+
+ if (!exec->ce)
+ return -ENODEV;
+
+ max_msg_size = PXP43_MAX_HECI_IN_SIZE - sizeof(*header);
+
+ if (msg_in_size > max_msg_size || msg_out_size_max > max_msg_size)
+ return -ENOSPC;
+
+ mutex_lock(&pxp->tee_mutex);
+
+ if (!exec->pkt_vma || !exec->bb_vma)
+ return -ENOENT;
+
+ memset(header, 0, sizeof(*header));
+ intel_gsc_uc_heci_cmd_emit_mtl_header(header, GSC_HECI_MEADDRESS_PXP,
+ msg_in_size + sizeof(*header),
+ exec->host_session_handle);
+
+ /* check if this is a host-session-handle cleanup call */
+ if (null_pkt)
+ header->flags |= GSC_HECI_FLAG_MSG_CLEANUP;
+
+ /* copy caller provided gsc message handle if this is polling for a
prior msg completion */
+ header->gsc_message_handle = *gsc_msg_handle_retry;
+
+ /* NOTE: zero size packets are used for session-cleanups */
+ if (msg_in && msg_in_size)
+ memcpy(exec->pkt_vaddr + sizeof(*header), msg_in, msg_in_size);
+
+ pkt.addr_in = i915_vma_offset(exec->pkt_vma);
+ pkt.size_in = header->message_size;
+ pkt.addr_out = pkt.addr_in + PXP43_MAX_HECI_IN_SIZE;
+ pkt.size_out = msg_out_size_max + sizeof(*header);
+ pkt.heci_pkt_vma = exec->pkt_vma;
+ pkt.bb_vma = exec->bb_vma;
+
+ ret = intel_gsc_uc_heci_cmd_submit_nonpriv(>->uc.gsc,
+ exec->ce, &pkt,
exec->bb_vaddr, 500);
+ if (ret) {
+ drm_err(&i915->drm, "failed to send gsc PXP msg (%d)\n", ret);
+ goto unlock;
+ }
+
+ /* we keep separate location for reply, so get the response header loc
first */
+ header = exec->pkt_vaddr + PXP43_MAX_HECI_IN_SIZE;
+
+ /* Response validity marker, status and busyness */
+ if (header->validity_marker != GSC_HECI_VALIDITY_MARKER) {
+ drm_err(&i915->drm, "gsc PXP reply with invalid validity
marker\n");
+ ret = -EINVAL;
+ goto unlock;
+ }
+ if (header->status != 0) {
+ drm_dbg(&i915->drm, "gsc PXP reply status has error = 0x%08x
[PATCH v5 5/8] drm/i915/pxp: Add ARB session creation and cleanup
Add MTL's function for ARB session creation using PXP firmware
version 4.3 ABI structure format.
Also add MTL's function for ARB session invalidation but this
reuses PXP firmware version 4.2 ABI structure format.
Before checking the return status, look at the GSC-CS-Mem-Header's
pending-bit which means the GSC firmware is busy and we should
resubmit.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp.c | 9 +-
.../drm/i915/pxp/intel_pxp_cmd_interface_43.h | 21 +
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 92 +++
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h| 3 +
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 11 ++-
5 files changed, 132 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index aecc65b5da70..c25e9ff16b57 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -353,8 +353,13 @@ int intel_pxp_start(struct intel_pxp *pxp)
if (!intel_pxp_is_enabled(pxp))
return -ENODEV;
- if (wait_for(pxp_component_bound(pxp), 250))
- return -ENXIO;
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0)) {
+ if (wait_for(intel_uc_fw_is_running(&pxp->ctrl_gt->uc.gsc.fw),
250))
+ return -ENXIO;
+ } else {
+ if (wait_for(pxp_component_bound(pxp), 250))
+ return -ENXIO;
+ }
mutex_lock(&pxp->arb_mutex);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
index b2523d6918c7..9089e02a8c2d 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
@@ -11,6 +11,7 @@
/* PXP-Cmd-Op definitions */
#define PXP43_CMDID_START_HUC_AUTH 0x003A
+#define PXP43_CMDID_INIT_SESSION 0x0036
/* PXP-Packet sizes for MTL's GSCCS-HECI instruction */
#define PXP43_MAX_HECI_IN_SIZE (SZ_32K)
@@ -27,4 +28,24 @@ struct pxp43_start_huc_auth_out {
struct pxp_cmd_header header;
} __packed;
+/* PXP-Input-Packet: Init PXP session */
+struct pxp43_create_arb_in {
+ struct pxp_cmd_header header;
+ /* header.stream_id fields for vesion 4.3 of Init PXP session:
*/
+ #define PXP43_INIT_SESSION_VALID BIT(0)
+ #define PXP43_INIT_SESSION_APPTYPE BIT(1)
+ #define PXP43_INIT_SESSION_APPID GENMASK(17, 2)
+ u32 protection_mode;
+ #define PXP43_INIT_SESSION_PROTECTION_ARB 0x2
+ u32 sub_session_id;
+ u32 init_flags;
+ u32 rsvd[12];
+} __packed;
+
+/* PXP-Input-Packet: Init PXP session */
+struct pxp43_create_arb_out {
+ struct pxp_cmd_header header;
+ u32 rsvd[8];
+} __packed;
+
#endif /* __INTEL_PXP_FW_INTERFACE_43_H__ */
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
index 3cd28db830c1..002686cc7c8a 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -9,6 +9,7 @@
#include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
#include "i915_drv.h"
+#include "intel_pxp_cmd_interface_42.h"
#include "intel_pxp_cmd_interface_43.h"
#include "intel_pxp_gsccs.h"
#include "intel_pxp_types.h"
@@ -121,6 +122,97 @@ static int gsccs_send_message(struct intel_pxp *pxp,
return ret;
}
+int intel_pxp_gsccs_create_session(struct intel_pxp *pxp,
+ int arb_session_id)
+{
+ struct drm_i915_private *i915 = pxp->ctrl_gt->i915;
+ struct gsccs_session_resources *exec = &pxp->gsccs_res;
+ struct pxp43_create_arb_in msg_in = {0};
+ struct pxp43_create_arb_out msg_out = {0};
+ u64 gsc_session_retry = 0;
+ int ret, tries = 0;
+
+ /* get a unique host-session-handle (used later in HW cmds) at time of
session creation */
+ get_random_bytes(&exec->host_session_handle,
sizeof(exec->host_session_handle));
+
+ msg_in.header.api_version = PXP_APIVER(4, 3);
+ msg_in.header.command_id = PXP43_CMDID_INIT_SESSION;
+ msg_in.header.stream_id = (FIELD_PREP(PXP43_INIT_SESSION_APPID,
arb_session_id) |
+ FIELD_PREP(PXP43_INIT_SESSION_VALID, 1) |
+ FIELD_PREP(PXP43_INIT_SESSION_APPTYPE, 0));
+ msg_in.header.buffer_len = sizeof(msg_in) - sizeof(msg_in.header);
+ msg_in.protection_mode = PXP43_INIT_SESSION_PROTECTION_ARB;
+
+ /*
+* Keep sending request if GSC firmware was busy.
+* Based on specs, we can expects a worst case pending-bit
+* delay of 2000 milisecs.
+*/
+ do {
+ ret = gsccs_send_message(pxp,
+&msg_in, sizeof(msg_in),
+&msg_out, sizeof(msg_out), NULL,
+&gsc_sessi
[PATCH v5 7/8] drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component
On legacy platforms, KCR HW enabling is done at the time the mei
component interface is bound. It's also disabled during unbind.
However, for MTL onwards, we don't depend on a tee component
to start sending GSC-CS firmware messages.
Thus, immediately enable (or disable) KCR HW on PXP's init,
fini and resume.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp.c| 19 +++
drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 3 ++-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index c25e9ff16b57..425e552e335d 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -119,6 +119,7 @@ static void destroy_vcs_context(struct intel_pxp *pxp)
static void pxp_init_full(struct intel_pxp *pxp)
{
struct intel_gt *gt = pxp->ctrl_gt;
+ intel_wakeref_t wakeref;
int ret;
/*
@@ -140,10 +141,15 @@ static void pxp_init_full(struct intel_pxp *pxp)
if (ret)
return;
- if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0)) {
ret = intel_pxp_gsccs_init(pxp);
- else
+ if (!ret) {
+ with_intel_runtime_pm(&pxp->ctrl_gt->i915->runtime_pm,
wakeref)
+ intel_pxp_init_hw(pxp);
+ }
+ } else {
ret = intel_pxp_tee_component_init(pxp);
+ }
if (ret)
goto out_context;
@@ -239,15 +245,20 @@ int intel_pxp_init(struct drm_i915_private *i915)
void intel_pxp_fini(struct drm_i915_private *i915)
{
+ intel_wakeref_t wakeref;
+
if (!i915->pxp)
return;
i915->pxp->arb_is_valid = false;
- if (HAS_ENGINE(i915->pxp->ctrl_gt, GSC0))
+ if (HAS_ENGINE(i915->pxp->ctrl_gt, GSC0)) {
+ with_intel_runtime_pm(&i915->pxp->ctrl_gt->i915->runtime_pm,
wakeref)
+ intel_pxp_fini_hw(i915->pxp);
intel_pxp_gsccs_fini(i915->pxp);
- else
+ } else {
intel_pxp_tee_component_fini(i915->pxp);
+ }
destroy_vcs_context(i915->pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
index 4f836b317424..1a04067f61fc 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
@@ -43,8 +43,9 @@ void intel_pxp_resume_complete(struct intel_pxp *pxp)
* The PXP component gets automatically unbound when we go into S3 and
* re-bound after we come out, so in that scenario we can defer the
* hw init to the bind call.
+* NOTE: GSC-CS backend doesn't rely on components.
*/
- if (!pxp->pxp_component)
+ if (!HAS_ENGINE(pxp->ctrl_gt, GSC0) && !pxp->pxp_component)
return;
intel_pxp_init_hw(pxp);
--
2.39.0
[PATCH v5 2/8] drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operation
Add MTL hw-plumbing enabling for KCR operation under PXP
which includes:
1. Updating 'pick-gt' to get the media tile for
KCR interrupt handling
2. Adding MTL's KCR registers for PXP operation
(init, status-checking, etc.).
While doing #2, lets create a separate registers header file for PXP
to be consistent with other i915 global subsystems.
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 3 +-
drivers/gpu/drm/i915/pxp/intel_pxp.c | 32
drivers/gpu/drm/i915/pxp/intel_pxp_regs.h| 27 +
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 12 +++-
drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 6
5 files changed, 58 insertions(+), 22 deletions(-)
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index 1b25a6039152..c360776a98b5 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -100,7 +100,8 @@ static struct intel_gt *pick_gt(struct intel_gt *gt, u8
class, u8 instance)
case VIDEO_ENHANCEMENT_CLASS:
return media_gt;
case OTHER_CLASS:
- if (instance == OTHER_GSC_INSTANCE && HAS_ENGINE(media_gt,
GSC0))
+ if ((instance == OTHER_GSC_INSTANCE || instance ==
OTHER_KCR_INSTANCE) &&
+ HAS_ENGINE(media_gt, GSC0))
return media_gt;
fallthrough;
default:
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 560d94d23114..aecc65b5da70 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -14,6 +14,7 @@
#include "intel_pxp.h"
#include "intel_pxp_gsccs.h"
#include "intel_pxp_irq.h"
+#include "intel_pxp_regs.h"
#include "intel_pxp_session.h"
#include "intel_pxp_tee.h"
#include "intel_pxp_types.h"
@@ -61,21 +62,22 @@ bool intel_pxp_is_active(const struct intel_pxp *pxp)
return IS_ENABLED(CONFIG_DRM_I915_PXP) && pxp && pxp->arb_is_valid;
}
-/* KCR register definitions */
-#define KCR_INIT _MMIO(0x320f0)
-/* Setting KCR Init bit is required after system boot */
-#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES REG_BIT(14)
+static void kcr_pxp_set_status(const struct intel_pxp *pxp, bool enable)
+{
+ u32 val = enable ? _MASKED_BIT_ENABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES)
:
+ _MASKED_BIT_DISABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES);
+
+ intel_uncore_write(pxp->ctrl_gt->uncore, KCR_INIT(pxp->kcr_base), val);
+}
-static void kcr_pxp_enable(struct intel_gt *gt)
+static void kcr_pxp_enable(const struct intel_pxp *pxp)
{
- intel_uncore_write(gt->uncore, KCR_INIT,
-
_MASKED_BIT_ENABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
+ kcr_pxp_set_status(pxp, true);
}
-static void kcr_pxp_disable(struct intel_gt *gt)
+static void kcr_pxp_disable(const struct intel_pxp *pxp)
{
- intel_uncore_write(gt->uncore, KCR_INIT,
-
_MASKED_BIT_DISABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
+ kcr_pxp_set_status(pxp, false);
}
static int create_vcs_context(struct intel_pxp *pxp)
@@ -127,6 +129,11 @@ static void pxp_init_full(struct intel_pxp *pxp)
init_completion(&pxp->termination);
complete_all(&pxp->termination);
+ if (pxp->ctrl_gt->type == GT_MEDIA)
+ pxp->kcr_base = MTL_KCR_BASE;
+ else
+ pxp->kcr_base = GEN12_KCR_BASE;
+
intel_pxp_session_management_init(pxp);
ret = create_vcs_context(pxp);
@@ -368,14 +375,13 @@ int intel_pxp_start(struct intel_pxp *pxp)
void intel_pxp_init_hw(struct intel_pxp *pxp)
{
- kcr_pxp_enable(pxp->ctrl_gt);
+ kcr_pxp_enable(pxp);
intel_pxp_irq_enable(pxp);
}
void intel_pxp_fini_hw(struct intel_pxp *pxp)
{
- kcr_pxp_disable(pxp->ctrl_gt);
-
+ kcr_pxp_disable(pxp);
intel_pxp_irq_disable(pxp);
}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
new file mode 100644
index ..a9e7e6efa4c7
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright(c) 2023, Intel Corporation. All rights reserved.
+ */
+
+#ifndef __INTEL_PXP_REGS_H__
+#define __INTEL_PXP_REGS_H__
+
+#include "i915_reg_defs.h"
+
+/* KCR subsystem register base address */
+#define GEN12_KCR_BASE 0x32000
+#define MTL_KCR_BASE 0x386000
+
+/* KCR enable/disable control */
+#define KCR_INIT(base) _MMIO((base) + 0xf0)
+
+/* Setting KCR Init bit is required after system boot */
+#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES REG_BIT(14)
+
+/* KCR hwdrm session in play status 0-31 */
+#define KCR_SIP(base) _MMIO((base) + 0x260)
+
+/* PXP global terminate register for session termination */
+#define KCR_GLOBAL_TERMINATE(bas
[PATCH v5 0/8] drm/i915/pxp: Add MTL PXP Support
This series enables PXP on MTL. On ADL/TGL platforms, we rely on the mei driver via the i915-mei PXP component interface to establish a connection to the security firmware via the HECI device interface. That interface is used to create and teardown the PXP ARB session. PXP ARB session is created when protected contexts are created. In this series, the front end behaviors and interfaces (uapi) remain the same. We add backend support for MTL but with MTL we directly use the GSC-CS engine on the MTL GPU device to send messages to the PXP (a.k.a. GSC a.k.a graphics-security) firmware. With MTL, the format of the message is slightly different with a 2-layer packetization that is explained in detail in Patch #3. Also, the second layer which is the actual PXP firmware packet is now rev'd to version 4.3 for MTL that is defined in Patch #5. Take note that Patch #4 adds the buffer allocation and gsccs-send- message without actually being called by the arb-creation code which gets added in Patch #5. Additionally, a seperate series being reviewed is introducing a change for session teardown (in pxp front- end layer that will need backend support by both legacy and gsccs). If we squash all of these together (buffer-alloc, send-message, arb-creation and, in future, session-termination), the single patch will be rather large. That said, we are keeping Patch #4 and #5 separate for now, but at merge time, we can squash them together if maintainer requires it. Changes from prior revs: v1 : - fixed when building with CONFIG_PXP disabled. - more alignment with gsc_mtl_header structure from the HDCP v2 : - (all following changes as per reviews from Daniele) - squashed Patch #1 from v1 into the next one. - replaced unnecessary "uses_gsccs" boolean in the pxp with "HAS_ENGINE(pxp->ctrl_gt, GSC0)". - moved the stashing of gsccs resources from a dynamically allocated opaque handle to an explicit sub-struct in 'struct intel_pxp'. - moved the buffer object allocations from Patch #1 of this series to Patch #5 (but keep the context allocation in Patch #1). - used the kernel default ppgtt for the gsccs context. - optimized the buffer allocation and deallocation code and drop the need to stash the drm_i915_gem_object. - use a macro with the right mmio reg base (depending on root-tile vs media-tile) along with common relative offset to access all KCR registers thus minimizing changes to the KCR register access codes. - fixed bugs in the heci packet request submission code in Patch #3 (of this series) - add comments in the mtl-gsc-heci-header regarding the host-session-handle. - re-use tee-mutex instead of introducing a gsccs specific cmd mutex. - minor cosmetic improvements in Patch #5. - before creating arb session, ensure intel_pxp_start first ensures the GSC FW is up and running. - use 2 second timeout for the pending-bit scenario when sending command to GSC-FW as per specs. - simplify intel_pxp_get_irq_gt with addition comments - redo Patch #7 to minimize the changes without introducing a common abstraction helper for suspend/resume/init/fini codes that have to change the kcr power state. v3 : - rebase onto latest drm-tip with the updated firmware session invalidation flow - on Patch#1: move 'mutex_init(&pxp->tee_mutex)' to a common init place in intel_pxp_init since its needed everywhere (Daniele) - on Patch#1: remove unneccasary "ce->vm = i915_vm_get(vm);" (Daniele) - on Patch#2: move the introduction of host_session_handle to Patch#4 where it starts getting used. - on Patch#4: move host-session-handle initialization to the allocate-resources during gsccs-init (away from Patch#5) and add the required call to PXP-firmware to cleanup the host-session-handle in destroy-resources during gsccs-fini - on Patch#5: add dispatching of arb session termination firmware cmd during session teardown (as per latest upstream flows) v4 : - Added proper initialization and cleanup of host-session-handle that the gsc firmware expects. - Fix the stream-session-key invalidation instruction for MTL. Alan Previn (8): drm/i915/pxp: Add GSC-CS back-end resource init and cleanup drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operation drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC drm/i915/pxp: Add GSC-CS backend to send GSC fw messages drm/i915/pxp: Add ARB session creation and cleanup drm/i915/pxp: MTL-KCR interrupt ctrl's are in GT-0 drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component drm/i915/pxp: Enable PXP with MTL-GSC-CS drivers/gpu/drm/i915/Makef
Re: [PATCH v1 RFC] video/hdmi: Fix HDMI_VENDOR_INFOFRAME_SIZE
On Tue, Feb 14, 2023 at 10:26:24PM +0100, Martin Blumenstingl wrote: > On Mon, Feb 13, 2023 at 12:11 PM Ville Syrjälä > wrote: > [...] > > > One could use HDMI_VENDOR_INFOFRAME_SIZE with this as well: > > > u8 buffer[HDMI_INFOFRAME_SIZE(VENDOR)]; > > > But it would only result in an 8 byte wide buffer. > > > Nobody uses it like this yet. > > > > Not sure that would make any sense since a vendor > > specific infoframe has no defined size until you > > figure out which vendor defined it (via the OUI). > My understanding is that all of the existing HDMI vendor infoframe > code is built for HDMI_IEEE_OUI. Only because no one has bothered to implement any others. > > > I suppose the current value of 4 is also a bit nonsense > > as well then, becasue that is a legal value for the > > HDMI 1.4 vendor specific infoframe, but might not be > > valid for any other infoframe. > > > > We should perhaps just get rid of HDMI_VENDOR_INFOFRAME_SIZE > > entirely. > My thought was to make it the correct size for > drm_hdmi_vendor_infoframe_from_display_mode(). Then developers using > this "common" vendor infoframe don't have to worry much. > If there's another vendor infoframe implementation (which I'm not > aware of, but it may exist - since as you point out: it's vendor > specific) then the driver code shouldn't use > drm_hdmi_vendor_infoframe_from_display_mode() but rather implement > something custom. At that point the person implementing that will also > need to know their specific infoframe maximum size. Yes but that other infoframe will still have type==HDMI_INFOFRAME_TYPE_VENDOR, and HDMI_INFOFRAME_SIZE(VENDOR) would again give the wrong answer. -- Ville Syrjälä Intel
Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
On Tue, Feb 14, 2023 at 10:18:49PM +0100, Sebastian Wick wrote: > On Tue, Feb 14, 2023 at 9:10 PM Ville Syrjälä > wrote: > > > > On Tue, Feb 14, 2023 at 08:45:00PM +0100, Sebastian Wick wrote: > > > On Tue, Feb 14, 2023 at 5:57 PM Harry Wentland > > > wrote: > > > > > > > > > > > > > > > > On 2/14/23 10:49, Sebastian Wick wrote: > > > > > On Fri, Feb 3, 2023 at 5:00 PM Ville Syrjälä > > > > > wrote: > > > > >> > > > > >> On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote: > > > > >>> > > > > >>> > > > > >>> On 2/3/23 10:19, Ville Syrjälä wrote: > > > > On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote: > > > > > > > > > > > > > > > On 2/3/23 07:59, Sebastian Wick wrote: > > > > >> On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä > > > > >> wrote: > > > > >>> > > > > >>> On Fri, Feb 03, 2023 at 02:07:44AM +, Joshua Ashton wrote: > > > > Userspace has no way of controlling or knowing the pixel > > > > encoding > > > > currently, so there is no way for it to ever get the right > > > > values here. > > > > >>> > > > > >>> That applies to a lot of the other values as well (they are > > > > >>> explicitly RGB or YCC). The idea was that this property sets the > > > > >>> infoframe/MSA/SDP value exactly, and other properties should be > > > > >>> added to for use userspace to control the pixel > > > > >>> encoding/colorspace > > > > >>> conversion(if desired, or userspace just makes sure to > > > > >>> directly feed in correct kind of data). > > > > >> > > > > >> I'm all for getting userspace control over pixel encoding but > > > > >> even > > > > >> then the kernel always knows which pixel encoding is selected and > > > > >> which InfoFrame has to be sent. Is there a reason why userspace > > > > >> would > > > > >> want to control the variant explicitly to the wrong value? > > > > >> > > > > > > > > > > I've asked this before but haven't seen an answer: Is there an > > > > > existing > > > > > upstream userspace project that makes use of this property (other > > > > > than > > > > > what Joshua is working on in gamescope right now)? That would > > > > > help us > > > > > understand the intent better. > > > > > > > > The intent was to control the infoframe colorimetry bits, > > > > nothing more. No idea what real userspace there was, if any. > > > > > > > > > > > > > > I don't think giving userspace explicit control over the exact > > > > > infoframe > > > > > values is the right thing to do. > > > > > > > > Only userspace knows what kind of data it's stuffing into > > > > the pixels (and/or how it configures the csc units/etc.) to > > > > generate them. > > > > > > > > >>> > > > > >>> Yes, but userspace doesn't control or know whether we drive > > > > >>> RGB or YCbCr on the wire. In fact, in some cases our driver > > > > >>> needs to fallback to YCbCr420 for bandwidth reasons. There > > > > >>> is currently no way for userspace to know that and I don't > > > > >>> think it makes sense. > > > > >> > > > > >> People want that control as well for whatever reason. We've > > > > >> been asked to allow YCbCr 4:4:4 output many times. > > > > > > > > > > I don't really think it's a question of if we want it but rather how > > > > > we get there. Harry is completely right that if we would make the > > > > > subsampling controllable by user space instead of the kernel handling > > > > > it magically, user space which does not adapt to the new control won't > > > > > be able to light up some modes which worked before. > > > > > > > > > > > > > Thanks for continuing this discussion and touching on the model of how > > > > we get to where we want to go. > > > > > > > > > This is obviously a problem and not one we can easily fix. We would > > > > > need a new cap for user space to signal "I know that I can control > > > > > bpc, subsampling and compression to lower the bandwidth and light up > > > > > modes which otherwise fail". That cap would also remove all the > > > > > properties which require kernel magic to work (that's also what I > > > > > proposed for my KMS color pipeline API). > > > > > > > > > > We all want to expose more of the scanout capability and give user > > > > > space more control but I don't think an incremental approach works > > > > > here and we would all do better if we accept that the current API > > > > > requires kernel magic to work and has a few implicit assumptions baked > > > > > in. > > > > > > > > > > With all that being said, I think the right decision here is to > > > > > > > > > > 1. Ignore subsampling for now > > > > > 2. Let the kernel select YCC or RGB on the cable > > > > > 3. Let the kernel figure out the conversion between RGB and YCC based > > > > > on the color space selected > > > > > 4. Let the kernel send the correc
Re: [PATCH v1 RFC] video/hdmi: Fix HDMI_VENDOR_INFOFRAME_SIZE
On Mon, Feb 13, 2023 at 12:11 PM Ville Syrjälä wrote: [...] > > One could use HDMI_VENDOR_INFOFRAME_SIZE with this as well: > > u8 buffer[HDMI_INFOFRAME_SIZE(VENDOR)]; > > But it would only result in an 8 byte wide buffer. > > Nobody uses it like this yet. > > Not sure that would make any sense since a vendor > specific infoframe has no defined size until you > figure out which vendor defined it (via the OUI). My understanding is that all of the existing HDMI vendor infoframe code is built for HDMI_IEEE_OUI. > I suppose the current value of 4 is also a bit nonsense > as well then, becasue that is a legal value for the > HDMI 1.4 vendor specific infoframe, but might not be > valid for any other infoframe. > > We should perhaps just get rid of HDMI_VENDOR_INFOFRAME_SIZE > entirely. My thought was to make it the correct size for drm_hdmi_vendor_infoframe_from_display_mode(). Then developers using this "common" vendor infoframe don't have to worry much. If there's another vendor infoframe implementation (which I'm not aware of, but it may exist - since as you point out: it's vendor specific) then the driver code shouldn't use drm_hdmi_vendor_infoframe_from_display_mode() but rather implement something custom. At that point the person implementing that will also need to know their specific infoframe maximum size. Best regards, Martin
Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
On Tue, Feb 14, 2023 at 9:10 PM Ville Syrjälä wrote: > > On Tue, Feb 14, 2023 at 08:45:00PM +0100, Sebastian Wick wrote: > > On Tue, Feb 14, 2023 at 5:57 PM Harry Wentland > > wrote: > > > > > > > > > > > > On 2/14/23 10:49, Sebastian Wick wrote: > > > > On Fri, Feb 3, 2023 at 5:00 PM Ville Syrjälä > > > > wrote: > > > >> > > > >> On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote: > > > >>> > > > >>> > > > >>> On 2/3/23 10:19, Ville Syrjälä wrote: > > > On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote: > > > > > > > > > > > > On 2/3/23 07:59, Sebastian Wick wrote: > > > >> On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä > > > >> wrote: > > > >>> > > > >>> On Fri, Feb 03, 2023 at 02:07:44AM +, Joshua Ashton wrote: > > > Userspace has no way of controlling or knowing the pixel encoding > > > currently, so there is no way for it to ever get the right > > > values here. > > > >>> > > > >>> That applies to a lot of the other values as well (they are > > > >>> explicitly RGB or YCC). The idea was that this property sets the > > > >>> infoframe/MSA/SDP value exactly, and other properties should be > > > >>> added to for use userspace to control the pixel > > > >>> encoding/colorspace > > > >>> conversion(if desired, or userspace just makes sure to > > > >>> directly feed in correct kind of data). > > > >> > > > >> I'm all for getting userspace control over pixel encoding but even > > > >> then the kernel always knows which pixel encoding is selected and > > > >> which InfoFrame has to be sent. Is there a reason why userspace > > > >> would > > > >> want to control the variant explicitly to the wrong value? > > > >> > > > > > > > > I've asked this before but haven't seen an answer: Is there an > > > > existing > > > > upstream userspace project that makes use of this property (other > > > > than > > > > what Joshua is working on in gamescope right now)? That would help > > > > us > > > > understand the intent better. > > > > > > The intent was to control the infoframe colorimetry bits, > > > nothing more. No idea what real userspace there was, if any. > > > > > > > > > > > I don't think giving userspace explicit control over the exact > > > > infoframe > > > > values is the right thing to do. > > > > > > Only userspace knows what kind of data it's stuffing into > > > the pixels (and/or how it configures the csc units/etc.) to > > > generate them. > > > > > > >>> > > > >>> Yes, but userspace doesn't control or know whether we drive > > > >>> RGB or YCbCr on the wire. In fact, in some cases our driver > > > >>> needs to fallback to YCbCr420 for bandwidth reasons. There > > > >>> is currently no way for userspace to know that and I don't > > > >>> think it makes sense. > > > >> > > > >> People want that control as well for whatever reason. We've > > > >> been asked to allow YCbCr 4:4:4 output many times. > > > > > > > > I don't really think it's a question of if we want it but rather how > > > > we get there. Harry is completely right that if we would make the > > > > subsampling controllable by user space instead of the kernel handling > > > > it magically, user space which does not adapt to the new control won't > > > > be able to light up some modes which worked before. > > > > > > > > > > Thanks for continuing this discussion and touching on the model of how > > > we get to where we want to go. > > > > > > > This is obviously a problem and not one we can easily fix. We would > > > > need a new cap for user space to signal "I know that I can control > > > > bpc, subsampling and compression to lower the bandwidth and light up > > > > modes which otherwise fail". That cap would also remove all the > > > > properties which require kernel magic to work (that's also what I > > > > proposed for my KMS color pipeline API). > > > > > > > > We all want to expose more of the scanout capability and give user > > > > space more control but I don't think an incremental approach works > > > > here and we would all do better if we accept that the current API > > > > requires kernel magic to work and has a few implicit assumptions baked > > > > in. > > > > > > > > With all that being said, I think the right decision here is to > > > > > > > > 1. Ignore subsampling for now > > > > 2. Let the kernel select YCC or RGB on the cable > > > > 3. Let the kernel figure out the conversion between RGB and YCC based > > > > on the color space selected > > > > 4. Let the kernel send the correct infoframe based on the selected > > > > color space and cable encoding > > > > 5. Only expose color spaces for which the kernel can do the conversion > > > > and send the infoframe > > > > > > I agree. We don't want to break or change existing behavior (that is > > > used by userspace) and this will get
[PATCH] drm/amd/display: only warn once in dce110_edp_wait_for_hpd_ready()
Since, hot plugging eDP displays isn't supported, it is sufficient for
us to warn about the lack of a connected display once. So, use ASSERT()
in dce110_edp_wait_for_hpd_ready() instead of DC_LOG_WARNING().
Signed-off-by: Hamza Mahfooz
---
drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
index fb3fd5b7c78b..0d4d3d586166 100644
--- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
@@ -779,10 +779,8 @@ void dce110_edp_wait_for_hpd_ready(
dal_gpio_destroy_irq(&hpd);
- if (false == edp_hpd_high) {
- DC_LOG_WARNING(
- "%s: wait timed out!\n", __func__);
- }
+ /* ensure that the panel is detected */
+ ASSERT(edp_hpd_high);
}
void dce110_edp_power_control(
--
2.39.1
Re: [PATCH 1/1] drm/bridge: analogix_dp: add a quirk for Bob panel
Hi,
You seem to have sent this twice, perhaps to adjust the To/CC list. I
think I've picked the right one to reply to, but it's usually nice to
use a "v2" notation or otherwise put a comment somewhere in the email.
On Wed, Feb 08, 2023 at 12:44:06PM +0800, Kencp huang wrote:
> From: zain wang
>
> Some panels' DP_PSR_STATUS (DPCD 0x2008) may be unstable when we
> enable psr. If we get the unexpected psr state, We need try the
> debounce to ensure the panel was in PSR
>
> Signed-off-by: zain wang
> Signed-off-by: Chris Zhong
> Commit-Ready: Kristian H. Kristensen
'Commit-Ready' isn't something that makes sense for upstream Linux. The
other 'Tested-by' and 'Reviewed-by' *might* make sense to carry forward,
even though these were from the Chromium Gerrit instance, but they also
applied to a very old and different version of this patch, so probably
not.
I'd suggest starting over with only the Signed-off-by tags.
> Tested-by: Kristian H. Kristensen
> Reviewed-by: Kristian H. Kristensen
> Tested-by: Kencp huang
> Signed-off-by: Kencp huang
> ---
> .../gpu/drm/bridge/analogix/analogix_dp_reg.c | 71 +++
> 1 file changed, 42 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> index 6a4f20fccf84..7b6e3f8f85b0 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> @@ -935,25 +935,54 @@ void analogix_dp_enable_psr_crc(struct
> analogix_dp_device *dp)
> writel(PSR_VID_CRC_ENABLE, dp->reg_base + ANALOGIX_DP_CRC_CON);
> }
>
> -static ssize_t analogix_dp_get_psr_status(struct analogix_dp_device *dp)
> +static int analogix_dp_get_psr_status(struct analogix_dp_device *dp,
Probably could be called 'analogix_dp_wait_psr_status()', since it's no
longer just a "getter" function.
> + int status)
This would probably make more sense as a 'bool psr_active' or some
similar naming, since it doesn't really represent a "status" field now,
but more of a "am I entering or exiting PSR?" parameter.
> {
> ssize_t val;
> - u8 status;
> + u8 reg, store = 0;
> + int cnt = 0;
> +
> + /* About 3ms for a loop */
The commit description explains why you need this polling/debounce loop,
but it's good to document such artifacts in the code too, when they're
as strange as this one. Perhaps a short explanation about the "bouncing"
behavior of some panels here? "Some panels' DP_PSR_STATUS register is
unstable when entering PSR."
Also, I already had a (pre mailing list) question about why this doesn't
use readx_poll_timeout(), so I'll repeat for the record one reason not
to: it's difficult to handle the stateful debouncing aspect with that
macro, and keep the 'store' variable around.
> + while (cnt < 100) {
> + /* Read operation would takes 900us */
> + val = drm_dp_dpcd_readb(&dp->aux, DP_PSR_STATUS, ®);
> + if (val < 0) {
> + dev_err(dp->dev, "PSR_STATUS read failed ret=%zd", val);
> + return val;
> + }
> +
> + /*
> + * Ensure the PSR_STATE should go to DP_PSR_SINK_ACTIVE_RFB
> + * from DP_PSR_SINK_ACTIVE_SINK_SYNCED or
> + * DP_PSR_SINK_ACTIVE_SRC_SYNCED.
> + * Otherwise, if we get DP_PSR_SINK_ACTIVE_RFB twice in
> + * succession, it show the Panel is stable PSR enabled state.
> + */
> + if (status == DP_PSR_SINK_ACTIVE_RFB) {
> + if ((reg == DP_PSR_SINK_ACTIVE_RFB) &&
> + ((store == DP_PSR_SINK_ACTIVE_SINK_SYNCED) ||
> + (store == DP_PSR_SINK_ACTIVE_SRC_SYNCED) ||
> + (store == DP_PSR_SINK_ACTIVE_RFB)))
> + return 0;
> + else
> + store = reg;
> + } else {
You dropped the ACTIVE_RESYNC and INACTIVE comments from below. Those
probably should move here.
With those fixed, I think this would be fine:
Reviewed-by: Brian Norris
> + if ((reg == DP_PSR_SINK_INACTIVE) ||
> + (reg == DP_PSR_SINK_ACTIVE_RESYNC))
> + return 0;
> + }
>
> - val = drm_dp_dpcd_readb(&dp->aux, DP_PSR_STATUS, &status);
> - if (val < 0) {
> - dev_err(dp->dev, "PSR_STATUS read failed ret=%zd", val);
> - return val;
> + usleep_range(2100, 2200);
> + cnt++;
> }
> - return status;
> +
> + return -ETIMEDOUT;
> }
>
> int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
>struct dp_sdp *vsc, bool blocking)
> {
> unsigned int val;
> - int ret;
> - ssize_t psr_status;
>
> /* don't send info frame */
> val = readl(dp->reg_base +
Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
On Tue, Feb 14, 2023 at 08:45:00PM +0100, Sebastian Wick wrote: > On Tue, Feb 14, 2023 at 5:57 PM Harry Wentland wrote: > > > > > > > > On 2/14/23 10:49, Sebastian Wick wrote: > > > On Fri, Feb 3, 2023 at 5:00 PM Ville Syrjälä > > > wrote: > > >> > > >> On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote: > > >>> > > >>> > > >>> On 2/3/23 10:19, Ville Syrjälä wrote: > > On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote: > > > > > > > > > On 2/3/23 07:59, Sebastian Wick wrote: > > >> On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä > > >> wrote: > > >>> > > >>> On Fri, Feb 03, 2023 at 02:07:44AM +, Joshua Ashton wrote: > > Userspace has no way of controlling or knowing the pixel encoding > > currently, so there is no way for it to ever get the right values > > here. > > >>> > > >>> That applies to a lot of the other values as well (they are > > >>> explicitly RGB or YCC). The idea was that this property sets the > > >>> infoframe/MSA/SDP value exactly, and other properties should be > > >>> added to for use userspace to control the pixel encoding/colorspace > > >>> conversion(if desired, or userspace just makes sure to > > >>> directly feed in correct kind of data). > > >> > > >> I'm all for getting userspace control over pixel encoding but even > > >> then the kernel always knows which pixel encoding is selected and > > >> which InfoFrame has to be sent. Is there a reason why userspace would > > >> want to control the variant explicitly to the wrong value? > > >> > > > > > > I've asked this before but haven't seen an answer: Is there an > > > existing > > > upstream userspace project that makes use of this property (other than > > > what Joshua is working on in gamescope right now)? That would help us > > > understand the intent better. > > > > The intent was to control the infoframe colorimetry bits, > > nothing more. No idea what real userspace there was, if any. > > > > > > > > I don't think giving userspace explicit control over the exact > > > infoframe > > > values is the right thing to do. > > > > Only userspace knows what kind of data it's stuffing into > > the pixels (and/or how it configures the csc units/etc.) to > > generate them. > > > > >>> > > >>> Yes, but userspace doesn't control or know whether we drive > > >>> RGB or YCbCr on the wire. In fact, in some cases our driver > > >>> needs to fallback to YCbCr420 for bandwidth reasons. There > > >>> is currently no way for userspace to know that and I don't > > >>> think it makes sense. > > >> > > >> People want that control as well for whatever reason. We've > > >> been asked to allow YCbCr 4:4:4 output many times. > > > > > > I don't really think it's a question of if we want it but rather how > > > we get there. Harry is completely right that if we would make the > > > subsampling controllable by user space instead of the kernel handling > > > it magically, user space which does not adapt to the new control won't > > > be able to light up some modes which worked before. > > > > > > > Thanks for continuing this discussion and touching on the model of how > > we get to where we want to go. > > > > > This is obviously a problem and not one we can easily fix. We would > > > need a new cap for user space to signal "I know that I can control > > > bpc, subsampling and compression to lower the bandwidth and light up > > > modes which otherwise fail". That cap would also remove all the > > > properties which require kernel magic to work (that's also what I > > > proposed for my KMS color pipeline API). > > > > > > We all want to expose more of the scanout capability and give user > > > space more control but I don't think an incremental approach works > > > here and we would all do better if we accept that the current API > > > requires kernel magic to work and has a few implicit assumptions baked > > > in. > > > > > > With all that being said, I think the right decision here is to > > > > > > 1. Ignore subsampling for now > > > 2. Let the kernel select YCC or RGB on the cable > > > 3. Let the kernel figure out the conversion between RGB and YCC based > > > on the color space selected > > > 4. Let the kernel send the correct infoframe based on the selected > > > color space and cable encoding > > > 5. Only expose color spaces for which the kernel can do the conversion > > > and send the infoframe > > > > I agree. We don't want to break or change existing behavior (that is > > used by userspace) and this will get us far without breaking things. > > > > > 6. Work on the new API which is hidden behind a cap > > > > > > > I assume you mean something like > > https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/11 > > Something like that, yes. The main point being a cap which removes a > lot of properties and sets new expecta
Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
On 2/14/23 14:45, Sebastian Wick wrote: On Tue, Feb 14, 2023 at 5:57 PM Harry Wentland wrote: On 2/14/23 10:49, Sebastian Wick wrote: On Fri, Feb 3, 2023 at 5:00 PM Ville Syrjälä wrote: On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote: On 2/3/23 10:19, Ville Syrjälä wrote: On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote: On 2/3/23 07:59, Sebastian Wick wrote: On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä wrote: On Fri, Feb 03, 2023 at 02:07:44AM +, Joshua Ashton wrote: Userspace has no way of controlling or knowing the pixel encoding currently, so there is no way for it to ever get the right values here. That applies to a lot of the other values as well (they are explicitly RGB or YCC). The idea was that this property sets the infoframe/MSA/SDP value exactly, and other properties should be added to for use userspace to control the pixel encoding/colorspace conversion(if desired, or userspace just makes sure to directly feed in correct kind of data). I'm all for getting userspace control over pixel encoding but even then the kernel always knows which pixel encoding is selected and which InfoFrame has to be sent. Is there a reason why userspace would want to control the variant explicitly to the wrong value? I've asked this before but haven't seen an answer: Is there an existing upstream userspace project that makes use of this property (other than what Joshua is working on in gamescope right now)? That would help us understand the intent better. The intent was to control the infoframe colorimetry bits, nothing more. No idea what real userspace there was, if any. I don't think giving userspace explicit control over the exact infoframe values is the right thing to do. Only userspace knows what kind of data it's stuffing into the pixels (and/or how it configures the csc units/etc.) to generate them. Yes, but userspace doesn't control or know whether we drive RGB or YCbCr on the wire. In fact, in some cases our driver needs to fallback to YCbCr420 for bandwidth reasons. There is currently no way for userspace to know that and I don't think it makes sense. People want that control as well for whatever reason. We've been asked to allow YCbCr 4:4:4 output many times. I don't really think it's a question of if we want it but rather how we get there. Harry is completely right that if we would make the subsampling controllable by user space instead of the kernel handling it magically, user space which does not adapt to the new control won't be able to light up some modes which worked before. Thanks for continuing this discussion and touching on the model of how we get to where we want to go. This is obviously a problem and not one we can easily fix. We would need a new cap for user space to signal "I know that I can control bpc, subsampling and compression to lower the bandwidth and light up modes which otherwise fail". That cap would also remove all the properties which require kernel magic to work (that's also what I proposed for my KMS color pipeline API). We all want to expose more of the scanout capability and give user space more control but I don't think an incremental approach works here and we would all do better if we accept that the current API requires kernel magic to work and has a few implicit assumptions baked in. With all that being said, I think the right decision here is to 1. Ignore subsampling for now 2. Let the kernel select YCC or RGB on the cable 3. Let the kernel figure out the conversion between RGB and YCC based on the color space selected 4. Let the kernel send the correct infoframe based on the selected color space and cable encoding 5. Only expose color spaces for which the kernel can do the conversion and send the infoframe I agree. We don't want to break or change existing behavior (that is used by userspace) and this will get us far without breaking things. 6. Work on the new API which is hidden behind a cap I assume you mean something like https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/11 Something like that, yes. The main point being a cap which removes a lot of properties and sets new expectations between user space and kernel. The actual API is not that important. Above you say that you don't think an incremental approach works here. Can you elaborate? Backwards compatibility is really hard. If we add another property to control e.g. the color range infoframe which doesn't magically convert colors, we now have to define how it interacts with the existing property. We also have to figure out how a user space which doesn't know about the new property behaves when another client has set that property. If any property which currently might change the pixel values is used, we can't expose the entire color pipeline because the kernel might have to use some element in it to achieve its magic conversion. So essentially you already have this hard device between "old" and "new" and
Re: [PATCH v2 1/2] drm: Introduce plane SIZE_HINTS property
On Tue, Feb 14, 2023 at 02:27:19PM -0500, Harry Wentland wrote: > > > On 2/14/23 05:28, Ville Syrjälä wrote: > > On Tue, Feb 14, 2023 at 10:54:27AM +0100, Jonas Ådahl wrote: > >> On Tue, Feb 14, 2023 at 11:25:56AM +0200, Ville Syrjälä wrote: > >>> On Thu, Feb 09, 2023 at 03:16:23PM +0100, Jonas Ådahl wrote: > On Wed, Feb 08, 2023 at 11:10:16PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Add a new immutable plane property by which a plane can advertise > > a handful of recommended plane sizes. This would be mostly exposed > > by cursor planes as a slightly more capable replacement for > > the DRM_CAP_CURSOR_WIDTH/HEIGHT caps, which can only declare > > a one size fits all limit for the whole device. > > > > Currently eg. amdgpu/i915/nouveau just advertize the max cursor > > size via the cursor size caps. But always using the max sized > > cursor can waste a surprising amount of power, so a better > > stragey is desirable. > > > > Most other drivers don't specify any cursor size at all, in > > which case the ioctl code just claims that 64x64 is a great > > choice. Whether that is actually true is debatable. > > > > A poll of various compositor developers informs us that > > blindly probing with setcursor/atomic ioctl to determine > > suitable cursor sizes is not acceptable, thus the > > introduction of the new property to supplant the cursor > > size caps. The compositor will now be free to select a > > more optimal cursor size from the short list of options. > > > > Note that the reported sizes (either via the property or the > > caps) make no claims about things such as plane scaling. So > > these things should only really be consulted for simple > > "cursor like" use cases. > > > > v2: Try to add some docs > > > > Cc: Simon Ser > > Cc: Jonas Ådahl > > Cc: Daniel Stone > > Cc: Pekka Paalanen > > Acked-by: Harry Wentland > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/drm_mode_config.c | 7 + > > drivers/gpu/drm/drm_plane.c | 48 +++ > > include/drm/drm_mode_config.h | 5 > > include/drm/drm_plane.h | 4 +++ > > include/uapi/drm/drm_mode.h | 11 +++ > > 5 files changed, 75 insertions(+) > > > > diff --git a/drivers/gpu/drm/drm_mode_config.c > > b/drivers/gpu/drm/drm_mode_config.c > > index 87eb591fe9b5..21860f94a18c 100644 > > --- a/drivers/gpu/drm/drm_mode_config.c > > +++ b/drivers/gpu/drm/drm_mode_config.c > > @@ -374,6 +374,13 @@ static int > > drm_mode_create_standard_properties(struct drm_device *dev) > > return -ENOMEM; > > dev->mode_config.modifiers_property = prop; > > > > + prop = drm_property_create(dev, > > + DRM_MODE_PROP_IMMUTABLE | > > DRM_MODE_PROP_BLOB, > > + "SIZE_HINTS", 0); > > + if (!prop) > > + return -ENOMEM; > > + dev->mode_config.size_hints_property = prop; > > + > > return 0; > > } > > > > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c > > index 24e7998d1731..ae51b1f83755 100644 > > --- a/drivers/gpu/drm/drm_plane.c > > +++ b/drivers/gpu/drm/drm_plane.c > > @@ -140,6 +140,21 @@ > >* DRM_FORMAT_MOD_LINEAR. Before linux kernel release v5.1 there > > have been > >* various bugs in this area with inconsistencies between the > > capability > >* flag and per-plane properties. > > + * > > + * SIZE_HINTS: > > + * Blob property which contains the set of recommended plane size > > + * which can used for simple "cursor like" use cases (eg. no > > scaling). > > + * Using these hints frees userspace from extensive probing of > > + * supported plane sizes through atomic/setcursor ioctls. > > + * > > + * For optimal usage userspace should pick the smallest size > > + * that satisfies its own requirements. > > + * > > + * The blob contains an array of struct drm_plane_size_hint. > > + * > > + * Drivers should only attach this property to planes that > > + * support a very limited set of sizes (eg. cursor planes > > + * on typical hardware). > > This is a bit awkward since problematic drivers would only expose > this property if they are new enough. > > A way to avoid this is for all new drivers expose this property, but > special case the size 0x0 as "everything below the max limit goes". Then > userspace can do (ignoring the missing cap fallback). > >>> > >>> I don't think there are any drivers that need that. > >>> So I'm thinking we can just ignore that
Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
On Tue, Feb 14, 2023 at 5:57 PM Harry Wentland wrote: > > > > On 2/14/23 10:49, Sebastian Wick wrote: > > On Fri, Feb 3, 2023 at 5:00 PM Ville Syrjälä > > wrote: > >> > >> On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote: > >>> > >>> > >>> On 2/3/23 10:19, Ville Syrjälä wrote: > On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote: > > > > > > On 2/3/23 07:59, Sebastian Wick wrote: > >> On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä > >> wrote: > >>> > >>> On Fri, Feb 03, 2023 at 02:07:44AM +, Joshua Ashton wrote: > Userspace has no way of controlling or knowing the pixel encoding > currently, so there is no way for it to ever get the right values > here. > >>> > >>> That applies to a lot of the other values as well (they are > >>> explicitly RGB or YCC). The idea was that this property sets the > >>> infoframe/MSA/SDP value exactly, and other properties should be > >>> added to for use userspace to control the pixel encoding/colorspace > >>> conversion(if desired, or userspace just makes sure to > >>> directly feed in correct kind of data). > >> > >> I'm all for getting userspace control over pixel encoding but even > >> then the kernel always knows which pixel encoding is selected and > >> which InfoFrame has to be sent. Is there a reason why userspace would > >> want to control the variant explicitly to the wrong value? > >> > > > > I've asked this before but haven't seen an answer: Is there an existing > > upstream userspace project that makes use of this property (other than > > what Joshua is working on in gamescope right now)? That would help us > > understand the intent better. > > The intent was to control the infoframe colorimetry bits, > nothing more. No idea what real userspace there was, if any. > > > > > I don't think giving userspace explicit control over the exact infoframe > > values is the right thing to do. > > Only userspace knows what kind of data it's stuffing into > the pixels (and/or how it configures the csc units/etc.) to > generate them. > > >>> > >>> Yes, but userspace doesn't control or know whether we drive > >>> RGB or YCbCr on the wire. In fact, in some cases our driver > >>> needs to fallback to YCbCr420 for bandwidth reasons. There > >>> is currently no way for userspace to know that and I don't > >>> think it makes sense. > >> > >> People want that control as well for whatever reason. We've > >> been asked to allow YCbCr 4:4:4 output many times. > > > > I don't really think it's a question of if we want it but rather how > > we get there. Harry is completely right that if we would make the > > subsampling controllable by user space instead of the kernel handling > > it magically, user space which does not adapt to the new control won't > > be able to light up some modes which worked before. > > > > Thanks for continuing this discussion and touching on the model of how > we get to where we want to go. > > > This is obviously a problem and not one we can easily fix. We would > > need a new cap for user space to signal "I know that I can control > > bpc, subsampling and compression to lower the bandwidth and light up > > modes which otherwise fail". That cap would also remove all the > > properties which require kernel magic to work (that's also what I > > proposed for my KMS color pipeline API). > > > > We all want to expose more of the scanout capability and give user > > space more control but I don't think an incremental approach works > > here and we would all do better if we accept that the current API > > requires kernel magic to work and has a few implicit assumptions baked > > in. > > > > With all that being said, I think the right decision here is to > > > > 1. Ignore subsampling for now > > 2. Let the kernel select YCC or RGB on the cable > > 3. Let the kernel figure out the conversion between RGB and YCC based > > on the color space selected > > 4. Let the kernel send the correct infoframe based on the selected > > color space and cable encoding > > 5. Only expose color spaces for which the kernel can do the conversion > > and send the infoframe > > I agree. We don't want to break or change existing behavior (that is > used by userspace) and this will get us far without breaking things. > > > 6. Work on the new API which is hidden behind a cap > > > > I assume you mean something like > https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/11 Something like that, yes. The main point being a cap which removes a lot of properties and sets new expectations between user space and kernel. The actual API is not that important. > Above you say that you don't think an incremental approach works > here. Can you elaborate? Backwards compatibility is really hard. If we add another property to control e.g. the color range infoframe which doesn't magicall
Re: [PATCH v2 1/2] drm: Introduce plane SIZE_HINTS property
On 2/14/23 05:28, Ville Syrjälä wrote: On Tue, Feb 14, 2023 at 10:54:27AM +0100, Jonas Ådahl wrote: On Tue, Feb 14, 2023 at 11:25:56AM +0200, Ville Syrjälä wrote: On Thu, Feb 09, 2023 at 03:16:23PM +0100, Jonas Ådahl wrote: On Wed, Feb 08, 2023 at 11:10:16PM +0200, Ville Syrjala wrote: From: Ville Syrjälä Add a new immutable plane property by which a plane can advertise a handful of recommended plane sizes. This would be mostly exposed by cursor planes as a slightly more capable replacement for the DRM_CAP_CURSOR_WIDTH/HEIGHT caps, which can only declare a one size fits all limit for the whole device. Currently eg. amdgpu/i915/nouveau just advertize the max cursor size via the cursor size caps. But always using the max sized cursor can waste a surprising amount of power, so a better stragey is desirable. Most other drivers don't specify any cursor size at all, in which case the ioctl code just claims that 64x64 is a great choice. Whether that is actually true is debatable. A poll of various compositor developers informs us that blindly probing with setcursor/atomic ioctl to determine suitable cursor sizes is not acceptable, thus the introduction of the new property to supplant the cursor size caps. The compositor will now be free to select a more optimal cursor size from the short list of options. Note that the reported sizes (either via the property or the caps) make no claims about things such as plane scaling. So these things should only really be consulted for simple "cursor like" use cases. v2: Try to add some docs Cc: Simon Ser Cc: Jonas Ådahl Cc: Daniel Stone Cc: Pekka Paalanen Acked-by: Harry Wentland Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_mode_config.c | 7 + drivers/gpu/drm/drm_plane.c | 48 +++ include/drm/drm_mode_config.h | 5 include/drm/drm_plane.h | 4 +++ include/uapi/drm/drm_mode.h | 11 +++ 5 files changed, 75 insertions(+) diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c index 87eb591fe9b5..21860f94a18c 100644 --- a/drivers/gpu/drm/drm_mode_config.c +++ b/drivers/gpu/drm/drm_mode_config.c @@ -374,6 +374,13 @@ static int drm_mode_create_standard_properties(struct drm_device *dev) return -ENOMEM; dev->mode_config.modifiers_property = prop; + prop = drm_property_create(dev, + DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB, + "SIZE_HINTS", 0); + if (!prop) + return -ENOMEM; + dev->mode_config.size_hints_property = prop; + return 0; } diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c index 24e7998d1731..ae51b1f83755 100644 --- a/drivers/gpu/drm/drm_plane.c +++ b/drivers/gpu/drm/drm_plane.c @@ -140,6 +140,21 @@ * DRM_FORMAT_MOD_LINEAR. Before linux kernel release v5.1 there have been * various bugs in this area with inconsistencies between the capability * flag and per-plane properties. + * + * SIZE_HINTS: + * Blob property which contains the set of recommended plane size + * which can used for simple "cursor like" use cases (eg. no scaling). + * Using these hints frees userspace from extensive probing of + * supported plane sizes through atomic/setcursor ioctls. + * + * For optimal usage userspace should pick the smallest size + * that satisfies its own requirements. + * + * The blob contains an array of struct drm_plane_size_hint. + * + * Drivers should only attach this property to planes that + * support a very limited set of sizes (eg. cursor planes + * on typical hardware). This is a bit awkward since problematic drivers would only expose this property if they are new enough. A way to avoid this is for all new drivers expose this property, but special case the size 0x0 as "everything below the max limit goes". Then userspace can do (ignoring the missing cap fallback). I don't think there are any drivers that need that. So I'm thinking we can just ignore that for now. None the less, userspace not seeing SIZE_HINTS will be required to indefinitely use the existing "old" behavior using the size cap as the buffer size with a fallback, and drivers without any size limitations that, i.e. details that are hard to express with a set of accepted sizes, will still use the inoptimal buffer sizes. If I read [1] correctly, AMD has no particular size limitations other than a size limit, but without a SIZE_HINTS, userspace still needs to use the maximum size. Simon pointed out they have pretty much the same exact limits as i915. Ie. only a few power of two sizes, and stride must match width. That's an artificial limitation in the driver. The HW has no such limitation and it would be nice to drop that from our driver as well. Harry [1] https://gitlab.freedesktop.org/drm/intel/-/issues/7687#note_1760865 Jonas if (has(
Re: [Intel-gfx] [RFC v2 0/5] Waitboost drm syncobj waits
On Tue, Feb 14, 2023 at 11:14 AM Rob Clark wrote: > > On Fri, Feb 10, 2023 at 5:07 AM Tvrtko Ursulin > wrote: > > > > From: Tvrtko Ursulin > > > > In i915 we have this concept of "wait boosting" where we give a priority > > boost > > for instance to fences which are actively waited upon from userspace. This > > has > > it's pros and cons and can certainly be discussed at lenght. However fact is > > some workloads really like it. > > > > Problem is that with the arrival of drm syncobj and a new userspace waiting > > entry point it added, the waitboost mechanism was bypassed. Hence I cooked > > up > > this mini series really (really) quickly to see if some discussion can be > > had. > > > > It adds a concept of "wait count" to dma fence, which is incremented for > > every > > explicit dma_fence_enable_sw_signaling and dma_fence_add_wait_callback (like > > dma_fence_add_callback but from explicit/userspace wait paths). > > I was thinking about a similar thing, but in the context of dma_fence > (or rather sync_file) fd poll()ing. How does the kernel differentiate > between "housekeeping" poll()ers that don't want to trigger boost but > simply know when to do cleanup, and waiters who are waiting with some > urgency. I think we could use EPOLLPRI for this purpose. > > Not sure how that translates to waits via the syncobj. But I think we > want to let userspace give some hint about urgent vs housekeeping > waits. So probably the syncobj equiv of this would be to add something along the lines of DRM_SYNCOBJ_WAIT_FLAGS_WAIT_PRI BR, -R > Also, on a related topic: https://lwn.net/Articles/868468/ > > BR, > -R > > > Individual drivers can then inspect this via dma_fence_wait_count() and > > decide > > to wait boost the waits on such fences. > > > > Again, quickly put together and smoke tested only - no guarantees > > whatsoever and > > I will rely on interested parties to test and report if it even works or how > > well. > > > > v2: > > * Small fixups based on CI feedback: > > * Handle decrement correctly for already signalled case while adding > > callback. > > * Remove i915 assert which was making sure struct i915_request does not > > grow. > > * Split out the i915 patch into three separate functional changes. > > > > Tvrtko Ursulin (5): > > dma-fence: Track explicit waiters > > drm/syncobj: Mark syncobj waits as external waiters > > drm/i915: Waitboost external waits > > drm/i915: Mark waits as explicit > > drm/i915: Wait boost requests waited upon by others > > > > drivers/dma-buf/dma-fence.c | 102 -- > > drivers/gpu/drm/drm_syncobj.c | 6 +- > > drivers/gpu/drm/i915/gt/intel_engine_pm.c | 1 - > > drivers/gpu/drm/i915/i915_request.c | 13 ++- > > include/linux/dma-fence.h | 14 +++ > > 5 files changed, 101 insertions(+), 35 deletions(-) > > > > -- > > 2.34.1 > >
Re: [Intel-gfx] [RFC v2 0/5] Waitboost drm syncobj waits
On Fri, Feb 10, 2023 at 5:07 AM Tvrtko Ursulin wrote: > > From: Tvrtko Ursulin > > In i915 we have this concept of "wait boosting" where we give a priority boost > for instance to fences which are actively waited upon from userspace. This has > it's pros and cons and can certainly be discussed at lenght. However fact is > some workloads really like it. > > Problem is that with the arrival of drm syncobj and a new userspace waiting > entry point it added, the waitboost mechanism was bypassed. Hence I cooked up > this mini series really (really) quickly to see if some discussion can be had. > > It adds a concept of "wait count" to dma fence, which is incremented for every > explicit dma_fence_enable_sw_signaling and dma_fence_add_wait_callback (like > dma_fence_add_callback but from explicit/userspace wait paths). I was thinking about a similar thing, but in the context of dma_fence (or rather sync_file) fd poll()ing. How does the kernel differentiate between "housekeeping" poll()ers that don't want to trigger boost but simply know when to do cleanup, and waiters who are waiting with some urgency. I think we could use EPOLLPRI for this purpose. Not sure how that translates to waits via the syncobj. But I think we want to let userspace give some hint about urgent vs housekeeping waits. Also, on a related topic: https://lwn.net/Articles/868468/ BR, -R > Individual drivers can then inspect this via dma_fence_wait_count() and decide > to wait boost the waits on such fences. > > Again, quickly put together and smoke tested only - no guarantees whatsoever > and > I will rely on interested parties to test and report if it even works or how > well. > > v2: > * Small fixups based on CI feedback: > * Handle decrement correctly for already signalled case while adding > callback. > * Remove i915 assert which was making sure struct i915_request does not > grow. > * Split out the i915 patch into three separate functional changes. > > Tvrtko Ursulin (5): > dma-fence: Track explicit waiters > drm/syncobj: Mark syncobj waits as external waiters > drm/i915: Waitboost external waits > drm/i915: Mark waits as explicit > drm/i915: Wait boost requests waited upon by others > > drivers/dma-buf/dma-fence.c | 102 -- > drivers/gpu/drm/drm_syncobj.c | 6 +- > drivers/gpu/drm/i915/gt/intel_engine_pm.c | 1 - > drivers/gpu/drm/i915/i915_request.c | 13 ++- > include/linux/dma-fence.h | 14 +++ > 5 files changed, 101 insertions(+), 35 deletions(-) > > -- > 2.34.1 >
Re: [PATCH v4 5/8] drm/i915/pxp: Add ARB session creation and cleanup
On Thu, 2023-02-09 at 16:42 -0800, Teres Alexis, Alan Previn wrote:
> Add MTL's function for ARB session creation using PXP firmware
> version 4.3 ABI structure format.
>
> Also add MTL's function for ARB session invalidation but this
> reuses PXP firmware version 4.2 ABI structure format.
>
> Before checking the return status, look at the GSC-CS-Mem-Header's
> pending-bit which means the GSC firmware is busy and we should
> resubmit.
>
> Signed-off-by: Alan Previn
> ---
>
alan:snip..
> +void intel_pxp_gsccs_end_arb_fw_session(struct intel_pxp *pxp, u32
> session_id)
> +{
> + struct drm_i915_private *i915 = pxp->ctrl_gt->i915;
> + struct pxp42_inv_stream_key_in msg_in = {0};
> + struct pxp42_inv_stream_key_out msg_out = {0};
> + int ret = 0, tries = 0;
> + u64 gsc_session_retry = 0;
> +
> + memset(&msg_in, 0, sizeof(msg_in));
> + memset(&msg_out, 0, sizeof(msg_out));
> + msg_in.header.api_version = PXP_APIVER(4, 2);
> +
Firmware API version is backward compatibility and enforces the correct
API calls for the platform+firmware. Thus, although the structs are v4.2,
the api_version needs to carry PXP_APIVER(4, 3)
alan:snip..
[PATCH v2 00/14] GMU-less A6xx support (A610, A619_holi)
v1 -> v2: - Fix A630 values in [2/14] - Fix [6/14] for GMU-equipped GPUs Link to v1: https://lore.kernel.org/linux-arm-msm/20230126151618.225127-1-konrad.dyb...@linaro.org/ This series concludes my couple-weeks-long suffering of figuring out the ins and outs of the "non-standard" A6xx GPUs which feature no GMU. The GMU functionality is essentially emulated by parting out a "GMU wrapper" region, which is essentially just a register space within the GPU. It's modeled to be as similar to the actual GMU as possible while staying as unnecessary as we can make it - there's no IRQs, communicating with a microcontroller, no RPMh communication etc. etc. I tried to reuse as much code as possible without making a mess where every even line is used for GMU and every odd line is used for GMU wrapper.. This series contains: - plumbing for non-GMU operation, if-ing out GMU calls based on GMU presence - GMU wrapper support - A610 support (w/ speedbin) - A619 support (w/ speedbin) - couple of minor fixes and improvements - VDDCX/VDDGX scaling fix for non-GMU GPUs (concerns more than just A6xx) - Enablement of opp interconnect properties A619_holi works perfectly fine using the already-present A619 support in mesa. A610 needs more work on that front, but can already replay command traces captures on downstream. NOTE: the "drm/msm/a6xx: Add support for A619_holi" patch contains two occurences of 0x18 used in place of a register #define, as it's supposed to be RBBM_GPR0_CNTL, but that will only be present after mesa-side changes are merged and headers are synced from there. Speedbin patches depend on: https://lore.kernel.org/linux-arm-msm/20230120172233.1905761-1-konrad.dyb...@linaro.org/ Konrad Dybcio (14): drm/msm/a6xx: De-staticize sptprac en/disable functions drm/msm/a6xx: Extend UBWC config drm/msm/a6xx: Introduce GMU wrapper support drm/msm/a6xx: Remove both GBIF and RBBM GBIF halt on hw init drm/msm/adreno: Disable has_cached_coherent for A610/A619_holi drm/msm/gpu: Use dev_pm_opp_set_rate for non-GMU GPUs drm/msm/a6xx: Add support for A619_holi drm/msm/a6xx: Add A610 support drm/msm/a6xx: Fix some A619 tunables drm/msm/a6xx: Fix up A6XX protected registers drm/msm/a6xx: Enable optional icc voting from OPP tables drm/msm/a6xx: Use "else if" in GPU speedbin rev matching drm/msm/a6xx: Add A619_holi speedbin support drm/msm/a6xx: Add A610 speedbin support drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 55 ++- drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 2 + drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 427 +--- drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 1 + drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 14 +- drivers/gpu/drm/msm/adreno/adreno_device.c | 34 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 4 + drivers/gpu/drm/msm/adreno/adreno_gpu.h | 19 +- drivers/gpu/drm/msm/msm_gpu_devfreq.c | 2 +- 9 files changed, 492 insertions(+), 66 deletions(-) -- 2.39.1
Re: [RFC PATCH 5/7] drm/msm/dpu: Document and enable TEAR interrupts on DSI interfaces
On 2/14/2023 5:06 AM, Marijn Suijten wrote: On 2023-02-13 19:09:32, Abhinav Kumar wrote: On 2/13/2023 1:46 PM, Dmitry Baryshkov wrote: On 13/02/2023 21:37, Jessica Zhang wrote: On 12/31/2022 1:50 PM, Marijn Suijten wrote: All SoCs since DPU 5.0.0 (and seemingly up until and including 6.0.0, but excluding 7.x.x) have the tear interrupt and control registers moved out of the PINGPONG block and into the INTF block. Wire up the necessary interrupts and IRQ masks on all supported hardware. Hi Marijn, Thanks for the patch. I saw that in your commit msg, you mentioned that 7.x doesn't have tearcheck in the INTF block -- can you double check that this is correct? It wasn't correct and has already been removed for v2 [1] after rebasing on top of SM8[345]50 support, where the registers reside at a different (named 7 downstream) offset. [1] https://github.com/SoMainline/linux/commit/886d3fb9eed925e7e9c8d6ca63d2439eaec1c702 I'm working on SM8350 (DPU v7) and I'm seeing that it does have tearcheck in INTF block. I confirm, according to the vendor drivers INTF TE should be used for all DPU >= 5.0, including 7.x and 8.x However I think I know what Marijn meant here. For 5.x and 6.x these IRQs are handled at the address MDSS + 0x6e800 / + 0x6e900 (which means offset here should 0x6d800 and 0x6d900) for INTF_1 and INTF_2. Since DPU 7.x these IRQ registers were moved close to the main INTF block (0x36800 and 0x37800 = INTF + 0x800). That might have been the case. Got it, then the commit text should remove "control" and just say tear interrupt registers. It got a bit confusing. The wording here points to both the interrupt (MDP_INTFx_TEAR_INTR) registers and control (INTF_TEAR_xxx) registers separately. Feel free to bikeshed the wording in preliminary v2 [1]; should I drop the mention of the control registers being "moved" from PP to INTF entirely, leaving just the wording about the interrupt registers moving from MDP_SSPP_TOP0_INTR to a dedicated MDP_INTFx_TEAR_INTR region? Yes, that makes more sense to me. Drop the mention on control registers. We will add the 7xxx intf tear check support on top of this series. No need, that is already taken care of in an impending v2 [1] (unless additional changes are required beyond the moved register offset). Ok, we will wait till you post v2 and see if that works for us without any of our local changes. Signed-off-by: Marijn Suijten --- .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 78 +++ .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 6 +- .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 12 +++ .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 2 + drivers/gpu/drm/msm/disp/dpu1/dpu_hwio.h | 3 + 5 files changed, 68 insertions(+), 33 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c index 1cfe94494135..b9b9b5b0b615 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c @@ -86,6 +86,15 @@ #define INTF_SC7280_MASK INTF_SC7180_MASK | BIT(DPU_DATA_HCTL_EN) +#define IRQ_MSM8998_MASK (BIT(MDP_SSPP_TOP0_INTR) | \ + BIT(MDP_SSPP_TOP0_INTR2) | \ + BIT(MDP_SSPP_TOP0_HIST_INTR) | \ + BIT(MDP_INTF0_INTR) | \ + BIT(MDP_INTF1_INTR) | \ + BIT(MDP_INTF2_INTR) | \ + BIT(MDP_INTF3_INTR) | \ + BIT(MDP_INTF4_INTR)) + #define IRQ_SDM845_MASK (BIT(MDP_SSPP_TOP0_INTR) | \ BIT(MDP_SSPP_TOP0_INTR2) | \ BIT(MDP_SSPP_TOP0_HIST_INTR) | \ @@ -100,13 +109,15 @@ #define IRQ_QCM2290_MASK (BIT(MDP_SSPP_TOP0_INTR) | \ BIT(MDP_SSPP_TOP0_INTR2) | \ BIT(MDP_SSPP_TOP0_HIST_INTR) | \ - BIT(MDP_INTF1_INTR)) + BIT(MDP_INTF1_INTR) | \ + BIT(MDP_INTF1_TEAR_INTR)) #define IRQ_SC7180_MASK (BIT(MDP_SSPP_TOP0_INTR) | \ BIT(MDP_SSPP_TOP0_INTR2) | \ BIT(MDP_SSPP_TOP0_HIST_INTR) | \ BIT(MDP_INTF0_INTR) | \ - BIT(MDP_INTF1_INTR)) + BIT(MDP_INTF1_INTR) | \ + BIT(MDP_INTF1_TEAR_INTR)) #define IRQ_SC7280_MASK (BIT(MDP_SSPP_TOP0_INTR) | \ BIT(MDP_SSPP_TOP0_INTR2) | \ @@ -120,7 +131,9 @@ BIT(MDP_SSPP_TOP0_HIST_INTR) | \ BIT(MDP_INTF0_INTR) | \ BIT(MDP_INTF1_INTR) | \ + BIT(MDP_INTF1_TEAR_INTR) | \ BIT(MDP_INTF2_INTR) | \ + BIT(MDP_INTF2_TEAR_INTR) | \ BIT(MDP_INTF3_INTR) | \ BIT(MDP_INTF4_INTR)) @@ -129,7 +142,9 @@ BIT(MDP_SSPP_TOP0_HIST_INTR) | \ BIT(MDP_INTF0_INTR) | \ BIT(MDP_INTF1_INTR) | \ + BIT(MDP_INTF1_TEAR_INTR) | \ BIT(MDP_INTF2_INTR) | \ + BIT(MDP_INTF2_TEAR_INTR) | \ BIT(MDP_INTF3_INTR) | \
Re: [PATCH 09/10] drm/amd/display: Make variables declaration inside ifdef guard
Applied. Thanks! On Mon, Feb 13, 2023 at 3:50 PM Arthur Grillo wrote: > > Make variables declaration inside ifdef guard, as they are only used > inside the same ifdef guard. This remove some of the > -Wunused-but-set-variable warning. > > Signed-off-by: Arthur Grillo > --- > .../gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c| 4 > .../gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c | 4 > 2 files changed, 8 insertions(+) > > diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c > b/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c > index ec351c8418cb..27f488405335 100644 > --- a/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c > +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c > @@ -878,7 +878,9 @@ static bool CalculatePrefetchSchedule( > double DSTTotalPixelsAfterScaler; > double LineTime; > double dst_y_prefetch_equ; > +#ifdef __DML_VBA_DEBUG__ > double Tsw_oto; > +#endif > double prefetch_bw_oto; > double prefetch_bw_pr; > double Tvm_oto; > @@ -1060,7 +1062,9 @@ static bool CalculatePrefetchSchedule( > > min_Lsw = dml_max(1, dml_max(PrefetchSourceLinesY, > PrefetchSourceLinesC) / max_vratio_pre); > Lsw_oto = dml_ceil(4 * dml_max(prefetch_sw_bytes / prefetch_bw_oto / > LineTime, min_Lsw), 1) / 4; > +#ifdef __DML_VBA_DEBUG__ > Tsw_oto = Lsw_oto * LineTime; > +#endif > > > #ifdef __DML_VBA_DEBUG__ > diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c > b/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c > index 950669f2c10d..0fd3889c2061 100644 > --- a/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c > +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c > @@ -900,7 +900,9 @@ static bool CalculatePrefetchSchedule( > double DSTTotalPixelsAfterScaler; > double LineTime; > double dst_y_prefetch_equ; > +#ifdef __DML_VBA_DEBUG__ > double Tsw_oto; > +#endif > double prefetch_bw_oto; > double prefetch_bw_pr; > double Tvm_oto; > @@ -1082,7 +1084,9 @@ static bool CalculatePrefetchSchedule( > > min_Lsw = dml_max(1, dml_max(PrefetchSourceLinesY, > PrefetchSourceLinesC) / max_vratio_pre); > Lsw_oto = dml_ceil(4 * dml_max(prefetch_sw_bytes / prefetch_bw_oto / > LineTime, min_Lsw), 1) / 4; > +#ifdef __DML_VBA_DEBUG__ > Tsw_oto = Lsw_oto * LineTime; > +#endif > > > #ifdef __DML_VBA_DEBUG__ > -- > 2.39.1 >
Re: [PATCH 05/10] drm/amd/display: Fix excess arguments on kernel-doc
Applied. Thanks! On Mon, Feb 13, 2023 at 3:50 PM Arthur Grillo wrote: > > Remove arguments present on kernel-doc that are not present on the > function declaration and add the new ones if present. > > Signed-off-by: Arthur Grillo > --- > drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c| 15 +++ > drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c | 2 +- > .../gpu/drm/amd/display/dc/dcn10/dcn10_dpp_dscl.c | 2 +- > 3 files changed, 9 insertions(+), 10 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c > b/drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c > index 3d36329be384..40e6b22daa22 100644 > --- a/drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c > +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c > @@ -273,8 +273,6 @@ static void sdma_v6_0_ring_emit_ib(struct amdgpu_ring > *ring, > * sdma_v6_0_ring_emit_mem_sync - flush the IB by graphics cache rinse > * > * @ring: amdgpu ring pointer > - * @job: job to retrieve vmid from > - * @ib: IB object to schedule > * > * flush the IB by graphics cache rinse. > */ > @@ -326,7 +324,9 @@ static void sdma_v6_0_ring_emit_hdp_flush(struct > amdgpu_ring *ring) > * sdma_v6_0_ring_emit_fence - emit a fence on the DMA ring > * > * @ring: amdgpu ring pointer > - * @fence: amdgpu fence object > + * @addr: address > + * @seq: fence seq number > + * @flags: fence flags > * > * Add a DMA fence packet to the ring to write > * the fence seq number and DMA trap packet to generate > @@ -1060,10 +1060,9 @@ static void sdma_v6_0_vm_copy_pte(struct amdgpu_ib *ib, > * > * @ib: indirect buffer to fill with commands > * @pe: addr of the page entry > - * @addr: dst addr to write into pe > + * @value: dst addr to write into pe > * @count: number of page entries to update > * @incr: increase next addr by incr bytes > - * @flags: access flags > * > * Update PTEs by writing them manually using sDMA. > */ > @@ -1167,7 +1166,6 @@ static void sdma_v6_0_ring_emit_pipeline_sync(struct > amdgpu_ring *ring) > * sdma_v6_0_ring_emit_vm_flush - vm flush using sDMA > * > * @ring: amdgpu_ring pointer > - * @vm: amdgpu_vm pointer > * > * Update the page table base and flush the VM TLB > * using sDMA. > @@ -1591,10 +1589,11 @@ static void sdma_v6_0_set_irq_funcs(struct > amdgpu_device *adev) > /** > * sdma_v6_0_emit_copy_buffer - copy buffer using the sDMA engine > * > - * @ring: amdgpu_ring structure holding ring information > + * @ib: indirect buffer to fill with commands > * @src_offset: src GPU address > * @dst_offset: dst GPU address > * @byte_count: number of bytes to xfer > + * @tmz: if a secure copy should be used > * > * Copy GPU buffers using the DMA engine. > * Used by the amdgpu ttm implementation to move pages if > @@ -1620,7 +1619,7 @@ static void sdma_v6_0_emit_copy_buffer(struct amdgpu_ib > *ib, > /** > * sdma_v6_0_emit_fill_buffer - fill buffer using the sDMA engine > * > - * @ring: amdgpu_ring structure holding ring information > + * @ib: indirect buffer to fill > * @src_data: value to write to buffer > * @dst_offset: dst GPU address > * @byte_count: number of bytes to xfer > diff --git a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c > b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c > index 6ccf477d1c4d..c2092775ca88 100644 > --- a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c > +++ b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c > @@ -698,7 +698,7 @@ static void populate_subvp_cmd_pipe_info(struct dc *dc, > * > * @dc: [in] current dc state > * @context: [in] new dc state > - * @cmd: [in] DMUB cmd to be populated with SubVP info > + * @enable: [in] if true enables the pipes population > * > * This function loops through each pipe and populates the DMUB SubVP CMD > info > * based on the pipe (e.g. SubVP, VBLANK). > diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp_dscl.c > b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp_dscl.c > index f607a0e28f14..f62368da875d 100644 > --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp_dscl.c > +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp_dscl.c > @@ -581,7 +581,7 @@ static void dpp1_dscl_set_manual_ratio_init( > * dpp1_dscl_set_recout - Set the first pixel of RECOUT in the OTG active > area > * > * @dpp: DPP data struct > - * @recount: Rectangle information > + * @recout: Rectangle information > * > * This function sets the MPC RECOUT_START and RECOUT_SIZE registers based on > * the values specified in the recount parameter. > -- > 2.39.1 >
Re: [PATCH 04/10] drm/amd/display: Add previously missing includes
Applied. Thanks!
On Mon, Feb 13, 2023 at 3:50 PM Arthur Grillo wrote:
>
> Add includes that were previously missing to reduce the number of
> -Wmissing-prototypes warnings.
>
> Signed-off-by: Arthur Grillo
> ---
> drivers/gpu/drm/amd/display/dc/dcn32/dcn32_init.c | 1 +
> drivers/gpu/drm/amd/display/dc/link/accessories/link_dp_trace.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_init.c
> b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_init.c
> index 330d7cbc7398..3069af3684c6 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_init.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_init.c
> @@ -30,6 +30,7 @@
> #include "dcn30/dcn30_hwseq.h"
> #include "dcn31/dcn31_hwseq.h"
> #include "dcn32_hwseq.h"
> +#include "dcn32_init.h"
>
> static const struct hw_sequencer_funcs dcn32_funcs = {
> .program_gamut_remap = dcn10_program_gamut_remap,
> diff --git a/drivers/gpu/drm/amd/display/dc/link/accessories/link_dp_trace.c
> b/drivers/gpu/drm/amd/display/dc/link/accessories/link_dp_trace.c
> index 04838a31e513..257f4fc065a5 100644
> --- a/drivers/gpu/drm/amd/display/dc/link/accessories/link_dp_trace.c
> +++ b/drivers/gpu/drm/amd/display/dc/link/accessories/link_dp_trace.c
> @@ -24,6 +24,7 @@
> */
> #include "dc_link.h"
> #include "link_dp_trace.h"
> +#include "link.h"
>
> void dp_trace_init(struct dc_link *link)
> {
> --
> 2.39.1
>
Re: [PATCH 03/10] drm/amd/amdgpu: Add function prototypes to headers
Applied. Thanks!
On Mon, Feb 13, 2023 at 3:50 PM Arthur Grillo wrote:
>
> Add function prototypes to headers to reduce the number of
> -Wmissing-prototypes warnings.
>
> Signed-off-by: Arthur Grillo
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h
> index bee93ab4298f..b03321e7d2d8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h
> @@ -538,6 +538,7 @@ struct amdgpu_firmware {
>
> void amdgpu_ucode_print_mc_hdr(const struct common_firmware_header *hdr);
> void amdgpu_ucode_print_smc_hdr(const struct common_firmware_header *hdr);
> +void amdgpu_ucode_print_imu_hdr(const struct common_firmware_header *hdr);
> void amdgpu_ucode_print_gfx_hdr(const struct common_firmware_header *hdr);
> void amdgpu_ucode_print_rlc_hdr(const struct common_firmware_header *hdr);
> void amdgpu_ucode_print_sdma_hdr(const struct common_firmware_header *hdr);
> --
> 2.39.1
>
Re: [PATCH 02/10] drm/amd/display: Add function prototypes to headers
Applied. Thanks! On Mon, Feb 13, 2023 at 3:50 PM Arthur Grillo wrote: > > Add function prototypes to headers to reduce the number of > -Wmissing-prototypes warnings. > > Signed-off-by: Arthur Grillo > --- > drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hubbub.h | 2 ++ > drivers/gpu/drm/amd/display/dc/dcn32/dcn32_hubbub.h | 2 ++ > drivers/gpu/drm/amd/display/dc/dcn32/dcn32_hubp.h | 2 ++ > 3 files changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hubbub.h > b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hubbub.h > index e015e5a6c866..89d6208287b5 100644 > --- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hubbub.h > +++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hubbub.h > @@ -133,6 +133,8 @@ > int hubbub31_init_dchub_sys_ctx(struct hubbub *hubbub, > struct dcn_hubbub_phys_addr_config *pa_config); > > +void hubbub31_init(struct hubbub *hubbub); > + > void hubbub31_construct(struct dcn20_hubbub *hubbub3, > struct dc_context *ctx, > const struct dcn_hubbub_registers *hubbub_regs, > diff --git a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_hubbub.h > b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_hubbub.h > index bdc146890fca..b20eb04724bb 100644 > --- a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_hubbub.h > +++ b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_hubbub.h > @@ -204,6 +204,8 @@ void hubbub32_force_usr_retraining_allow(struct hubbub > *hubbub, bool allow); > > void hubbub32_force_wm_propagate_to_pipes(struct hubbub *hubbub); > > +void hubbub32_init(struct hubbub *hubbub); > + > void dcn32_program_det_size(struct hubbub *hubbub, int hubp_inst, unsigned > int det_buffer_size_in_kbyte); > > void hubbub32_construct(struct dcn20_hubbub *hubbub2, > diff --git a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_hubp.h > b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_hubp.h > index 56ef71151536..4cdbf63c952b 100644 > --- a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_hubp.h > +++ b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_hubp.h > @@ -61,6 +61,8 @@ void hubp32_phantom_hubp_post_enable(struct hubp *hubp); > void hubp32_cursor_set_attributes(struct hubp *hubp, > const struct dc_cursor_attributes *attr); > > +void hubp32_init(struct hubp *hubp); > + > bool hubp32_construct( > struct dcn20_hubp *hubp2, > struct dc_context *ctx, > -- > 2.39.1 >
Re: [PATCH 01/10] drm/amd/display: Turn global functions into static
On Mon, Feb 13, 2023 at 3:49 PM Arthur Grillo wrote:
>
> Turn global functions that are only used locally into static ones. This
> reduces the number of -Wmissing-prototypes warnings.
>
> Signed-off-by: Arthur Grillo
The first hunk was already fixed, but I applied the second hunk.
Alex
> ---
> drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c | 2 +-
> drivers/gpu/drm/amd/display/dc/irq/dcn201/irq_service_dcn201.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
> b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
> index 8c368bcc8e7e..a737782b2840 100644
> --- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
> +++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
> @@ -87,7 +87,7 @@ static int dcn315_get_active_display_cnt_wa(
> return display_count;
> }
>
> -bool should_disable_otg(struct pipe_ctx *pipe)
> +static bool should_disable_otg(struct pipe_ctx *pipe)
> {
> bool ret = true;
>
> diff --git a/drivers/gpu/drm/amd/display/dc/irq/dcn201/irq_service_dcn201.c
> b/drivers/gpu/drm/amd/display/dc/irq/dcn201/irq_service_dcn201.c
> index 27dc8c9955f4..3c7cb3dc046b 100644
> --- a/drivers/gpu/drm/amd/display/dc/irq/dcn201/irq_service_dcn201.c
> +++ b/drivers/gpu/drm/amd/display/dc/irq/dcn201/irq_service_dcn201.c
> @@ -37,7 +37,7 @@
> #include "soc15_hw_ip.h"
> #include "ivsrcid/dcn/irqsrcs_dcn_1_0.h"
>
> -enum dc_irq_source to_dal_irq_source_dcn201(
> +static enum dc_irq_source to_dal_irq_source_dcn201(
> struct irq_service *irq_service,
> uint32_t src_id,
> uint32_t ext_id)
> --
> 2.39.1
>
Re: [PATCH 4/4] drm/msm/a5xx: fix context faults during ring switch
On Mon, Feb 13, 2023 at 6:10 PM Dmitry Baryshkov
wrote:
>
> The rptr_addr is set in the preempt_init_ring(), which is called from
> a5xx_gpu_init(). It uses shadowptr() to set the address, however the
> shadow_iova is not yet initialized at that time. Move the rptr_addr
> setting to the a5xx_preempt_hw_init() which is called after setting the
> shadow_iova, getting the correct value for the address.
>
> Fixes: 8907afb476ac ("drm/msm: Allow a5xx to mark the RPTR shadow as
> privileged")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7555
> Suggested-by: Rob Clark
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
> b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
> index 7e0affd60993..f58dd564d122 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
> @@ -207,6 +207,7 @@ void a5xx_preempt_hw_init(struct msm_gpu *gpu)
> a5xx_gpu->preempt[i]->wptr = 0;
> a5xx_gpu->preempt[i]->rptr = 0;
> a5xx_gpu->preempt[i]->rbase = gpu->rb[i]->iova;
> + a5xx_gpu->preempt[i]->rptr_addr = shadowptr(a5xx_gpu,
> gpu->rb[i]);
> }
>
> /* Write a 0 to signal that we aren't switching pagetables */
> @@ -257,7 +258,6 @@ static int preempt_init_ring(struct a5xx_gpu *a5xx_gpu,
> ptr->data = 0;
> ptr->cntl = MSM_GPU_RB_CNTL_DEFAULT | AXXX_CP_RB_CNTL_NO_UPDATE;
>
> - ptr->rptr_addr = shadowptr(a5xx_gpu, ring);
> ptr->counter = counters_iova;
>
> return 0;
> --
> 2.30.2
>
[PATCH v2 14/14] drm/msm/a6xx: Add A610 speedbin support
A610 is implemented on at least three SoCs: SM6115 (bengal), SM6125
(trinket) and SM6225 (khaje). Trinket does not support speed binning
(only a single SKU exists) and we don't yet support khaje upstream.
Hence, add a fuse mapping table for bengal to allow for per-chip
frequency limiting.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 94b4d93619ed..f2679f9cc137 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -2082,6 +2082,30 @@ static bool a6xx_progress(struct msm_gpu *gpu, struct
msm_ringbuffer *ring)
return progress;
}
+static u32 a610_get_speed_bin(u32 fuse)
+{
+ /*
+* There are (at least) three SoCs implementing A610: SM6125 (trinket),
+* SM6115 (bengal) and SM6225 (khaje). Trinket does not have
speedbinning,
+* as only a single SKU exists and we don't support khaje upstream yet.
+* Hence, this matching table is only valid for bengal and can be easily
+* expanded if need be.
+*/
+
+ if (fuse == 0)
+ return 0;
+ else if (fuse == 206)
+ return 1;
+ else if (fuse == 200)
+ return 2;
+ else if (fuse == 157)
+ return 3;
+ else if (fuse == 127)
+ return 4;
+
+ return UINT_MAX;
+}
+
static u32 a618_get_speed_bin(u32 fuse)
{
if (fuse == 0)
@@ -2178,6 +2202,9 @@ static u32 fuse_to_supp_hw(struct device *dev, struct
adreno_rev rev, u32 fuse)
{
u32 val = UINT_MAX;
+ if (adreno_cmp_rev(ADRENO_REV(6, 1, 0, ANY_ID), rev))
+ val = a610_get_speed_bin(fuse);
+
if (adreno_cmp_rev(ADRENO_REV(6, 1, 8, ANY_ID), rev))
val = a618_get_speed_bin(fuse);
--
2.39.1
[PATCH v2 13/14] drm/msm/a6xx: Add A619_holi speedbin support
A619_holi is implemented on at least two SoCs: SM4350 (holi) and SM6375
(blair). This is what seems to be a first occurrence of this happening,
but it's easy to overcome by guarding the SoC-specific fuse values with
of_machine_is_compatible(). Do just that to enable frequency limiting
on these SoCs.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index ffe0fd431a76..94b4d93619ed 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -2094,6 +2094,34 @@ static u32 a618_get_speed_bin(u32 fuse)
return UINT_MAX;
}
+static u32 a619_holi_get_speed_bin(u32 fuse)
+{
+ /*
+* There are (at least) two SoCs implementing A619_holi: SM4350 (holi)
+* and SM6375 (blair). Limit the fuse matching to the corresponding
+* SoC to prevent bogus frequency setting (as improbable as it may be,
+* given unexpected fuse values are.. unexpected! But still possible.)
+*/
+
+ if (fuse == 0)
+ return 0;
+
+ if (of_machine_is_compatible("qcom,sm4350")) {
+ if (fuse == 138)
+ return 1;
+ else if (fuse == 92)
+ return 2;
+ } else if (of_machine_is_compatible("qcom,sm6375")) {
+ if (fuse == 190)
+ return 1;
+ else if (fuse == 177)
+ return 2;
+ } else
+ pr_warn("Unknown SoC implementing A619_holi!\n");
+
+ return UINT_MAX;
+}
+
static u32 a619_get_speed_bin(u32 fuse)
{
if (fuse == 0)
@@ -2153,6 +2181,9 @@ static u32 fuse_to_supp_hw(struct device *dev, struct
adreno_rev rev, u32 fuse)
if (adreno_cmp_rev(ADRENO_REV(6, 1, 8, ANY_ID), rev))
val = a618_get_speed_bin(fuse);
+ else if (adreno_cmp_rev(ADRENO_REV(6, 1, 9, 1), rev))
+ val = a619_holi_get_speed_bin(fuse);
+
else if (adreno_cmp_rev(ADRENO_REV(6, 1, 9, ANY_ID), rev))
val = a619_get_speed_bin(fuse);
--
2.39.1
[PATCH v2 12/14] drm/msm/a6xx: Use "else if" in GPU speedbin rev matching
The GPU can only be one at a time. Turn a series of ifs into if +
elseifs to save some CPU cycles.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index b08ed127f8c4..ffe0fd431a76 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -2153,16 +2153,16 @@ static u32 fuse_to_supp_hw(struct device *dev, struct
adreno_rev rev, u32 fuse)
if (adreno_cmp_rev(ADRENO_REV(6, 1, 8, ANY_ID), rev))
val = a618_get_speed_bin(fuse);
- if (adreno_cmp_rev(ADRENO_REV(6, 1, 9, ANY_ID), rev))
+ else if (adreno_cmp_rev(ADRENO_REV(6, 1, 9, ANY_ID), rev))
val = a619_get_speed_bin(fuse);
- if (adreno_cmp_rev(ADRENO_REV(6, 3, 5, ANY_ID), rev))
+ else if (adreno_cmp_rev(ADRENO_REV(6, 3, 5, ANY_ID), rev))
val = adreno_7c3_get_speed_bin(fuse);
- if (adreno_cmp_rev(ADRENO_REV(6, 4, 0, ANY_ID), rev))
+ else if (adreno_cmp_rev(ADRENO_REV(6, 4, 0, ANY_ID), rev))
val = a640_get_speed_bin(fuse);
- if (adreno_cmp_rev(ADRENO_REV(6, 5, 0, ANY_ID), rev))
+ else if (adreno_cmp_rev(ADRENO_REV(6, 5, 0, ANY_ID), rev))
val = a650_get_speed_bin(fuse);
if (val == UINT_MAX) {
--
2.39.1
[PATCH v2 11/14] drm/msm/a6xx: Enable optional icc voting from OPP tables
On GMU-equipped GPUs, the GMU requests appropriate bandwidth votes for us. This is however not the case for the other GPUs. Add the dev_pm_opp_of_find_icc_paths() call to let the OPP framework handle bus voting as part of power level setting. Signed-off-by: Konrad Dybcio --- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c index d6b38bfdb3b4..b08ed127f8c4 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c @@ -2338,5 +2338,9 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev) msm_mmu_set_fault_handler(gpu->aspace->mmu, gpu, a6xx_fault_handler); + ret = dev_pm_opp_of_find_icc_paths(&pdev->dev, NULL); + if (ret) + return ERR_PTR(ret); + return gpu; } -- 2.39.1
[PATCH v2 10/14] drm/msm/a6xx: Fix up A6XX protected registers
One of the protected ranges was too small (compared to the data we
have downstream). Fix it.
Fixes: 408434036958 ("drm/msm/a6xx: update/fix CP_PROTECT initialization")
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 503c750216e6..d6b38bfdb3b4 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -690,7 +690,7 @@ static const u32 a6xx_protect[] = {
A6XX_PROTECT_NORDWR(0x00800, 0x0082),
A6XX_PROTECT_NORDWR(0x008a0, 0x0008),
A6XX_PROTECT_NORDWR(0x008ab, 0x0024),
- A6XX_PROTECT_RDONLY(0x008de, 0x00ae),
+ A6XX_PROTECT_RDONLY(0x008d0, 0x00bc),
A6XX_PROTECT_NORDWR(0x00900, 0x004d),
A6XX_PROTECT_NORDWR(0x0098d, 0x0272),
A6XX_PROTECT_NORDWR(0x00e00, 0x0001),
--
2.39.1
[PATCH v2 09/14] drm/msm/a6xx: Fix some A619 tunables
Adreno 619 expects some tunables to be set differently. Make up for it.
Fixes: b7616b5c69e6 ("drm/msm/adreno: Add A619 support")
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 1e259e9901ca..503c750216e6 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1174,6 +1174,8 @@ static int hw_init(struct msm_gpu *gpu)
gpu_write(gpu, REG_A6XX_PC_DBG_ECO_CNTL, 0x00200200);
else if (adreno_is_a650(adreno_gpu) || adreno_is_a660(adreno_gpu))
gpu_write(gpu, REG_A6XX_PC_DBG_ECO_CNTL, 0x00300200);
+ else if (adreno_is_a619(adreno_gpu))
+ gpu_write(gpu, REG_A6XX_PC_DBG_ECO_CNTL, 0x00018000);
else if (adreno_is_a610(adreno_gpu))
gpu_write(gpu, REG_A6XX_PC_DBG_ECO_CNTL, 0x0008);
else
@@ -1191,7 +1193,9 @@ static int hw_init(struct msm_gpu *gpu)
a6xx_set_ubwc_config(gpu);
/* Enable fault detection */
- if (adreno_is_a610(adreno_gpu))
+ if (adreno_is_a619(adreno_gpu))
+ gpu_write(gpu, REG_A6XX_RBBM_INTERFACE_HANG_INT_CNTL, (1 << 30)
| 0x3f);
+ else if (adreno_is_a610(adreno_gpu))
gpu_write(gpu, REG_A6XX_RBBM_INTERFACE_HANG_INT_CNTL, (1 << 30)
| 0x3);
else
gpu_write(gpu, REG_A6XX_RBBM_INTERFACE_HANG_INT_CNTL, (1 << 30)
| 0x1f);
--
2.39.1
[PATCH v2 08/14] drm/msm/a6xx: Add A610 support
A610 is one of (if not the) lowest-tier SKUs in the A6XX family. It
features no GMU, as it's implemented solely on SoCs with SMD_RPM.
What's more interesting is that it does not feature a VDDGX line
either, being powered solely by VDDCX and has an unfortunate hardware
quirk that makes its reset line broken - after a couple of assert/
deassert cycles, it will hang for good and will not wake up again.
This GPU requires mesa changes for proper rendering, and lots of them
at that. The command streams are quite far away from any other A6XX
GPU and hence it needs special care. This patch was validated both
by running an (incomplete) downstream mesa with some hacks (frames
rendered correctly, though some instructions made the GPU hangcheck
which is expected - garbage in, garbage out) and by replaying RD
traces captured with the downstream KGSL driver - no crashes there,
ever.
Add support for this GPU on the kernel side, which comes down to
pretty simply adding A612 HWCG tables, altering a few values and
adding a special case for handling the reset line.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 95 --
drivers/gpu/drm/msm/adreno/adreno_device.c | 13 +++
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 8 +-
3 files changed, 106 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index c168712a0dc4..1e259e9901ca 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -254,6 +254,56 @@ static void a6xx_submit(struct msm_gpu *gpu, struct
msm_gem_submit *submit)
a6xx_flush(gpu, ring);
}
+const struct adreno_reglist a612_hwcg[] = {
+ {REG_A6XX_RBBM_CLOCK_CNTL_SP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL2_SP0, 0x0220},
+ {REG_A6XX_RBBM_CLOCK_DELAY_SP0, 0x0081},
+ {REG_A6XX_RBBM_CLOCK_HYST_SP0, 0xf3cf},
+ {REG_A6XX_RBBM_CLOCK_CNTL_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL2_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL3_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL4_TP0, 0x0002},
+ {REG_A6XX_RBBM_CLOCK_DELAY_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY2_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY3_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY4_TP0, 0x0001},
+ {REG_A6XX_RBBM_CLOCK_HYST_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST2_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST3_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST4_TP0, 0x0007},
+ {REG_A6XX_RBBM_CLOCK_CNTL_RB0, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL2_RB0, 0x0120},
+ {REG_A6XX_RBBM_CLOCK_CNTL_CCU0, 0x2220},
+ {REG_A6XX_RBBM_CLOCK_HYST_RB_CCU0, 0x00040f00},
+ {REG_A6XX_RBBM_CLOCK_CNTL_RAC, 0x05522022},
+ {REG_A6XX_RBBM_CLOCK_CNTL2_RAC, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY_RAC, 0x0011},
+ {REG_A6XX_RBBM_CLOCK_HYST_RAC, 0x00445044},
+ {REG_A6XX_RBBM_CLOCK_CNTL_TSE_RAS_RBBM, 0x0422},
+ {REG_A6XX_RBBM_CLOCK_MODE_VFD, 0x},
+ {REG_A6XX_RBBM_CLOCK_MODE_GPC, 0x0222},
+ {REG_A6XX_RBBM_CLOCK_DELAY_HLSQ_2, 0x0002},
+ {REG_A6XX_RBBM_CLOCK_MODE_HLSQ, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY_TSE_RAS_RBBM, 0x4000},
+ {REG_A6XX_RBBM_CLOCK_DELAY_VFD, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY_GPC, 0x0200},
+ {REG_A6XX_RBBM_CLOCK_DELAY_HLSQ, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST_TSE_RAS_RBBM, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST_VFD, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST_GPC, 0x04104004},
+ {REG_A6XX_RBBM_CLOCK_HYST_HLSQ, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL_UCHE, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST_UCHE, 0x0004},
+ {REG_A6XX_RBBM_CLOCK_DELAY_UCHE, 0x0002},
+ {REG_A6XX_RBBM_ISDB_CNT, 0x0182},
+ {REG_A6XX_RBBM_RAC_THRESHOLD_CNT, 0x},
+ {REG_A6XX_RBBM_SP_HYST_CNT, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL_GMU_GX, 0x0222},
+ {REG_A6XX_RBBM_CLOCK_DELAY_GMU_GX, 0x0111},
+ {REG_A6XX_RBBM_CLOCK_HYST_GMU_GX, 0x0555},
+ {},
+};
+
/* For a615 family (a615, a616, a618 and a619) */
const struct adreno_reglist a615_hwcg[] = {
{REG_A6XX_RBBM_CLOCK_CNTL_SP0, 0x0222},
@@ -604,6 +654,8 @@ static void a6xx_set_hwcg(struct msm_gpu *gpu, bool state)
if (adreno_is_a630(adreno_gpu))
clock_cntl_on = 0x8aa8aa02;
+ else if (adreno_is_a610(adreno_gpu))
+ clock_cntl_on = 0xaaa8aa82;
else
clock_cntl_on = 0x8aa8aa82;
@@ -798,6 +850,11 @@ static void a6xx_set_ubwc_config(struct msm_gpu *gpu)
u32 min_acc_len = 0;
u32 ubwc_mode = 0;
+ if (adreno_is_a610(adreno_gpu)) {
+ min_acc_len = 1;
+ ubwc_mode = 1;
+ }
+
/* a618 is using the hw default values */
if (adreno_is_a618(
[PATCH v2 07/14] drm/msm/a6xx: Add support for A619_holi
A619_holi is a GMU-less variant of the already-supported A619 GPU.
It's present on at least SM4350 (holi) and SM6375 (blair). No mesa
changes are required. Add the required kernel-side support for it.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 37 +-
drivers/gpu/drm/msm/adreno/adreno_device.c | 13
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 5 +++
3 files changed, 47 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 75cf94b03c29..c168712a0dc4 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -614,14 +614,14 @@ static void a6xx_set_hwcg(struct msm_gpu *gpu, bool state)
return;
/* Disable SP clock before programming HWCG registers */
- if (!adreno_has_gmu_wrapper(adreno_gpu))
+ if ((!adreno_has_gmu_wrapper(adreno_gpu) ||
adreno_is_a619_holi(adreno_gpu)))
gmu_rmw(gmu, REG_A6XX_GPU_GMU_GX_SPTPRAC_CLOCK_CONTROL, 1, 0);
for (i = 0; (reg = &adreno_gpu->info->hwcg[i], reg->offset); i++)
gpu_write(gpu, reg->offset, state ? reg->value : 0);
/* Enable SP clock */
- if (!adreno_has_gmu_wrapper(adreno_gpu))
+ if ((!adreno_has_gmu_wrapper(adreno_gpu) ||
adreno_is_a619_holi(adreno_gpu)))
gmu_rmw(gmu, REG_A6XX_GPU_GMU_GX_SPTPRAC_CLOCK_CONTROL, 0, 1);
gpu_write(gpu, REG_A6XX_RBBM_CLOCK_CNTL, state ? clock_cntl_on : 0);
@@ -1007,7 +1007,12 @@ static int hw_init(struct msm_gpu *gpu)
}
/* Clear GBIF halt in case GX domain was not collapsed */
- if (a6xx_has_gbif(adreno_gpu)) {
+ if (adreno_is_a619_holi(adreno_gpu)) {
+ gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
+ gpu_write(gpu, 0x18, 0);
+ /* Let's make extra sure that the GPU can access the memory.. */
+ mb();
+ } else if (a6xx_has_gbif(adreno_gpu)) {
gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
gpu_write(gpu, REG_A6XX_RBBM_GBIF_HALT, 0);
/* Let's make extra sure that the GPU can access the memory.. */
@@ -1016,6 +1021,9 @@ static int hw_init(struct msm_gpu *gpu)
gpu_write(gpu, REG_A6XX_RBBM_SECVID_TSB_CNTL, 0);
+ if (adreno_is_a619_holi(adreno_gpu))
+ a6xx_sptprac_enable(gmu);
+
/*
* Disable the trusted memory range - we don't actually supported secure
* memory rendering at this point in time and we don't want to block off
@@ -1293,7 +1301,8 @@ static void a6xx_dump(struct msm_gpu *gpu)
#define GBIF_CLIENT_HALT_MASK BIT(0)
#define GBIF_ARB_HALT_MASK BIT(1)
#define VBIF_RESET_ACK_TIMEOUT 100
-#define VBIF_RESET_ACK_MASK0x00f0
+#define VBIF_RESET_ACK_MASK0xF0
+#define GPR0_GBIF_HALT_REQUEST 0x1E0
static void a6xx_recover(struct msm_gpu *gpu)
{
@@ -1350,10 +1359,16 @@ static void a6xx_recover(struct msm_gpu *gpu)
/* Software-reset the GPU */
if (adreno_has_gmu_wrapper(adreno_gpu)) {
- /* Halt the GX side of GBIF */
- gpu_write(gpu, REG_A6XX_RBBM_GBIF_HALT, GBIF_GX_HALT_MASK);
- spin_until(gpu_read(gpu, REG_A6XX_RBBM_GBIF_HALT_ACK) &
- GBIF_GX_HALT_MASK);
+ if (adreno_is_a619_holi(adreno_gpu)) {
+ gpu_write(gpu, 0x18, GPR0_GBIF_HALT_REQUEST);
+ spin_until((gpu_read(gpu,
REG_A6XX_RBBM_VBIF_GX_RESET_STATUS) &
+ (VBIF_RESET_ACK_MASK)) ==
VBIF_RESET_ACK_MASK);
+ } else {
+ /* Halt the GX side of GBIF */
+ gpu_write(gpu, REG_A6XX_RBBM_GBIF_HALT,
GBIF_GX_HALT_MASK);
+ spin_until(gpu_read(gpu, REG_A6XX_RBBM_GBIF_HALT_ACK) &
+ GBIF_GX_HALT_MASK);
+ }
/* Halt new client requests on GBIF */
gpu_write(gpu, REG_A6XX_GBIF_HALT, GBIF_CLIENT_HALT_MASK);
@@ -1763,6 +1778,9 @@ static int a6xx_pm_resume(struct msm_gpu *gpu)
if (ret)
return ret;
+ if (adreno_is_a619_holi(adreno_gpu))
+ a6xx_sptprac_enable(gmu);
+
mutex_unlock(&a6xx_gpu->gmu.lock);
msm_devfreq_resume(gpu);
@@ -1795,6 +1813,9 @@ static int a6xx_pm_suspend(struct msm_gpu *gpu)
mutex_lock(&a6xx_gpu->gmu.lock);
+ if (adreno_is_a619_holi(adreno_gpu))
+ a6xx_sptprac_disable(gmu);
+
ret = clk_prepare_enable(gpu->ebi1_clk);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 82757f005a1a..71faeb3fd466 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adr
[PATCH v2 06/14] drm/msm/gpu: Use dev_pm_opp_set_rate for non-GMU GPUs
Currently we only utilize the OPP table connected to the GPU for
getting (available) frequencies. We do however need to scale the
voltage rail(s) accordingly to ensure that we aren't trying to
run the GPU at 1GHz with a VDD_LOW vote, as that would result in
an otherwise inexplainable hang.
Tell the OPP framework that we want to scale the "core" clock
and swap out the clk_set_rate to a dev_pm_opp_set_rate in
msm_devfreq_target() to enable usage of required-opps and by
extension proper voltage level/corner scaling.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 4
drivers/gpu/drm/msm/msm_gpu_devfreq.c | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index ce6b76c45b6f..15e405e4f977 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -1047,6 +1047,10 @@ int adreno_gpu_init(struct drm_device *drm, struct
platform_device *pdev,
const char *gpu_name;
u32 speedbin;
+ /* This can only be done here, or devm_pm_opp_set_supported_hw will
WARN_ON() */
+ if (!IS_ERR(devm_clk_get(dev, "core")))
+ devm_pm_opp_set_clkname(dev, "core");
+
adreno_gpu->funcs = funcs;
adreno_gpu->info = adreno_info(config->rev);
adreno_gpu->gmem = adreno_gpu->info->gmem;
diff --git a/drivers/gpu/drm/msm/msm_gpu_devfreq.c
b/drivers/gpu/drm/msm/msm_gpu_devfreq.c
index e27dbf12b5e8..ea70c1c32d94 100644
--- a/drivers/gpu/drm/msm/msm_gpu_devfreq.c
+++ b/drivers/gpu/drm/msm/msm_gpu_devfreq.c
@@ -48,7 +48,7 @@ static int msm_devfreq_target(struct device *dev, unsigned
long *freq,
gpu->funcs->gpu_set_freq(gpu, opp, df->suspended);
mutex_unlock(&df->lock);
} else {
- clk_set_rate(gpu->core_clk, *freq);
+ dev_pm_opp_set_rate(dev, *freq);
}
dev_pm_opp_put(opp);
--
2.39.1
[PATCH v2 05/14] drm/msm/adreno: Disable has_cached_coherent for A610/A619_holi
These SKUs don't support the feature. Disable it to make the GPU stop
crashing after almost each and every submission - the received data on
the GPU end was simply incomplete in garbled, resulting in almost nothing
being executed properly.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 36f062c7582f..82757f005a1a 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -540,7 +540,13 @@ static int adreno_bind(struct device *dev, struct device
*master, void *data)
config.rev.minor, config.rev.patchid);
priv->is_a2xx = config.rev.core == 2;
- priv->has_cached_coherent = config.rev.core >= 6;
+
+ if (config.rev.core >= 6) {
+ /* Exclude A610 and A619_holi */
+ if (!(adreno_cmp_rev(ADRENO_REV(6, 1, 0, ANY_ID), config.rev) ||
+ adreno_cmp_rev(ADRENO_REV(6, 1, 9, 1), config.rev)))
+ priv->has_cached_coherent = true;
+ }
gpu = info->init(drm);
if (IS_ERR(gpu)) {
--
2.39.1
[PATCH v2 01/14] drm/msm/a6xx: De-staticize sptprac en/disable functions
These two will be reused by at least A619_holi in the non-gmu
paths. De-staticize them to make it possible.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 4 ++--
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index f3c9600221d4..90e636dcdd5b 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -354,7 +354,7 @@ void a6xx_gmu_clear_oob(struct a6xx_gmu *gmu, enum
a6xx_gmu_oob_state state)
}
/* Enable CPU control of SPTP power power collapse */
-static int a6xx_sptprac_enable(struct a6xx_gmu *gmu)
+int a6xx_sptprac_enable(struct a6xx_gmu *gmu)
{
int ret;
u32 val;
@@ -376,7 +376,7 @@ static int a6xx_sptprac_enable(struct a6xx_gmu *gmu)
}
/* Disable CPU control of SPTP power power collapse */
-static void a6xx_sptprac_disable(struct a6xx_gmu *gmu)
+void a6xx_sptprac_disable(struct a6xx_gmu *gmu)
{
u32 val;
int ret;
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index e034935b3986..ec28abdd327b 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
@@ -186,5 +186,7 @@ int a6xx_hfi_set_freq(struct a6xx_gmu *gmu, int index);
bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu);
bool a6xx_gmu_sptprac_is_on(struct a6xx_gmu *gmu);
+void a6xx_sptprac_disable(struct a6xx_gmu *gmu);
+int a6xx_sptprac_enable(struct a6xx_gmu *gmu);
#endif
--
2.39.1
[PATCH v2 03/14] drm/msm/a6xx: Introduce GMU wrapper support
Some (particularly SMD_RPM, a.k.a non-RPMh) SoCs implement A6XX GPUs
but don't implement the associated GMUs. This is due to the fact that
the GMU directly pokes at RPMh. Sadly, this means we have to take care
of enabling & scaling power rails, clocks and bandwidth ourselves.
Reuse existing Adreno-common code and modify the deeply-GMU-infused
A6XX code to facilitate these GPUs. This involves if-ing out lots
of GMU callbacks and introducing a new type of GMU - GMU wrapper.
This is essentially a register region which is convenient to model
as a device. We'll use it for managing the GDSCs.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 51 -
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 198 +---
drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 1 +
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 14 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 6 +
5 files changed, 233 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 90e636dcdd5b..5aa9f3ef41c2 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -1474,6 +1474,7 @@ static int a6xx_gmu_get_irq(struct a6xx_gmu *gmu, struct
platform_device *pdev,
void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
{
+ struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
struct a6xx_gmu *gmu = &a6xx_gpu->gmu;
struct platform_device *pdev = to_platform_device(gmu->dev);
@@ -1493,10 +1494,12 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
gmu->mmio = NULL;
gmu->rscc = NULL;
- a6xx_gmu_memory_free(gmu);
+ if (!adreno_has_gmu_wrapper(adreno_gpu)) {
+ a6xx_gmu_memory_free(gmu);
- free_irq(gmu->gmu_irq, gmu);
- free_irq(gmu->hfi_irq, gmu);
+ free_irq(gmu->gmu_irq, gmu);
+ free_irq(gmu->hfi_irq, gmu);
+ }
/* Drop reference taken in of_find_device_by_node */
put_device(gmu->dev);
@@ -1504,6 +1507,48 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
gmu->initialized = false;
}
+int a6xx_gmu_wrapper_init(struct a6xx_gpu *a6xx_gpu, struct device_node *node)
+{
+ struct platform_device *pdev = of_find_device_by_node(node);
+ struct a6xx_gmu *gmu = &a6xx_gpu->gmu;
+ int ret;
+
+ if (!pdev)
+ return -ENODEV;
+
+ gmu->dev = &pdev->dev;
+
+ of_dma_configure(gmu->dev, node, true);
+
+ pm_runtime_enable(gmu->dev);
+
+ /* Mark legacy for manual SPTPRAC control */
+ gmu->legacy = true;
+
+ /* Map the GMU registers */
+ gmu->mmio = a6xx_gmu_get_mmio(pdev, "gmu");
+ if (IS_ERR(gmu->mmio)) {
+ ret = PTR_ERR(gmu->mmio);
+ goto err_mmio;
+ }
+
+ /* Get a link to the GX power domain to reset the GPU */
+ gmu->gxpd = dev_pm_domain_attach_by_name(gmu->dev, "gx");
+
+ gmu->initialized = true;
+
+ return 0;
+
+err_mmio:
+ iounmap(gmu->mmio);
+ ret = -ENODEV;
+
+ /* Drop reference taken in of_find_device_by_node */
+ put_device(gmu->dev);
+
+ return ret;
+}
+
int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct device_node *node)
{
struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 8855d798bbb3..72bf5c9f7ff1 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -20,9 +20,11 @@ static inline bool _a6xx_check_idle(struct msm_gpu *gpu)
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
- /* Check that the GMU is idle */
- if (!a6xx_gmu_isidle(&a6xx_gpu->gmu))
- return false;
+ if (!adreno_has_gmu_wrapper(adreno_gpu)) {
+ /* Check that the GMU is idle */
+ if (!a6xx_gmu_isidle(&a6xx_gpu->gmu))
+ return false;
+ }
/* Check tha the CX master is idle */
if (gpu_read(gpu, REG_A6XX_RBBM_STATUS) &
@@ -612,13 +614,15 @@ static void a6xx_set_hwcg(struct msm_gpu *gpu, bool state)
return;
/* Disable SP clock before programming HWCG registers */
- gmu_rmw(gmu, REG_A6XX_GPU_GMU_GX_SPTPRAC_CLOCK_CONTROL, 1, 0);
+ if (!adreno_has_gmu_wrapper(adreno_gpu))
+ gmu_rmw(gmu, REG_A6XX_GPU_GMU_GX_SPTPRAC_CLOCK_CONTROL, 1, 0);
for (i = 0; (reg = &adreno_gpu->info->hwcg[i], reg->offset); i++)
gpu_write(gpu, reg->offset, state ? reg->value : 0);
/* Enable SP clock */
- gmu_rmw(gmu, REG_A6XX_GPU_GMU_GX_SPTPRAC_CLOCK_CONTROL, 0, 1);
+ if (!adreno_has_gmu_wrapper(adreno_gpu))
+ gmu_rmw(gmu, REG_A6XX_GPU_GMU_GX_SPTPRAC_CLOCK_CONTROL, 0, 1);
gpu_write(gpu, REG_A6XX_RBBM_CLOCK_CNTL, state ? clock_cntl_on
[PATCH v2 04/14] drm/msm/a6xx: Remove both GBIF and RBBM GBIF halt on hw init
Currently we're only deasserting REG_A6XX_RBBM_GBIF_HALT, but we also
need REG_A6XX_GBIF_HALT to be set to 0. For GMU-equipped GPUs this is
done in a6xx_bus_clear_pending_transactions(), but for the GMU-less
ones we have to do it *somewhere*. Unhalting both side by side sounds
like a good plan and it won't cause any issues if it's unnecessary.
Also, add a memory barrier to ensure it's gone through.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 72bf5c9f7ff1..75cf94b03c29 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1007,8 +1007,12 @@ static int hw_init(struct msm_gpu *gpu)
}
/* Clear GBIF halt in case GX domain was not collapsed */
- if (a6xx_has_gbif(adreno_gpu))
+ if (a6xx_has_gbif(adreno_gpu)) {
+ gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
gpu_write(gpu, REG_A6XX_RBBM_GBIF_HALT, 0);
+ /* Let's make extra sure that the GPU can access the memory.. */
+ mb();
+ }
gpu_write(gpu, REG_A6XX_RBBM_SECVID_TSB_CNTL, 0);
--
2.39.1
[PATCH v2 02/14] drm/msm/a6xx: Extend UBWC config
Port setting min_access_length, ubwc_mode and upper_bit from downstream.
Values were validated using downstream device trees for SM8[123]50 and
left default (as per downstream) elsewhere.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 29 +++
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index c5f5d0bb3fdc..8855d798bbb3 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -786,17 +786,25 @@ static void a6xx_set_cp_protect(struct msm_gpu *gpu)
static void a6xx_set_ubwc_config(struct msm_gpu *gpu)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
- u32 lower_bit = 2;
+ u32 lower_bit = 1;
+ u32 upper_bit = 0;
u32 amsbc = 0;
u32 rgb565_predicator = 0;
u32 uavflagprd_inv = 0;
+ u32 min_acc_len = 0;
+ u32 ubwc_mode = 0;
/* a618 is using the hw default values */
if (adreno_is_a618(adreno_gpu))
return;
- if (adreno_is_a640_family(adreno_gpu))
+ if (adreno_is_a630(adreno_gpu))
+ lower_bit = 2;
+
+ if (adreno_is_a640_family(adreno_gpu)) {
amsbc = 1;
+ lower_bit = 2;
+ }
if (adreno_is_a650(adreno_gpu) || adreno_is_a660(adreno_gpu)) {
/* TODO: get ddr type from bootloader and use 2 for LPDDR4 */
@@ -807,18 +815,23 @@ static void a6xx_set_ubwc_config(struct msm_gpu *gpu)
}
if (adreno_is_7c3(adreno_gpu)) {
- lower_bit = 1;
amsbc = 1;
rgb565_predicator = 1;
uavflagprd_inv = 2;
}
gpu_write(gpu, REG_A6XX_RB_NC_MODE_CNTL,
- rgb565_predicator << 11 | amsbc << 4 | lower_bit << 1);
- gpu_write(gpu, REG_A6XX_TPL1_NC_MODE_CNTL, lower_bit << 1);
- gpu_write(gpu, REG_A6XX_SP_NC_MODE_CNTL,
- uavflagprd_inv << 4 | lower_bit << 1);
- gpu_write(gpu, REG_A6XX_UCHE_MODE_CNTL, lower_bit << 21);
+ rgb565_predicator << 11 | upper_bit << 10 | amsbc << 4 |
+ min_acc_len << 3 | lower_bit << 1 | ubwc_mode);
+
+ gpu_write(gpu, REG_A6XX_TPL1_NC_MODE_CNTL, upper_bit << 4 |
+ min_acc_len << 3 | lower_bit << 1 | ubwc_mode);
+
+ gpu_write(gpu, REG_A6XX_SP_NC_MODE_CNTL, upper_bit << 10 |
+ uavflagprd_inv << 4 | min_acc_len << 3 |
+ lower_bit << 1 | ubwc_mode);
+
+ gpu_write(gpu, REG_A6XX_UCHE_MODE_CNTL, min_acc_len << 23 | lower_bit
<< 21);
}
static int a6xx_cp_init(struct msm_gpu *gpu)
--
2.39.1
Re: [PATCH v2] drm: panel-orientation-quirks: Add quirk for Lenovo IdeaPad Duet 3 10IGL5
Hi,
On 2/14/23 17:46, Darrell Kavanagh wrote:
> Another Lenovo convertable where the panel is installed landscape but is
> reported to the kernel as portrait.
>
> Signed-off-by: Darrell Kavanagh
Thanks, patch looks good to me:
Reviewed-by: Hans de Goede
Note for other developers the reason this is v2 is to
fix various code-style / submission process issues with v1,
there are no functional changes.
Regards,
Hans
>
> ---
> drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> index b409fe256fd0..5522d610c5cf 100644
> --- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> +++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> @@ -322,6 +322,12 @@ static const struct dmi_system_id orientation_data[] = {
> DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad
> D330-10IGL"),
> },
> .driver_data = (void *)&lcd800x1280_rightside_up,
> + }, {/* Lenovo IdeaPad Duet 3 10IGL5 */
> + .matches = {
> + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> + DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "IdeaPad Duet 3 10IGL5"),
> + },
> + .driver_data = (void *)&lcd1200x1920_rightside_up,
> }, {/* Lenovo Yoga Book X90F / X91F / X91L */
> .matches = {
> /* Non exact match to match all versions */
Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
On 2/14/23 10:49, Sebastian Wick wrote: > On Fri, Feb 3, 2023 at 5:00 PM Ville Syrjälä > wrote: >> >> On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote: >>> >>> >>> On 2/3/23 10:19, Ville Syrjälä wrote: On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote: > > > On 2/3/23 07:59, Sebastian Wick wrote: >> On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä >> wrote: >>> >>> On Fri, Feb 03, 2023 at 02:07:44AM +, Joshua Ashton wrote: Userspace has no way of controlling or knowing the pixel encoding currently, so there is no way for it to ever get the right values here. >>> >>> That applies to a lot of the other values as well (they are >>> explicitly RGB or YCC). The idea was that this property sets the >>> infoframe/MSA/SDP value exactly, and other properties should be >>> added to for use userspace to control the pixel encoding/colorspace >>> conversion(if desired, or userspace just makes sure to >>> directly feed in correct kind of data). >> >> I'm all for getting userspace control over pixel encoding but even >> then the kernel always knows which pixel encoding is selected and >> which InfoFrame has to be sent. Is there a reason why userspace would >> want to control the variant explicitly to the wrong value? >> > > I've asked this before but haven't seen an answer: Is there an existing > upstream userspace project that makes use of this property (other than > what Joshua is working on in gamescope right now)? That would help us > understand the intent better. The intent was to control the infoframe colorimetry bits, nothing more. No idea what real userspace there was, if any. > > I don't think giving userspace explicit control over the exact infoframe > values is the right thing to do. Only userspace knows what kind of data it's stuffing into the pixels (and/or how it configures the csc units/etc.) to generate them. >>> >>> Yes, but userspace doesn't control or know whether we drive >>> RGB or YCbCr on the wire. In fact, in some cases our driver >>> needs to fallback to YCbCr420 for bandwidth reasons. There >>> is currently no way for userspace to know that and I don't >>> think it makes sense. >> >> People want that control as well for whatever reason. We've >> been asked to allow YCbCr 4:4:4 output many times. > > I don't really think it's a question of if we want it but rather how > we get there. Harry is completely right that if we would make the > subsampling controllable by user space instead of the kernel handling > it magically, user space which does not adapt to the new control won't > be able to light up some modes which worked before. > Thanks for continuing this discussion and touching on the model of how we get to where we want to go. > This is obviously a problem and not one we can easily fix. We would > need a new cap for user space to signal "I know that I can control > bpc, subsampling and compression to lower the bandwidth and light up > modes which otherwise fail". That cap would also remove all the > properties which require kernel magic to work (that's also what I > proposed for my KMS color pipeline API). > > We all want to expose more of the scanout capability and give user > space more control but I don't think an incremental approach works > here and we would all do better if we accept that the current API > requires kernel magic to work and has a few implicit assumptions baked > in. > > With all that being said, I think the right decision here is to > > 1. Ignore subsampling for now > 2. Let the kernel select YCC or RGB on the cable > 3. Let the kernel figure out the conversion between RGB and YCC based > on the color space selected > 4. Let the kernel send the correct infoframe based on the selected > color space and cable encoding > 5. Only expose color spaces for which the kernel can do the conversion > and send the infoframe I agree. We don't want to break or change existing behavior (that is used by userspace) and this will get us far without breaking things. > 6. Work on the new API which is hidden behind a cap > I assume you mean something like https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/11 Above you say that you don't think an incremental approach works here. Can you elaborate? >From what I've seen recently I am inclined to favor an incremental approach more. The reason is that any API, or portion thereof, is useless unless it's enabled full stack. When it isn't it becomes dead code quickly, or never really works because we overlooked one thing. The colorspace debacle shows how even something as simple as extra enum values in KMS APIs shouldn't be added unless someone in a canonical upstream project actually uses them. I would argue that such a canonical upstream project actually has to be a production environment and not something like Weston.
[PATCH v2] drm: panel-orientation-quirks: Add quirk for Lenovo IdeaPad Duet 3 10IGL5
Another Lenovo convertable where the panel is installed landscape but is
reported to the kernel as portrait.
Signed-off-by: Darrell Kavanagh
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index b409fe256fd0..5522d610c5cf 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -322,6 +322,12 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad
D330-10IGL"),
},
.driver_data = (void *)&lcd800x1280_rightside_up,
+ }, {/* Lenovo IdeaPad Duet 3 10IGL5 */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "IdeaPad Duet 3 10IGL5"),
+ },
+ .driver_data = (void *)&lcd1200x1920_rightside_up,
}, {/* Lenovo Yoga Book X90F / X91F / X91L */
.matches = {
/* Non exact match to match all versions */
--
2.39.1
Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
On Fri, Feb 3, 2023 at 5:00 PM Ville Syrjälä wrote: > > On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote: > > > > > > On 2/3/23 10:19, Ville Syrjälä wrote: > > > On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote: > > >> > > >> > > >> On 2/3/23 07:59, Sebastian Wick wrote: > > >>> On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä > > >>> wrote: > > > > On Fri, Feb 03, 2023 at 02:07:44AM +, Joshua Ashton wrote: > > > Userspace has no way of controlling or knowing the pixel encoding > > > currently, so there is no way for it to ever get the right values > > > here. > > > > That applies to a lot of the other values as well (they are > > explicitly RGB or YCC). The idea was that this property sets the > > infoframe/MSA/SDP value exactly, and other properties should be > > added to for use userspace to control the pixel encoding/colorspace > > conversion(if desired, or userspace just makes sure to > > directly feed in correct kind of data). > > >>> > > >>> I'm all for getting userspace control over pixel encoding but even > > >>> then the kernel always knows which pixel encoding is selected and > > >>> which InfoFrame has to be sent. Is there a reason why userspace would > > >>> want to control the variant explicitly to the wrong value? > > >>> > > >> > > >> I've asked this before but haven't seen an answer: Is there an existing > > >> upstream userspace project that makes use of this property (other than > > >> what Joshua is working on in gamescope right now)? That would help us > > >> understand the intent better. > > > > > > The intent was to control the infoframe colorimetry bits, > > > nothing more. No idea what real userspace there was, if any. > > > > > >> > > >> I don't think giving userspace explicit control over the exact infoframe > > >> values is the right thing to do. > > > > > > Only userspace knows what kind of data it's stuffing into > > > the pixels (and/or how it configures the csc units/etc.) to > > > generate them. > > > > > > > Yes, but userspace doesn't control or know whether we drive > > RGB or YCbCr on the wire. In fact, in some cases our driver > > needs to fallback to YCbCr420 for bandwidth reasons. There > > is currently no way for userspace to know that and I don't > > think it makes sense. > > People want that control as well for whatever reason. We've > been asked to allow YCbCr 4:4:4 output many times. I don't really think it's a question of if we want it but rather how we get there. Harry is completely right that if we would make the subsampling controllable by user space instead of the kernel handling it magically, user space which does not adapt to the new control won't be able to light up some modes which worked before. This is obviously a problem and not one we can easily fix. We would need a new cap for user space to signal "I know that I can control bpc, subsampling and compression to lower the bandwidth and light up modes which otherwise fail". That cap would also remove all the properties which require kernel magic to work (that's also what I proposed for my KMS color pipeline API). We all want to expose more of the scanout capability and give user space more control but I don't think an incremental approach works here and we would all do better if we accept that the current API requires kernel magic to work and has a few implicit assumptions baked in. With all that being said, I think the right decision here is to 1. Ignore subsampling for now 2. Let the kernel select YCC or RGB on the cable 3. Let the kernel figure out the conversion between RGB and YCC based on the color space selected 4. Let the kernel send the correct infoframe based on the selected color space and cable encoding 5. Only expose color spaces for which the kernel can do the conversion and send the infoframe 6. Work on the new API which is hidden behind a cap > The automagic 4:2:0 fallback I think is rather fundementally > incompatible with fancy color management. How would we even > know whether to use eg. BT.2020 vs. BT.709 matrix? In i915 > that stuff is just always BT.709 limited range, no questions > asked. > > So I think if userspace wants real color management it's > going to have to set up the whole pipeline. And for that > we need at least one new property to control the RGB->YCbCr > conversion (or to explicitly avoid it). > > And given that the proposed patch just swept all the > non-BT.2020 issues under the rug makes me think no > one has actually come up with any kind of consistent > plan for anything else really. > > > > > Userspace needs full control of framebuffer pixel formats, > > as well as control over DEGAMMA, GAMMA, CTM color operations. > > It also needs to be able to select whether to drive the panel > > as sRGB or BT.2020/PQ but it doesn't make sense for it to > > control the pixel encoding on the wire (RGB vs YCbCr). > > > > > I really don't want a repeat of the disaster of the > > > 'B
Re: [PATCH v5 0/4] drm/rockchip: dw_hdmi: Add 4k@30 support
On Mon, Feb 13, 2023 at 04:11:46PM +0900, FUKAUMI Naoki wrote: > hi, > > on my rk3399 boards(ROCK Pi 4B+ and ROCK 4C+), fb0 is configured as > 1920x1080, and nothing is displayed... "no signal" on display. I can confirm this. First of all there is a stupid bug in my patch: > + if (vop->data->max_output.width && mode->hdisplay > > vop->data->max_output.height) > + return MODE_BAD_HVALUE; The comparison should be against the width here of course, not against the height. Fixing this should at least allow you to display something when a 1080p display is connected. The other problem comes with the legacy fbdev emulation. I think failure is pretty much expected here. The fbdev emulation happens to use the VOPL to display a 4k picture, but the VOPL can only do up to 2560x1600 and so the mode is denied in vop_crtc_mode_valid(). Quoting Daniel Stone on this topic: > You've done the right thing. Userspace should detect this and try with > alternative CRTC routing. The kernel shouldn't be trying to solve this > problem. Trying an alternative CRTC routing is exactly what the fbdev emulation doesn't do. Now my "userspace" is in kernel and the kernel shouldn't try to solve this problem. We're trapped :-/ Sascha > > -- > FUKAUMI Naoki > > On 2/8/23 18:08, Sascha Hauer wrote: > > Some more small changes to this series, see changelog. > > > > Sascha > > > > Changes since v4: > > - Use struct vop_reg to store resolutions > > - Only check for valid clock rates when clock != NULL > > > > Changes since v3 > > - Add patch to limit VOP resolutions to hardware capabilitie > > > > Changes since v2: > > - Use correct register values for mpll_cfg > > - Add patch to discard modes we cannot achieve > > > > Changes since v1: > > - Allow non standard clock rates only on Synopsys phy as suggested by > >Robin Murphy > > > > Sascha Hauer (4): > >drm/rockchip: vop: limit maximium resolution to hardware capabilities > >drm/rockchip: dw_hdmi: relax mode_valid hook > >drm/rockchip: dw_hdmi: Add support for 4k@30 resolution > >drm/rockchip: dw_hdmi: discard modes with unachievable pixelclocks > > > > drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 41 > > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 15 +++ > > drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 6 +++ > > drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 5 --- > > drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 18 + > > 5 files changed, 73 insertions(+), 12 deletions(-) > > > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [Freedreno] [RFT PATCH v2 3/3] drm/msm/dsi: More properly handle errors in regards to dsi_mgr_bridge_power_on()
Hi,
On Mon, Feb 13, 2023 at 6:02 PM Abhinav Kumar wrote:
>
> Hi Doug
>
> Sorry for the delayed response.
>
> On 2/2/2023 2:46 PM, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, Feb 2, 2023 at 2:37 PM Abhinav Kumar
> > wrote:
> >>
> >> Hi Doug
> >>
> >> On 1/31/2023 2:18 PM, Douglas Anderson wrote:
> >>> In commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset
> >>> time") the error handling with regards to dsi_mgr_bridge_power_on()
> >>> got a bit worse. Specifically if we failed to power the bridge on then
> >>> nothing would really notice. The modeset function couldn't return an
> >>> error and thus we'd blindly go forward and try to do the pre-enable.
> >>>
> >>> In commit ec7981e6c614 ("drm/msm/dsi: don't powerup at modeset time
> >>> for parade-ps8640") we added a special case to move the powerup back
> >>> to pre-enable time for ps8640. When we did that, we didn't try to
> >>> recover the old/better error handling just for ps8640.
> >>>
> >>> In the patch ("drm/msm/dsi: Stop unconditionally powering up DSI hosts
> >>> at modeset") we've now moved the powering up back to exclusively being
> >>> during pre-enable. That means we can add the better error handling
> >>> back in, so let's do it. To do so we'll add a new function
> >>> dsi_mgr_bridge_power_off() that's matches how errors were handled
> >>> prior to commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to
> >>> modeset time").
> >>>
> >>> NOTE: Now that we have dsi_mgr_bridge_power_off(), it feels as if we
> >>> should be calling it in dsi_mgr_bridge_post_disable(). That would make
> >>> some sense, but doing so would change the current behavior and thus
> >>> should be a separate patch. Specifically:
> >>> * dsi_mgr_bridge_post_disable() always calls dsi_mgr_phy_disable()
> >>> even in the slave-DSI case of bonded DSI. We'd need to add special
> >>> handling for this if it's truly needed.
> >>> * dsi_mgr_bridge_post_disable() calls msm_dsi_phy_pll_save_state()
> >>> midway through the poweroff.
> >>> * dsi_mgr_bridge_post_disable() has a different order of some of the
> >>> poweroffs / IRQ disables.
> >>> For now we'll leave dsi_mgr_bridge_post_disable() alone.
> >>>
> >>> Signed-off-by: Douglas Anderson
> >>> ---
> >>>
> >>> Changes in v2:
> >>> - ("More properly handle errors...") new for v2.
> >>>
> >>>drivers/gpu/drm/msm/dsi/dsi_manager.c | 32 ++-
> >>>1 file changed, 26 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
> >>> b/drivers/gpu/drm/msm/dsi/dsi_manager.c
> >>> index 2197a54b9b96..28b8012a21f2 100644
> >>> --- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
> >>> +++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
> >>> @@ -228,7 +228,7 @@ static void msm_dsi_manager_set_split_display(u8 id)
> >>>}
> >>>}
> >>>
> >>> -static void dsi_mgr_bridge_power_on(struct drm_bridge *bridge)
> >>> +static int dsi_mgr_bridge_power_on(struct drm_bridge *bridge)
> >>>{
> >>>int id = dsi_mgr_bridge_get_id(bridge);
> >>>struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
> >>> @@ -268,14 +268,31 @@ static void dsi_mgr_bridge_power_on(struct
> >>> drm_bridge *bridge)
> >>>if (is_bonded_dsi && msm_dsi1)
> >>>msm_dsi_host_enable_irq(msm_dsi1->host);
> >>>
> >>> - return;
> >>> + return 0;
> >>>
> >>>host1_on_fail:
> >>>msm_dsi_host_power_off(host);
> >>>host_on_fail:
> >>>dsi_mgr_phy_disable(id);
> >>>phy_en_fail:
> >>> - return;
> >>> + return ret;
> >>> +}
> >>> +
> >>> +static void dsi_mgr_bridge_power_off(struct drm_bridge *bridge)
> >>> +{
> >>> + int id = dsi_mgr_bridge_get_id(bridge);
> >>> + struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
> >>> + struct msm_dsi *msm_dsi1 = dsi_mgr_get_dsi(DSI_1);
> >>> + struct mipi_dsi_host *host = msm_dsi->host;
> >>> + bool is_bonded_dsi = IS_BONDED_DSI();
> >>> +
> >>> + msm_dsi_host_disable_irq(host);
> >>> + if (is_bonded_dsi && msm_dsi1) {
> >>> + msm_dsi_host_disable_irq(msm_dsi1->host);
> >>> + msm_dsi_host_power_off(msm_dsi1->host);
> >>> + }
> >>
> >> The order of disabling the IRQs should be opposite of how they were
> >> enabled.
> >>
> >> So while enabling it was DSI0 and then DSI1.
> >>
> >> Hence while disabling it should be DSI1 and then DSI0.
> >>
> >> So the order here should be
> >>
> >> DSI1 irq disable
> >> DSI0 irq disable
> >> DSI1 host power off
> >> DSI0 host power off
> >
> > Right. Normally you want to go opposite. I guess a few points, though:
> >
> > 1. As talked about in the commit message, the order I have matches the
> > order we had prior to commit 7d8e9a90509f ("drm/msm/dsi: move DSI host
> > powerup to modeset time").
> >
> > 2. I'd be curious if it matters. The order you request means we need
> > to check for `(is_bonded_dsi && msm_dsi1)` twice. While that's not a
> > big deal if it's important, it's nice not to have to do so
Re: [PATCH v3 3/6] drm: lcdif: Determine bus format and flags in ->atomic_check()
On Tue, Feb 14, 2023 at 03:12:55PM +0100, Alexander Stein wrote:
> Hi Liu,
>
> thanks for the update.
>
> Am Montag, 13. Februar 2023, 09:56:09 CET schrieb Liu Ying:
> > Instead of determining LCDIF output bus format and bus flags in
> > ->atomic_enable(), do that in ->atomic_check(). This is a
> > preparation for the upcoming patch to check consistent bus format
> > and bus flags across all first downstream bridges in ->atomic_check().
> > New lcdif_crtc_state structure is introduced to cache bus format
> > and bus flags states in ->atomic_check() so that they can be read
> > in ->atomic_enable().
> >
> > Signed-off-by: Liu Ying
> > ---
> > v2->v3:
> > * No change.
> >
> > v1->v2:
> > * Split from patch 2/2 in v1. (Marek, Alexander)
> > * Add comment on the 'base' member of lcdif_crtc_state structure to
> > note it should always be the first member. (Lothar)
> >
> > drivers/gpu/drm/mxsfb/lcdif_kms.c | 138 ++
> > 1 file changed, 100 insertions(+), 38 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > b/drivers/gpu/drm/mxsfb/lcdif_kms.c index e54200a9fcb9..294cecdf5439 100644
> > --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > +++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > @@ -30,6 +30,18 @@
> > #include "lcdif_drv.h"
> > #include "lcdif_regs.h"
> >
> > +struct lcdif_crtc_state {
> > + struct drm_crtc_state base; /* always be the first
> member */
>
> Is it strictly necessary that base is the first member? to_lcdif_crtc_state()
> should be able to handle any position within the struct. I mean it's sensible
> to put it in first place. But the comment somehow bugs me.
NULL pointers is where these things go bad if it't not at
offset 0. Unless you're willing to always handle those
explicitly.
--
Ville Syrjälä
Intel
Re: [PATCH v3 3/6] drm: lcdif: Determine bus format and flags in ->atomic_check()
Hi Liu,
thanks for the update.
Am Montag, 13. Februar 2023, 09:56:09 CET schrieb Liu Ying:
> Instead of determining LCDIF output bus format and bus flags in
> ->atomic_enable(), do that in ->atomic_check(). This is a
> preparation for the upcoming patch to check consistent bus format
> and bus flags across all first downstream bridges in ->atomic_check().
> New lcdif_crtc_state structure is introduced to cache bus format
> and bus flags states in ->atomic_check() so that they can be read
> in ->atomic_enable().
>
> Signed-off-by: Liu Ying
> ---
> v2->v3:
> * No change.
>
> v1->v2:
> * Split from patch 2/2 in v1. (Marek, Alexander)
> * Add comment on the 'base' member of lcdif_crtc_state structure to
> note it should always be the first member. (Lothar)
>
> drivers/gpu/drm/mxsfb/lcdif_kms.c | 138 ++
> 1 file changed, 100 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> b/drivers/gpu/drm/mxsfb/lcdif_kms.c index e54200a9fcb9..294cecdf5439 100644
> --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> +++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> @@ -30,6 +30,18 @@
> #include "lcdif_drv.h"
> #include "lcdif_regs.h"
>
> +struct lcdif_crtc_state {
> + struct drm_crtc_state base; /* always be the first
member */
Is it strictly necessary that base is the first member? to_lcdif_crtc_state()
should be able to handle any position within the struct. I mean it's sensible
to put it in first place. But the comment somehow bugs me.
> + u32 bus_format;
> + u32 bus_flags;
> +};
> +
> +static inline struct lcdif_crtc_state *
> +to_lcdif_crtc_state(struct drm_crtc_state *s)
> +{
> + return container_of(s, struct lcdif_crtc_state, base);
> +}
> +
> /*
> ---
> -- * CRTC
> */
> @@ -385,48 +397,72 @@ static void lcdif_reset_block(struct lcdif_drm_private
> *lcdif) readl(lcdif->base + LCDC_V8_CTRL);
> }
>
> -static void lcdif_crtc_mode_set_nofb(struct lcdif_drm_private *lcdif,
> - struct drm_plane_state
*plane_state,
> - struct drm_bridge_state
*bridge_state,
> - const u32 bus_format)
> +static void lcdif_crtc_mode_set_nofb(struct drm_crtc_state *crtc_state,
> + struct drm_plane_state
*plane_state)
> {
> - struct drm_device *drm = lcdif->crtc.dev;
> - struct drm_display_mode *m = &lcdif->crtc.state->adjusted_mode;
> - u32 bus_flags = 0;
> -
> - if (lcdif->bridge->timings)
> - bus_flags = lcdif->bridge->timings->input_bus_flags;
> - else if (bridge_state)
> - bus_flags = bridge_state->input_bus_cfg.flags;
> + struct lcdif_crtc_state *lcdif_crtc_state =
> to_lcdif_crtc_state(crtc_state); +struct drm_device *drm =
> crtc_state->crtc->dev;
> + struct lcdif_drm_private *lcdif = to_lcdif_drm_private(drm);
> + struct drm_display_mode *m = &crtc_state->adjusted_mode;
>
> DRM_DEV_DEBUG_DRIVER(drm->dev, "Pixel clock: %dkHz (actual: %dkHz)
\n",
>m->crtc_clock,
>(int)(clk_get_rate(lcdif->clk) / 1000));
> DRM_DEV_DEBUG_DRIVER(drm->dev, "Bridge bus_flags: 0x%08X\n",
> - bus_flags);
> + lcdif_crtc_state->bus_flags);
> DRM_DEV_DEBUG_DRIVER(drm->dev, "Mode flags: 0x%08X\n", m->flags);
>
> /* Mandatory eLCDIF reset as per the Reference Manual */
> lcdif_reset_block(lcdif);
>
> - lcdif_set_formats(lcdif, plane_state, bus_format);
> + lcdif_set_formats(lcdif, plane_state, lcdif_crtc_state->bus_format);
>
> - lcdif_set_mode(lcdif, bus_flags);
> + lcdif_set_mode(lcdif, lcdif_crtc_state->bus_flags);
> }
>
> static int lcdif_crtc_atomic_check(struct drm_crtc *crtc,
> struct drm_atomic_state *state)
> {
> + struct drm_device *drm = crtc->dev;
> + struct lcdif_drm_private *lcdif = to_lcdif_drm_private(drm);
> struct drm_crtc_state *crtc_state =
drm_atomic_get_new_crtc_state(state,
>
crtc);
> + struct lcdif_crtc_state *lcdif_crtc_state =
> to_lcdif_crtc_state(crtc_state); bool has_primary = crtc_state->plane_mask
> &
> drm_plane_mask(crtc->primary);
> + struct drm_bridge_state *bridge_state;
> + struct drm_bridge *bridge = lcdif->bridge;
> + int ret;
>
> /* The primary plane has to be enabled when the CRTC is active. */
> if (crtc_state->active && !has_primary)
> return -EINVAL;
>
> - return drm_atomic_add_affected_planes(state, crtc);
> + ret = drm_atomic_add_affected_planes(state, crtc);
> + if (ret)
> + return ret;
> +
> + bridge_state = drm_atomic_get_new_bridge_state(state, bridge);
> +
Re: [PATCH] drm/gem: Expose the buffer object handle to userspace last
Am 14.02.23 um 13:50 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Currently drm_gem_handle_create_tail exposes the handle to userspace
before the buffer object constructions is complete. This allowing
of working against a partially constructed object, which may also be in
the process of having its creation fail, can have a range of negative
outcomes.
A lot of those will depend on what the individual drivers are doing in
their obj->funcs->open() callbacks, and also with a common failure mode
being -ENOMEM from drm_vma_node_allow.
We can make sure none of this can happen by allocating a handle last,
although with a downside that more of the function now runs under the
dev->object_name_lock.
Looking into the individual drivers open() hooks, we have
amdgpu_gem_object_open which seems like it could have a potential security
issue without this change.
A couple drivers like qxl_gem_object_open and vmw_gem_object_open
implement no-op hooks so no impact for them.
A bunch of other require a deeper look by individual owners to asses for
impact. Those are lima_gem_object_open, nouveau_gem_object_open,
panfrost_gem_open, radeon_gem_object_open and virtio_gpu_gem_object_open.
Putting aside the risk assesment of the above, some common scenarios to
think about are along these lines:
1)
Userspace closes a handle by speculatively "guessing" it from a second
thread.
This results in an unreachable buffer object so, a memory leak.
2)
Same as 1), but object is in the process of getting closed (failed
creation).
The second thread is then able to re-cycle the handle and idr_remove would
in the first thread would then remove the handle it does not own from the
idr.
3)
Going back to the earlier per driver problem space - individual impact
assesment of allowing a second thread to access and operate on a partially
constructed handle / object. (Can something crash? Leak information?)
In terms of identifying when the problem started I will tag some patches
as references, but not all, if even any, of them actually point to a
broken state. I am just identifying points at which more opportunity for
issues to arise was added.
Yes I've looked into this once as well, but couldn't completely solve it
for some reason.
Give me a day or two to get this tested and all the logic swapped back
into my head again.
Christian.
References: 304eda32920b ("drm/gem: add hooks to notify driver when object handle is
created/destroyed")
References: ca481c9b2a3a ("drm/gem: implement vma access management")
References: b39b5394fabc ("drm/gem: Add drm_gem_object_funcs")
Cc: dri-devel@lists.freedesktop.org
Cc: Rob Clark
Cc: Ben Skeggs
Cc: David Herrmann
Cc: Noralf Trønnes
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Cc: l...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: Steven Price
Cc: virtualizat...@lists.linux-foundation.org
Cc: spice-de...@lists.freedesktop.org
Cc: Zack Rusin
---
drivers/gpu/drm/drm_gem.c | 48 +++
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index aa15c52ae182..e3d897bca0f2 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -356,52 +356,52 @@ drm_gem_handle_create_tail(struct drm_file *file_priv,
u32 *handlep)
{
struct drm_device *dev = obj->dev;
- u32 handle;
int ret;
WARN_ON(!mutex_is_locked(&dev->object_name_lock));
if (obj->handle_count++ == 0)
drm_gem_object_get(obj);
+ ret = drm_vma_node_allow(&obj->vma_node, file_priv);
+ if (ret)
+ goto err_put;
+
+ if (obj->funcs->open) {
+ ret = obj->funcs->open(obj, file_priv);
+ if (ret)
+ goto err_revoke;
+ }
+
/*
-* Get the user-visible handle using idr. Preload and perform
-* allocation under our spinlock.
+* Get the user-visible handle using idr as the _last_ step.
+* Preload and perform allocation under our spinlock.
*/
idr_preload(GFP_KERNEL);
spin_lock(&file_priv->table_lock);
-
ret = idr_alloc(&file_priv->object_idr, obj, 1, 0, GFP_NOWAIT);
-
spin_unlock(&file_priv->table_lock);
idr_preload_end();
- mutex_unlock(&dev->object_name_lock);
if (ret < 0)
- goto err_unref;
-
- handle = ret;
+ goto err_close;
- ret = drm_vma_node_allow(&obj->vma_node, file_priv);
- if (ret)
- goto err_remove;
+ mutex_unlock(&dev->object_name_lock);
- if (obj->funcs->open) {
- ret = obj->funcs->open(obj, file_priv);
- if (ret)
- goto err_revoke;
- }
+ *handlep = ret;
- *handlep = handle;
return 0;
+err_close:
+ if (obj->funcs->close)
+ obj->funcs->close(obj, file_priv);
err_revo
Re: [PATCH v3 2/6] drm: lcdif: Drop unnecessary NULL pointer check on lcdif->bridge
Hi Liu,
thanks for the update.
Am Montag, 13. Februar 2023, 09:56:08 CET schrieb Liu Ying:
> A valid bridge is already found in lcdif_attach_bridge() and set
> to lcdif->bridge, so lcdif->bridge cannot be a NULL pointer. Drop
> the unnecessary NULL pointer check in KMS stage.
>
> Signed-off-by: Liu Ying
> ---
> v2->v3:
> * No change.
>
> v1->v2:
> * Split from patch 2/2 in v1. (Marek, Alexander)
>
> drivers/gpu/drm/mxsfb/lcdif_kms.c | 33 +++
> 1 file changed, 12 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> b/drivers/gpu/drm/mxsfb/lcdif_kms.c index 262bc43b1079..e54200a9fcb9 100644
> --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> +++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> @@ -394,7 +394,7 @@ static void lcdif_crtc_mode_set_nofb(struct
> lcdif_drm_private *lcdif, struct drm_display_mode *m =
> &lcdif->crtc.state->adjusted_mode;
> u32 bus_flags = 0;
>
> - if (lcdif->bridge && lcdif->bridge->timings)
> + if (lcdif->bridge->timings)
> bus_flags = lcdif->bridge->timings->input_bus_flags;
> else if (bridge_state)
> bus_flags = bridge_state->input_bus_cfg.flags;
> @@ -463,30 +463,21 @@ static void lcdif_crtc_atomic_enable(struct drm_crtc
> *crtc, struct drm_display_mode *m = &lcdif->crtc.state->adjusted_mode;
> struct drm_bridge_state *bridge_state = NULL;
> struct drm_device *drm = lcdif->drm;
> - u32 bus_format = 0;
> + u32 bus_format;
> dma_addr_t paddr;
>
> - /* If there is a bridge attached to the LCDIF, use its bus format */
> - if (lcdif->bridge) {
> - bridge_state =
> - drm_atomic_get_new_bridge_state(state,
> - lcdif-
>bridge);
> - if (!bridge_state)
> - bus_format = MEDIA_BUS_FMT_FIXED;
> - else
> - bus_format = bridge_state->input_bus_cfg.format;
> -
> - if (bus_format == MEDIA_BUS_FMT_FIXED) {
> - dev_warn_once(drm->dev,
> - "Bridge does not provide bus
format, assuming
> MEDIA_BUS_FMT_RGB888_1X24.\n" -
"Please fix bridge driver by
> handling atomic_get_input_bus_fmts.\n"); -
bus_format =
> MEDIA_BUS_FMT_RGB888_1X24;
> - }
> - }
> + bridge_state = drm_atomic_get_new_bridge_state(state, lcdif-
>bridge);
> + if (!bridge_state)
> + bus_format = MEDIA_BUS_FMT_FIXED;
> + else
> + bus_format = bridge_state->input_bus_cfg.format;
>
> - /* If all else fails, default to RGB888_1X24 */
> - if (!bus_format)
> + if (bus_format == MEDIA_BUS_FMT_FIXED) {
> + dev_warn_once(drm->dev,
> + "Bridge does not provide bus format,
assuming
> MEDIA_BUS_FMT_RGB888_1X24.\n" + "Please fix
bridge driver by
> handling atomic_get_input_bus_fmts.\n"); bus_format =
> MEDIA_BUS_FMT_RGB888_1X24;
> + }
>
> clk_set_rate(lcdif->clk, m->crtc_clock * 1000);
LGTM.
Reviewed-by: Alexander Stein
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
Re: [RFC PATCH 5/7] drm/msm/dpu: Document and enable TEAR interrupts on DSI interfaces
On 2023-02-13 19:09:32, Abhinav Kumar wrote: > > > On 2/13/2023 1:46 PM, Dmitry Baryshkov wrote: > > On 13/02/2023 21:37, Jessica Zhang wrote: > >> > >> > >> On 12/31/2022 1:50 PM, Marijn Suijten wrote: > >>> All SoCs since DPU 5.0.0 (and seemingly up until and including 6.0.0, > >>> but excluding 7.x.x) have the tear interrupt and control registers moved > >>> out of the PINGPONG block and into the INTF block. Wire up the > >>> necessary interrupts and IRQ masks on all supported hardware. > >> > >> Hi Marijn, > >> > >> Thanks for the patch. > >> > >> I saw that in your commit msg, you mentioned that 7.x doesn't have > >> tearcheck in the INTF block -- can you double check that this is correct? It wasn't correct and has already been removed for v2 [1] after rebasing on top of SM8[345]50 support, where the registers reside at a different (named 7 downstream) offset. [1] https://github.com/SoMainline/linux/commit/886d3fb9eed925e7e9c8d6ca63d2439eaec1c702 > >> I'm working on SM8350 (DPU v7) and I'm seeing that it does have > >> tearcheck in INTF block. > > > > I confirm, according to the vendor drivers INTF TE should be used for > > all DPU >= 5.0, including 7.x and 8.x > > > > However I think I know what Marijn meant here. For 5.x and 6.x these > > IRQs are handled at the address MDSS + 0x6e800 / + 0x6e900 (which means > > offset here should 0x6d800 and 0x6d900) for INTF_1 and INTF_2. Since DPU > > 7.x these IRQ registers were moved close to the main INTF block (0x36800 > > and 0x37800 = INTF + 0x800). That might have been the case. > Got it, then the commit text should remove "control" and just say tear > interrupt registers. It got a bit confusing. The wording here points to both the interrupt (MDP_INTFx_TEAR_INTR) registers and control (INTF_TEAR_xxx) registers separately. Feel free to bikeshed the wording in preliminary v2 [1]; should I drop the mention of the control registers being "moved" from PP to INTF entirely, leaving just the wording about the interrupt registers moving from MDP_SSPP_TOP0_INTR to a dedicated MDP_INTFx_TEAR_INTR region? > We will add the 7xxx intf tear check support on top of this series. No need, that is already taken care of in an impending v2 [1] (unless additional changes are required beyond the moved register offset). > >>> Signed-off-by: Marijn Suijten > >>> --- > >>> .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 78 +++ > >>> .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 6 +- > >>> .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 12 +++ > >>> .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 2 + > >>> drivers/gpu/drm/msm/disp/dpu1/dpu_hwio.h | 3 + > >>> 5 files changed, 68 insertions(+), 33 deletions(-) > >>> > >>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c > >>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c > >>> index 1cfe94494135..b9b9b5b0b615 100644 > >>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c > >>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c > >>> @@ -86,6 +86,15 @@ > >>> #define INTF_SC7280_MASK INTF_SC7180_MASK | BIT(DPU_DATA_HCTL_EN) > >>> +#define IRQ_MSM8998_MASK (BIT(MDP_SSPP_TOP0_INTR) | \ > >>> + BIT(MDP_SSPP_TOP0_INTR2) | \ > >>> + BIT(MDP_SSPP_TOP0_HIST_INTR) | \ > >>> + BIT(MDP_INTF0_INTR) | \ > >>> + BIT(MDP_INTF1_INTR) | \ > >>> + BIT(MDP_INTF2_INTR) | \ > >>> + BIT(MDP_INTF3_INTR) | \ > >>> + BIT(MDP_INTF4_INTR)) > >>> + > >>> #define IRQ_SDM845_MASK (BIT(MDP_SSPP_TOP0_INTR) | \ > >>> BIT(MDP_SSPP_TOP0_INTR2) | \ > >>> BIT(MDP_SSPP_TOP0_HIST_INTR) | \ > >>> @@ -100,13 +109,15 @@ > >>> #define IRQ_QCM2290_MASK (BIT(MDP_SSPP_TOP0_INTR) | \ > >>> BIT(MDP_SSPP_TOP0_INTR2) | \ > >>> BIT(MDP_SSPP_TOP0_HIST_INTR) | \ > >>> - BIT(MDP_INTF1_INTR)) > >>> + BIT(MDP_INTF1_INTR) | \ > >>> + BIT(MDP_INTF1_TEAR_INTR)) > >>> #define IRQ_SC7180_MASK (BIT(MDP_SSPP_TOP0_INTR) | \ > >>> BIT(MDP_SSPP_TOP0_INTR2) | \ > >>> BIT(MDP_SSPP_TOP0_HIST_INTR) | \ > >>> BIT(MDP_INTF0_INTR) | \ > >>> - BIT(MDP_INTF1_INTR)) > >>> + BIT(MDP_INTF1_INTR) | \ > >>> + BIT(MDP_INTF1_TEAR_INTR)) > >>> #define IRQ_SC7280_MASK (BIT(MDP_SSPP_TOP0_INTR) | \ > >>> BIT(MDP_SSPP_TOP0_INTR2) | \ > >>> @@ -120,7 +131,9 @@ > >>> BIT(MDP_SSPP_TOP0_HIST_INTR) | \ > >>> BIT(MDP_INTF0_INTR) | \ > >>> BIT(MDP_INTF1_INTR) | \ > >>> + BIT(MDP_INTF1_TEAR_INTR) | \ > >>> BIT(MDP_INTF2_INTR) | \ > >>> + BIT(MDP_INTF2_TEAR_INTR) | \ > >>> BIT(MDP_INTF3_INTR) | \ > >>> BIT(MDP_INTF4_INTR)) > >>> @@ -129,7 +142,9 @@ > >>> BIT(MDP_SSPP_TOP0_HIST_INTR) | \ > >>> BIT(MDP_INTF0_INTR) | \ > >
[PATCH] drm/gem: Expose the buffer object handle to userspace last
From: Tvrtko Ursulin
Currently drm_gem_handle_create_tail exposes the handle to userspace
before the buffer object constructions is complete. This allowing
of working against a partially constructed object, which may also be in
the process of having its creation fail, can have a range of negative
outcomes.
A lot of those will depend on what the individual drivers are doing in
their obj->funcs->open() callbacks, and also with a common failure mode
being -ENOMEM from drm_vma_node_allow.
We can make sure none of this can happen by allocating a handle last,
although with a downside that more of the function now runs under the
dev->object_name_lock.
Looking into the individual drivers open() hooks, we have
amdgpu_gem_object_open which seems like it could have a potential security
issue without this change.
A couple drivers like qxl_gem_object_open and vmw_gem_object_open
implement no-op hooks so no impact for them.
A bunch of other require a deeper look by individual owners to asses for
impact. Those are lima_gem_object_open, nouveau_gem_object_open,
panfrost_gem_open, radeon_gem_object_open and virtio_gpu_gem_object_open.
Putting aside the risk assesment of the above, some common scenarios to
think about are along these lines:
1)
Userspace closes a handle by speculatively "guessing" it from a second
thread.
This results in an unreachable buffer object so, a memory leak.
2)
Same as 1), but object is in the process of getting closed (failed
creation).
The second thread is then able to re-cycle the handle and idr_remove would
in the first thread would then remove the handle it does not own from the
idr.
3)
Going back to the earlier per driver problem space - individual impact
assesment of allowing a second thread to access and operate on a partially
constructed handle / object. (Can something crash? Leak information?)
In terms of identifying when the problem started I will tag some patches
as references, but not all, if even any, of them actually point to a
broken state. I am just identifying points at which more opportunity for
issues to arise was added.
References: 304eda32920b ("drm/gem: add hooks to notify driver when object
handle is created/destroyed")
References: ca481c9b2a3a ("drm/gem: implement vma access management")
References: b39b5394fabc ("drm/gem: Add drm_gem_object_funcs")
Cc: dri-devel@lists.freedesktop.org
Cc: Rob Clark
Cc: Ben Skeggs
Cc: David Herrmann
Cc: Noralf Trønnes
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Cc: l...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: Steven Price
Cc: virtualizat...@lists.linux-foundation.org
Cc: spice-de...@lists.freedesktop.org
Cc: Zack Rusin
---
drivers/gpu/drm/drm_gem.c | 48 +++
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index aa15c52ae182..e3d897bca0f2 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -356,52 +356,52 @@ drm_gem_handle_create_tail(struct drm_file *file_priv,
u32 *handlep)
{
struct drm_device *dev = obj->dev;
- u32 handle;
int ret;
WARN_ON(!mutex_is_locked(&dev->object_name_lock));
if (obj->handle_count++ == 0)
drm_gem_object_get(obj);
+ ret = drm_vma_node_allow(&obj->vma_node, file_priv);
+ if (ret)
+ goto err_put;
+
+ if (obj->funcs->open) {
+ ret = obj->funcs->open(obj, file_priv);
+ if (ret)
+ goto err_revoke;
+ }
+
/*
-* Get the user-visible handle using idr. Preload and perform
-* allocation under our spinlock.
+* Get the user-visible handle using idr as the _last_ step.
+* Preload and perform allocation under our spinlock.
*/
idr_preload(GFP_KERNEL);
spin_lock(&file_priv->table_lock);
-
ret = idr_alloc(&file_priv->object_idr, obj, 1, 0, GFP_NOWAIT);
-
spin_unlock(&file_priv->table_lock);
idr_preload_end();
- mutex_unlock(&dev->object_name_lock);
if (ret < 0)
- goto err_unref;
-
- handle = ret;
+ goto err_close;
- ret = drm_vma_node_allow(&obj->vma_node, file_priv);
- if (ret)
- goto err_remove;
+ mutex_unlock(&dev->object_name_lock);
- if (obj->funcs->open) {
- ret = obj->funcs->open(obj, file_priv);
- if (ret)
- goto err_revoke;
- }
+ *handlep = ret;
- *handlep = handle;
return 0;
+err_close:
+ if (obj->funcs->close)
+ obj->funcs->close(obj, file_priv);
err_revoke:
drm_vma_node_revoke(&obj->vma_node, file_priv);
-err_remove:
- spin_lock(&file_priv->table_lock);
- idr_remove(&file_priv->object_idr, handle);
- spin_unlock(&file_priv->table_lock);
-err_unref:
-
Re: [PATCH 3/3] drm/debugfs: remove dev->debugfs_list and debugfs_mutex
On Tue, Feb 14, 2023 at 01:19:51PM +0100, Stanislaw Gruszka wrote:
> On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
> > -void drm_debugfs_late_register(struct drm_device *dev)
> > -{
> > - struct drm_minor *minor = dev->primary;
> > - struct drm_debugfs_entry *entry, *tmp;
> > -
> > - if (!minor)
> > - return;
> > -
> > - list_for_each_entry_safe(entry, tmp, &dev->debugfs_list, list) {
> > - debugfs_create_file(entry->file.name, 0444,
> > - minor->debugfs_root, entry,
> > &drm_debugfs_entry_fops);
> > - list_del(&entry->list);
> > - }
> > }
> >
> > int drm_debugfs_remove_files(const struct drm_info_list *files, int count,
> > @@ -343,9 +321,13 @@ void drm_debugfs_add_file(struct drm_device *dev,
> > const char *name,
> > entry->file.data = data;
> > entry->dev = dev;
> >
> > - mutex_lock(&dev->debugfs_mutex);
> > - list_add(&entry->list, &dev->debugfs_list);
> > - mutex_unlock(&dev->debugfs_mutex);
> > + debugfs_create_file(name, 0444, dev->primary->debugfs_root, entry,
> > + &drm_debugfs_entry_fops);
> > +
> > + /* TODO: This should probably only be a symlink */
> > + if (dev->render)
> > + debugfs_create_file(name, 0444, dev->render->debugfs_root,
> > + entry, &drm_debugfs_entry_fops);
>
> For accel we would need conditional check for DRM_MINOR_ACCEL here as
> well.
Actually my comment make no sense, since we do not have minor pointer
here. What is needed is additional dev->accel code like for dev->render,
perhaps also make dev->primary conditional.
Alternatively we can just create separate helper: accel_debugfs_add_file.
> With this change and one from first patch, drm_debugfs_add_file() should
> work for accel as well. We could get rid of debugfs_init from
> accel_debugfs_init().
>
> However we still need support for writable files. I think we can just
> add helper for providing debugfs dir to drivers i.e:
>
> struct dentry *accel_debugfs_dir(struct drm_device *drm)
> {
> return drm->accel->debugfs_root;
> }
or just this :-)
Regards
Stanislaw
[PATCH 3/3] drm/msm/a5xx: add devcoredump support to the fault handler
Use adreno_fault_handler() to implement a5xx_fault_handler(). This
enables devcoredump support on a5xx platforms, allowing one to capture
the crashed GPU state at the time of context fault.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index b5270324f5f8..d38ebfb5965b 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1099,16 +1099,19 @@ bool a5xx_idle(struct msm_gpu *gpu, struct
msm_ringbuffer *ring)
static int a5xx_fault_handler(void *arg, unsigned long iova, int flags, void
*data)
{
struct msm_gpu *gpu = arg;
- pr_warn_ratelimited("*** gpu fault: iova=%08lx, flags=%d
(%u,%u,%u,%u)\n",
- iova, flags,
+ struct adreno_smmu_fault_info *info = data;
+ char block[12] = "unknown";
+ u32 scratch[] = {
gpu_read(gpu, REG_A5XX_CP_SCRATCH_REG(4)),
gpu_read(gpu, REG_A5XX_CP_SCRATCH_REG(5)),
gpu_read(gpu, REG_A5XX_CP_SCRATCH_REG(6)),
- gpu_read(gpu, REG_A5XX_CP_SCRATCH_REG(7)));
+ gpu_read(gpu, REG_A5XX_CP_SCRATCH_REG(7)),
+ };
- gpu->aspace->mmu->funcs->resume_translation(gpu->aspace->mmu);
+ if (info)
+ snprintf(block, sizeof(block), "%x", info->fsynr1);
- return 0;
+ return adreno_fault_handler(gpu, iova, flags, info, block, scratch);
}
static void a5xx_cp_err_irq(struct msm_gpu *gpu)
--
2.30.2
[PATCH 0/3] drm/msm/adreno: implement devcoredump support for a5xx
During the debug of the a5xx preempt issue, having the devcoredump support was a great help. These patches port necessary code bits from being a6xx-specific to generic code path and then enables devcoredump for a5xx. Dmitry Baryshkov (3): drm/msm/adreno: stall translation on fault for all GPU families drm/msm/adreno: split a6xx fault handler into generic and a6xx parts drm/msm/a5xx: add devcoredump support to the fault handler drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 13 +++-- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 64 +++-- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 62 +++- drivers/gpu/drm/msm/adreno/adreno_gpu.h | 4 ++ drivers/gpu/drm/msm/msm_iommu.c | 38 ++- drivers/gpu/drm/msm/msm_mmu.h | 1 + 6 files changed, 109 insertions(+), 73 deletions(-) -- 2.30.2
[PATCH 2/3] drm/msm/adreno: split a6xx fault handler into generic and a6xx parts
Split the a6xx_fault_handler() into the generic adreno_fault_handler()
and platform-specific parts. The adreno_fault_handler() can further be
used by a5xx and hopefully by a4xx (at some point).
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 64 +++--
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 60 +++
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 4 ++
3 files changed, 71 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index aae60cbd9164..faee45135ca8 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1361,73 +1361,23 @@ static const char *a6xx_fault_block(struct msm_gpu
*gpu, u32 id)
return a6xx_uche_fault_block(gpu, id);
}
-#define ARM_SMMU_FSR_TF BIT(1)
-#define ARM_SMMU_FSR_PFBIT(3)
-#define ARM_SMMU_FSR_EFBIT(4)
-
static int a6xx_fault_handler(void *arg, unsigned long iova, int flags, void
*data)
{
struct msm_gpu *gpu = arg;
struct adreno_smmu_fault_info *info = data;
- const char *type = "UNKNOWN";
- const char *block;
- bool do_devcoredump = info && !READ_ONCE(gpu->crashstate);
-
- /*
-* If we aren't going to be resuming later from fault_worker, then do
-* it now.
-*/
- if (!do_devcoredump) {
- gpu->aspace->mmu->funcs->resume_translation(gpu->aspace->mmu);
- }
+ const char *block = "unknown";
- /*
-* Print a default message if we couldn't get the data from the
-* adreno-smmu-priv
-*/
- if (!info) {
- pr_warn_ratelimited("*** gpu fault: iova=%.16lx flags=%d
(%u,%u,%u,%u)\n",
- iova, flags,
+ u32 scratch[] = {
gpu_read(gpu, REG_A6XX_CP_SCRATCH_REG(4)),
gpu_read(gpu, REG_A6XX_CP_SCRATCH_REG(5)),
gpu_read(gpu, REG_A6XX_CP_SCRATCH_REG(6)),
- gpu_read(gpu, REG_A6XX_CP_SCRATCH_REG(7)));
-
- return 0;
- }
-
- if (info->fsr & ARM_SMMU_FSR_TF)
- type = "TRANSLATION";
- else if (info->fsr & ARM_SMMU_FSR_PF)
- type = "PERMISSION";
- else if (info->fsr & ARM_SMMU_FSR_EF)
- type = "EXTERNAL";
-
- block = a6xx_fault_block(gpu, info->fsynr1 & 0xff);
-
- pr_warn_ratelimited("*** gpu fault: ttbr0=%.16llx iova=%.16lx dir=%s
type=%s source=%s (%u,%u,%u,%u)\n",
- info->ttbr0, iova,
- flags & IOMMU_FAULT_WRITE ? "WRITE" : "READ",
- type, block,
- gpu_read(gpu, REG_A6XX_CP_SCRATCH_REG(4)),
- gpu_read(gpu, REG_A6XX_CP_SCRATCH_REG(5)),
- gpu_read(gpu, REG_A6XX_CP_SCRATCH_REG(6)),
- gpu_read(gpu, REG_A6XX_CP_SCRATCH_REG(7)));
-
- if (do_devcoredump) {
- /* Turn off the hangcheck timer to keep it from bothering us */
- del_timer(&gpu->hangcheck_timer);
+ gpu_read(gpu, REG_A6XX_CP_SCRATCH_REG(7)),
+ };
- gpu->fault_info.ttbr0 = info->ttbr0;
- gpu->fault_info.iova = iova;
- gpu->fault_info.flags = flags;
- gpu->fault_info.type = type;
- gpu->fault_info.block = block;
+ if (info)
+ block = a6xx_fault_block(gpu, info->fsynr1 & 0xff);
- kthread_queue_work(gpu->worker, &gpu->fault_work);
- }
-
- return 0;
+ return adreno_fault_handler(gpu, iova, flags, info, block, scratch);
}
static void a6xx_cp_hw_err_irq(struct msm_gpu *gpu)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index a05d48ecae15..9bbc298fe6d6 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -246,6 +246,66 @@ u64 adreno_private_address_space_size(struct msm_gpu *gpu)
return SZ_4G;
}
+#define ARM_SMMU_FSR_TF BIT(1)
+#define ARM_SMMU_FSR_PFBIT(3)
+#define ARM_SMMU_FSR_EFBIT(4)
+
+int adreno_fault_handler(struct msm_gpu *gpu, unsigned long iova, int flags,
+struct adreno_smmu_fault_info *info, const char *block,
+u32 scratch[4])
+{
+ const char *type = "UNKNOWN";
+ bool do_devcoredump = info && !READ_ONCE(gpu->crashstate);
+
+ /*
+* If we aren't going to be resuming later from fault_worker, then do
+* it now.
+*/
+ if (!do_devcoredump) {
+ gpu->aspace->mmu->funcs->resume_translation(gpu->aspace->mmu);
+ }
+
+ /*
+* Print a default message if we couldn't get the data from the
+* adreno-smmu-priv
+
[PATCH 1/3] drm/msm/adreno: stall translation on fault for all GPU families
The commit e25e92e08e32 ("drm/msm: devcoredump iommu fault support")
enabled SMMU stalling to collect GPU state, but only for a6xx. It tied
enabling the stall with tha per-instance pagetables creation.
Since that commit SoCs with a5xx also gained support for
adreno-smmu-priv. Move stalling into generic code and add corresponding
resume_translation calls.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +-
drivers/gpu/drm/msm/msm_iommu.c | 38 ++---
drivers/gpu/drm/msm/msm_mmu.h | 1 +
4 files changed, 31 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 047c5e8c87ff..b5270324f5f8 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1106,6 +1106,8 @@ static int a5xx_fault_handler(void *arg, unsigned long
iova, int flags, void *da
gpu_read(gpu, REG_A5XX_CP_SCRATCH_REG(6)),
gpu_read(gpu, REG_A5XX_CP_SCRATCH_REG(7)));
+ gpu->aspace->mmu->funcs->resume_translation(gpu->aspace->mmu);
+
return 0;
}
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 3bc02dbed9a7..a05d48ecae15 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -208,7 +208,7 @@ adreno_iommu_create_address_space(struct msm_gpu *gpu,
struct msm_gem_address_space *aspace;
u64 start, size;
- mmu = msm_iommu_new(&pdev->dev, quirks);
+ mmu = msm_iommu_gpu_new(&pdev->dev, gpu, quirks);
if (IS_ERR_OR_NULL(mmu))
return ERR_CAST(mmu);
diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
index c2507582ecf3..418e1e06cdde 100644
--- a/drivers/gpu/drm/msm/msm_iommu.c
+++ b/drivers/gpu/drm/msm/msm_iommu.c
@@ -237,13 +237,6 @@ struct msm_mmu *msm_iommu_pagetable_create(struct msm_mmu
*parent)
if (!ttbr1_cfg)
return ERR_PTR(-ENODEV);
- /*
-* Defer setting the fault handler until we have a valid adreno_smmu
-* to avoid accidentially installing a GPU specific fault handler for
-* the display's iommu
-*/
- iommu_set_fault_handler(iommu->domain, msm_fault_handler, iommu);
-
pagetable = kzalloc(sizeof(*pagetable), GFP_KERNEL);
if (!pagetable)
return ERR_PTR(-ENOMEM);
@@ -271,9 +264,6 @@ struct msm_mmu *msm_iommu_pagetable_create(struct msm_mmu
*parent)
* the arm-smmu driver as a trigger to set up TTBR0
*/
if (atomic_inc_return(&iommu->pagetables) == 1) {
- /* Enable stall on iommu fault: */
- adreno_smmu->set_stall(adreno_smmu->cookie, true);
-
ret = adreno_smmu->set_ttbr0_cfg(adreno_smmu->cookie,
&ttbr0_cfg);
if (ret) {
free_io_pgtable_ops(pagetable->pgtbl_ops);
@@ -302,6 +292,7 @@ static int msm_fault_handler(struct iommu_domain *domain,
struct device *dev,
unsigned long iova, int flags, void *arg)
{
struct msm_iommu *iommu = arg;
+ struct msm_mmu *mmu = &iommu->base;
struct adreno_smmu_priv *adreno_smmu = dev_get_drvdata(iommu->base.dev);
struct adreno_smmu_fault_info info, *ptr = NULL;
@@ -314,6 +305,10 @@ static int msm_fault_handler(struct iommu_domain *domain,
struct device *dev,
return iommu->base.handler(iommu->base.arg, iova, flags, ptr);
pr_warn_ratelimited("*** fault: iova=%16lx, flags=%d\n", iova, flags);
+
+ if (mmu->funcs->resume_translation)
+ mmu->funcs->resume_translation(mmu);
+
return 0;
}
@@ -321,7 +316,8 @@ static void msm_iommu_resume_translation(struct msm_mmu
*mmu)
{
struct adreno_smmu_priv *adreno_smmu = dev_get_drvdata(mmu->dev);
- adreno_smmu->resume_translation(adreno_smmu->cookie, true);
+ if (adreno_smmu->resume_translation)
+ adreno_smmu->resume_translation(adreno_smmu->cookie, true);
}
static void msm_iommu_detach(struct msm_mmu *mmu)
@@ -406,3 +402,23 @@ struct msm_mmu *msm_iommu_new(struct device *dev, unsigned
long quirks)
return &iommu->base;
}
+
+struct msm_mmu *msm_iommu_gpu_new(struct device *dev, struct msm_gpu *gpu,
unsigned long quirks)
+{
+ struct adreno_smmu_priv *adreno_smmu = dev_get_drvdata(dev);
+ struct msm_iommu *iommu;
+ struct msm_mmu *mmu;
+
+ mmu = msm_iommu_new(dev, quirks);
+ if (IS_ERR(mmu))
+ return mmu;
+
+ iommu = to_msm_iommu(mmu);
+ iommu_set_fault_handler(iommu->domain, msm_fault_handler, iommu);
+
+ /* Enable stall on iommu fault: */
+ if (adreno_smmu->set_stall)
+ adreno_smmu->set_stall(adreno_smmu->cookie, true);
+
+ return mmu;
+}
diff --git a/drivers/gp
Re: [PATCH 3/3] drm/debugfs: remove dev->debugfs_list and debugfs_mutex
On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
> -void drm_debugfs_late_register(struct drm_device *dev)
> -{
> - struct drm_minor *minor = dev->primary;
> - struct drm_debugfs_entry *entry, *tmp;
> -
> - if (!minor)
> - return;
> -
> - list_for_each_entry_safe(entry, tmp, &dev->debugfs_list, list) {
> - debugfs_create_file(entry->file.name, 0444,
> - minor->debugfs_root, entry,
> &drm_debugfs_entry_fops);
> - list_del(&entry->list);
> - }
> }
>
> int drm_debugfs_remove_files(const struct drm_info_list *files, int count,
> @@ -343,9 +321,13 @@ void drm_debugfs_add_file(struct drm_device *dev, const
> char *name,
> entry->file.data = data;
> entry->dev = dev;
>
> - mutex_lock(&dev->debugfs_mutex);
> - list_add(&entry->list, &dev->debugfs_list);
> - mutex_unlock(&dev->debugfs_mutex);
> + debugfs_create_file(name, 0444, dev->primary->debugfs_root, entry,
> + &drm_debugfs_entry_fops);
> +
> + /* TODO: This should probably only be a symlink */
> + if (dev->render)
> + debugfs_create_file(name, 0444, dev->render->debugfs_root,
> + entry, &drm_debugfs_entry_fops);
For accel we would need conditional check for DRM_MINOR_ACCEL here as
well.
With this change and one from first patch, drm_debugfs_add_file() should
work for accel as well. We could get rid of debugfs_init from
accel_debugfs_init().
However we still need support for writable files. I think we can just
add helper for providing debugfs dir to drivers i.e:
struct dentry *accel_debugfs_dir(struct drm_device *drm)
{
return drm->accel->debugfs_root;
}
Then individual accel driver could create files with different permissions
there.
Regards
Stanislaw
Re: [PATCH 1/3] drm/debugfs: separate debugfs creation into init and register
On Thu, Feb 09, 2023 at 09:18:36AM +0100, Christian König wrote:
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index c6eb8972451a..88ce22c04672 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -156,6 +156,10 @@ static int drm_minor_alloc(struct drm_device *dev,
> unsigned int type)
> if (IS_ERR(minor->kdev))
> return PTR_ERR(minor->kdev);
>
> + r = drm_debugfs_init(minor, minor->index, drm_debugfs_root);
> + if (r)
> + return r;
> +
> *drm_minor_get_slot(dev, type) = minor;
> return 0;
> }
> @@ -172,15 +176,10 @@ static int drm_minor_register(struct drm_device *dev,
> unsigned int type)
> if (!minor)
> return 0;
>
> - if (minor->type == DRM_MINOR_ACCEL) {
> + if (minor->type == DRM_MINOR_ACCEL)
> accel_debugfs_init(minor, minor->index);
Please move this to drm_minor_alloc() as well. Or perhaps make
conditional code for DRM_MINOR_ACCEL inside drm_debugfs_init().
Regards
Stanislaw
> - } else {
> - ret = drm_debugfs_init(minor, minor->index, drm_debugfs_root);
> - if (ret) {
> - DRM_ERROR("DRM: Failed to initialize
> /sys/kernel/debug/dri.\n");
> - goto err_debugfs;
> - }
> - }
> + else
> + drm_debugfs_register(minor);
>
> ret = device_add(minor->kdev);
> if (ret)
> diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
> index ed2103ee272c..332fb65a935a 100644
> --- a/drivers/gpu/drm/drm_internal.h
> +++ b/drivers/gpu/drm/drm_internal.h
> @@ -185,6 +185,7 @@ int drm_gem_dumb_destroy(struct drm_file *file, struct
> drm_device *dev,
> #if defined(CONFIG_DEBUG_FS)
> int drm_debugfs_init(struct drm_minor *minor, int minor_id,
>struct dentry *root);
> +void drm_debugfs_register(struct drm_minor *minor);
> void drm_debugfs_cleanup(struct drm_minor *minor);
> void drm_debugfs_late_register(struct drm_device *dev);
> void drm_debugfs_connector_add(struct drm_connector *connector);
> --
> 2.34.1
>
Re: [PATCH drm-next 03/14] drm: manager to keep track of GPUs VA mappings
On 2/3/23 18:37, Matthew Brost wrote: On Wed, Jan 18, 2023 at 07:12:45AM +0100, Danilo Krummrich wrote: This adds the infrastructure for a manager implementation to keep track of GPU virtual address (VA) mappings. New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers start implementing, allow userspace applications to request multiple and arbitrary GPU VA mappings of buffer objects. The DRM GPU VA manager is intended to serve the following purposes in this context. 1) Provide a dedicated range allocator to track GPU VA allocations and mappings, making use of the drm_mm range allocator. 2) Generically connect GPU VA mappings to their backing buffers, in particular DRM GEM objects. 3) Provide a common implementation to perform more complex mapping operations on the GPU VA space. In particular splitting and merging of GPU VA mappings, e.g. for intersecting mapping requests or partial unmap requests. Over the past week I've hacked together a PoC port of Xe to GPUVA [1], so far it seems really promising. 95% of the way to being feature equivalent of the current Xe VM bind implementation and have line of sight to getting sparse bindings implemented on top of GPUVA too. IMO this has basically everything we need for Xe with a few tweaks. I am out until 2/14 but wanted to get my thoughts / suggestions out on the list before I leave. Thanks for your work on that! 1. GPUVA post didn't support the way Xe does userptrs - a NULL GEM. I believe with [2], [3], and [4] GPUVA will support NULL GEMs. Also my thinking sparse binds will also have NULL GEMs, more on sparse bindings below. 2. I agree with Christian that drm_mm probably isn't what we want to base the GPUVA implementation on, rather a RB tree or Maple tree has been discussed. The implementation should be fairly easy to tune once we have benchmarks running so not to concerned here as we can figure this out down the line. 3. In Xe we want create xe_vm_op list which inherits from drm_gpuva_op I've done this with a hack [5], I believe when we rebase we can do this with a custom callback to allocate a large op size. 4. I'd like add user bits to drm_gpuva_flags like I do in [6]. This is similar to DMA_FENCE_FLAG_USER_BITS. 5. In Xe we have VM prefetch operation which is needed for our compute UMD with page faults. I'd like add prefetch type of operation like we do in [7]. 6. In Xe we have VM unbind all mappings for a GEM IOCTL, I'd like to add support to generate this operation list to GPUVA like we do in [8]. 7. I've thought about how Xe will implement sparse mappings (read 0, writes dropped). My current thinking is a sparse mapping will be represented as a drm_gpuva rather than region like in Nouveau. Making regions optional to me seems likes good idea rather than forcing the user of GPUVA code to create 1 large region for the manager as I currently do in the Xe PoC. 8. Personally I'd like the caller to own the locking for GEM drm_gpuva list (drm_gpuva_link_*, drm_gpuva_unlink_* functions). In Xe we almost certainly will have the GEM dma-resv lock when we touch this list so an extra lock here is redundant. Also it kinda goofy that caller owns the for drm_gpuva insertion / removal but not the locking for this list. You really mean having the dma-resv lock aquired or have a fence on the dma_resv obj? In Nouveau I map/unmap gpuvas in the ttm_device_funcs' move() callback. I only validate() and add a dma_resv fence to GEMs of new mappings. For unmap / remap operations I just take the GEMs gpuva list lock and check whether the GEM is evicted currently. If it is evicted currently (and hence unmapped) and I'm on a remap operation I can just do the update on the GPUVA space, since latest on the next EXEC ioctl() the corresponding GEM is validated and hence re-mapped correctly. If it's an unmap operation I just need to remove the GPUVA, since the corresponding mapping is already unmapped when it's GEM is evicted. If it's not evicted I proceed as usual. Anyway, drm_gpuva_insert() and drm_gpuva_remove() (was drm_gpuva_destroy() before) do *not* implicitly add the gpuva to the GEM's gpuva list anymore. Instead there is only drm_gpuva_link() and drm_gpuva_unlink(), not doing any lockdep checks, but clearly documenting that the caller is resposible to take care of mutual exclusion. WRT to Christian thoughts on a common uAPI rules for VM binds, I kinda like that idea but I don't think that is necessary. All of pur uAPI should be close but also the GPUVA implementation should be flexible enough to fit all of our needs and I think for the most part it is. Let me know what everything thinks about this. It would be great if when I'm back on 2/14 I can rebase the Xe port to GPUVA on another version of the GPUVA code and get sparse binding support implementation. Also I'd like to get GPUVA merged in the Xe repo ASAP as our VM bind code badly needed to be cleaned and this was the push we needed to make this
Re: [PATCH] drm/edid: Add Vive Pro 2 to non-desktop list
On 2/13/23 14:50, Jani Nikula wrote:
> On Mon, 13 Feb 2023, Dmitry Osipenko wrote:
>> On 2/13/23 12:56, Jani Nikula wrote:
>>> On Sun, 12 Feb 2023, Dmitry Osipenko wrote:
Hi,
On 1/18/22 20:00, Yaroslav Bolyukin wrote:
Add a brief commit message, describing a user-visible effect of this
patch. Tell that this change prevents exposing headset as a regular
display to the system, while it will work with SteamVR.
> Signed-off-by: Yaroslav Bolyukin
> ---
> drivers/gpu/drm/drm_edid.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 12893e7be..fdb8f0a6f 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -200,9 +200,10 @@ static const struct edid_quirk {
> EDID_QUIRK('V', 'L', 'V', 0x91be, EDID_QUIRK_NON_DESKTOP),
> EDID_QUIRK('V', 'L', 'V', 0x91bf, EDID_QUIRK_NON_DESKTOP),
>
> - /* HTC Vive and Vive Pro VR Headsets */
> + /* HTC Vive, Vive Pro and Vive Pro 2 VR Headsets */
Nit: I'd keep the original comment, or change it to a generic "HTC VR
Headsets" to prevent further comment changes
> EDID_QUIRK('H', 'V', 'R', 0xaa01, EDID_QUIRK_NON_DESKTOP),
> EDID_QUIRK('H', 'V', 'R', 0xaa02, EDID_QUIRK_NON_DESKTOP),
> + EDID_QUIRK('H', 'V', 'R', 0xaa04, EDID_QUIRK_NON_DESKTOP),
>
> /* Oculus Rift DK1, DK2, CV1 and Rift S VR Headsets */
> EDID_QUIRK('O', 'V', 'R', 0x0001, EDID_QUIRK_NON_DESKTOP),
>
> base-commit: 99613159ad749543621da8238acf1a122880144e
Please send the v2 patch with the added EDID for Cosmos VR and the
addressed comments. Thanks!
>>>
>>> Yeah, we'll need to EDID to check that it doesn't have the Microsoft
>>> VSDB to indicate non-desktop. See 2869f599c0d8 ("drm/edid: support
>>> Microsoft extension for HMDs and specialized monitors").
>>
>> Do you mean to skip using the EDID_QUIRK_NON_DESKTOP if MS VSDB entry
>> presents in the EDID?
>>
>> These HTC EDIDs don't have MS VSDB, otherwise the quirk wouldn't be needed.
>
> Okay, I didn't know that. I just observed that the original patch was
> sent before the the MS VSDB parsing was added.
This will be good to mention in the v2 commit message.
--
Best regards,
Dmitry
Re: Try to address the drm_debugfs issues
On Tue, Feb 14, 2023 at 10:28:24AM +0100, Christian König wrote: > Am 14.02.23 um 09:59 schrieb Stanislaw Gruszka: > > On Thu, Feb 09, 2023 at 09:18:35AM +0100, Christian König wrote: > > > Hello everyone, > > > > > > the drm_debugfs has a couple of well known design problems. > > > > > > Especially it wasn't possible to add files between initializing and > > > registering > > > of DRM devices since the underlying debugfs directory wasn't created yet. > > > > > > The resulting necessity of the driver->debugfs_init() callback function > > > is a > > > mid-layering which is really frowned on since it creates a horrible > > > driver->DRM->driver design layering. > > > > > > The recent patch "drm/debugfs: create device-centered debugfs functions" > > > tried > > > to address those problem, but doesn't seem to work correctly. This looks > > > like > > > a misunderstanding of the call flow around drm_debugfs_init(), which is > > > called > > > multiple times, once for the primary and once for the render node. > > > > > > So what happens now is the following: > > > > > > 1. drm_dev_init() initially allocates the drm_minor objects. > > > 2. ... back to the driver ... > > > 3. drm_dev_register() is called. > > > > > > 4. drm_debugfs_init() is called for the primary node. > > > 5. drm_framebuffer_debugfs_init(), drm_client_debugfs_init() and > > > drm_atomic_debugfs_init() call drm_debugfs_add_file(s)() to add the > > > files > > > for the primary node. > > > 6. The driver->debugfs_init() callback is called to add debugfs files for > > > the > > > primary node. > > > 7. The added files are consumed and added to the primary node debugfs > > > directory. > > > > > > 8. drm_debugfs_init() is called for the render node. > > > 9. drm_framebuffer_debugfs_init(), drm_client_debugfs_init() and > > > drm_atomic_debugfs_init() call drm_debugfs_add_file(s)() to add the > > > files > > > again for the render node. > > > 10. The driver->debugfs_init() callback is called to add debugfs files > > > for the > > > render node. > > > 11. The added files are consumed and added to the render node debugfs > > > directory. > > > > > > 12. Some more files are added through drm_debugfs_add_file(). > > > 13. drm_debugfs_late_register() add the files once more to the primary > > > node > > > debugfs directory. > > > 14. From this point on files added through drm_debugfs_add_file() are > > > simply ignored. > > > 15. ... back to the driver ... > > > > > > Because of this the dev->debugfs_mutex lock is also completely pointless > > > since > > > any concurrent use of the interface would just randomly either add the > > > files to > > > the primary or render node or just not at all. > > > > > > Even worse is that this implementation nails the coffin for removing the > > > driver->debugfs_init() mid-layering because otherwise drivers can't > > > control > > > where their debugfs (primary/render node) are actually added. > > > > > > This patch set here now tries to clean this up a bit, but most likely > > > isn't > > > fully complete either since I didn't audit every driver/call path. > > > > > > Please comment/discuss. > > What is end goal here regarding debugfs in DRM ? My undersigning is that > > the direction is get rid of debugfs_init callback as described in: > > https://cgit.freedesktop.org/drm/drm-misc/tree/Documentation/gpu/todo.rst#n511 > > and also make it driver/device-centric instead of minor-centric as > > described here: > > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=99845faae7099cd704ebf67514c1157c26960a > > > > Well my main goal is to get rid of the debugfs_init() mid-layering in the > mid term, everything else is just nice to have. > > > I'm asking from accel point of view. We can make things there as they > > should look like at the end for DRM, since currently no drivers have > > established their interfaces and they can be changed. > > > > Is drivers/device-centric mean we should use drm_dev->unique for debugfs > > dir entry name instead of minor ? > > Oh, good idea! That would also finally make it a bit less problematic to > figure out which PCI or platform device corresponds to which debugfs > directory. > > Only potential problem I see is that we would need to rename the directory > should a driver every decide to set drm_dev->unique to something else than > the default. But a quick check shows no users of drm_dev_set_unique(), so we > could potentially just unexport the function > > > Or perhaps we should have 2 separate dir entries: one (old dri/minor/) > > for device drm debugfs files and other one for driver specific files ? > > How about we just create symlinks between the old and the new directory for > now which we remove after everything has settled again? Yes, that would make perfect sense. However my idea was a bit different, that we have separate directories one for drm specific debugfs files (i.e. clints, framebuffer, gem, ... ) an
Re: [PATCH 06/10] drm/amd/display: Fix implicit enum conversion
On 2/13/23 21:49, Arthur Grillo wrote: > Make implicit enum conversion to avoid -Wenum-conversion warning, such > as: > > drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn21/display_mode_vba_21.c:4109:88: > warning: implicit conversion from ‘enum ’ to ‘enum > odm_combine_mode’ [-Wenum-conversion] > 4109 | > locals->ODMCombineEnablePerState[i][k] = true; > | > ^ > > [...] > > @@ -3897,14 +3898,14 @@ void > dml20_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_l > > mode_lib->vba.PlaneRequiredDISPCLKWithODMCombine = > mode_lib->vba.PixelClock[k] / 2 > * (1 + > mode_lib->vba.DISPCLKDPPCLKDSCCLKDownSpreading / 100.0); > > - locals->ODMCombineEnablePerState[i][k] = false; > + locals->ODMCombineEnablePerState[i][k] = (enum > odm_combine_mode)false; dm_odm_combine_mode_disabled would seem clearer than (enum odm_combine_mode)false. > - > locals->ODMCombineEnablePerState[i][k] = true; > + > locals->ODMCombineEnablePerState[i][k] = (enum odm_combine_mode)true; I'm not sure which enum value (enum odm_combine_mode)true will be converted to, probably dm_odm_combine_mode_2to1? Is that really appropriate everywhere true is used? If so, again dm_odm_combine_mode_2to1 would seem clearer. -- Earthling Michel Dänzer| https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
Re: [Intel-gfx] [PATCH 1/2] drm: Introduce plane SIZE_HINTS property
On Tue, Feb 14, 2023 at 01:17:45PM +0200, Pekka Paalanen wrote: > On Tue, 14 Feb 2023 12:27:45 +0200 > Ville Syrjälä wrote: > > > On Tue, Feb 14, 2023 at 11:42:27AM +0200, Pekka Paalanen wrote: > > > On Thu, 9 Feb 2023 13:51:05 +0200 > > > Pekka Paalanen wrote: > > > > > > > Maybe we could refine this so that userspace uses the stride and height > > > > implied by the caps for allocation, and then use the exact cursor image > > > > size for AddFB2? And have drivers pick any size between those two they > > > > can use. The kernel would need the userspace to promise that the > > > > padding is always zero-initialized, so the driver can simply scan out > > > > any area of the buffer it needs. > > > > > > > > Then we don't need SIZE_HINTS. > > > > > > Would there be any problem with this? > > > > > > If this works, it would seem the superior solution to me, because > > > userspace does not need to guess or test for the exact right size. > > > Simply allocate at the CAP size, pad the cursor image with transparent > > > pixels, and let the kernel scan out the optimal area. > > > > No, the hardware cannot scan out a smaller area because the > > stride will be wrong. > > In another email of yours you said that hardware requires stride to be > equivalent to the width. So it's not that hardware supports only > specific strides, it must equal to width. That's really unfortunate and > surprising. Yeah, probably some Windows legacy hangover that refuses to die. Ye olde Intel gen2 desktop chipsets (i845/i865) had a somewhat programmable stride for cursors (still POT, but could exceed the width), but the mobile chipsets (i830/i85x) did not. Unfortunately the mobile lineage won out and we've been stuck with this limitation ever since. -- Ville Syrjälä Intel
Re: [Freedreno] [PATCH 09/14] drm/msm/a6xx: Fix some A619 tunables
On 8.02.2023 19:21, Jordan Crouse wrote:
> On Thu, Jan 26, 2023 at 04:16:13PM +0100, Konrad Dybcio wrote:
>> Adreno 619 expects some tunables to be set differently. Make up for it.
>>
>> Fixes: b7616b5c69e6 ("drm/msm/adreno: Add A619 support")
>> Signed-off-by: Konrad Dybcio
>> ---
>> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
>> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
>> index 7a480705f407..f34ab3f39f09 100644
>> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
>> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
>> @@ -1171,6 +1171,8 @@ static int hw_init(struct msm_gpu *gpu)
>> gpu_write(gpu, REG_A6XX_PC_DBG_ECO_CNTL, 0x00200200);
>> else if (adreno_is_a650(adreno_gpu) || adreno_is_a660(adreno_gpu))
>> gpu_write(gpu, REG_A6XX_PC_DBG_ECO_CNTL, 0x00300200);
>> + else if (adreno_is_a619(adreno_gpu))
>> + gpu_write(gpu, REG_A6XX_PC_DBG_ECO_CNTL, 0x00018000);
>> else if (adreno_is_a610(adreno_gpu))
>> gpu_write(gpu, REG_A6XX_PC_DBG_ECO_CNTL, 0x0008);
>> else
>> @@ -1188,7 +1190,9 @@ static int hw_init(struct msm_gpu *gpu)
>> a6xx_set_ubwc_config(gpu);
>>
>> /* Enable fault detection */
>> - if (adreno_is_a610(adreno_gpu))
>> + if (adreno_is_a619(adreno_gpu))
>> + gpu_write(gpu, REG_A6XX_RBBM_INTERFACE_HANG_INT_CNTL, (1 <<
>> 30) | 0x3f);
>> + else if (adreno_is_a610(adreno_gpu))
>> gpu_write(gpu, REG_A6XX_RBBM_INTERFACE_HANG_INT_CNTL, (1 <<
>> 30) | 0x3);
>> else
>> gpu_write(gpu, REG_A6XX_RBBM_INTERFACE_HANG_INT_CNTL, (1 <<
>> 30) | 0x1f);
>
> The number appended to the register is the number of clock ticks to wait
> before declaring a hang. 0x3f happens to be the largest value that
> can be set for the a6xx family (excepting the 610 which, IIRC, used older
> hardware that had a smaller field for the counter).
Makes sense!
Downstream the
> number would creep up over time as unexplained hangs were discovered and
> diagnosed or covered up as "just wait longer".
lol..
>
> So in theory you could leave this with the "default value" or even bump
> up the default value to 0x3f for all targets if you wanted to. An
> alternate solution (that downstream does) is to put this as a
> pre-defined configuration in gpulist[].
I'm not sure it's a good idea to let things loose, as that may let some
bugs slip through.. Perhaps let's leave that as-is until we have a seriously
otherwise-unresolvable situation..
Konrad
>
> Jordan
Re: [PATCH v2 1/2] drm: Introduce plane SIZE_HINTS property
On Tue, Feb 14, 2023 at 12:01:49PM +0100, Jonas Ådahl wrote: > On Tue, Feb 14, 2023 at 12:28:44PM +0200, Ville Syrjälä wrote: > > On Tue, Feb 14, 2023 at 10:54:27AM +0100, Jonas Ådahl wrote: > > > On Tue, Feb 14, 2023 at 11:25:56AM +0200, Ville Syrjälä wrote: > > > > On Thu, Feb 09, 2023 at 03:16:23PM +0100, Jonas Ådahl wrote: > > > > > On Wed, Feb 08, 2023 at 11:10:16PM +0200, Ville Syrjala wrote: > > > > > > From: Ville Syrjälä > > > > > > > > > > > > Add a new immutable plane property by which a plane can advertise > > > > > > a handful of recommended plane sizes. This would be mostly exposed > > > > > > by cursor planes as a slightly more capable replacement for > > > > > > the DRM_CAP_CURSOR_WIDTH/HEIGHT caps, which can only declare > > > > > > a one size fits all limit for the whole device. > > > > > > > > > > > > Currently eg. amdgpu/i915/nouveau just advertize the max cursor > > > > > > size via the cursor size caps. But always using the max sized > > > > > > cursor can waste a surprising amount of power, so a better > > > > > > stragey is desirable. > > > > > > > > > > > > Most other drivers don't specify any cursor size at all, in > > > > > > which case the ioctl code just claims that 64x64 is a great > > > > > > choice. Whether that is actually true is debatable. > > > > > > > > > > > > A poll of various compositor developers informs us that > > > > > > blindly probing with setcursor/atomic ioctl to determine > > > > > > suitable cursor sizes is not acceptable, thus the > > > > > > introduction of the new property to supplant the cursor > > > > > > size caps. The compositor will now be free to select a > > > > > > more optimal cursor size from the short list of options. > > > > > > > > > > > > Note that the reported sizes (either via the property or the > > > > > > caps) make no claims about things such as plane scaling. So > > > > > > these things should only really be consulted for simple > > > > > > "cursor like" use cases. > > > > > > > > > > > > v2: Try to add some docs > > > > > > > > > > > > Cc: Simon Ser > > > > > > Cc: Jonas Ådahl > > > > > > Cc: Daniel Stone > > > > > > Cc: Pekka Paalanen > > > > > > Acked-by: Harry Wentland > > > > > > Signed-off-by: Ville Syrjälä > > > > > > --- > > > > > > drivers/gpu/drm/drm_mode_config.c | 7 + > > > > > > drivers/gpu/drm/drm_plane.c | 48 > > > > > > +++ > > > > > > include/drm/drm_mode_config.h | 5 > > > > > > include/drm/drm_plane.h | 4 +++ > > > > > > include/uapi/drm/drm_mode.h | 11 +++ > > > > > > 5 files changed, 75 insertions(+) > > > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_mode_config.c > > > > > > b/drivers/gpu/drm/drm_mode_config.c > > > > > > index 87eb591fe9b5..21860f94a18c 100644 > > > > > > --- a/drivers/gpu/drm/drm_mode_config.c > > > > > > +++ b/drivers/gpu/drm/drm_mode_config.c > > > > > > @@ -374,6 +374,13 @@ static int > > > > > > drm_mode_create_standard_properties(struct drm_device *dev) > > > > > > return -ENOMEM; > > > > > > dev->mode_config.modifiers_property = prop; > > > > > > > > > > > > + prop = drm_property_create(dev, > > > > > > + DRM_MODE_PROP_IMMUTABLE | > > > > > > DRM_MODE_PROP_BLOB, > > > > > > + "SIZE_HINTS", 0); > > > > > > + if (!prop) > > > > > > + return -ENOMEM; > > > > > > + dev->mode_config.size_hints_property = prop; > > > > > > + > > > > > > return 0; > > > > > > } > > > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_plane.c > > > > > > b/drivers/gpu/drm/drm_plane.c > > > > > > index 24e7998d1731..ae51b1f83755 100644 > > > > > > --- a/drivers/gpu/drm/drm_plane.c > > > > > > +++ b/drivers/gpu/drm/drm_plane.c > > > > > > @@ -140,6 +140,21 @@ > > > > > > * DRM_FORMAT_MOD_LINEAR. Before linux kernel release v5.1 > > > > > > there have been > > > > > > * various bugs in this area with inconsistencies between the > > > > > > capability > > > > > > * flag and per-plane properties. > > > > > > + * > > > > > > + * SIZE_HINTS: > > > > > > + * Blob property which contains the set of recommended plane > > > > > > size > > > > > > + * which can used for simple "cursor like" use cases (eg. no > > > > > > scaling). > > > > > > + * Using these hints frees userspace from extensive probing of > > > > > > + * supported plane sizes through atomic/setcursor ioctls. > > > > > > + * > > > > > > + * For optimal usage userspace should pick the smallest size > > > > > > + * that satisfies its own requirements. > > > > > > + * > > > > > > + * The blob contains an array of struct drm_plane_size_hint. > > > > > > + * > > > > > > + * Drivers should only attach this property to planes that > > > > > > + * support a very limited set of sizes (eg. cursor planes > > > > > > + * on typical hardware). > > > > > > > > > > This is a bit awkward since problematic drivers wo
