Re: [PATCHv1 0/4] panel-dsi-cm: update bindings
Hi Sebastian. On Tue, Jun 30, 2020 at 12:33:11AM +0200, Sebastian Reichel wrote: > Subject: panel-dsi-cm: update bindings > > The cleanup series for omapdrm's DSI code got too big. Reviewing > this is not fun and the same goes for keeping track of the change > requests. Let's do the cleanup in smaller steps instead. Appreciated! Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv1 1/4] dt-bindings: display: panel-dsi-cm: convert to YAML
Hi Sebastian.
On Tue, Jun 30, 2020 at 12:33:12AM +0200, Sebastian Reichel wrote:
> Convert panel-dsi-cm bindings to YAML and add
> missing properties while at it.
>
> Signed-off-by: Sebastian Reichel
Thanks, one of the few panel bindings still pending.
And you added some nice explanations too, good.
Some small comments in the folllowing.
Sam
> ---
> .../bindings/display/panel/panel-dsi-cm.txt | 29 -
> .../bindings/display/panel/panel-dsi-cm.yaml | 100 ++
> 2 files changed, 100 insertions(+), 29 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/display/panel/panel-dsi-cm.txt
> create mode 100644
> Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.txt
> b/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.txt
> deleted file mode 100644
> index dce48eb9db57..
> --- a/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.txt
> +++ /dev/null
> @@ -1,29 +0,0 @@
> -Generic MIPI DSI Command Mode Panel
> -===
> -
> -Required properties:
> -- compatible: "panel-dsi-cm"
> -
> -Optional properties:
> -- label: a symbolic name for the panel
> -- reset-gpios: panel reset gpio
> -- te-gpios: panel TE gpio
> -
> -Required nodes:
> -- Video port for DSI input
> -
> -Example
>
> -
> -lcd0: display {
> - compatible = "tpo,taal", "panel-dsi-cm";
> - label = "lcd0";
> -
> - reset-gpios = < 6 GPIO_ACTIVE_HIGH>;
> -
> - port {
> - lcd0_in: endpoint {
> - remote-endpoint = <_out_ep>;
> - };
> - };
> -};
> diff --git
> a/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml
> b/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml
> new file mode 100644
> index ..8d6a20f26470
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml
> @@ -0,0 +1,100 @@
> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/panel-dsi-cm.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: DSI command mode panels
> +
> +maintainers:
> + - Tomi Valkeinen
> + - Sebastian Reichel
> +
> +description: |
> + This binding file is a collection of the DSI panels that
> + are usually driven in command mode. If no backlight is
> + referenced via the optional backlight property, the DSI
> + panel is assumed to have native backlight support.
> + The panel may use an OF graph binding for the association
> + to the display, or it may be a direct child node of the
> + display.
Later port: is required which does not really match this explanation.
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> +
> + compatible:
> +items:
> + - enum:
> +- motorola,droid4-panel# Panel from Motorola Droid4 phone
> +- nokia,himalaya # Panel from Nokia N950 phone
> +- tpo,taal # Panel from OMAP4 SDP board
> + - const: panel-dsi-cm# Generic DSI command mode panel
> compatible fallback
> +
> + reg:
> +maxItems: 1
> +description: DSI virtual channel
> +
> + vddi-supply:
> +description:
> + Display panels require power to be supplied. While several panels need
> + more than one power supply with panel-specific constraints governing
> the
> + order and timings of the power supplies, in many cases a single power
> + supply is sufficient, either because the panel has a single power
> rail, or
> + because all its power rails can be driven by the same supply. In that
> case
> + the vddi-supply property specifies the supply powering the panel as a
> + phandle to a regulator.
> +
> + vpnl-supply:
> +description:
> + When the display panel needs a second power supply, this property can
> be
> + used in addition to vddi-supply. Both supplies will be enabled at the
> + same time before the panel is being accessed.
> +
> + width-mm: true
> + height-mm: true
> + label: true
> + rotation: true
> + panel-timing: true
> + port: true
> + reset-gpios: true
> + te-gpios: true
> + backlight: true
> +
> +additionalProperties: false
> +
> +required:
> + - compatible
> + - port
> + - reg
> +
> +examples:
My personal preference is indent 4 spaces.
But there is no hard rule so do what you like.
> + - |
> +#include
> +
> +dsi-controller {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port {
> +dsi1_out_ep: endpoint {
> + remote-endpoint = <_in>;
> + lanes = <0 1 2 3 4 5>;
> +};
> + };
Addding the port node here does not really help me,
I was left confused about the lanes = <...> property.
> +
> + panel@0 {
> +compatible = "tpo,taal", "panel-dsi-cm";
> +
Re: [PATCH 0/2] drm/msm/a6xx: add A640/A650 hwcg
On Mon, Jun 29, 2020 at 4:49 PM Jonathan Marek wrote: > > Initialize hardware clock-gating registers on A640 and A650 GPUs. > > I put the hwcg tables in adreno_device.c, but maybe it makes more > sense to keep them in a6xx_gpu.c? (this would allow switching a5xx > to use the gpulist too.. it isn't possible to include both a6xx.xml.h > and a5xx.xml.h in adreno_device.c) yeah, I've kinda tried to avoid "crossing the streams".. maybe these should move to adreno_gpu BR, -R > > Jonathan Marek (2): > drm/msm/a6xx: hwcg tables in gpulist > drm/msm/a6xx: add A640/A650 hwcg > > drivers/gpu/drm/msm/adreno/a6xx.xml.h | 8 + > drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 140 ++--- > drivers/gpu/drm/msm/adreno/adreno_device.c | 219 + > drivers/gpu/drm/msm/adreno/adreno_gpu.h| 7 + > 4 files changed, 251 insertions(+), 123 deletions(-) > > -- > 2.26.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/9] drm/simplekms: Initialize framebuffer data from device-tree node
On Thu, Jun 25, 2020 at 6:00 AM Thomas Zimmermann wrote:
>
> A firmware framebuffer might also be specified via device-tree files. If
> no device platform data is given, try the DT device node.
You are missing a DT match table for driver matching and module
loading (if a module is supported).
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/tiny/simplekms.c | 84
> 1 file changed, 84 insertions(+)
>
> diff --git a/drivers/gpu/drm/tiny/simplekms.c
> b/drivers/gpu/drm/tiny/simplekms.c
> index ac2ebfcedd22..87636307aa4f 100644
> --- a/drivers/gpu/drm/tiny/simplekms.c
> +++ b/drivers/gpu/drm/tiny/simplekms.c
> @@ -113,6 +113,76 @@ simplefb_get_format_pd(struct drm_device *dev,
> return simplefb_get_validated_format(dev, pd->format);
> }
>
> +static int
> +simplefb_read_u32_of(struct drm_device *dev, struct device_node *of_node,
> +const char* name, u32 *value)
> +{
> + int ret = of_property_read_u32(of_node, name, value);
> + if (ret)
> + drm_err(dev, "simplefb: can't parse framebuffer %s: error
> %d\n",
> + name, ret);
> + return ret;
> +}
> +
> +static int
> +simplefb_read_string_of(struct drm_device *dev, struct device_node *of_node,
> + const char* name, const char **value)
> +{
> + int ret = of_property_read_string(of_node, name, value);
> + if (ret)
> + drm_err(dev, "simplefb: can't parse framebuffer %s: error
> %d\n",
> + name, ret);
> + return ret;
> +}
> +
> +static int
> +simplefb_get_width_of(struct drm_device *dev, struct device_node *of_node)
> +{
> + int ret;
> + u32 width;
> +
> + ret = simplefb_read_u32_of(dev, of_node, "width", );
> + if (ret)
> + return ret;
> + return simplefb_get_validated_int0(dev, "width", width);
> +}
> +
> +static int
> +simplefb_get_height_of(struct drm_device *dev, struct device_node *of_node)
> +{
> + int ret;
> + u32 height;
> +
> + ret = simplefb_read_u32_of(dev, of_node, "height", );
> + if (ret)
> + return ret;
> + return simplefb_get_validated_int0(dev, "height", height);
> +}
> +
> +static int
> +simplefb_get_stride_of(struct drm_device *dev, struct device_node *of_node)
> +{
> + int ret;
> + u32 stride;
> +
> + ret = simplefb_read_u32_of(dev, of_node, "stride", );
> + if (ret)
> + return ret;
> + return simplefb_get_validated_int(dev, "stride", stride);
> +}
> +
> +static const struct drm_format_info *
> +simplefb_get_format_of(struct drm_device *dev, struct device_node *of_node)
> +{
> + int ret;
> + const char *format;
> +
> + ret = simplefb_read_string_of(dev, of_node, "format", );
> + if (ret)
> + return ERR_PTR(ret);
> + return simplefb_get_validated_format(dev, format);
> +}
> +
> /*
> * Simple Framebuffer device
> */
> @@ -163,6 +233,7 @@ static int simplekms_device_init_fb(struct
> simplekms_device *sdev)
> struct drm_device *dev = >dev;
> struct platform_device *pdev = sdev->pdev;
> const struct simplefb_platform_data *pd =
> dev_get_platdata(>dev);
> + struct device_node *of_node = pdev->dev.of_node;
>
> if (pd) {
> width = simplefb_get_width_pd(dev, pd);
> @@ -177,6 +248,19 @@ static int simplekms_device_init_fb(struct
> simplekms_device *sdev)
> format = simplefb_get_format_pd(dev, pd);
> if (IS_ERR(format))
> return PTR_ERR(format);
> + } else if (of_node) {
> + width = simplefb_get_width_of(dev, of_node);
> + if (width < 0)
> + return width;
> + height = simplefb_get_height_of(dev, of_node);
> + if (height < 0)
> + return height;
> + stride = simplefb_get_stride_of(dev, of_node);
> + if (stride < 0)
> + return stride;
> + format = simplefb_get_format_of(dev, of_node);
> + if (IS_ERR(format))
> + return PTR_ERR(format);
> } else {
> drm_err(dev, "no simplefb configuration found\n");
> return -ENODEV;
> --
> 2.27.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 9/9] drm/simplekms: Acquire memory aperture for framebuffer
On Mon, Jun 29, 2020 at 10:04 AM Greg KH wrote:
>
> On Mon, Jun 29, 2020 at 11:22:30AM +0200, Daniel Vetter wrote:
> > On Thu, Jun 25, 2020 at 02:00:11PM +0200, Thomas Zimmermann wrote:
> > > We register the simplekms device with the DRM platform helpers. A
> > > native driver for the graphics hardware will kickout the simplekms
> > > driver before taking over the device.
> > >
> > > Signed-off-by: Thomas Zimmermann
> > > ---
> > > drivers/gpu/drm/tiny/Kconfig | 1 +
> > > drivers/gpu/drm/tiny/simplekms.c | 94 +++-
> > > 2 files changed, 92 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
> > > index 50dbde8bdcb2..a47ed337a7fe 100644
> > > --- a/drivers/gpu/drm/tiny/Kconfig
> > > +++ b/drivers/gpu/drm/tiny/Kconfig
> > > @@ -33,6 +33,7 @@ config DRM_SIMPLEKMS
> > > depends on DRM
> > > select DRM_GEM_SHMEM_HELPER
> > > select DRM_KMS_HELPER
> > > + select DRM_PLATFORM_HELPER
> > > help
> > > DRM driver for simple platform-provided framebuffers.
> > >
> > > diff --git a/drivers/gpu/drm/tiny/simplekms.c
> > > b/drivers/gpu/drm/tiny/simplekms.c
> > > index ae5d3cbadbe8..a903a4e0100a 100644
> > > --- a/drivers/gpu/drm/tiny/simplekms.c
> > > +++ b/drivers/gpu/drm/tiny/simplekms.c
> > > @@ -5,6 +5,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > >
> > > #include
> > > #include
> > > @@ -17,6 +18,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > >
> > > @@ -36,6 +38,12 @@
> > > #define SIMPLEKMS_MODE(hd, vd) \
> > > DRM_SIMPLE_MODE(hd, vd, RES_MM(hd), RES_MM(vd))
> > >
> > > +/*
> > > + * Protects the platform device's drvdata against
> > > + * concurrent manipulation.
> > > + */
> > > +static DEFINE_SPINLOCK(simplekms_drvdata_lock);
> > > +
> > > /*
> > > * Helpers for simplefb
> > > */
> > > @@ -211,6 +219,7 @@ struct simplekms_device {
> > > unsigned int pitch;
> > >
> > > /* memory management */
> > > + struct drm_aperture *aperture;
> > > struct resource *mem;
> > > void __iomem *screen_base;
> > >
> > > @@ -224,6 +233,8 @@ static struct simplekms_device
> > > *simplekms_device_of_dev(struct drm_device *dev)
> > > return container_of(dev, struct simplekms_device, dev);
> > > }
> > >
> > > +static void simplekms_device_cleanup(struct simplekms_device *sdev);
> > > +
> > > /*
> > > * Hardware
> > > */
> > > @@ -514,22 +525,72 @@ static int simplekms_device_init_fb(struct
> > > simplekms_device *sdev)
> > > * Memory management
> > > */
> > >
> > > +static void simplekms_aperture_kickout(struct drm_aperture *ap)
> > > +{
> > > + struct drm_device *dev = ap->dev;
> > > + struct simplekms_device *sdev = simplekms_device_of_dev(dev);
> > > + struct platform_device *pdev = sdev->pdev;
> > > +
> > > + if (WARN_ON(!sdev->aperture))
> > > + return; /* BUG: driver already got kicked out */
> > > +
> > > + drm_dev_unregister(dev);
> >
> > >From a semantic pov I think the platform driver getting kicked out is more
> > like a hotunplug, so drm_dev_unplug(dev); here is imo better.
> >
> > That then also gives you a nice drm_dev_enter/exit to sprinkle over the
> > various driver callbacks, instead of the racy ->aperture check reinvented
> > wheel here.
> >
> > I also wonder whether we couldn't go full driver model for these platform
> > devices, and instead of this here call a core driver model function to
> > force the unbding of the driver. Only change we'd need it that our
> > ->remove hook uses drm_dev_unplug().
>
> Yes, please do that. Or, use the "virtual bus/device" code that some
> people at Intel are still trying to get into mergable shape. See the
> posts on the netdev list for those details.
>
> Don't use platform devices for anything that is not actually a platform
> device (i.e. something described by hardware resources).
Well, 'simple-framebuffer' is described by DT and includes h/w
resources such as clocks. So this is a gray area. I'm not saying we
couldn't use virtual bus for DT nodes, but we'll need some clear
guidelines of when to use virtual vs. platform devices. No doubt I'll
get a 'virtual bus' binding if folks are directed to make things a
virtual device.
Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: display: arm: versatile: Pass the sysreg unit name
On Mon, 29 Jun 2020 18:55:00 -0300, Fabio Estevam wrote: > Pass the sysreg unit name to fix the following warning seen with > 'make dt_binding_check': > > Warning (unit_address_vs_reg): /example-0/sysreg: node has a reg or ranges > property, but no unit name > > Signed-off-by: Fabio Estevam > --- > .../bindings/display/panel/arm,versatile-tft-panel.yaml | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Applied, thanks! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/gvt/handlers.c
between commit:
fc1e3aa0337c ("drm/i915/gvt: Fix incorrect check of enabled bits in mask
registers")
from the drm-intel-fixes tree and commit:
5f4ae2704d59 ("drm/i915: Identify Cometlake platform")
from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/i915/gvt/handlers.c
index fadd2adb8030,26cae4846c82..
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@@ -1731,8 -1734,9 +1734,9 @@@ static int ring_mode_mmio_write(struct
return 0;
}
- if (IS_COFFEELAKE(vgpu->gvt->gt->i915) &&
+ if ((IS_COFFEELAKE(vgpu->gvt->gt->i915) ||
+IS_COMETLAKE(vgpu->gvt->gt->i915)) &&
- data & _MASKED_BIT_ENABLE(2)) {
+ IS_MASKED_BITS_ENABLED(data, 2)) {
enter_failsafe_mode(vgpu, GVT_FAILSAFE_UNSUPPORTED_GUEST);
return 0;
}
pgpYROwFA0DU7.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/4] dt-bindings: display: renesas: lvds: RZ/G2E needs renesas,companion too
Hi Sam, On Mon, Jun 29, 2020 at 10:11:40AM +0200, Sam Ravnborg wrote: > On Thu, May 14, 2020 at 08:44:19AM +0200, Geert Uytterhoeven wrote: > > On Thu, May 14, 2020 at 1:39 AM Laurent Pinchart wrote: > > > From: Fabrizio Castro > > > > > > Document RZ/G2E support for property renesas,companion. > > > > > > Signed-off-by: Fabrizio Castro > > > Reviewed-by: Laurent Pinchart > > > Signed-off-by: Laurent Pinchart > > > > > > > > --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml > > > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml > > > @@ -81,9 +81,9 @@ properties: > > > $ref: /schemas/types.yaml#/definitions/phandle > > > description: > > >phandle to the companion LVDS encoder. This property is mandatory > > > - for the first LVDS encoder on D3 and E3 SoCs, and shall point to > > > - the second encoder to be used as a companion in dual-link mode. It > > > - shall not be set for any other LVDS encoder. > > > + for the first LVDS encoder on D3, R-Car E3 and RZ/G2E SoCs, and > > > shall > > > > R-Car D3 and E3, and RZ/G2E SoCs > > > > > + point to the second encoder to be used as a companion in dual-link > > > mode. > > > + It shall not be set for any other LVDS encoder. > > Laurent, I assume you will re-spin a ne version wth the changelog > corrected. Yes I will. Thanks for checking. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1.2 4/4] dt-bindings: display: bridge: renesas, lvds: Convert binding to YAML
Hi Sam,
On Mon, Jun 29, 2020 at 10:10:01AM +0200, Sam Ravnborg wrote:
> On Fri, May 15, 2020 at 12:42:11AM +0300, Laurent Pinchart wrote:
> > Convert the Renesas R-Car LVDS encoder text binding to YAML.
> >
> > Signed-off-by: Laurent Pinchart
> > Acked-by: Maxime Ripard
> > ---
> > Changes since v1:
> >
> > - Mention RZ/G1 and R2/G2 explicitly
> > - Drop the part numbers in comments, only keep the SoC names
> > - Use one address and size cell in the examples
>
> Seems this was not picked up so I went ahead and applied to
> drm-misc-next.
I was planning to send a pull request with other DT bindings conversion,
but merging it earlier is better :-) Thank you.
> > ---
> > .../bindings/display/bridge/renesas,lvds.txt | 85 --
> > .../bindings/display/bridge/renesas,lvds.yaml | 248 ++
> > 2 files changed, 248 insertions(+), 85 deletions(-)
> > delete mode 100644
> > Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > deleted file mode 100644
> > index c62ce2494ed9..
> > --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > +++ /dev/null
> > @@ -1,85 +0,0 @@
> > -Renesas R-Car LVDS Encoder
> > -==
> > -
> > -These DT bindings describe the LVDS encoder embedded in the Renesas R-Car
> > -Gen2, R-Car Gen3 and RZ/G SoCs.
> > -
> > -Required properties:
> > -
> > -- compatible : Shall contain one of
> > - - "renesas,r8a7743-lvds" for R8A7743 (RZ/G1M) compatible LVDS encoders
> > - - "renesas,r8a7744-lvds" for R8A7744 (RZ/G1N) compatible LVDS encoders
> > - - "renesas,r8a774a1-lvds" for R8A774A1 (RZ/G2M) compatible LVDS encoders
> > - - "renesas,r8a774b1-lvds" for R8A774B1 (RZ/G2N) compatible LVDS encoders
> > - - "renesas,r8a774c0-lvds" for R8A774C0 (RZ/G2E) compatible LVDS encoders
> > - - "renesas,r8a7790-lvds" for R8A7790 (R-Car H2) compatible LVDS encoders
> > - - "renesas,r8a7791-lvds" for R8A7791 (R-Car M2-W) compatible LVDS
> > encoders
> > - - "renesas,r8a7793-lvds" for R8A7793 (R-Car M2-N) compatible LVDS
> > encoders
> > - - "renesas,r8a7795-lvds" for R8A7795 (R-Car H3) compatible LVDS encoders
> > - - "renesas,r8a7796-lvds" for R8A7796 (R-Car M3-W) compatible LVDS
> > encoders
> > - - "renesas,r8a77965-lvds" for R8A77965 (R-Car M3-N) compatible LVDS
> > encoders
> > - - "renesas,r8a77970-lvds" for R8A77970 (R-Car V3M) compatible LVDS
> > encoders
> > - - "renesas,r8a77980-lvds" for R8A77980 (R-Car V3H) compatible LVDS
> > encoders
> > - - "renesas,r8a77990-lvds" for R8A77990 (R-Car E3) compatible LVDS
> > encoders
> > - - "renesas,r8a77995-lvds" for R8A77995 (R-Car D3) compatible LVDS
> > encoders
> > -
> > -- reg: Base address and length for the memory-mapped registers
> > -- clocks: A list of phandles + clock-specifier pairs, one for each entry in
> > - the clock-names property.
> > -- clock-names: Name of the clocks. This property is model-dependent.
> > - - The functional clock, which mandatory for all models, shall be listed
> > -first, and shall be named "fck".
> > - - On R8A77990, R8A77995 and R8A774C0, the LVDS encoder can use the EXTAL
> > or
> > -DU_DOTCLKINx clocks. Those clocks are optional. When supplied they
> > must be
> > -named "extal" and "dclkin.x" respectively, with "x" being the
> > DU_DOTCLKIN
> > -numerical index.
> > - - When the clocks property only contains the functional clock, the
> > -clock-names property may be omitted.
> > -- resets: A phandle + reset specifier for the module reset
> > -
> > -Required nodes:
> > -
> > -The LVDS encoder has two video ports. Their connections are modelled using
> > the
> > -OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> > -
> > -- Video port 0 corresponds to the parallel RGB input
> > -- Video port 1 corresponds to the LVDS output
> > -
> > -Each port shall have a single endpoint.
> > -
> > -Optional properties:
> > -
> > -- renesas,companion : phandle to the companion LVDS encoder. This property
> > is
> > - mandatory for the first LVDS encoder on D3 and E3 SoCs, and shall point
> > to
> > - the second encoder to be used as a companion in dual-link mode. It shall
> > not
> > - be set for any other LVDS encoder.
> > -
> > -
> > -Example:
> > -
> > - lvds0: lvds@feb9 {
> > - compatible = "renesas,r8a77990-lvds";
> > - reg = <0 0xfeb9 0 0x20>;
> > - clocks = < CPG_MOD 727>;
> > - power-domains = < R8A77990_PD_ALWAYS_ON>;
> > - resets = < 727>;
> > -
> > - renesas,companion = <>;
> > -
> > - ports {
> > - #address-cells = <1>;
> > - #size-cells = <0>;
> > -
> > -
[PATCH v2 3/4] drm: panel: simple: Drop drive/sample bus flags for LVDS panels
The DRM bus flags reporting on which clock edge the pixel data and sync
signals are sampled or driven don't make sense for LVDS panels, as the
bus then uses sub-clock timings to send data. Drop those flags and add a
warning in the probe function to make sure the mistake won't be
repeated.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- White list flags instead of black listing them
---
drivers/gpu/drm/panel/panel-simple.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index c659d8262e5c..cd416376bf71 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -549,6 +549,14 @@ static int panel_simple_probe(struct device *dev, const
struct panel_desc *desc)
panel_simple_parse_panel_timing_node(dev, panel, );
}
+ if (desc->connector_type == DRM_MODE_CONNECTOR_LVDS)
+ /* Catch common mistakes for LVDS panels. */
+ WARN_ON(desc->bus_flags &
+ ~(DRM_BUS_FLAG_DE_LOW |
+ DRM_BUS_FLAG_DE_HIGH |
+ DRM_BUS_FLAG_DATA_MSB_TO_LSB |
+ DRM_BUS_FLAG_DATA_LSB_TO_MSB));
+
drm_panel_init(>base, dev, _simple_funcs,
desc->connector_type);
@@ -688,7 +696,7 @@ static const struct panel_desc auo_b101aw03 = {
.height = 125,
},
.bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
- .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
@@ -1398,7 +1406,7 @@ static const struct panel_desc chunghwa_claa070wp03xg = {
.height = 150,
},
.bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
- .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
@@ -1423,7 +1431,7 @@ static const struct panel_desc chunghwa_claa101wa01a = {
.height = 120,
},
.bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
- .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
@@ -1448,7 +1456,7 @@ static const struct panel_desc chunghwa_claa101wb01 = {
.height = 125,
},
.bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
- .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
@@ -2123,7 +2131,7 @@ static const struct panel_desc innolux_n156bge_l21 = {
.height = 193,
},
.bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
- .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
@@ -2256,7 +2264,7 @@ static const struct panel_desc koe_tx26d202vm0bwa = {
.disable = 1000,
},
.bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
- .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
@@ -2497,9 +2505,7 @@ static const struct panel_desc logictechno_lt170410_2whc
= {
.height = 136,
},
.bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
- .bus_flags = DRM_BUS_FLAG_DE_HIGH |
-DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE |
-DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
@@ -3072,7 +3078,7 @@ static const struct panel_desc samsung_ltn101nt05 = {
.height = 125,
},
.bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
- .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
@@ -3512,7 +3518,7 @@ static const struct panel_desc toshiba_lt089ac29000 = {
.height = 116,
},
.bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA,
- .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/4] drm: panel: simple: Correct connector type for Starry KR070PE2T
The Starry KR070PE2T panel is a DPI panel, not and LVDS panel. Fix its
connector type.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index bff1cab529d2..ac6e8d55a3a2 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3320,7 +3320,7 @@ static const struct panel_desc starry_kr070pe2t = {
},
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
- .connector_type = DRM_MODE_CONNECTOR_LVDS,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
};
static const struct drm_display_mode starry_kr122ea0sra_mode = {
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/4] drm: panel: simple: Correct bus format for Satoz SAT050AT40H12R2
The Satoz SAT050AT40H12R2 panel is an LVDS panel, the
MEDIA_BUS_FMT_RGB888_1X24 bus format is thus incorrect. Set it to the
correct value MEDIA_BUS_FMT_RGB888_1X7X4_SPWG.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index ac6e8d55a3a2..c659d8262e5c 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3118,7 +3118,7 @@ static const struct panel_desc satoz_sat050at40h12r2 = {
.width = 108,
.height = 65,
},
- .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/4] drm: panel: simple: Fix mistakes in panel descriptions
Hello, This small patch series is the second version of what has been previously submitted as "[PATCH] drm: panel: simple: Drop drive/sample bus flags for LVDS panels". It fixes incorrect bus format and connector type in the description of two panels (patches 1/4 and 2/4), drop invalid bus flags for LVDS panels (patch 3/4), and add a warning to catch invalid bus formats for future LVDS panels. Laurent Pinchart (4): drm: panel: simple: Correct connector type for Starry KR070PE2T drm: panel: simple: Correct bus format for Satoz SAT050AT40H12R2 drm: panel: simple: Drop drive/sample bus flags for LVDS panels drm: panel: simple: Warn in case of incorrect bus format for LVDS panels drivers/gpu/drm/panel/panel-simple.c | 41 +++- 1 file changed, 28 insertions(+), 13 deletions(-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/4] drm: panel: simple: Warn in case of incorrect bus format for LVDS panels
Only the MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
MEDIA_BUS_FMT_RGB888_1X7X4_SPWG and MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA bus
formats are valid for LVDS panels. Warn at probe time to catch the
common mistake of using an incorrect format, as well as discrepancies
between the bus format and the reported bpc.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/panel/panel-simple.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index cd416376bf71..3a35f74d6cb7 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -549,13 +549,22 @@ static int panel_simple_probe(struct device *dev, const
struct panel_desc *desc)
panel_simple_parse_panel_timing_node(dev, panel, );
}
- if (desc->connector_type == DRM_MODE_CONNECTOR_LVDS)
+ if (desc->connector_type == DRM_MODE_CONNECTOR_LVDS) {
/* Catch common mistakes for LVDS panels. */
WARN_ON(desc->bus_flags &
~(DRM_BUS_FLAG_DE_LOW |
DRM_BUS_FLAG_DE_HIGH |
DRM_BUS_FLAG_DATA_MSB_TO_LSB |
DRM_BUS_FLAG_DATA_LSB_TO_MSB));
+ WARN_ON(desc->bus_format != MEDIA_BUS_FMT_RGB666_1X7X3_SPWG &&
+ desc->bus_format != MEDIA_BUS_FMT_RGB888_1X7X4_SPWG &&
+ desc->bus_format != MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA);
+ WARN_ON(desc->bus_format == MEDIA_BUS_FMT_RGB666_1X7X3_SPWG &&
+ desc->bpc != 6);
+ WARN_ON((desc->bus_format == MEDIA_BUS_FMT_RGB888_1X7X4_SPWG ||
+desc->bus_format == MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA)
&&
+ desc->bpc != 8);
+ }
drm_panel_init(>base, dev, _simple_funcs,
desc->connector_type);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 1/7] of_graph: add of_graph_presents()
On Thu, Jun 18, 2020 at 01:26:57AM +0300, Dmitry Osipenko wrote:
> In some case, like a DRM display code for example, it's useful to silently
> check whether port node exists at all in a device-tree before proceeding
> with parsing of the graph.
>
> This patch adds of_graph_presents() that returns true if given device-tree
> node contains OF graph port.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/of/property.c| 52 +---
> include/linux/of_graph.h | 6 +
> 2 files changed, 49 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/of/property.c b/drivers/of/property.c
> index 1f2086f4e7ce..b84ed6a7cf50 100644
> --- a/drivers/of/property.c
> +++ b/drivers/of/property.c
> @@ -29,6 +29,48 @@
>
> #include "of_private.h"
>
> +/**
> + * of_graph_get_first_local_port() - get first local port node
> + * @node: pointer to a local endpoint device_node
> + *
> + * Return: First local port node associated with local endpoint node linked
> + * to @node. Use of_node_put() on it when done.
> + */
> +static struct device_node *
> +of_graph_get_first_local_port(const struct device_node *node)
> +{
> + struct device_node *ports, *port;
> +
> + ports = of_get_child_by_name(node, "ports");
> + if (ports)
> + node = ports;
> +
> + port = of_get_child_by_name(node, "port");
> + of_node_put(ports);
> +
> + return port;
> +}
> +
> +/**
> + * of_graph_presents() - check graph's presence
> + * @node: pointer to a device_node checked for the graph's presence
> + *
> + * Return: True if @node has a port or ports sub-node, false otherwise.
> + */
> +bool of_graph_presents(const struct device_node *node)
of_graph_is_present
Otherwise,
Reviewed-by: Rob Herring
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau/kms/nvd9-: Fix disabling CRCs alongside OR reprogramming
While I had thought I'd tested this before, it looks like this one issue
slipped by my original CRC patches. Basically, there seem to be a few
rules we need to follow when sending CRC commands to the display
controller:
* CRCs cannot be both disabled and enabled for a single head in the same
flush
* If a head with CRC reporting enabled switches from one OR to another,
there must be a flush before the OR is re-enabled regardless of the
final state of CRC reporting.
So, split nv50_crc_atomic_prepare_notifier_contexts() into two
functions:
* nv_crc_atomic_release_notifier_contexts() - checks whether the CRC
notifier contexts were released successfully after the first flush
* nv_crc_atomic_init_notifier_contexts() - prepares any CRC notifier
contexts for use before enabling reporting
Additionally, in order to force a flush when we re-assign ORs with heads
that have CRCs enabled we split our atomic check function into two:
* nv50_crc_atomic_check_head() - called from our heads' atomic checks,
determines whether a state needs to set or clear CRC reporting
* nv50_crc_atomic_check_outp() - called at the end of the atomic check
after all ORs have been added to the atomic state, and sets
nv50_atom->flush_disable if needed
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/crc.c | 107
drivers/gpu/drm/nouveau/dispnv50/crc.h | 18 ++--
drivers/gpu/drm/nouveau/dispnv50/disp.c | 13 ++-
drivers/gpu/drm/nouveau/dispnv50/head.c | 2 +-
4 files changed, 97 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/crc.c
b/drivers/gpu/drm/nouveau/dispnv50/crc.c
index 0b18d9e3a2b96..f17fb6d56757a 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/crc.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/crc.c
@@ -261,7 +261,29 @@ void nv50_crc_atomic_stop_reporting(struct
drm_atomic_state *state)
}
}
-void nv50_crc_atomic_prepare_notifier_contexts(struct drm_atomic_state *state)
+void nv50_crc_atomic_init_notifier_contexts(struct drm_atomic_state *state)
+{
+ struct drm_crtc_state *new_crtc_state;
+ struct drm_crtc *crtc;
+ int i;
+
+ for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
+ struct nv50_head *head = nv50_head(crtc);
+ struct nv50_head_atom *asyh = nv50_head_atom(new_crtc_state);
+ struct nv50_crc *crc = >crc;
+ int i;
+
+ if (!asyh->set.crc)
+ continue;
+
+ crc->entry_idx = 0;
+ crc->ctx_changed = false;
+ for (i = 0; i < ARRAY_SIZE(crc->ctx); i++)
+ nv50_crc_reset_ctx(>ctx[i]);
+ }
+}
+
+void nv50_crc_atomic_release_notifier_contexts(struct drm_atomic_state *state)
{
const struct nv50_crc_func *func =
nv50_disp(state->dev)->core->func->crc;
@@ -274,22 +296,15 @@ void nv50_crc_atomic_prepare_notifier_contexts(struct
drm_atomic_state *state)
struct nv50_head_atom *asyh = nv50_head_atom(new_crtc_state);
struct nv50_crc *crc = >crc;
struct nv50_crc_notifier_ctx *ctx = >ctx[crc->ctx_idx];
- int i;
- if (asyh->clr.crc && asyh->crc.src) {
- if (crc->ctx_changed) {
- nv50_crc_wait_ctx_finished(head, func, ctx);
- ctx = >ctx[crc->ctx_idx ^ 1];
- }
- nv50_crc_wait_ctx_finished(head, func, ctx);
- }
+ if (!asyh->clr.crc)
+ continue;
- if (asyh->set.crc) {
- crc->entry_idx = 0;
- crc->ctx_changed = false;
- for (i = 0; i < ARRAY_SIZE(crc->ctx); i++)
- nv50_crc_reset_ctx(>ctx[i]);
+ if (crc->ctx_changed) {
+ nv50_crc_wait_ctx_finished(head, func, ctx);
+ ctx = >ctx[crc->ctx_idx ^ 1];
}
+ nv50_crc_wait_ctx_finished(head, func, ctx);
}
}
@@ -325,16 +340,13 @@ void nv50_crc_atomic_start_reporting(struct
drm_atomic_state *state)
}
}
-int nv50_crc_atomic_check(struct nv50_head *head,
- struct nv50_head_atom *asyh,
- struct nv50_head_atom *armh)
+int nv50_crc_atomic_check_head(struct nv50_head *head,
+ struct nv50_head_atom *asyh,
+ struct nv50_head_atom *armh)
{
- struct drm_atomic_state *state = asyh->state.state;
+ struct nv50_atom *atom = nv50_atom(asyh->state.state);
struct drm_device *dev = head->base.base.dev;
- struct nv50_atom *atom = nv50_atom(state);
struct nv50_disp *disp = nv50_disp(dev);
- struct drm_encoder *encoder;
- struct nv50_outp_atom *outp_atom;
bool changed = armh->crc.src !=
[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #34 from mn...@protonmail.com --- Has anyone tried 5.8-rc3? I've been testing it out for the past 3 hours and it seems stable to me. Also, there were some amdgpu drm fixes pushed between rc2 and rc3 which could have fixed it. Could someone else experiencing this bug test 5.8-rc3 and see if it's fixed? I have some debug code and kernel options which may have interfered with my testing so I wouldn't exactly say the bug is fixed based on my findings. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 02/13] dt-bindings: panel: Convert rocktech, jh057n00900 to yaml
On Fri, 26 Jun 2020 02:55:50 +0200, Ondrej Jirman wrote: > Convert Rocktech MIPI DSI panel driver from txt to yaml bindings. > > Signed-off-by: Ondrej Jirman > --- > .../display/panel/rocktech,jh057n00900.txt| 23 --- > .../display/panel/rocktech,jh057n00900.yaml | 66 +++ > 2 files changed, 66 insertions(+), 23 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt > create mode 100644 > Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > My bot found errors running 'make dt_binding_check' on your patch: Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml: while scanning a block scalar in "", line 51, column 5 found a tab character where an indentation space is expected in "", line 58, column 1 Documentation/devicetree/bindings/Makefile:20: recipe for target 'Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.example.dts' failed make[1]: *** [Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.example.dts] Error 1 make[1]: *** Waiting for unfinished jobs /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml: ignoring, error parsing file warning: no schema found in file: ./Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml: ignoring, error parsing file warning: no schema found in file: ./Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml Makefile:1347: recipe for target 'dt_binding_check' failed make: *** [dt_binding_check] Error 2 See https://patchwork.ozlabs.org/patch/1317299 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dt-bindings: display: arm: versatile: Pass the sysreg unit name
Pass the sysreg unit name to fix the following warning seen with
'make dt_binding_check':
Warning (unit_address_vs_reg): /example-0/sysreg: node has a reg or ranges
property, but no unit name
Signed-off-by: Fabio Estevam
---
.../bindings/display/panel/arm,versatile-tft-panel.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.yaml
b/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.yaml
index 41fd5713c156..be69e0cc50fc 100644
---
a/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.yaml
+++
b/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.yaml
@@ -33,7 +33,7 @@ additionalProperties: false
examples:
- |
-sysreg {
+sysreg@0 {
compatible = "arm,versatile-sysreg", "syscon", "simple-mfd";
reg = <0x0 0x1000>;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Remove handhelds.org links and email addresses
On Mon, Jun 29, 2020 at 10:31:21PM +0200, Alexander A. Klimov wrote: > Rationale: > https://lore.kernel.org/linux-doc/20200626110706.7b5d4...@lwn.net/ > > Signed-off-by: Alexander A. Klimov > --- > @Jon I thought about what I said and *no*, unfortunately I *can't* automate > the detection of such as easy as the HTTPSifying. As you maybe see below > cleaning up is even "harder". > > We have only 17 files and one domain here. Shall I split it up per subsystem > or can we let it as is? > > Documentation/arm/sa1100/assabet.rst | 2 -- > Documentation/arm/samsung-s3c24xx/h1940.rst| 10 -- > Documentation/arm/samsung-s3c24xx/overview.rst | 3 +-- > Documentation/arm/samsung-s3c24xx/smdk2440.rst | 4 > arch/arm/mach-omap1/Kconfig| 4 +--- > arch/arm/mach-pxa/h5000.c | 2 +- > arch/arm/mach-s3c24xx/mach-h1940.c | 2 -- > arch/arm/mach-s3c24xx/mach-n30.c | 3 --- > arch/arm/mach-s3c24xx/mach-rx3715.c| 2 -- For s3c24xx, I am fine taking it through docs tree: Acked-by: Krzysztof Kozlowski Otherwise, after splitting, I could take the s3c-24xx bits. Best regards, Krzysztof > drivers/input/keyboard/gpio_keys.c | 2 +- > drivers/input/keyboard/jornada720_kbd.c| 2 +- > drivers/input/touchscreen/jornada720_ts.c | 2 +- > drivers/mfd/asic3.c| 2 +- > drivers/mmc/host/renesas_sdhi_core.c | 2 +- > drivers/net/ethernet/dec/tulip/de4x5.c | 1 - > drivers/video/fbdev/sa1100fb.c | 2 +- > include/linux/apm-emulation.h | 2 -- > 17 files changed, 9 insertions(+), 38 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/msm: Quiet error during failure in optional resource mappings.
On Mon, Jun 29, 2020 at 11:19 AM Eric Anholt wrote:
>
> We don't expect to find vbif_nrt or regdma on cheza, but were clogging
> up dmesg with errors about it.
nit: s/cheza/sdm845/ (since this really applies to the SoC rather than
the board..
also, maybe msm_ioremap_optional() ?
BR,
-R
>
> Signed-off-by: Eric Anholt
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4 ++--
> drivers/gpu/drm/msm/msm_drv.c | 22 ++
> drivers/gpu/drm/msm/msm_drv.h | 2 ++
> 3 files changed, 22 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index a4ab802fee6d..d9aef2b5e930 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -838,13 +838,13 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
> dpu_kms->vbif[VBIF_RT] = NULL;
> goto error;
> }
> - dpu_kms->vbif[VBIF_NRT] = msm_ioremap(dpu_kms->pdev, "vbif_nrt",
> "vbif_nrt");
> + dpu_kms->vbif[VBIF_NRT] = msm_ioremap_quiet(dpu_kms->pdev,
> "vbif_nrt", "vbif_nrt");
> if (IS_ERR(dpu_kms->vbif[VBIF_NRT])) {
> dpu_kms->vbif[VBIF_NRT] = NULL;
> DPU_DEBUG("VBIF NRT is not defined");
> }
>
> - dpu_kms->reg_dma = msm_ioremap(dpu_kms->pdev, "regdma", "regdma");
> + dpu_kms->reg_dma = msm_ioremap_quiet(dpu_kms->pdev, "regdma",
> "regdma");
> if (IS_ERR(dpu_kms->reg_dma)) {
> dpu_kms->reg_dma = NULL;
> DPU_DEBUG("REG_DMA is not defined");
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index f6ce40bf3699..df4a3c6a49cd 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -120,8 +120,8 @@ struct clk *msm_clk_get(struct platform_device *pdev,
> const char *name)
> return clk;
> }
>
> -void __iomem *msm_ioremap(struct platform_device *pdev, const char *name,
> - const char *dbgname)
> +void __iomem *_msm_ioremap(struct platform_device *pdev, const char *name,
> + const char *dbgname, bool quiet)
> {
> struct resource *res;
> unsigned long size;
> @@ -133,7 +133,8 @@ void __iomem *msm_ioremap(struct platform_device *pdev,
> const char *name,
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>
> if (!res) {
> - DRM_DEV_ERROR(>dev, "failed to get memory resource:
> %s\n", name);
> + if (!quiet)
> + DRM_DEV_ERROR(>dev, "failed to get memory
> resource: %s\n", name);
> return ERR_PTR(-EINVAL);
> }
>
> @@ -141,7 +142,8 @@ void __iomem *msm_ioremap(struct platform_device *pdev,
> const char *name,
>
> ptr = devm_ioremap(>dev, res->start, size);
> if (!ptr) {
> - DRM_DEV_ERROR(>dev, "failed to ioremap: %s\n", name);
> + if (!quiet)
> + DRM_DEV_ERROR(>dev, "failed to ioremap: %s\n",
> name);
> return ERR_PTR(-ENOMEM);
> }
>
> @@ -151,6 +153,18 @@ void __iomem *msm_ioremap(struct platform_device *pdev,
> const char *name,
> return ptr;
> }
>
> +void __iomem *msm_ioremap(struct platform_device *pdev, const char *name,
> + const char *dbgname)
> +{
> + return _msm_ioremap(pdev, name, dbgname, false);
> +}
> +
> +void __iomem *msm_ioremap_quiet(struct platform_device *pdev, const char
> *name,
> + const char *dbgname)
> +{
> + return _msm_ioremap(pdev, name, dbgname, true);
> +}
> +
> void msm_writel(u32 data, void __iomem *addr)
> {
> if (reglog)
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index e2d6a6056418..2687f7a42c15 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -411,6 +411,8 @@ struct clk *msm_clk_bulk_get_clock(struct clk_bulk_data
> *bulk, int count,
> const char *name);
> void __iomem *msm_ioremap(struct platform_device *pdev, const char *name,
> const char *dbgname);
> +void __iomem *msm_ioremap_quiet(struct platform_device *pdev, const char
> *name,
> + const char *dbgname);
> void msm_writel(u32 data, void __iomem *addr);
> u32 msm_readl(const void __iomem *addr);
>
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: backlight: Convert common backlight bindings to DT schema
On Fri, Jun 19, 2020 at 3:53 PM Sam Ravnborg wrote:
>
> Hi Rob.
>
> Good to have these converted. A few comments in the following. One
> comment is for the backlight people as you copied the original text.
>
> Sam
>
> On Thu, Jun 18, 2020 at 04:44:13PM -0600, Rob Herring wrote:
> > Convert the common GPIO, LED, and PWM backlight bindings to DT schema
> > format.
> >
> > Given there's only 2 common properties and the descriptions are slightly
> > different, I opted to not create a common backlight schema.
> >
> > Cc: Lee Jones
> > Cc: Daniel Thompson
> > Cc: Jingoo Han
> > Signed-off-by: Rob Herring
> > ---
> > .../leds/backlight/gpio-backlight.txt | 16 ---
> > .../leds/backlight/gpio-backlight.yaml| 41
> > .../bindings/leds/backlight/led-backlight.txt | 28 --
> > .../leds/backlight/led-backlight.yaml | 58 +++
> > .../bindings/leds/backlight/pwm-backlight.txt | 61
> > .../leds/backlight/pwm-backlight.yaml | 98 +++
> > 6 files changed, 197 insertions(+), 105 deletions(-)
> > delete mode 100644
> > Documentation/devicetree/bindings/leds/backlight/gpio-backlight.txt
> > create mode 100644
> > Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml
> > delete mode 100644
> > Documentation/devicetree/bindings/leds/backlight/led-backlight.txt
> > create mode 100644
> > Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml
> > delete mode 100644
> > Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt
> > create mode 100644
> > Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.txt
> > b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.txt
> > deleted file mode 100644
> > index 321be6640533..
> > --- a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.txt
> > +++ /dev/null
> > @@ -1,16 +0,0 @@
> > -gpio-backlight bindings
> > -
> > -Required properties:
> > - - compatible: "gpio-backlight"
> > - - gpios: describes the gpio that is used for enabling/disabling the
> > backlight.
> > -refer to bindings/gpio/gpio.txt for more details.
> > -
> > -Optional properties:
> > - - default-on: enable the backlight at boot.
> > -
> > -Example:
> > - backlight {
> > - compatible = "gpio-backlight";
> > - gpios = < 4 GPIO_ACTIVE_HIGH>;
> > - default-on;
> > - };
> > diff --git
> > a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml
> > b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml
> > new file mode 100644
> > index ..75cc569b9c55
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml
> > @@ -0,0 +1,41 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/leds/backlight/gpio-backlight.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: gpio-backlight bindings
> > +
> > +maintainers:
> > + - Lee Jones
> > + - Daniel Thompson
> > + - Jingoo Han
> > +
> > +properties:
> > + compatible:
> > +const: gpio-backlight
> > +
> > + gpios:
> > +description: The gpio that is used for enabling/disabling the
> > backlight.
> > +maxItems: 1
> > +
> > + default-on:
> > +description: enable the backlight at boot.
> > +type: boolean
> > +
> > +required:
> > + - compatible
> > + - gpios
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +backlight {
> > +compatible = "gpio-backlight";
> > +gpios = < 4 GPIO_ACTIVE_HIGH>;
> > +default-on;
> > +};
> > +
> > +...
> > diff --git
> > a/Documentation/devicetree/bindings/leds/backlight/led-backlight.txt
> > b/Documentation/devicetree/bindings/leds/backlight/led-backlight.txt
> > deleted file mode 100644
> > index 4c7dfbe7f67a..
> > --- a/Documentation/devicetree/bindings/leds/backlight/led-backlight.txt
> > +++ /dev/null
> > @@ -1,28 +0,0 @@
> > -led-backlight bindings
> > -
> > -This binding is used to describe a basic backlight device made of LEDs.
> > -It can also be used to describe a backlight device controlled by the
> > output of
> > -a LED driver.
> > -
> > -Required properties:
> > - - compatible: "led-backlight"
> > - - leds: a list of LEDs
> > -
> > -Optional properties:
> > - - brightness-levels: Array of distinct brightness levels. The levels
> > must be
> > - in the range accepted by the underlying LED devices.
> > - This is used to translate a backlight brightness
> > level
> > - into a LED brightness level. If it is not provided,
> > the
> > - identity mapping is used.
> > -
> > - - default-brightness-level: The default brightness level.
> >
Re: [PATCH] dt-bindings: backlight: Convert common backlight bindings to DT schema
On Mon, Jun 29, 2020 at 11:57:37AM -0600, Rob Herring wrote: > On Mon, Jun 22, 2020 at 10:57 AM Daniel Thompson > wrote: > > > > On Fri, Jun 19, 2020 at 11:53:41PM +0200, Sam Ravnborg wrote: > > > > diff --git > > > > a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml > > > > b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml > > > > new file mode 100644 > > > > index ..7e1f109a38a4 > > > > --- /dev/null > > > > +++ > > > > b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml > > > > @@ -0,0 +1,98 @@ > > > > +# SPDX-License-Identifier: GPL-2.0-only > > > > +%YAML 1.2 > > > > +--- > > > > +$id: http://devicetree.org/schemas/leds/backlight/pwm-backlight.yaml# > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > + > > > > +title: pwm-backlight bindings > > > > + > > > > +maintainers: > > > > + - Lee Jones > > > > + - Daniel Thompson > > > > + - Jingoo Han > > > > + > > > > +properties: > > > > + compatible: > > > > +const: pwm-backlight > > > > + > > > > + pwms: > > > > +maxItems: 1 > > > > + > > > > + pwm-names: true > > > > + > > > > + power-supply: > > > > +description: regulator for supply voltage > > > > + > > > > + enable-gpios: > > > > +description: Contains a single GPIO specifier for the GPIO which > > > > enables > > > > + and disables the backlight > > > > +maxItems: 1 > > > > + > > > > + post-pwm-on-delay-ms: > > > > +description: Delay in ms between setting an initial (non-zero) PWM > > > > and > > > > + enabling the backlight using GPIO. > > > > + > > > > + pwm-off-delay-ms: > > > > +description: Delay in ms between disabling the backlight using GPIO > > > > + and setting PWM value to 0. > > > > + > > > > + brightness-levels: > > > > +description: Array of distinct brightness levels. Typically these > > > > are > > > > + in the range from 0 to 255, but any range starting at 0 will do. > > > > The > > > > + actual brightness level (PWM duty cycle) will be interpolated > > > > from > > > > + these values. 0 means a 0% duty cycle (darkest/off), while the > > > > last > > > > + value in the array represents a 100% duty cycle (brightest). > > > > +$ref: /schemas/types.yaml#/definitions/uint32-array > > > > + > > > > + default-brightness-level: > > > > +description: The default brightness level (index into the array > > > > defined > > > > + by the "brightness-levels" property). > > > > +$ref: /schemas/types.yaml#/definitions/uint32 > > > Same comment as before... > > > > Sorry the "ditto" meant I didn't thing about PWM as much as I should > > have. > > > > The situation for PWM is a little different to LED. That's mostly > > because we decided not to clutter the LED code with > > "num-interpolated-steps". > > > > The PWM code implements the default-brightness-level as an index into > > the brightness array *after* it has been expanded using interpolation. > > In other words today Linux treats the default-brightness-level more > > like[1]. > > > > description: The default brightness level. When > > num-interpolated-steps is not set this is simply an index into > > the array defined by the "brightness-levels" property. If > > num-interpolated-steps is set the brightness array will be > > expanded by interpolation before we index to get a default > > level. > > > > This is the best I have come up with so far... but I concede it still > > lacks elegance. > > Happy to add this or whatever folks want if there's agreement, but I > don't want to get bogged down on re-reviewing and re-writing the > binding on what is just a conversion. There's a mountain of bindings > to convert. The original explanation is ok, as pointed out by Daniel. So I suggest moving forward with that and then others can improve the descriptions later as necessary. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/msm: Quiet error during failure in optional resource mappings.
We don't expect to find vbif_nrt or regdma on cheza, but were clogging
up dmesg with errors about it.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4 ++--
drivers/gpu/drm/msm/msm_drv.c | 22 ++
drivers/gpu/drm/msm/msm_drv.h | 2 ++
3 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index a4ab802fee6d..d9aef2b5e930 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -838,13 +838,13 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
dpu_kms->vbif[VBIF_RT] = NULL;
goto error;
}
- dpu_kms->vbif[VBIF_NRT] = msm_ioremap(dpu_kms->pdev, "vbif_nrt",
"vbif_nrt");
+ dpu_kms->vbif[VBIF_NRT] = msm_ioremap_quiet(dpu_kms->pdev, "vbif_nrt",
"vbif_nrt");
if (IS_ERR(dpu_kms->vbif[VBIF_NRT])) {
dpu_kms->vbif[VBIF_NRT] = NULL;
DPU_DEBUG("VBIF NRT is not defined");
}
- dpu_kms->reg_dma = msm_ioremap(dpu_kms->pdev, "regdma", "regdma");
+ dpu_kms->reg_dma = msm_ioremap_quiet(dpu_kms->pdev, "regdma", "regdma");
if (IS_ERR(dpu_kms->reg_dma)) {
dpu_kms->reg_dma = NULL;
DPU_DEBUG("REG_DMA is not defined");
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index f6ce40bf3699..df4a3c6a49cd 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -120,8 +120,8 @@ struct clk *msm_clk_get(struct platform_device *pdev, const
char *name)
return clk;
}
-void __iomem *msm_ioremap(struct platform_device *pdev, const char *name,
- const char *dbgname)
+void __iomem *_msm_ioremap(struct platform_device *pdev, const char *name,
+ const char *dbgname, bool quiet)
{
struct resource *res;
unsigned long size;
@@ -133,7 +133,8 @@ void __iomem *msm_ioremap(struct platform_device *pdev,
const char *name,
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
- DRM_DEV_ERROR(>dev, "failed to get memory resource:
%s\n", name);
+ if (!quiet)
+ DRM_DEV_ERROR(>dev, "failed to get memory
resource: %s\n", name);
return ERR_PTR(-EINVAL);
}
@@ -141,7 +142,8 @@ void __iomem *msm_ioremap(struct platform_device *pdev,
const char *name,
ptr = devm_ioremap(>dev, res->start, size);
if (!ptr) {
- DRM_DEV_ERROR(>dev, "failed to ioremap: %s\n", name);
+ if (!quiet)
+ DRM_DEV_ERROR(>dev, "failed to ioremap: %s\n",
name);
return ERR_PTR(-ENOMEM);
}
@@ -151,6 +153,18 @@ void __iomem *msm_ioremap(struct platform_device *pdev,
const char *name,
return ptr;
}
+void __iomem *msm_ioremap(struct platform_device *pdev, const char *name,
+ const char *dbgname)
+{
+ return _msm_ioremap(pdev, name, dbgname, false);
+}
+
+void __iomem *msm_ioremap_quiet(struct platform_device *pdev, const char *name,
+ const char *dbgname)
+{
+ return _msm_ioremap(pdev, name, dbgname, true);
+}
+
void msm_writel(u32 data, void __iomem *addr)
{
if (reglog)
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index e2d6a6056418..2687f7a42c15 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -411,6 +411,8 @@ struct clk *msm_clk_bulk_get_clock(struct clk_bulk_data
*bulk, int count,
const char *name);
void __iomem *msm_ioremap(struct platform_device *pdev, const char *name,
const char *dbgname);
+void __iomem *msm_ioremap_quiet(struct platform_device *pdev, const char *name,
+ const char *dbgname);
void msm_writel(u32 data, void __iomem *addr);
u32 msm_readl(const void __iomem *addr);
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/msm: Garbage collect unused resource _len fields.
Nothing was using the lengths of these ioremaps.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 21 -
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 9 -
3 files changed, 31 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 680527e28d09..a4ab802fee6d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -45,20 +45,6 @@
static int dpu_kms_hw_init(struct msm_kms *kms);
static void _dpu_kms_mmu_destroy(struct dpu_kms *dpu_kms);
-static unsigned long dpu_iomap_size(struct platform_device *pdev,
- const char *name)
-{
- struct resource *res;
-
- res = platform_get_resource_byname(pdev, IORESOURCE_MEM, name);
- if (!res) {
- DRM_ERROR("failed to get memory resource: %s\n", name);
- return 0;
- }
-
- return resource_size(res);
-}
-
#ifdef CONFIG_DEBUG_FS
static int _dpu_danger_signal_status(struct seq_file *s,
bool danger_status)
@@ -844,7 +830,6 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
goto error;
}
DRM_DEBUG("mapped dpu address space @%pK\n", dpu_kms->mmio);
- dpu_kms->mmio_len = dpu_iomap_size(dpu_kms->pdev, "mdp");
dpu_kms->vbif[VBIF_RT] = msm_ioremap(dpu_kms->pdev, "vbif", "vbif");
if (IS_ERR(dpu_kms->vbif[VBIF_RT])) {
@@ -853,22 +838,16 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
dpu_kms->vbif[VBIF_RT] = NULL;
goto error;
}
- dpu_kms->vbif_len[VBIF_RT] = dpu_iomap_size(dpu_kms->pdev, "vbif");
dpu_kms->vbif[VBIF_NRT] = msm_ioremap(dpu_kms->pdev, "vbif_nrt",
"vbif_nrt");
if (IS_ERR(dpu_kms->vbif[VBIF_NRT])) {
dpu_kms->vbif[VBIF_NRT] = NULL;
DPU_DEBUG("VBIF NRT is not defined");
- } else {
- dpu_kms->vbif_len[VBIF_NRT] = dpu_iomap_size(dpu_kms->pdev,
-"vbif_nrt");
}
dpu_kms->reg_dma = msm_ioremap(dpu_kms->pdev, "regdma", "regdma");
if (IS_ERR(dpu_kms->reg_dma)) {
dpu_kms->reg_dma = NULL;
DPU_DEBUG("REG_DMA is not defined");
- } else {
- dpu_kms->reg_dma_len = dpu_iomap_size(dpu_kms->pdev, "regdma");
}
pm_runtime_get_sync(_kms->pdev->dev);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index 4e32d040f1e6..13034cdb8665 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -100,7 +100,6 @@ struct dpu_kms {
/* io/register spaces: */
void __iomem *mmio, *vbif[VBIF_MAX], *reg_dma;
- unsigned long mmio_len, vbif_len[VBIF_MAX], reg_dma_len;
struct regulator *vdd;
struct regulator *mmagic;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
index 80d3cfc14007..9f20b84d5c0a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
@@ -37,7 +37,6 @@ struct dpu_mdss_hw_init_handler {
struct dpu_mdss {
struct msm_mdss base;
void __iomem *mmio;
- unsigned long mmio_len;
struct dss_module_power mp;
struct dpu_irq_controller irq_controller;
struct icc_path *path[2];
@@ -292,7 +291,6 @@ int dpu_mdss_init(struct drm_device *dev)
{
struct platform_device *pdev = to_platform_device(dev->dev);
struct msm_drm_private *priv = dev->dev_private;
- struct resource *res;
struct dpu_mdss *dpu_mdss;
struct dss_module_power *mp;
int ret = 0;
@@ -308,13 +306,6 @@ int dpu_mdss_init(struct drm_device *dev)
DRM_DEBUG("mapped mdss address space @%pK\n", dpu_mdss->mmio);
- res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "mdss");
- if (!res) {
- DRM_ERROR("failed to get memory resource for mdss\n");
- return -ENOMEM;
- }
- dpu_mdss->mmio_len = resource_size(res);
-
ret = dpu_mdss_parse_data_bus_icc_path(dev, dpu_mdss);
if (ret)
return ret;
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: backlight: Convert common backlight bindings to DT schema
On Mon, Jun 22, 2020 at 10:57 AM Daniel Thompson wrote: > > On Fri, Jun 19, 2020 at 11:53:41PM +0200, Sam Ravnborg wrote: > > > diff --git > > > a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml > > > b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml > > > new file mode 100644 > > > index ..7e1f109a38a4 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml > > > @@ -0,0 +1,98 @@ > > > +# SPDX-License-Identifier: GPL-2.0-only > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/leds/backlight/pwm-backlight.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: pwm-backlight bindings > > > + > > > +maintainers: > > > + - Lee Jones > > > + - Daniel Thompson > > > + - Jingoo Han > > > + > > > +properties: > > > + compatible: > > > +const: pwm-backlight > > > + > > > + pwms: > > > +maxItems: 1 > > > + > > > + pwm-names: true > > > + > > > + power-supply: > > > +description: regulator for supply voltage > > > + > > > + enable-gpios: > > > +description: Contains a single GPIO specifier for the GPIO which > > > enables > > > + and disables the backlight > > > +maxItems: 1 > > > + > > > + post-pwm-on-delay-ms: > > > +description: Delay in ms between setting an initial (non-zero) PWM > > > and > > > + enabling the backlight using GPIO. > > > + > > > + pwm-off-delay-ms: > > > +description: Delay in ms between disabling the backlight using GPIO > > > + and setting PWM value to 0. > > > + > > > + brightness-levels: > > > +description: Array of distinct brightness levels. Typically these are > > > + in the range from 0 to 255, but any range starting at 0 will do. > > > The > > > + actual brightness level (PWM duty cycle) will be interpolated from > > > + these values. 0 means a 0% duty cycle (darkest/off), while the last > > > + value in the array represents a 100% duty cycle (brightest). > > > +$ref: /schemas/types.yaml#/definitions/uint32-array > > > + > > > + default-brightness-level: > > > +description: The default brightness level (index into the array > > > defined > > > + by the "brightness-levels" property). > > > +$ref: /schemas/types.yaml#/definitions/uint32 > > Same comment as before... > > Sorry the "ditto" meant I didn't thing about PWM as much as I should > have. > > The situation for PWM is a little different to LED. That's mostly > because we decided not to clutter the LED code with > "num-interpolated-steps". > > The PWM code implements the default-brightness-level as an index into > the brightness array *after* it has been expanded using interpolation. > In other words today Linux treats the default-brightness-level more > like[1]. > > description: The default brightness level. When > num-interpolated-steps is not set this is simply an index into > the array defined by the "brightness-levels" property. If > num-interpolated-steps is set the brightness array will be > expanded by interpolation before we index to get a default > level. > > This is the best I have come up with so far... but I concede it still > lacks elegance. Happy to add this or whatever folks want if there's agreement, but I don't want to get bogged down on re-reviewing and re-writing the binding on what is just a conversion. There's a mountain of bindings to convert. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: drm_fourcc: Add generic alias for 16_16_TILE modifier
On Mon, Jun 29, 2020 at 10:32:41AM +0200, Daniel Vetter wrote:
> On Fri, Jun 26, 2020 at 05:48:00PM +0100, Brian Starkey wrote:
> > In cases such as DRM_FORMAT_MOD_SAMSUNG_16_16_TILE, the modifier
> > describes a generic pixel re-ordering which can be applicable to
> > multiple vendors.
> >
> > Define an alias: DRM_FORMAT_MOD_GENERIC_16_16_TILE, which can be
> > used to describe this layout in a vendor-neutral way, and add a
> > comment about the expected usage of such "generic" modifiers.
> >
> > Changes in v2:
> > - Move note about future cases to comment (Daniel)
> >
> > Signed-off-by: Brian Starkey
>
> Reviewed-by: Daniel Vetter
Thanks. I guess this should go into drm-misc-next? @Liviu would you be
able to pick it up?
Cheers,
-Brian
>
> > ---
> > include/uapi/drm/drm_fourcc.h | 25 +
> > 1 file changed, 25 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index 299f9ac4840b..cb3db4a21012 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -345,8 +345,33 @@ extern "C" {
> > * When adding a new token please document the layout with a code comment,
> > * similar to the fourcc codes above. drm_fourcc.h is considered the
> > * authoritative source for all of these.
> > + *
> > + * Generic modifier names:
> > + *
> > + * DRM_FORMAT_MOD_GENERIC_* definitions are used to provide vendor-neutral
> > names
> > + * for layouts which are common across multiple vendors. To preserve
> > + * compatibility, in cases where a vendor-specific definition already
> > exists and
> > + * a generic name for it is desired, the common name is a purely symbolic
> > alias
> > + * and must use the same numerical value as the original definition.
> > + *
> > + * Note that generic names should only be used for modifiers which describe
> > + * generic layouts (such as pixel re-ordering), which may have
> > + * independently-developed support across multiple vendors.
> > + *
> > + * In future cases where a generic layout is identified before merging
> > with a
> > + * vendor-specific modifier, a new 'GENERIC' vendor or modifier using
> > vendor
> > + * 'NONE' could be considered. This should only be for obvious, exceptional
> > + * cases to avoid polluting the 'GENERIC' namespace with modifiers which
> > only
> > + * apply to a single vendor.
> > + *
> > + * Generic names should not be used for cases where multiple hardware
> > vendors
> > + * have implementations of the same standardised compression scheme (such
> > as
> > + * AFBC). In those cases, all implementations should use the same format
> > + * modifier(s), reflecting the vendor of the standard.
> > */
> >
> > +#define DRM_FORMAT_MOD_GENERIC_16_16_TILE DRM_FORMAT_MOD_SAMSUNG_16_16_TILE
> > +
> > /*
> > * Invalid Modifier
> > *
> > --
> > 2.17.1
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 9/9] drm/simplekms: Acquire memory aperture for framebuffer
On Mon, Jun 29, 2020 at 05:23:16PM +0100, Mark Brown wrote: > On Mon, Jun 29, 2020 at 06:04:21PM +0200, Greg KH wrote: > > > Yes, please do that. Or, use the "virtual bus/device" code that some > > people at Intel are still trying to get into mergable shape. See the > > posts on the netdev list for those details. > > Any pointers on that? There's also some ongoing discussion with MFD and > that's not been mentioned at all. https://lore.kernel.org/r/20200520070227.3392100-2-jeffrey.t.kirs...@intel.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208333] No desktop on 5.8 rc1 rc2 with Gtx 760 driver nouveau
https://bugzilla.kernel.org/show_bug.cgi?id=208333 --- Comment #1 from Roberto Guerrini (robyguerr...@yahoo.it) --- Tested with 5.8 rc3 also and the result is the same black screen ... but the computer works so I think it is the Nouveau driver with the gtx 760 to wrong the video output. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 00/13] drm/trace: Mirror DRM debug logs to tracefs
On Mon, Jun 8, 2020 at 5:05 PM Sean Paul wrote: > > From: Sean Paul > > This series is the latest in my journey to create a lightweight, > always-on "flight recorder" (name credit Weston) of drm logs. This > incarnation uses a trace_array to keep logs in memory exposed through > tracefs. Users and distros can enable drm logs by using the drm.trace > module parameter to choose the debug categories they are interested in. > > The set has ballooned a little bit since the last version. Reason being > is that I decided to return true from drm_debug_enabled if trace was > enabled. This should make it easier and more seamless for driver > developers to use the correct interface, but meant I needed to audit all > uses of drm_debug_enabled and drm_debug_printer. > > Out of all those calls, there are 3 situations which arose: > 1- The logs should only go to syslog: > I've converted these to use the drm_debug_syslog variant of > enable check/printer. > > 2- The logs should go to both syslog/trace, but were using pr_debug(): > I've converted these to use the proper drm logging helper. In > cases which used a drm_printer I've had to use a new > drm_debug_category_printer to ensure they are routed correctly. > > 3- The logs should go to both syslog/trace and are using drm logging fns: > These are untouched and should be routed to the appropriate > place(s) > Friendly ping. Is this something upstream wants, or should we continue carrying it downstream? Sean > > Sean Paul (13): > drm/mipi_dbi: Convert pr_debug calls to DRM_DEBUG_DRIVER > drm/sil164: Convert dev_printk to drm_dev_dbg > drm/i915/utils: Replace dev_printk with drm helpers > drm/msm/dpu: Replace definitions for dpu debug macros > drm/print: rename drm_debug* to be more syslog-centric > drm/amd: Gate i2c transaction logs on drm_debug_syslog > drm/etnaviv: Change buffer dump checks to target syslog > drm/nouveau: Change debug checks to specifically target syslog > drm/i915: Change infoframe debug checks to specify syslog > drm/print: Add drm_debug_category_printer > drm/mst: Convert debug printers to debug category printers > drm/i915: Use debug category printer for welcome message > drm/print: Add tracefs support to the drm logging helpers > > Documentation/gpu/drm-uapi.rst | 6 + > drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c | 4 +- > drivers/gpu/drm/drm_dp_mst_topology.c| 9 +- > drivers/gpu/drm/drm_drv.c| 3 + > drivers/gpu/drm/drm_mipi_dbi.c | 8 +- > drivers/gpu/drm/drm_print.c | 228 --- > drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 8 +- > drivers/gpu/drm/i2c/sil164_drv.c | 12 +- > drivers/gpu/drm/i915/display/intel_display.c | 4 +- > drivers/gpu/drm/i915/i915_drv.c | 3 +- > drivers/gpu/drm/i915/i915_utils.c| 5 +- > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 20 +- > drivers/gpu/drm/nouveau/dispnv50/disp.h | 4 +- > drivers/gpu/drm/nouveau/nouveau_drv.h| 4 +- > include/drm/drm_print.h | 96 +++- > 15 files changed, 318 insertions(+), 96 deletions(-) > > -- > Sean Paul, Software Engineer, Google / Chromium OS > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 1/4] driver core: add device probe log helper
On Mon, Jun 29, 2020 at 2:22 PM Andrzej Hajda wrote:
>
> During probe every time driver gets resource it should usually check for
> error printk some message if it is not -EPROBE_DEFER and return the error.
> This pattern is simple but requires adding few lines after any resource
> acquisition code, as a result it is often omitted or implemented only
> partially.
> dev_err_probe helps to replace such code sequences with simple call,
> so code:
> if (err != -EPROBE_DEFER)
> dev_err(dev, ...);
> return err;
> becomes:
> return dev_err_probe(dev, err, ...);
FWIW,
Reviewed-by: Andy Shevchenko
(I'm fine with current code, though, consider below comments)
> Signed-off-by: Andrzej Hajda
> Reviewed-by: Rafael J. Wysocki
> ---
> drivers/base/core.c| 42 ++
> include/linux/device.h | 3 +++
> 2 files changed, 45 insertions(+)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 67d39a90b45c..3a827c82933f 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -3953,6 +3953,48 @@ define_dev_printk_level(_dev_info, KERN_INFO);
>
> #endif
>
> +/**
> + * dev_err_probe - probe error check and log helper
> + * @dev: the pointer to the struct device
> + * @err: error value to test
> + * @fmt: printf-style format string
> + * @...: arguments as specified in the format string
> + *
> + * This helper implements common pattern present in probe functions for error
> + * checking: print debug or error message depending if the error value is
> + * -EPROBE_DEFER and propagate error upwards.
> + * It replaces code sequence:
> + * if (err != -EPROBE_DEFER)
> + * dev_err(dev, ...);
> + * else
> + * dev_dbg(dev, ...);
> + * return err;
> + * with
> + * return dev_err_probe(dev, err, ...);
> + *
> + * Returns @err.
> + *
> + */
> +int dev_err_probe(const struct device *dev, int err, const char *fmt, ...)
> +{
> + struct va_format vaf;
> + va_list args;
> +
> + va_start(args, fmt);
> + vaf.fmt = fmt;
> + vaf.va =
> +
> + if (err != -EPROBE_DEFER)
Perhaps positive conditional.
> + dev_err(dev, "error %d: %pV", err, );
> + else
> + dev_dbg(dev, "error %d: %pV", err, );
Perhaps {} to be added here.
> +
> + va_end(args);
> +
> + return err;
> +}
> +EXPORT_SYMBOL_GPL(dev_err_probe);
> +
> static inline bool fwnode_is_primary(struct fwnode_handle *fwnode)
> {
> return fwnode && !IS_ERR(fwnode->secondary);
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 15460a5ac024..6b2272ae9af8 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -964,6 +964,9 @@ void device_link_remove(void *consumer, struct device
> *supplier);
> void device_links_supplier_sync_state_pause(void);
> void device_links_supplier_sync_state_resume(void);
>
> +extern __printf(3, 4)
> +int dev_err_probe(const struct device *dev, int err, const char *fmt, ...);
> +
> /* Create alias, so I can be autoloaded. */
> #define MODULE_ALIAS_CHARDEV(major,minor) \
> MODULE_ALIAS("char-major-" __stringify(major) "-" __stringify(minor))
> --
> 2.17.1
>
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 2/4] driver core: add deferring probe reason to devices_deferred property
On Mon, Jun 29, 2020 at 2:22 PM Andrzej Hajda wrote:
>
> /sys/kernel/debug/devices_deferred property contains list of deferred devices.
> This list does not contain reason why the driver deferred probe, the patch
> improves it.
> The natural place to set the reason is dev_err_probe function introduced
> recently,
> ie. if dev_err_probe will be called with -EPROBE_DEFER instead of printk the
> message
> will be attached to deferred device and printed when user read
> devices_deferred
to a deferred
reads
> property.
...
> @@ -3984,10 +3986,12 @@ int dev_err_probe(const struct device *dev, int err,
> const char *fmt, ...)
> vaf.fmt = fmt;
> vaf.va =
>
> - if (err != -EPROBE_DEFER)
> + if (err != -EPROBE_DEFER) {
Why not positive conditional? (Okay, I'm fine with either in this case)
> dev_err(dev, "error %d: %pV", err, );
> - else
> + } else {
> + device_set_deferred_probe_reson(dev, );
> dev_dbg(dev, "error %d: %pV", err, );
> + }
To reduce churn, you may move {} addition to the first patch.
...
> list_for_each_entry(curr, _probe_pending_list,
> deferred_probe)
> - seq_printf(s, "%s\n", dev_name(curr->device));
> + seq_printf(s, "%s\t%s", dev_name(curr->device),
> + curr->device->p->deferred_probe_reason ?: "\n");
Hmm... "\t" will be dangling in the latter case.
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 9/9] drm/simplekms: Acquire memory aperture for framebuffer
On Mon, Jun 29, 2020 at 06:04:21PM +0200, Greg KH wrote: > Yes, please do that. Or, use the "virtual bus/device" code that some > people at Intel are still trying to get into mergable shape. See the > posts on the netdev list for those details. Any pointers on that? There's also some ongoing discussion with MFD and that's not been mentioned at all. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 9/9] drm/simplekms: Acquire memory aperture for framebuffer
On Mon, Jun 29, 2020 at 11:22:30AM +0200, Daniel Vetter wrote:
> On Thu, Jun 25, 2020 at 02:00:11PM +0200, Thomas Zimmermann wrote:
> > We register the simplekms device with the DRM platform helpers. A
> > native driver for the graphics hardware will kickout the simplekms
> > driver before taking over the device.
> >
> > Signed-off-by: Thomas Zimmermann
> > ---
> > drivers/gpu/drm/tiny/Kconfig | 1 +
> > drivers/gpu/drm/tiny/simplekms.c | 94 +++-
> > 2 files changed, 92 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
> > index 50dbde8bdcb2..a47ed337a7fe 100644
> > --- a/drivers/gpu/drm/tiny/Kconfig
> > +++ b/drivers/gpu/drm/tiny/Kconfig
> > @@ -33,6 +33,7 @@ config DRM_SIMPLEKMS
> > depends on DRM
> > select DRM_GEM_SHMEM_HELPER
> > select DRM_KMS_HELPER
> > + select DRM_PLATFORM_HELPER
> > help
> > DRM driver for simple platform-provided framebuffers.
> >
> > diff --git a/drivers/gpu/drm/tiny/simplekms.c
> > b/drivers/gpu/drm/tiny/simplekms.c
> > index ae5d3cbadbe8..a903a4e0100a 100644
> > --- a/drivers/gpu/drm/tiny/simplekms.c
> > +++ b/drivers/gpu/drm/tiny/simplekms.c
> > @@ -5,6 +5,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -17,6 +18,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -36,6 +38,12 @@
> > #define SIMPLEKMS_MODE(hd, vd) \
> > DRM_SIMPLE_MODE(hd, vd, RES_MM(hd), RES_MM(vd))
> >
> > +/*
> > + * Protects the platform device's drvdata against
> > + * concurrent manipulation.
> > + */
> > +static DEFINE_SPINLOCK(simplekms_drvdata_lock);
> > +
> > /*
> > * Helpers for simplefb
> > */
> > @@ -211,6 +219,7 @@ struct simplekms_device {
> > unsigned int pitch;
> >
> > /* memory management */
> > + struct drm_aperture *aperture;
> > struct resource *mem;
> > void __iomem *screen_base;
> >
> > @@ -224,6 +233,8 @@ static struct simplekms_device
> > *simplekms_device_of_dev(struct drm_device *dev)
> > return container_of(dev, struct simplekms_device, dev);
> > }
> >
> > +static void simplekms_device_cleanup(struct simplekms_device *sdev);
> > +
> > /*
> > * Hardware
> > */
> > @@ -514,22 +525,72 @@ static int simplekms_device_init_fb(struct
> > simplekms_device *sdev)
> > * Memory management
> > */
> >
> > +static void simplekms_aperture_kickout(struct drm_aperture *ap)
> > +{
> > + struct drm_device *dev = ap->dev;
> > + struct simplekms_device *sdev = simplekms_device_of_dev(dev);
> > + struct platform_device *pdev = sdev->pdev;
> > +
> > + if (WARN_ON(!sdev->aperture))
> > + return; /* BUG: driver already got kicked out */
> > +
> > + drm_dev_unregister(dev);
>
> >From a semantic pov I think the platform driver getting kicked out is more
> like a hotunplug, so drm_dev_unplug(dev); here is imo better.
>
> That then also gives you a nice drm_dev_enter/exit to sprinkle over the
> various driver callbacks, instead of the racy ->aperture check reinvented
> wheel here.
>
> I also wonder whether we couldn't go full driver model for these platform
> devices, and instead of this here call a core driver model function to
> force the unbding of the driver. Only change we'd need it that our
> ->remove hook uses drm_dev_unplug().
Yes, please do that. Or, use the "virtual bus/device" code that some
people at Intel are still trying to get into mergable shape. See the
posts on the netdev list for those details.
Don't use platform devices for anything that is not actually a platform
device (i.e. something described by hardware resources).
thanks,
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 1/2] drm/ttm: cleanup ttm_mem_type_manager_func.get_node interface v3
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Monday, June 29, 2020 11:19 AM
>To: dri-devel@lists.freedesktop.org
>Subject: [PATCH 1/2] drm/ttm: cleanup
>ttm_mem_type_manager_func.get_node interface v3
>
>Instead of signaling failure by setting the node pointer to
>NULL do so by returning -ENOSPC.
>
>v2: add memset() to make sure that mem is always initialized.
>v3: drop memset() only set mm_node = NULL, move mm_node init in amdgpu
Reviewed-by: Michael J. Ruhl
m
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 3 +--
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 5 ++---
> drivers/gpu/drm/nouveau/nouveau_ttm.c | 8
> drivers/gpu/drm/ttm/ttm_bo.c | 13 +++--
> drivers/gpu/drm/ttm/ttm_bo_manager.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 4 +---
> 6 files changed, 12 insertions(+), 23 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
>index 627104401e84..2c20d23d62d1 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
>@@ -229,7 +229,7 @@ static int amdgpu_gtt_mgr_new(struct
>ttm_mem_type_manager *man,
> if ((>mem == mem || tbo->mem.mem_type != TTM_PL_TT) &&
> atomic64_read(>available) < mem->num_pages) {
> spin_unlock(>lock);
>- return 0;
>+ return -ENOSPC;
> }
> atomic64_sub(mem->num_pages, >available);
> spin_unlock(>lock);
>@@ -250,7 +250,6 @@ static int amdgpu_gtt_mgr_new(struct
>ttm_mem_type_manager *man,
> if (unlikely(r)) {
> kfree(node);
> mem->mm_node = NULL;
>- r = 0;
> goto err_out;
> }
> } else {
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>index 128a667ed8fa..e8d1dd564006 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>@@ -336,8 +336,7 @@ static int amdgpu_vram_mgr_new(struct
>ttm_mem_type_manager *man,
> mem_bytes = (u64)mem->num_pages << PAGE_SHIFT;
> if (atomic64_add_return(mem_bytes, >usage) > max_bytes) {
> atomic64_sub(mem_bytes, >usage);
>- mem->mm_node = NULL;
>- return 0;
>+ return -ENOSPC;
> }
>
> if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
>@@ -417,7 +416,7 @@ static int amdgpu_vram_mgr_new(struct
>ttm_mem_type_manager *man,
> atomic64_sub(mem->num_pages << PAGE_SHIFT, >usage);
>
> kvfree(nodes);
>- return r == -ENOSPC ? 0 : r;
>+ return r;
> }
>
> /**
>diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
>b/drivers/gpu/drm/nouveau/nouveau_ttm.c
>index 7ca0a2498532..e89ea052cf71 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
>@@ -75,10 +75,6 @@ nouveau_vram_manager_new(struct
>ttm_mem_type_manager *man,
> ret = nouveau_mem_vram(reg, nvbo->contig, nvbo->page);
> if (ret) {
> nouveau_mem_del(reg);
>- if (ret == -ENOSPC) {
>- reg->mm_node = NULL;
>- return 0;
>- }
> return ret;
> }
>
>@@ -139,10 +135,6 @@ nv04_gart_manager_new(struct
>ttm_mem_type_manager *man,
> reg->num_pages << PAGE_SHIFT, >vma[0]);
> if (ret) {
> nouveau_mem_del(reg);
>- if (ret == -ENOSPC) {
>- reg->mm_node = NULL;
>- return 0;
>- }
> return ret;
> }
>
>diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>index f78cfc76ad78..2da8dbd2553b 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo.c
>@@ -909,10 +909,10 @@ static int ttm_bo_mem_force_space(struct
>ttm_buffer_object *bo,
> ticket = dma_resv_locking_ctx(bo->base.resv);
> do {
> ret = (*man->func->get_node)(man, bo, place, mem);
>- if (unlikely(ret != 0))
>- return ret;
>- if (mem->mm_node)
>+ if (likely(!ret))
> break;
>+ if (unlikely(ret != -ENOSPC))
>+ return ret;
> ret = ttm_mem_evict_first(bdev, mem->mem_type, place,
>ctx,
> ticket);
> if (unlikely(ret != 0))
>@@ -1056,12 +1056,11 @@ int ttm_bo_mem_space(struct ttm_buffer_object
>*bo,
>
> man = >man[mem->mem_type];
> ret = (*man->func->get_node)(man, bo, place, mem);
>+ if (ret == -ENOSPC)
>+ continue;
> if (unlikely(ret))
> goto error;
>
>- if (!mem->mm_node)
>-
[PATCH 5.7 252/265] drm/panel-simple: fix connector type for LogicPD Type28 Display
From: Adam Ford
commit efb94790852ae673b18efde1b171d284689ff333 upstream.
The LogicPD Type28 display used by several Logic PD products has not
worked since v5.6.
The connector type for the LogicPD Type 28 display is missing and
drm_panel_bridge_add() requires connector type to be set.
Signed-off-by: Adam Ford
Fixes: 0d35408afbeb ("drm/panel: simple: Add Logic PD Type 28 display support")
Cc: Adam Ford
Cc: Sam Ravnborg
Cc: Thierry Reding
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.6+
Signed-off-by: Sam Ravnborg
Link:
https://patchwork.freedesktop.org/patch/msgid/20200615131934.12440-1-aford...@gmail.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/panel/panel-simple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 00c1a8dc4ce8f..db91b3c031a13 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2297,6 +2297,7 @@ static const struct panel_desc logicpd_type_28 = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE |
DRM_BUS_FLAG_SYNC_DRIVE_NEGEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
};
static const struct panel_desc mitsubishi_aa070mc01 = {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5.7 248/265] drm/fb-helper: Fix vt restore
From: Daniel Vetter
commit dc5bdb68b5b369d5bc7d1de96fa64cc1737a6320 upstream.
In the past we had a pile of hacks to orchestrate access between fbdev
emulation and native kms clients. We've tried to streamline this, by
always preferring the kms side above fbdev calls when a drm master
exists, because drm master controls access to the display resources.
Unfortunately this breaks existing userspace, specifically Xorg. When
exiting Xorg first restores the console to text mode using the KDSET
ioctl on the vt. This does nothing, because a drm master is still
around. Then it drops the drm master status, which again does nothing,
because logind is keeping additional drm fd open to be able to
orchestrate vt switches. In the past this is the point where fbdev was
restored, as part of the ->lastclose hook on the drm side.
Now to fix this regression we don't want to go back to letting fbdev
restore things whenever it feels like, or to the pile of hacks we've
had before. Instead try and go with a minimal exception to make the
KDSET case work again, and nothing else.
This means that if userspace does a KDSET call when switching between
graphical compositors, there will be some flickering with fbcon
showing up for a bit. But a) that's not a regression and b) userspace
can fix it by improving the vt switching dance - logind should have
all the information it needs.
While pondering all this I'm also wondering wheter we should have a
SWITCH_MASTER ioctl to allow race-free master status handover. But
that's for another day.
v2: Somehow forgot to cc all the fbdev people.
v3: Fix typo Alex spotted.
Reviewed-by: Alex Deucher
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=208179
Cc: shl...@fastmail.com
Reported-and-Tested-by: shl...@fastmail.com
Cc: Michel Dänzer
Fixes: 64914da24ea9 ("drm/fbdev-helper: don't force restores")
Cc: Noralf Trønnes
Cc: Thomas Zimmermann
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.7+
Cc: Bartlomiej Zolnierkiewicz
Cc: Geert Uytterhoeven
Cc: Nathan Chancellor
Cc: Qiujun Huang
Cc: Peter Rosin
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20200624092910.3280448-1-daniel.vet...@ffwll.ch
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_fb_helper.c | 63 +---
drivers/video/fbdev/core/fbcon.c | 3 +-
include/uapi/linux/fb.h | 1 +
3 files changed, 52 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index a9771de4d17e6..c7be39a00d437 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -227,18 +227,9 @@ int drm_fb_helper_debug_leave(struct fb_info *info)
}
EXPORT_SYMBOL(drm_fb_helper_debug_leave);
-/**
- * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
- * @fb_helper: driver-allocated fbdev helper, can be NULL
- *
- * This should be called from driver's drm _driver.lastclose callback
- * when implementing an fbcon on top of kms using this helper. This ensures
that
- * the user isn't greeted with a black screen when e.g. X dies.
- *
- * RETURNS:
- * Zero if everything went ok, negative error code otherwise.
- */
-int drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper)
+static int
+__drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper,
+ bool force)
{
bool do_delayed;
int ret;
@@ -250,7 +241,16 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct
drm_fb_helper *fb_helper)
return 0;
mutex_lock(_helper->lock);
- ret = drm_client_modeset_commit(_helper->client);
+ if (force) {
+ /*
+* Yes this is the _locked version which expects the master lock
+* to be held. But for forced restores we're intentionally
+* racing here, see drm_fb_helper_set_par().
+*/
+ ret = drm_client_modeset_commit_locked(_helper->client);
+ } else {
+ ret = drm_client_modeset_commit(_helper->client);
+ }
do_delayed = fb_helper->delayed_hotplug;
if (do_delayed)
@@ -262,6 +262,22 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct
drm_fb_helper *fb_helper)
return ret;
}
+
+/**
+ * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
+ * @fb_helper: driver-allocated fbdev helper, can be NULL
+ *
+ * This should be called from driver's drm _driver.lastclose callback
+ * when implementing an fbcon on top of kms using this helper. This ensures
that
+ * the user isn't greeted with a black screen when e.g. X dies.
+ *
+ * RETURNS:
+ * Zero if everything went ok, negative error code otherwise.
+ */
+int drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper)
[PATCH 2/2] drm/ttm: make TT creation purely optional v3
We only need the page array when the BO is about to be accessed.
So not only populate, but also create it on demand.
v2: move NULL check into ttm_tt_create()
v3: fix the occurrence in ttm_bo_kmap_ttm as well
Signed-off-by: Christian König
Reviewed-by: Michael J. Ruhl
---
drivers/gpu/drm/ttm/ttm_bo.c | 37 ---
drivers/gpu/drm/ttm/ttm_bo_util.c | 7 --
drivers/gpu/drm/ttm/ttm_bo_vm.c | 5 +
drivers/gpu/drm/ttm/ttm_tt.c | 4 +++-
4 files changed, 22 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2da8dbd2553b..0c13fe96c7e3 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -292,12 +292,11 @@ static int ttm_bo_handle_move_mem(struct
ttm_buffer_object *bo,
*/
if (!(new_man->flags & TTM_MEMTYPE_FLAG_FIXED)) {
- if (bo->ttm == NULL) {
- bool zero = !(old_man->flags & TTM_MEMTYPE_FLAG_FIXED);
- ret = ttm_tt_create(bo, zero);
- if (ret)
- goto out_err;
- }
+ bool zero = !(old_man->flags & TTM_MEMTYPE_FLAG_FIXED);
+
+ ret = ttm_tt_create(bo, zero);
+ if (ret)
+ goto out_err;
ret = ttm_tt_set_placement_caching(bo->ttm, mem->placement);
if (ret)
@@ -660,13 +659,8 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
placement.num_busy_placement = 0;
bdev->driver->evict_flags(bo, );
- if (!placement.num_placement && !placement.num_busy_placement) {
- ret = ttm_bo_pipeline_gutting(bo);
- if (ret)
- return ret;
-
- return ttm_tt_create(bo, false);
- }
+ if (!placement.num_placement && !placement.num_busy_placement)
+ return ttm_bo_pipeline_gutting(bo);
evict_mem = bo->mem;
evict_mem.mm_node = NULL;
@@ -1195,13 +1189,8 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
/*
* Remove the backing store if no placement is given.
*/
- if (!placement->num_placement && !placement->num_busy_placement) {
- ret = ttm_bo_pipeline_gutting(bo);
- if (ret)
- return ret;
-
- return ttm_tt_create(bo, false);
- }
+ if (!placement->num_placement && !placement->num_busy_placement)
+ return ttm_bo_pipeline_gutting(bo);
/*
* Check whether we need to move buffer.
@@ -1218,14 +1207,6 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
ttm_flag_masked(>mem.placement, new_flags,
~TTM_PL_MASK_MEMTYPE);
}
- /*
-* We might need to add a TTM.
-*/
- if (bo->mem.mem_type == TTM_PL_SYSTEM && bo->ttm == NULL) {
- ret = ttm_tt_create(bo, true);
- if (ret)
- return ret;
- }
return 0;
}
EXPORT_SYMBOL(ttm_bo_validate);
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 52d2b71f1588..dc4db7613666 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -580,12 +580,15 @@ static int ttm_bo_kmap_ttm(struct ttm_buffer_object *bo,
.interruptible = false,
.no_wait_gpu = false
};
- struct ttm_tt *ttm = bo->ttm;
+ struct ttm_tt *ttm;
pgprot_t prot;
int ret;
- BUG_ON(!ttm);
+ ret = ttm_tt_create(bo, true);
+ if (ret)
+ return ret;
+ ttm = bo->ttm;
ret = ttm_tt_populate(ttm, );
if (ret)
return ret;
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 0ad30b112982..0586870ab642 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -349,6 +349,11 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
};
+ if (ttm_tt_create(bo, true)) {
+ ret = VM_FAULT_OOM;
+ goto out_io_unlock;
+ }
+
ttm = bo->ttm;
if (ttm_tt_populate(bo->ttm, )) {
ret = VM_FAULT_OOM;
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 2ec448e1d663..e25d4097aa16 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -50,6 +50,9 @@ int ttm_tt_create(struct ttm_buffer_object *bo, bool
zero_alloc)
dma_resv_assert_held(bo->base.resv);
+ if (bo->ttm)
+ return 0;
+
if (bdev->need_dma32)
page_flags |= TTM_PAGE_FLAG_DMA32;
@@ -67,7 +70,6 @@ int ttm_tt_create(struct ttm_buffer_object *bo, bool
zero_alloc)
page_flags |= TTM_PAGE_FLAG_SG;
[PATCH 1/2] drm/ttm: cleanup ttm_mem_type_manager_func.get_node interface v3
Instead of signaling failure by setting the node pointer to
NULL do so by returning -ENOSPC.
v2: add memset() to make sure that mem is always initialized.
v3: drop memset() only set mm_node = NULL, move mm_node init in amdgpu
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 3 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 5 ++---
drivers/gpu/drm/nouveau/nouveau_ttm.c | 8
drivers/gpu/drm/ttm/ttm_bo.c | 13 +++--
drivers/gpu/drm/ttm/ttm_bo_manager.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 4 +---
6 files changed, 12 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 627104401e84..2c20d23d62d1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -229,7 +229,7 @@ static int amdgpu_gtt_mgr_new(struct ttm_mem_type_manager
*man,
if ((>mem == mem || tbo->mem.mem_type != TTM_PL_TT) &&
atomic64_read(>available) < mem->num_pages) {
spin_unlock(>lock);
- return 0;
+ return -ENOSPC;
}
atomic64_sub(mem->num_pages, >available);
spin_unlock(>lock);
@@ -250,7 +250,6 @@ static int amdgpu_gtt_mgr_new(struct ttm_mem_type_manager
*man,
if (unlikely(r)) {
kfree(node);
mem->mm_node = NULL;
- r = 0;
goto err_out;
}
} else {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 128a667ed8fa..e8d1dd564006 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -336,8 +336,7 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager
*man,
mem_bytes = (u64)mem->num_pages << PAGE_SHIFT;
if (atomic64_add_return(mem_bytes, >usage) > max_bytes) {
atomic64_sub(mem_bytes, >usage);
- mem->mm_node = NULL;
- return 0;
+ return -ENOSPC;
}
if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
@@ -417,7 +416,7 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager
*man,
atomic64_sub(mem->num_pages << PAGE_SHIFT, >usage);
kvfree(nodes);
- return r == -ENOSPC ? 0 : r;
+ return r;
}
/**
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index 7ca0a2498532..e89ea052cf71 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -75,10 +75,6 @@ nouveau_vram_manager_new(struct ttm_mem_type_manager *man,
ret = nouveau_mem_vram(reg, nvbo->contig, nvbo->page);
if (ret) {
nouveau_mem_del(reg);
- if (ret == -ENOSPC) {
- reg->mm_node = NULL;
- return 0;
- }
return ret;
}
@@ -139,10 +135,6 @@ nv04_gart_manager_new(struct ttm_mem_type_manager *man,
reg->num_pages << PAGE_SHIFT, >vma[0]);
if (ret) {
nouveau_mem_del(reg);
- if (ret == -ENOSPC) {
- reg->mm_node = NULL;
- return 0;
- }
return ret;
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index f78cfc76ad78..2da8dbd2553b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -909,10 +909,10 @@ static int ttm_bo_mem_force_space(struct
ttm_buffer_object *bo,
ticket = dma_resv_locking_ctx(bo->base.resv);
do {
ret = (*man->func->get_node)(man, bo, place, mem);
- if (unlikely(ret != 0))
- return ret;
- if (mem->mm_node)
+ if (likely(!ret))
break;
+ if (unlikely(ret != -ENOSPC))
+ return ret;
ret = ttm_mem_evict_first(bdev, mem->mem_type, place, ctx,
ticket);
if (unlikely(ret != 0))
@@ -1056,12 +1056,11 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
man = >man[mem->mem_type];
ret = (*man->func->get_node)(man, bo, place, mem);
+ if (ret == -ENOSPC)
+ continue;
if (unlikely(ret))
goto error;
- if (!mem->mm_node)
- continue;
-
ret = ttm_bo_add_move_fence(bo, man, mem, ctx->no_wait_gpu);
if (unlikely(ret)) {
(*man->func->put_node)(man, mem);
@@ -1126,6 +1125,8 @@ static int ttm_bo_move_buffer(struct ttm_buffer_object
*bo,
mem.page_alignment =
[Bug 208373] drm:drm_atomic_helper_wait_for_dependencies - drm_kms_helper - flip_done timed out
https://bugzilla.kernel.org/show_bug.cgi?id=208373 --- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) --- If this is a regression between 5.7.2 and 5.7.0, can you bisect? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH v2 6/6] drm/msm/a6xx: Add support for per-instance pagetables
On Sat, Jun 27, 2020 at 01:11:14PM -0700, Rob Clark wrote:
> On Sat, Jun 27, 2020 at 12:56 PM Rob Clark wrote:
> >
> > On Fri, Jun 26, 2020 at 1:04 PM Jordan Crouse
> > wrote:
> > >
> > > Add support for using per-instance pagetables if all the dependencies are
> > > available.
> > >
> > > Signed-off-by: Jordan Crouse
> > > ---
> > >
> > > drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 43 +++
> > > drivers/gpu/drm/msm/msm_ringbuffer.h | 1 +
> > > 2 files changed, 44 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > > b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > > index aa53f47b7e8b..95ed2ceac121 100644
> > > --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > > +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > > @@ -79,6 +79,34 @@ static void get_stats_counter(struct msm_ringbuffer
> > > *ring, u32 counter,
> > > OUT_RING(ring, upper_32_bits(iova));
> > > }
> > >
> > > +static void a6xx_set_pagetable(struct msm_gpu *gpu, struct
> > > msm_ringbuffer *ring,
> > > + struct msm_file_private *ctx)
> > > +{
> > > + phys_addr_t ttbr;
> > > + u32 asid;
> > > +
> > > + if (msm_iommu_pagetable_params(ctx->aspace->mmu, , ))
> > > + return;
> > > +
> > > + /* Execute the table update */
> > > + OUT_PKT7(ring, CP_SMMU_TABLE_UPDATE, 4);
> > > + OUT_RING(ring, lower_32_bits(ttbr));
> > > + OUT_RING(ring, (((u64) asid) << 48) | upper_32_bits(ttbr));
> > > + /* CONTEXTIDR is currently unused */
> > > + OUT_RING(ring, 0);
> > > + /* CONTEXTBANK is currently unused */
> > > + OUT_RING(ring, 0);
> > > +
> > > + /*
> > > +* Write the new TTBR0 to the memstore. This is good for
> > > debugging.
> > > +*/
> > > + OUT_PKT7(ring, CP_MEM_WRITE, 4);
> > > + OUT_RING(ring, lower_32_bits(rbmemptr(ring, ttbr0)));
> > > + OUT_RING(ring, upper_32_bits(rbmemptr(ring, ttbr0)));
> > > + OUT_RING(ring, lower_32_bits(ttbr));
> > > + OUT_RING(ring, (((u64) asid) << 48) | upper_32_bits(ttbr));
> > > +}
> > > +
> > > static void a6xx_submit(struct msm_gpu *gpu, struct msm_gem_submit
> > > *submit,
> > > struct msm_file_private *ctx)
> > > {
> > > @@ -89,6 +117,8 @@ static void a6xx_submit(struct msm_gpu *gpu, struct
> > > msm_gem_submit *submit,
> > > struct msm_ringbuffer *ring = submit->ring;
> > > unsigned int i;
> > >
> > > + a6xx_set_pagetable(gpu, ring, ctx);
> > > +
> > > get_stats_counter(ring, REG_A6XX_RBBM_PERFCTR_CP_0_LO,
> > > rbmemptr_stats(ring, index, cpcycles_start));
> > >
> > > @@ -872,6 +902,18 @@ static unsigned long a6xx_gpu_busy(struct msm_gpu
> > > *gpu)
> > > return (unsigned long)busy_time;
> > > }
> > >
> > > +struct msm_gem_address_space *a6xx_address_space_instance(struct msm_gpu
> > > *gpu)
> > > +{
> > > + struct msm_mmu *mmu;
> > > +
> > > + mmu = msm_iommu_pagetable_create(gpu->aspace->mmu);
> > > + if (IS_ERR(mmu))
> > > + return msm_gem_address_space_get(gpu->aspace);
> > > +
> > > + return msm_gem_address_space_create(mmu,
> > > + "gpu", 0x1ULL, 0x1ULL);
> > > +}
> > > +
> > > static const struct adreno_gpu_funcs funcs = {
> > > .base = {
> > > .get_param = adreno_get_param,
> > > @@ -895,6 +937,7 @@ static const struct adreno_gpu_funcs funcs = {
> > > .gpu_state_put = a6xx_gpu_state_put,
> > > #endif
> > > .create_address_space = adreno_iommu_create_address_space,
> > > + .address_space_instance = a6xx_address_space_instance,
> >
> > Hmm, maybe instead of .address_space_instance, something like
> > .create_context_address_space?
> >
> > Since like .create_address_space, it is creating an address space..
> > the difference is that it is a per context/process aspace..
> >
This is a good suggestion. I'm always open to changing function names.
>
>
> or maybe just .create_pgtable and return the 'struct msm_mmu' (which
> is itself starting to become less of a great name)..
>
> The only other thing a6xx_address_space_instance() adds is knowing
> where the split is between the kernel and user pgtables, and I suppose
> that isn't a thing that would really be changing between gens?
In theory the split is determined by the hardware but its been the same for all
a5xx/a6xx targets.
Jordan
> BR,
> -R
>
> > BR,
> > -R
> >
> > > },
> > > .get_timestamp = a6xx_get_timestamp,
> > > };
> > > diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.h
> > > b/drivers/gpu/drm/msm/msm_ringbuffer.h
> > > index 7764373d0ed2..0987d6bf848c 100644
> > > --- a/drivers/gpu/drm/msm/msm_ringbuffer.h
> > > +++ b/drivers/gpu/drm/msm/msm_ringbuffer.h
> > > @@ -31,6 +31,7 @@ struct msm_rbmemptrs {
> > > volatile uint32_t fence;
> > >
> > > volatile struct msm_gpu_submit_stats
> > >
Re: [Freedreno] [PATCH v9 6/7] drm/msm: Set the global virtual address range from the IOMMU domain
On Sat, Jun 27, 2020 at 10:10:14AM -0700, Rob Clark wrote:
> On Fri, Jun 26, 2020 at 1:01 PM Jordan Crouse wrote:
> >
> > Use the aperture settings from the IOMMU domain to set up the virtual
> > address range for the GPU. This allows us to transparently deal with
> > IOMMU side features (like split pagetables).
> >
> > Signed-off-by: Jordan Crouse
> > ---
> >
> > drivers/gpu/drm/msm/adreno/adreno_gpu.c | 13 +++--
> > drivers/gpu/drm/msm/msm_iommu.c | 7 +++
> > 2 files changed, 18 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > index 5db06b590943..3e717c1ebb7f 100644
> > --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > @@ -192,9 +192,18 @@ adreno_iommu_create_address_space(struct msm_gpu *gpu,
> > struct iommu_domain *iommu = iommu_domain_alloc(_bus_type);
> > struct msm_mmu *mmu = msm_iommu_new(>dev, iommu);
> > struct msm_gem_address_space *aspace;
> > + u64 start, size;
> >
> > - aspace = msm_gem_address_space_create(mmu, "gpu", SZ_16M,
> > - 0x - SZ_16M);
> > + /*
> > +* Use the aperture start or SZ_16M, whichever is greater. This will
> > +* ensure that we align with the allocated pagetable range while
> > still
> > +* allowing room in the lower 32 bits for GMEM and whatnot
> > +*/
> > + start = max_t(u64, SZ_16M, iommu->geometry.aperture_start);
> > + size = iommu->geometry.aperture_end - start + 1;
> > +
> > + aspace = msm_gem_address_space_create(mmu, "gpu",
> > + start & GENMASK(48, 0), size);
>
> hmm, I kinda think this isn't going to play well for the 32b gpus
> (pre-a5xx).. possibly we should add address space size to 'struct
> adreno_info'?
I checked and qcom-iommu sets the aperture correctly so this should be okay for
everybody. To be honest, I'm nots sure if we even need to mask the start to 49
bits. It seems that all of the iommu implementations do the right thing. Of
course it would be worth a check if you have a 4xx handy.
> Or I guess it is always going to be the same for all devices within a
> generation? So it could just be passed in to adreno_gpu_init()
We can do that easily if we are worried about it (see also: a2xx). I just
figured this might save us a bit of code.
> Hopefully that makes things smoother if we someday had more than 48bits..
We'll be at 49 bits for as far ahead as I can see. 49 bits has a special
meaning in the SMMU so it is a natural fit for the GPU hardware. If we change in
N generations we can just shift to a family specific function at that point.
Jordan
> BR,
> -R
>
> >
> > if (IS_ERR(aspace) && !IS_ERR(mmu))
> > mmu->funcs->destroy(mmu);
> > diff --git a/drivers/gpu/drm/msm/msm_iommu.c
> > b/drivers/gpu/drm/msm/msm_iommu.c
> > index 3a381a9674c9..1b6635504069 100644
> > --- a/drivers/gpu/drm/msm/msm_iommu.c
> > +++ b/drivers/gpu/drm/msm/msm_iommu.c
> > @@ -36,6 +36,10 @@ static int msm_iommu_map(struct msm_mmu *mmu, uint64_t
> > iova,
> > struct msm_iommu *iommu = to_msm_iommu(mmu);
> > size_t ret;
> >
> > + /* The arm-smmu driver expects the addresses to be sign extended */
> > + if (iova & BIT_ULL(48))
> > + iova |= GENMASK_ULL(63, 49);
> > +
> > ret = iommu_map_sg(iommu->domain, iova, sgt->sgl, sgt->nents, prot);
> > WARN_ON(!ret);
> >
> > @@ -46,6 +50,9 @@ static int msm_iommu_unmap(struct msm_mmu *mmu, uint64_t
> > iova, size_t len)
> > {
> > struct msm_iommu *iommu = to_msm_iommu(mmu);
> >
> > + if (iova & BIT_ULL(48))
> > + iova |= GENMASK_ULL(63, 49);
> > +
> > iommu_unmap(iommu->domain, iova, len);
> >
> > return 0;
> > --
> > 2.17.1
> >
> > ___
> > Freedreno mailing list
> > freedr...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/freedreno
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 2/2] drm/ttm: make TT creation purely optional v2
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Monday, June 29, 2020 8:22 AM
>To: dri-devel@lists.freedesktop.org
>Subject: [PATCH 2/2] drm/ttm: make TT creation purely optional v2
>
>We only need the page array when the BO is about to be accessed.
>
>So not only populate, but also create it on demand.
>
>v2: move NULL check into ttm_tt_create()
>
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/ttm/ttm_bo.c | 37 ---
> drivers/gpu/drm/ttm/ttm_bo_util.c | 9 ++--
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 5 +
> drivers/gpu/drm/ttm/ttm_tt.c | 4 +++-
> 4 files changed, 24 insertions(+), 31 deletions(-)
>
>diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>index 06b8bc0d8f23..c8c25e45751a 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo.c
>@@ -292,12 +292,11 @@ static int ttm_bo_handle_move_mem(struct
>ttm_buffer_object *bo,
>*/
>
> if (!(new_man->flags & TTM_MEMTYPE_FLAG_FIXED)) {
>- if (bo->ttm == NULL) {
>- bool zero = !(old_man->flags &
>TTM_MEMTYPE_FLAG_FIXED);
>- ret = ttm_tt_create(bo, zero);
>- if (ret)
>- goto out_err;
>- }
>+ bool zero = !(old_man->flags &
>TTM_MEMTYPE_FLAG_FIXED);
>+
>+ ret = ttm_tt_create(bo, zero);
>+ if (ret)
>+ goto out_err;
>
> ret = ttm_tt_set_placement_caching(bo->ttm, mem-
>>placement);
> if (ret)
>@@ -660,13 +659,8 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
> placement.num_busy_placement = 0;
> bdev->driver->evict_flags(bo, );
>
>- if (!placement.num_placement &&
>!placement.num_busy_placement) {
>- ret = ttm_bo_pipeline_gutting(bo);
>- if (ret)
>- return ret;
>-
>- return ttm_tt_create(bo, false);
>- }
>+ if (!placement.num_placement &&
>!placement.num_busy_placement)
>+ return ttm_bo_pipeline_gutting(bo);
>
> evict_mem = bo->mem;
> evict_mem.mm_node = NULL;
>@@ -1194,13 +1188,8 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
> /*
>* Remove the backing store if no placement is given.
>*/
>- if (!placement->num_placement && !placement-
>>num_busy_placement) {
>- ret = ttm_bo_pipeline_gutting(bo);
>- if (ret)
>- return ret;
>-
>- return ttm_tt_create(bo, false);
>- }
>+ if (!placement->num_placement && !placement-
>>num_busy_placement)
>+ return ttm_bo_pipeline_gutting(bo);
>
> /*
>* Check whether we need to move buffer.
>@@ -1217,14 +1206,6 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
> ttm_flag_masked(>mem.placement, new_flags,
> ~TTM_PL_MASK_MEMTYPE);
> }
>- /*
>- * We might need to add a TTM.
>- */
>- if (bo->mem.mem_type == TTM_PL_SYSTEM && bo->ttm == NULL) {
>- ret = ttm_tt_create(bo, true);
>- if (ret)
>- return ret;
>- }
> return 0;
> }
> EXPORT_SYMBOL(ttm_bo_validate);
>diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
>b/drivers/gpu/drm/ttm/ttm_bo_util.c
>index 52d2b71f1588..f8414f820350 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
>@@ -580,12 +580,17 @@ static int ttm_bo_kmap_ttm(struct
>ttm_buffer_object *bo,
> .interruptible = false,
> .no_wait_gpu = false
> };
>- struct ttm_tt *ttm = bo->ttm;
>+ struct ttm_tt *ttm;
> pgprot_t prot;
> int ret;
>
>- BUG_ON(!ttm);
>+ if (!bo->ttm) {
>+ ret = ttm_tt_create(bo, true);
>+ if (ret)
>+ return ret;
>+ }
I think that this chunk can be reduced to:
ret = ttm_tt_create(bo, true);
if (ret)
return ret;
?
With that change (unless I missed something here?):
Reviewed-by: Michael J. Ruhl
Mike
>
>+ ttm = bo->ttm;
> ret = ttm_tt_populate(ttm, );
> if (ret)
> return ret;
>diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>index 0ad30b112982..0586870ab642 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>@@ -349,6 +349,11 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct
>vm_fault *vmf,
>
> };
>
>+ if (ttm_tt_create(bo, true)) {
>+ ret = VM_FAULT_OOM;
>+ goto out_io_unlock;
>+ }
>+
> ttm = bo->ttm;
> if (ttm_tt_populate(bo->ttm, )) {
> ret = VM_FAULT_OOM;
>diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
>index 2ec448e1d663..e25d4097aa16 100644
>---
RE: [PATCH 1/2] drm/ttm: cleanup ttm_mem_type_manager_func.get_node interface v2
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Monday, June 29, 2020 8:22 AM
>To: dri-devel@lists.freedesktop.org
>Subject: [PATCH 1/2] drm/ttm: cleanup
>ttm_mem_type_manager_func.get_node interface v2
>
>Instead of signaling failure by setting the node pointer to
>NULL do so by returning -ENOSPC.
>
>v2: add memset() to make sure that mem is always initialized.
>
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 4 +---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 5 ++---
> drivers/gpu/drm/nouveau/nouveau_ttm.c | 8
> drivers/gpu/drm/ttm/ttm_bo.c | 12 ++--
> drivers/gpu/drm/ttm/ttm_bo_manager.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 4 +---
> 6 files changed, 11 insertions(+), 24 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
>index 627104401e84..2baa80224fa4 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
>@@ -229,7 +229,7 @@ static int amdgpu_gtt_mgr_new(struct
>ttm_mem_type_manager *man,
> if ((>mem == mem || tbo->mem.mem_type != TTM_PL_TT) &&
> atomic64_read(>available) < mem->num_pages) {
> spin_unlock(>lock);
>- return 0;
>+ return -ENOSPC;
> }
> atomic64_sub(mem->num_pages, >available);
> spin_unlock(>lock);
>@@ -249,8 +249,6 @@ static int amdgpu_gtt_mgr_new(struct
>ttm_mem_type_manager *man,
> r = amdgpu_gtt_mgr_alloc(man, tbo, place, mem);
> if (unlikely(r)) {
> kfree(node);
>- mem->mm_node = NULL;
>- r = 0;
I think that this one is still a problem. The code path sets:
mem->mm_node = node;
(about 3 lines above this chunk, and then calls
amdgpu_gtt_mgr_malloc()
If amdgpu_gtt_mgr_malloc() fails, mm_node is still set. I think you need to
keep
this mm_node = NULL setting, or the path needs to be modified to not set
mm_node.
> goto err_out;
> }
> } else {
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>index 128a667ed8fa..e8d1dd564006 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>@@ -336,8 +336,7 @@ static int amdgpu_vram_mgr_new(struct
>ttm_mem_type_manager *man,
> mem_bytes = (u64)mem->num_pages << PAGE_SHIFT;
> if (atomic64_add_return(mem_bytes, >usage) > max_bytes) {
> atomic64_sub(mem_bytes, >usage);
>- mem->mm_node = NULL;
>- return 0;
>+ return -ENOSPC;
> }
>
> if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
>@@ -417,7 +416,7 @@ static int amdgpu_vram_mgr_new(struct
>ttm_mem_type_manager *man,
> atomic64_sub(mem->num_pages << PAGE_SHIFT, >usage);
>
> kvfree(nodes);
>- return r == -ENOSPC ? 0 : r;
>+ return r;
> }
>
> /**
>diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
>b/drivers/gpu/drm/nouveau/nouveau_ttm.c
>index 7ca0a2498532..e89ea052cf71 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
>@@ -75,10 +75,6 @@ nouveau_vram_manager_new(struct
>ttm_mem_type_manager *man,
> ret = nouveau_mem_vram(reg, nvbo->contig, nvbo->page);
> if (ret) {
> nouveau_mem_del(reg);
>- if (ret == -ENOSPC) {
>- reg->mm_node = NULL;
>- return 0;
>- }
> return ret;
> }
>
>@@ -139,10 +135,6 @@ nv04_gart_manager_new(struct
>ttm_mem_type_manager *man,
> reg->num_pages << PAGE_SHIFT, >vma[0]);
> if (ret) {
> nouveau_mem_del(reg);
>- if (ret == -ENOSPC) {
>- reg->mm_node = NULL;
>- return 0;
>- }
> return ret;
> }
>
>diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>index f78cfc76ad78..06b8bc0d8f23 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo.c
>@@ -909,10 +909,10 @@ static int ttm_bo_mem_force_space(struct
>ttm_buffer_object *bo,
> ticket = dma_resv_locking_ctx(bo->base.resv);
> do {
> ret = (*man->func->get_node)(man, bo, place, mem);
>- if (unlikely(ret != 0))
>- return ret;
>- if (mem->mm_node)
>+ if (likely(!ret))
> break;
>+ if (unlikely(ret != -ENOSPC))
>+ return ret;
> ret = ttm_mem_evict_first(bdev, mem->mem_type, place,
>ctx,
> ticket);
> if (unlikely(ret != 0))
>@@ -1056,12 +1056,11 @@ int ttm_bo_mem_space(struct ttm_buffer_object
>*bo,
>
>
[PATCH 2/2] drm/ttm: make TT creation purely optional v2
We only need the page array when the BO is about to be accessed.
So not only populate, but also create it on demand.
v2: move NULL check into ttm_tt_create()
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 37 ---
drivers/gpu/drm/ttm/ttm_bo_util.c | 9 ++--
drivers/gpu/drm/ttm/ttm_bo_vm.c | 5 +
drivers/gpu/drm/ttm/ttm_tt.c | 4 +++-
4 files changed, 24 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 06b8bc0d8f23..c8c25e45751a 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -292,12 +292,11 @@ static int ttm_bo_handle_move_mem(struct
ttm_buffer_object *bo,
*/
if (!(new_man->flags & TTM_MEMTYPE_FLAG_FIXED)) {
- if (bo->ttm == NULL) {
- bool zero = !(old_man->flags & TTM_MEMTYPE_FLAG_FIXED);
- ret = ttm_tt_create(bo, zero);
- if (ret)
- goto out_err;
- }
+ bool zero = !(old_man->flags & TTM_MEMTYPE_FLAG_FIXED);
+
+ ret = ttm_tt_create(bo, zero);
+ if (ret)
+ goto out_err;
ret = ttm_tt_set_placement_caching(bo->ttm, mem->placement);
if (ret)
@@ -660,13 +659,8 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
placement.num_busy_placement = 0;
bdev->driver->evict_flags(bo, );
- if (!placement.num_placement && !placement.num_busy_placement) {
- ret = ttm_bo_pipeline_gutting(bo);
- if (ret)
- return ret;
-
- return ttm_tt_create(bo, false);
- }
+ if (!placement.num_placement && !placement.num_busy_placement)
+ return ttm_bo_pipeline_gutting(bo);
evict_mem = bo->mem;
evict_mem.mm_node = NULL;
@@ -1194,13 +1188,8 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
/*
* Remove the backing store if no placement is given.
*/
- if (!placement->num_placement && !placement->num_busy_placement) {
- ret = ttm_bo_pipeline_gutting(bo);
- if (ret)
- return ret;
-
- return ttm_tt_create(bo, false);
- }
+ if (!placement->num_placement && !placement->num_busy_placement)
+ return ttm_bo_pipeline_gutting(bo);
/*
* Check whether we need to move buffer.
@@ -1217,14 +1206,6 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
ttm_flag_masked(>mem.placement, new_flags,
~TTM_PL_MASK_MEMTYPE);
}
- /*
-* We might need to add a TTM.
-*/
- if (bo->mem.mem_type == TTM_PL_SYSTEM && bo->ttm == NULL) {
- ret = ttm_tt_create(bo, true);
- if (ret)
- return ret;
- }
return 0;
}
EXPORT_SYMBOL(ttm_bo_validate);
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 52d2b71f1588..f8414f820350 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -580,12 +580,17 @@ static int ttm_bo_kmap_ttm(struct ttm_buffer_object *bo,
.interruptible = false,
.no_wait_gpu = false
};
- struct ttm_tt *ttm = bo->ttm;
+ struct ttm_tt *ttm;
pgprot_t prot;
int ret;
- BUG_ON(!ttm);
+ if (!bo->ttm) {
+ ret = ttm_tt_create(bo, true);
+ if (ret)
+ return ret;
+ }
+ ttm = bo->ttm;
ret = ttm_tt_populate(ttm, );
if (ret)
return ret;
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 0ad30b112982..0586870ab642 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -349,6 +349,11 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
};
+ if (ttm_tt_create(bo, true)) {
+ ret = VM_FAULT_OOM;
+ goto out_io_unlock;
+ }
+
ttm = bo->ttm;
if (ttm_tt_populate(bo->ttm, )) {
ret = VM_FAULT_OOM;
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 2ec448e1d663..e25d4097aa16 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -50,6 +50,9 @@ int ttm_tt_create(struct ttm_buffer_object *bo, bool
zero_alloc)
dma_resv_assert_held(bo->base.resv);
+ if (bo->ttm)
+ return 0;
+
if (bdev->need_dma32)
page_flags |= TTM_PAGE_FLAG_DMA32;
@@ -67,7 +70,6 @@ int ttm_tt_create(struct ttm_buffer_object *bo, bool
zero_alloc)
page_flags |= TTM_PAGE_FLAG_SG;
break;
default:
-
[PATCH 1/2] drm/ttm: cleanup ttm_mem_type_manager_func.get_node interface v2
Instead of signaling failure by setting the node pointer to
NULL do so by returning -ENOSPC.
v2: add memset() to make sure that mem is always initialized.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 4 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 5 ++---
drivers/gpu/drm/nouveau/nouveau_ttm.c | 8
drivers/gpu/drm/ttm/ttm_bo.c | 12 ++--
drivers/gpu/drm/ttm/ttm_bo_manager.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 4 +---
6 files changed, 11 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 627104401e84..2baa80224fa4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -229,7 +229,7 @@ static int amdgpu_gtt_mgr_new(struct ttm_mem_type_manager
*man,
if ((>mem == mem || tbo->mem.mem_type != TTM_PL_TT) &&
atomic64_read(>available) < mem->num_pages) {
spin_unlock(>lock);
- return 0;
+ return -ENOSPC;
}
atomic64_sub(mem->num_pages, >available);
spin_unlock(>lock);
@@ -249,8 +249,6 @@ static int amdgpu_gtt_mgr_new(struct ttm_mem_type_manager
*man,
r = amdgpu_gtt_mgr_alloc(man, tbo, place, mem);
if (unlikely(r)) {
kfree(node);
- mem->mm_node = NULL;
- r = 0;
goto err_out;
}
} else {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 128a667ed8fa..e8d1dd564006 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -336,8 +336,7 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager
*man,
mem_bytes = (u64)mem->num_pages << PAGE_SHIFT;
if (atomic64_add_return(mem_bytes, >usage) > max_bytes) {
atomic64_sub(mem_bytes, >usage);
- mem->mm_node = NULL;
- return 0;
+ return -ENOSPC;
}
if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
@@ -417,7 +416,7 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager
*man,
atomic64_sub(mem->num_pages << PAGE_SHIFT, >usage);
kvfree(nodes);
- return r == -ENOSPC ? 0 : r;
+ return r;
}
/**
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index 7ca0a2498532..e89ea052cf71 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -75,10 +75,6 @@ nouveau_vram_manager_new(struct ttm_mem_type_manager *man,
ret = nouveau_mem_vram(reg, nvbo->contig, nvbo->page);
if (ret) {
nouveau_mem_del(reg);
- if (ret == -ENOSPC) {
- reg->mm_node = NULL;
- return 0;
- }
return ret;
}
@@ -139,10 +135,6 @@ nv04_gart_manager_new(struct ttm_mem_type_manager *man,
reg->num_pages << PAGE_SHIFT, >vma[0]);
if (ret) {
nouveau_mem_del(reg);
- if (ret == -ENOSPC) {
- reg->mm_node = NULL;
- return 0;
- }
return ret;
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index f78cfc76ad78..06b8bc0d8f23 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -909,10 +909,10 @@ static int ttm_bo_mem_force_space(struct
ttm_buffer_object *bo,
ticket = dma_resv_locking_ctx(bo->base.resv);
do {
ret = (*man->func->get_node)(man, bo, place, mem);
- if (unlikely(ret != 0))
- return ret;
- if (mem->mm_node)
+ if (likely(!ret))
break;
+ if (unlikely(ret != -ENOSPC))
+ return ret;
ret = ttm_mem_evict_first(bdev, mem->mem_type, place, ctx,
ticket);
if (unlikely(ret != 0))
@@ -1056,12 +1056,11 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
man = >man[mem->mem_type];
ret = (*man->func->get_node)(man, bo, place, mem);
+ if (ret == -ENOSPC)
+ continue;
if (unlikely(ret))
goto error;
- if (!mem->mm_node)
- continue;
-
ret = ttm_bo_add_move_fence(bo, man, mem, ctx->no_wait_gpu);
if (unlikely(ret)) {
(*man->func->put_node)(man, mem);
@@ -1121,6 +1120,7 @@ static int ttm_bo_move_buffer(struct ttm_buffer_object
*bo,
Patch "drm/panel-simple: fix connector type for LogicPD Type28 Display" has been added to the 5.7-stable tree
This is a note to let you know that I've just added the patch titled
drm/panel-simple: fix connector type for LogicPD Type28 Display
to the 5.7-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-panel-simple-fix-connector-type-for-logicpd-type28-display.patch
and it can be found in the queue-5.7 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From efb94790852ae673b18efde1b171d284689ff333 Mon Sep 17 00:00:00 2001
From: Adam Ford
Date: Mon, 15 Jun 2020 08:19:34 -0500
Subject: drm/panel-simple: fix connector type for LogicPD Type28 Display
From: Adam Ford
commit efb94790852ae673b18efde1b171d284689ff333 upstream.
The LogicPD Type28 display used by several Logic PD products has not
worked since v5.6.
The connector type for the LogicPD Type 28 display is missing and
drm_panel_bridge_add() requires connector type to be set.
Signed-off-by: Adam Ford
Fixes: 0d35408afbeb ("drm/panel: simple: Add Logic PD Type 28 display support")
Cc: Adam Ford
Cc: Sam Ravnborg
Cc: Thierry Reding
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.6+
Signed-off-by: Sam Ravnborg
Link:
https://patchwork.freedesktop.org/patch/msgid/20200615131934.12440-1-aford...@gmail.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/panel/panel-simple.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2297,6 +2297,7 @@ static const struct panel_desc logicpd_t
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE |
DRM_BUS_FLAG_SYNC_DRIVE_NEGEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
};
static const struct panel_desc mitsubishi_aa070mc01 = {
Patches currently in stable-queue which might be from aford...@gmail.com are
queue-5.7/drm-panel-simple-fix-connector-type-for-logicpd-type28-display.patch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Patch "drm/fb-helper: Fix vt restore" has been added to the 5.7-stable tree
This is a note to let you know that I've just added the patch titled
drm/fb-helper: Fix vt restore
to the 5.7-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-fb-helper-fix-vt-restore.patch
and it can be found in the queue-5.7 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
From dc5bdb68b5b369d5bc7d1de96fa64cc1737a6320 Mon Sep 17 00:00:00 2001
From: Daniel Vetter
Date: Wed, 24 Jun 2020 11:29:10 +0200
Subject: drm/fb-helper: Fix vt restore
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Daniel Vetter
commit dc5bdb68b5b369d5bc7d1de96fa64cc1737a6320 upstream.
In the past we had a pile of hacks to orchestrate access between fbdev
emulation and native kms clients. We've tried to streamline this, by
always preferring the kms side above fbdev calls when a drm master
exists, because drm master controls access to the display resources.
Unfortunately this breaks existing userspace, specifically Xorg. When
exiting Xorg first restores the console to text mode using the KDSET
ioctl on the vt. This does nothing, because a drm master is still
around. Then it drops the drm master status, which again does nothing,
because logind is keeping additional drm fd open to be able to
orchestrate vt switches. In the past this is the point where fbdev was
restored, as part of the ->lastclose hook on the drm side.
Now to fix this regression we don't want to go back to letting fbdev
restore things whenever it feels like, or to the pile of hacks we've
had before. Instead try and go with a minimal exception to make the
KDSET case work again, and nothing else.
This means that if userspace does a KDSET call when switching between
graphical compositors, there will be some flickering with fbcon
showing up for a bit. But a) that's not a regression and b) userspace
can fix it by improving the vt switching dance - logind should have
all the information it needs.
While pondering all this I'm also wondering wheter we should have a
SWITCH_MASTER ioctl to allow race-free master status handover. But
that's for another day.
v2: Somehow forgot to cc all the fbdev people.
v3: Fix typo Alex spotted.
Reviewed-by: Alex Deucher
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=208179
Cc: shl...@fastmail.com
Reported-and-Tested-by: shl...@fastmail.com
Cc: Michel Dänzer
Fixes: 64914da24ea9 ("drm/fbdev-helper: don't force restores")
Cc: Noralf Trønnes
Cc: Thomas Zimmermann
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.7+
Cc: Bartlomiej Zolnierkiewicz
Cc: Geert Uytterhoeven
Cc: Nathan Chancellor
Cc: Qiujun Huang
Cc: Peter Rosin
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20200624092910.3280448-1-daniel.vet...@ffwll.ch
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_fb_helper.c | 63 ++-
drivers/video/fbdev/core/fbcon.c |3 +
include/uapi/linux/fb.h |1
3 files changed, 52 insertions(+), 15 deletions(-)
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -227,18 +227,9 @@ int drm_fb_helper_debug_leave(struct fb_
}
EXPORT_SYMBOL(drm_fb_helper_debug_leave);
-/**
- * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
- * @fb_helper: driver-allocated fbdev helper, can be NULL
- *
- * This should be called from driver's drm _driver.lastclose callback
- * when implementing an fbcon on top of kms using this helper. This ensures
that
- * the user isn't greeted with a black screen when e.g. X dies.
- *
- * RETURNS:
- * Zero if everything went ok, negative error code otherwise.
- */
-int drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper)
+static int
+__drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper,
+ bool force)
{
bool do_delayed;
int ret;
@@ -250,7 +241,16 @@ int drm_fb_helper_restore_fbdev_mode_unl
return 0;
mutex_lock(_helper->lock);
- ret = drm_client_modeset_commit(_helper->client);
+ if (force) {
+ /*
+* Yes this is the _locked version which expects the master lock
+* to be held. But for forced restores we're intentionally
+* racing here, see drm_fb_helper_set_par().
+*/
+ ret = drm_client_modeset_commit_locked(_helper->client);
+ } else {
+ ret = drm_client_modeset_commit(_helper->client);
+ }
do_delayed = fb_helper->delayed_hotplug;
if (do_delayed)
@@ -262,6 +262,22 @@ int drm_fb_helper_restore_fbdev_mode_unl
return ret;
}
+
Re: [PATCH v6 2/4] driver core: add deferring probe reason to devices_deferred property
Hi Grygorii, (...) >> /* >> * deferred_devs_show() - Show the devices in the deferred probe >> pending list. >> */ >> @@ -221,7 +241,8 @@ static int deferred_devs_show(struct seq_file *s, >> void *data) >> mutex_lock(_probe_mutex); >> list_for_each_entry(curr, _probe_pending_list, >> deferred_probe) >> - seq_printf(s, "%s\n", dev_name(curr->device)); >> + seq_printf(s, "%s\t%s", dev_name(curr->device), >> + curr->device->p->deferred_probe_reason ?: "\n"); >> mutex_unlock(_probe_mutex); >> > > Sry, may be i missing smth, but shouldn't it be optional > (CONFIG_DEBUG_FS is probably too generic). > I am not sure what exactly are you referring to, but this patch does not add new property, it just extends functionality of existing one. Regards Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 2/4] driver core: add deferring probe reason to devices_deferred property
/sys/kernel/debug/devices_deferred property contains list of deferred devices.
This list does not contain reason why the driver deferred probe, the patch
improves it.
The natural place to set the reason is dev_err_probe function introduced
recently,
ie. if dev_err_probe will be called with -EPROBE_DEFER instead of printk the
message
will be attached to deferred device and printed when user read devices_deferred
property.
Signed-off-by: Andrzej Hajda
Reviewed-by: Mark Brown
Reviewed-by: Javier Martinez Canillas
Reviewed-by: Andy Shevchenko
Reviewed-by: Rafael J. Wysocki
---
drivers/base/base.h | 3 +++
drivers/base/core.c | 8 ++--
drivers/base/dd.c | 23 ++-
3 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/drivers/base/base.h b/drivers/base/base.h
index 95c22c0f9036..6954fccab3d7 100644
--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -93,6 +93,7 @@ struct device_private {
struct klist_node knode_class;
struct list_head deferred_probe;
struct device_driver *async_driver;
+ char *deferred_probe_reason;
struct device *device;
u8 dead:1;
};
@@ -134,6 +135,8 @@ extern void device_release_driver_internal(struct device
*dev,
extern void driver_detach(struct device_driver *drv);
extern int driver_probe_device(struct device_driver *drv, struct device *dev);
extern void driver_deferred_probe_del(struct device *dev);
+extern void device_set_deferred_probe_reson(const struct device *dev,
+ struct va_format *vaf);
static inline int driver_match_device(struct device_driver *drv,
struct device *dev)
{
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 3a827c82933f..fee047f03681 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -3963,6 +3963,8 @@ define_dev_printk_level(_dev_info, KERN_INFO);
* This helper implements common pattern present in probe functions for error
* checking: print debug or error message depending if the error value is
* -EPROBE_DEFER and propagate error upwards.
+ * In case of -EPROBE_DEFER it sets also defer probe reason, which can be
+ * checked later by reading devices_deferred debugfs attribute.
* It replaces code sequence:
* if (err != -EPROBE_DEFER)
* dev_err(dev, ...);
@@ -3984,10 +3986,12 @@ int dev_err_probe(const struct device *dev, int err,
const char *fmt, ...)
vaf.fmt = fmt;
vaf.va =
- if (err != -EPROBE_DEFER)
+ if (err != -EPROBE_DEFER) {
dev_err(dev, "error %d: %pV", err, );
- else
+ } else {
+ device_set_deferred_probe_reson(dev, );
dev_dbg(dev, "error %d: %pV", err, );
+ }
va_end(args);
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 9a1d940342ac..dd5683b61f74 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include "base.h"
#include "power/power.h"
@@ -136,6 +137,8 @@ void driver_deferred_probe_del(struct device *dev)
if (!list_empty(>p->deferred_probe)) {
dev_dbg(dev, "Removed from deferred list\n");
list_del_init(>p->deferred_probe);
+ kfree(dev->p->deferred_probe_reason);
+ dev->p->deferred_probe_reason = NULL;
}
mutex_unlock(_probe_mutex);
}
@@ -211,6 +214,23 @@ void device_unblock_probing(void)
driver_deferred_probe_trigger();
}
+/**
+ * device_set_deferred_probe_reson() - Set defer probe reason message for
device
+ * @dev: the pointer to the struct device
+ * @vaf: the pointer to va_format structure with message
+ */
+void device_set_deferred_probe_reson(const struct device *dev, struct
va_format *vaf)
+{
+ const char *drv = dev_driver_string(dev);
+
+ mutex_lock(_probe_mutex);
+
+ kfree(dev->p->deferred_probe_reason);
+ dev->p->deferred_probe_reason = kasprintf(GFP_KERNEL, "%s: %pV", drv,
vaf);
+
+ mutex_unlock(_probe_mutex);
+}
+
/*
* deferred_devs_show() - Show the devices in the deferred probe pending list.
*/
@@ -221,7 +241,8 @@ static int deferred_devs_show(struct seq_file *s, void
*data)
mutex_lock(_probe_mutex);
list_for_each_entry(curr, _probe_pending_list, deferred_probe)
- seq_printf(s, "%s\n", dev_name(curr->device));
+ seq_printf(s, "%s\t%s", dev_name(curr->device),
+ curr->device->p->deferred_probe_reason ?: "\n");
mutex_unlock(_probe_mutex);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 1/4] driver core: add device probe log helper
During probe every time driver gets resource it should usually check for
error printk some message if it is not -EPROBE_DEFER and return the error.
This pattern is simple but requires adding few lines after any resource
acquisition code, as a result it is often omitted or implemented only
partially.
dev_err_probe helps to replace such code sequences with simple call,
so code:
if (err != -EPROBE_DEFER)
dev_err(dev, ...);
return err;
becomes:
return dev_err_probe(dev, err, ...);
Signed-off-by: Andrzej Hajda
Reviewed-by: Rafael J. Wysocki
---
drivers/base/core.c| 42 ++
include/linux/device.h | 3 +++
2 files changed, 45 insertions(+)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 67d39a90b45c..3a827c82933f 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -3953,6 +3953,48 @@ define_dev_printk_level(_dev_info, KERN_INFO);
#endif
+/**
+ * dev_err_probe - probe error check and log helper
+ * @dev: the pointer to the struct device
+ * @err: error value to test
+ * @fmt: printf-style format string
+ * @...: arguments as specified in the format string
+ *
+ * This helper implements common pattern present in probe functions for error
+ * checking: print debug or error message depending if the error value is
+ * -EPROBE_DEFER and propagate error upwards.
+ * It replaces code sequence:
+ * if (err != -EPROBE_DEFER)
+ * dev_err(dev, ...);
+ * else
+ * dev_dbg(dev, ...);
+ * return err;
+ * with
+ * return dev_err_probe(dev, err, ...);
+ *
+ * Returns @err.
+ *
+ */
+int dev_err_probe(const struct device *dev, int err, const char *fmt, ...)
+{
+ struct va_format vaf;
+ va_list args;
+
+ va_start(args, fmt);
+ vaf.fmt = fmt;
+ vaf.va =
+
+ if (err != -EPROBE_DEFER)
+ dev_err(dev, "error %d: %pV", err, );
+ else
+ dev_dbg(dev, "error %d: %pV", err, );
+
+ va_end(args);
+
+ return err;
+}
+EXPORT_SYMBOL_GPL(dev_err_probe);
+
static inline bool fwnode_is_primary(struct fwnode_handle *fwnode)
{
return fwnode && !IS_ERR(fwnode->secondary);
diff --git a/include/linux/device.h b/include/linux/device.h
index 15460a5ac024..6b2272ae9af8 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -964,6 +964,9 @@ void device_link_remove(void *consumer, struct device
*supplier);
void device_links_supplier_sync_state_pause(void);
void device_links_supplier_sync_state_resume(void);
+extern __printf(3, 4)
+int dev_err_probe(const struct device *dev, int err, const char *fmt, ...);
+
/* Create alias, so I can be autoloaded. */
#define MODULE_ALIAS_CHARDEV(major,minor) \
MODULE_ALIAS("char-major-" __stringify(major) "-" __stringify(minor))
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 3/4] drm/bridge/sii8620: fix resource acquisition error handling
In case of error during resource acquisition driver should print error
message only in case it is not deferred probe, using dev_err_probe helper
solves the issue. Moreover it records defer probe reason for debugging.
Signed-off-by: Andrzej Hajda
Reviewed-by: Neil Armstrong
---
drivers/gpu/drm/bridge/sil-sii8620.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 92acd336aa89..389c1f029774 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -2299,10 +2299,9 @@ static int sii8620_probe(struct i2c_client *client,
INIT_LIST_HEAD(>mt_queue);
ctx->clk_xtal = devm_clk_get(dev, "xtal");
- if (IS_ERR(ctx->clk_xtal)) {
- dev_err(dev, "failed to get xtal clock from DT\n");
- return PTR_ERR(ctx->clk_xtal);
- }
+ if (IS_ERR(ctx->clk_xtal))
+ return dev_err_probe(dev, PTR_ERR(ctx->clk_xtal),
+"failed to get xtal clock from DT\n");
if (!client->irq) {
dev_err(dev, "no irq provided\n");
@@ -2313,16 +2312,14 @@ static int sii8620_probe(struct i2c_client *client,
sii8620_irq_thread,
IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
"sii8620", ctx);
- if (ret < 0) {
- dev_err(dev, "failed to install IRQ handler\n");
- return ret;
- }
+ if (ret < 0)
+ return dev_err_probe(dev, ret,
+"failed to install IRQ handler\n");
ctx->gpio_reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
- if (IS_ERR(ctx->gpio_reset)) {
- dev_err(dev, "failed to get reset gpio from DT\n");
- return PTR_ERR(ctx->gpio_reset);
- }
+ if (IS_ERR(ctx->gpio_reset))
+ return dev_err_probe(dev, PTR_ERR(ctx->gpio_reset),
+"failed to get reset gpio from DT\n");
ctx->supplies[0].supply = "cvcc10";
ctx->supplies[1].supply = "iovcc18";
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 0/4] driver core: add probe error check helper
Hi All, Thanks for comments. Changes since v6: - removed leftovers from old naming scheme in commit descritions, - added R-Bs. Changes since v5: - removed patch adding macro, dev_err_probe(dev, PTR_ERR(ptr), ...) should be used instead, - added dev_dbg logging in case of -EPROBE_DEFER, - renamed functions and vars according to comments, - extended docs, - cosmetics. Original message (with small adjustments): Recently I took some time to re-check error handling in drivers probe code, and I have noticed that number of incorrect resource acquisition error handling increased and there are no other propositions which can cure the situation. So I have decided to resend my old proposition of probe_err helper which should simplify resource acquisition error handling, it also extend it with adding defer probe reason to devices_deferred debugfs property, which should improve debugging experience for developers/testers. I have also added two patches showing usage and benefits of the helper. My dirty/ad-hoc cocci scripts shows that this helper can be used in at least 2700 places saving about 3500 lines of code. Regards Andrzej Andrzej Hajda (4): driver core: add device probe log helper driver core: add deferring probe reason to devices_deferred property drm/bridge/sii8620: fix resource acquisition error handling drm/bridge: lvds-codec: simplify error handling drivers/base/base.h | 3 ++ drivers/base/core.c | 46 drivers/base/dd.c| 23 +- drivers/gpu/drm/bridge/lvds-codec.c | 10 ++ drivers/gpu/drm/bridge/sil-sii8620.c | 21 ++--- include/linux/device.h | 3 ++ 6 files changed, 86 insertions(+), 20 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 4/4] drm/bridge: lvds-codec: simplify error handling
Using dev_err_probe code has following advantages:
- shorter code,
- recorded defer probe reason for debugging,
- uniform error code logging.
Signed-off-by: Andrzej Hajda
Reviewed-by: Neil Armstrong
---
drivers/gpu/drm/bridge/lvds-codec.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
b/drivers/gpu/drm/bridge/lvds-codec.c
index 24fb1befdfa2..f19d9f7a5db2 100644
--- a/drivers/gpu/drm/bridge/lvds-codec.c
+++ b/drivers/gpu/drm/bridge/lvds-codec.c
@@ -71,13 +71,9 @@ static int lvds_codec_probe(struct platform_device *pdev)
lvds_codec->connector_type = (uintptr_t)of_device_get_match_data(dev);
lvds_codec->powerdown_gpio = devm_gpiod_get_optional(dev, "powerdown",
GPIOD_OUT_HIGH);
- if (IS_ERR(lvds_codec->powerdown_gpio)) {
- int err = PTR_ERR(lvds_codec->powerdown_gpio);
-
- if (err != -EPROBE_DEFER)
- dev_err(dev, "powerdown GPIO failure: %d\n", err);
- return err;
- }
+ if (IS_ERR(lvds_codec->powerdown_gpio))
+ return dev_err_probe(dev, PTR_ERR(lvds_codec->powerdown_gpio),
+"powerdown GPIO failure\n");
/* Locate the panel DT node. */
panel_node = of_graph_get_remote_node(dev->of_node, 1, 0);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] backlight: sky81452: Privatize platform data
On Fri, Jun 26, 2020 at 10:37:42PM +0200, Linus Walleij wrote: > The only way the platform data for the SKY81452 ever gets populated > is through the device tree. > > The MFD device is bothered with this for no reason at all. Just > allocate the platform data in the driver and be happy. > > Cc: Gyungoh Yoo > Signed-off-by: Linus Walleij Reviewed-by: Daniel Thompson Daniel. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] backlight: sky81452: Convert to GPIO descriptors
On Fri, Jun 26, 2020 at 10:37:41PM +0200, Linus Walleij wrote: > The SKY81452 backlight driver just obtains a GPIO (named "gpios" > in the device tree) drives it high and leaves it high until the > driver is removed. > > Switch to use GPIO descriptors for this, simple and > straight-forward. > > Cc: Gyungoh Yoo > Signed-off-by: Linus Walleij Reviewed-by: Daniel Thompson Daniel. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208373] New: drm:drm_atomic_helper_wait_for_dependencies - drm_kms_helper - flip_done timed out
https://bugzilla.kernel.org/show_bug.cgi?id=208373 Bug ID: 208373 Summary: drm:drm_atomic_helper_wait_for_dependencies - drm_kms_helper - flip_done timed out Product: Drivers Version: 2.5 Kernel Version: 5.7.2 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: ionut_n2...@yahoo.com Regression: No Hi Kernel Team, With 5.7.2, observe this issue: [1263266.374115] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:38:crtc-0] flip_done timed out [1263276.614099] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:34:plane-0] flip_done timed out [1266457.945569] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:38:crtc-0] flip_done timed out [1266468.185524] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:34:plane-0] flip_done timed out [1268050.016722] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:38:crtc-0] flip_done timed out [1268060.256836] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:34:plane-0] flip_done timed out [1270654.054668] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:38:crtc-0] flip_done timed out [1270664.294675] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:34:plane-0] flip_done timed out [1271127.144282] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:38:crtc-0] flip_done timed out [1271137.384328] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:34:plane-0] flip_done timed out [1274245.495567] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:38:crtc-0] flip_done timed out [1274255.735657] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:34:plane-0] flip_done timed out [1279238.818759] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:38:crtc-0] flip_done timed out [1279249.058822] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:34:plane-0] flip_done timed out dmesg | grep drm [2.598899] [drm] DMA map mode: Caching DMA mappings. [2.599179] [drm] Capabilities: [2.599297] [drm] Rect copy. [2.599369] [drm] Cursor. [2.599412] [drm] Cursor bypass. [2.599461] [drm] Cursor bypass 2. [2.599510] [drm] 8bit emulation. [2.599558] [drm] Alpha cursor. [2.599605] [drm] Extended Fifo. [2.599653] [drm] Multimon. [2.599696] [drm] Pitchlock. [2.599740] [drm] Irq mask. [2.599784] [drm] Display Topology. [2.599834] [drm] GMR. [2.599873] [drm] Traces. [2.599915] [drm] GMR2. [2.599955] [drm] Screen Object 2. [2.65] [drm] Command Buffers. [2.600054] [drm] Command Buffers 2. [2.600105] [drm] Guest Backed Resources. [2.600160] [drm] DX Features. [2.600476] [drm] HP Command Queue. [2.600527] [drm] Capabilities2: [2.600573] [drm] Grow oTable. [2.600620] [drm] IntraSurface copy. [2.600671] [drm] Max GMR ids is 64 [2.600721] [drm] Max number of GMR pages is 65536 [2.600782] [drm] Max dedicated hypervisor surface memory is 0 kiB [2.600857] [drm] Maximum display memory size is 16384 kiB [2.600925] [drm] VRAM at 0xe800 size is 4096 kiB [2.600990] [drm] MMIO at 0xfe00 size is 256 kiB [2.601616] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [2.601785] [drm] Screen Target Display device initialized [2.601890] [drm] width 640 [2.601938] [drm] height 480 [2.601986] [drm] bpp 32 [2.621888] [drm] Fifo max 0x0004 min 0x1000 cap 0x077f [2.625498] [drm] Using command buffers with DMA pool. [2.625580] [drm] Atomic: yes. [2.630205] fbcon: svgadrmfb (fb0) is primary device [2.642217] [drm] Initialized vmwgfx 2.18.0 20200114 for :00:0f.0 on minor 0 cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-5.7.2-vanilla root=UUID=27e2847b-d1ad-427c-97ed-b0b65028d30a ro video=SVIDEO-1:d lspci | grep 00:0f.0 00:0f.0 VGA compatible controller: VMware SVGA II Adapter lspci -s 00:0f.0 -v 00:0f.0 VGA compatible controller: VMware SVGA II Adapter (prog-if 00 [VGA controller]) Subsystem: VMware SVGA II Adapter Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Capabilities: [44] PCI Advanced Features AFCap: TP+ FLR+ AFCtrl: FLR- AFStatus: TP- Kernel driver in use: vmwgfx Kernel modules:
Re: [RFC] Host1x/TegraDRM UAPI (sync points)
On 6/29/20 5:36 AM, Dmitry Osipenko wrote:
28.06.2020 12:44, Mikko Perttunen пишет:
On 6/28/20 2:27 AM, Dmitry Osipenko wrote:
23.06.2020 15:09, Mikko Perttunen пишет:
### IOCTL HOST1X_ALLOCATE_SYNCPOINT (on /dev/host1x)
Allocates a free syncpoint, returning a file descriptor representing it.
Only the owner of the file descriptor is allowed to mutate the value of
the syncpoint.
```
struct host1x_ctrl_allocate_syncpoint {
/**
* @fd:
*
* [out] New file descriptor representing the allocated
syncpoint.
*/
__s32 fd;
__u32 reserved[3];
};
We should need at least these basic things from the sync points API >
- Execution context shouldn't be able to tamper sync points of the other
contexts.
This is covered by this UAPI - when submitting, as part of the
syncpt_incr struct you pass the syncpoint FD. This way the driver can
check the syncpoints used are correct, or program HW protection.
- Sync point could be shared with other contexts for explicit fencing.
Not sure what you specifically mean; you can get the ID out of the
syncpoint fd and share the ID for read-only access. (Or the FD for
read-write access)
I enumerated the overall points that UAPI should provide to us, just for
clarity. Not like you haven't covered any of them, sorry for the
confusion! :)
Please see more comments below!
Ok, good :)
- Sync points should work reliably.
Some problems of the current Host1x driver, like where it falls over if
sync point value is out-of-sync + all the hang-job recovery labor could
be easily reduced if sync point health is protected by extra UAPI
constraints. >
So I think we may want the following:
1. We still should need to assign sync point ID to a DRM-channel's
context. This sync point ID will be used for a commands stream forming,
like it is done by the current staging UAPI.
So we should need to retain the DRM_TEGRA_GET_SYNCPT IOCTL, but
improve it.
My point here is that the UAPI shouldn't be able to increment the job's
sync point using SYNCPOINT_INCREMENT IOCTL, which is another UAPI
constraint.
I'm suggesting that we should have two methods of sync point allocations:
1) Sync point that could be used only by a submitted job.
2) Sync point that could be incremented by CPU.
The first method will allocate a raw sync point ID that is assigned to
the channel's context. This ID will be used for the job's completion
tracking. Perhaps this method also could optionally return a sync point
FD if you'd want to wait on this sync point by another job.
We don't need a dedicated sync point FD for all kinds of jobs, don't we?
For example, I don't see why a sync point FD may be needed in a case of
Opentegra jobs.
I think it's cleaner if we have just one way to allocate syncpoints, and
then those syncpoints can be passed to different things depending on the
situation.
If we want to protect direct incrementing while a job is submitted, we
could have a locking API where an ongoing job can take a lock refcount
in the syncpoint, and incrementing would return -EBUSY.
2. Allocated sync point must have a clean hardware state.
What do you mean by clean hardware state?
I mean that sync point should have a predictable state [1], it shouldn't
accidentally fire during of hardware programming for example.
[1]
https://github.com/grate-driver/linux/blob/master/drivers/gpu/host1x/soc/syncpoints.c#L132
For a submitted job, the job's sync point state could be reset at a
submission time, for example like I did it in the grate-kernel's
experimental driver [2].
[2]
https://github.com/grate-driver/linux/blob/master/drivers/gpu/host1x/soc/channel.c#L145
3. Sync points should be properly refcounted. Job's sync points
shouldn't be re-used while job is alive.
4. The job's sync point can't be re-used after job's submission (UAPI
constraint!). Userspace must free sync point and allocate a new one for
the next job submission. And now we:
- Know that job's sync point is always in a healthy state!
- We're not limited by a number of physically available hardware sync
points! Allocation should block until free sync point is available.
- The logical number of job's sync point increments matches the SP
hardware state! Which is handy for a job's debugging.
Optionally, the job's sync point could be auto-removed from the DRM's
context after job's submission, avoiding a need for an extra SYNCPT_PUT
IOCTL invocation to be done by userspace after the job's submission.
Could be a job's flag.
I think this would cause problems where after a job completes but before
the fence has been waited, the syncpoint is already recycled (especially
if the syncpoint is reset into some clean state).
Exactly, good point! The dma-fence shouldn't be hardwired to the sync
point in order to avoid this situation :)
Please take a look at the fence implementation that I made for the
grate-driver [3]. The host1x-fence is a dma-fence [4] that is attached
Re: [RFC][PATCH 0/9] drm: Support simple-framebuffer devices and firmware fbs
Hi, On 6/25/20 2:00 PM, Thomas Zimmermann wrote: This patchset adds support for simple-framebuffer platform devices and a handover mechanism for native drivers to take-over control of the hardware. The new driver, called simplekms, binds to a simple-frambuffer platform device. The kernel's boot code creates such devices for firmware-provided framebuffers, such as EFI-GOP or VESA. Typically the BIOS, UEFI or boot loader sets up the framebuffers. Description via device tree is also an option. Simplekms is small enough to be linked into the kernel. The driver's main purpose is to provide graphical output during the early phases of the boot process, before the native DRM drivers are available. Native drivers are typically loaded from an initrd ram disk. Occationally simplekms can also serve as interim solution on graphics hardware without native DRM driver. Cool, thank you for doing this, this is a very welcome change, but ... (see below). So far distributions rely on fbdev drivers, such as efifb, vesafb or simplefb, for early-boot graphical output. However fbdev is deprecated and the drivers do not provide DRM interfaces for modern userspace. Patches 1 and 2 prepare the DRM format helpers for simplekms. Patches 3 to 7 add the simplekms driver. It's build on simple DRM helpers and SHMEM. It supports 16-bit, 24-bit and 32-bit RGB framebuffers. During pageflips, SHMEM buffers are copied into the framebuffer memory, similar to cirrus or mgag200. The code in patches 6 and 7 handles clocks and regulators. It's based on the simplefb drivers, but has been modified for DRM. Patches 8 and 9 add a hand-over mechanism. Simplekms acquires it's framebuffer's I/O-memory range and provides a callback function to be removed by a native driver. The native driver will remove simplekms before taking over the hardware. The removal is integrated into existing helpers, so drivers use it automatically. I tested simplekms with x86 EFI and VESA framebuffers, which both work reliably. The fbdev console and Weston work automatically. Xorg requires manual configuration of the device. Xorgs current modesetting driver does not work with both, platform and PCI device, for the same physical hardware. Once configured, X11 works. Ugh, Xorg not working OOTB is a bit of a showstopper, we cannot just go around and break userspace. OTOH this does seem like an userspace issue and not something which we can (or should try to) fix in the kernel. I guess the solution will have to be to have this default to N for now in Kconfig and clearly mention in the Kconfig help text that this needs a fixed Xorg modesetting driver before it can be enabled. Any chance you have time to work on fixing the Xorg modesetting driver so that this will just work with the standard Xorg autoconfiguration stuff? One cosmetical issue is that simplekms's device file is card0 and the native driver's device file is card1. After simplekms has been kicked out, only card1 is left. This does not seem to be a practical problem however. TODO/IDEAS: * provide deferred takeover I assume you mean akin to CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER ? I don't think you need to do anything for that, as long as you just leave the fb contents intact until requested to change it. Right now with flickerfree boot we have fbcon on top of efifb and efifb does not do anything special wrt CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER ATM it does draw/restore the ACPI BGRT logo since since some firmwares don't draw that themselves, but that is not necessary in most cases and other then that all the deferred takeover magic is in the fbcon code, it does not bind to the fbdev (and thus does not draw to it) until the first time the kernel tries to output text to the console, together with the "quiet" kernel commandline argument that ensures that the fb is kept unmodified until e.g. a panic happens. With simplekms we would replace "fbcon on top of efifb" with "fbcon on top of emulated-fbdev on top of simplekms" so as long as the emulated-fbdev and simplekms code defer from say clearing the screen to black, but keep it as is. Then the fb contents should be preserved until fbcon decides to takeover the fbdev and draw to it. * provide bootsplash DRM client Hmm, I guess this might be interesting for simple cases, but although I would love to kill plymouth (I've become one of the upstream maintainers for it) I'm afraid it is not that easy, it does a bunch of stuff which will be tricky to do in the kernel: 1) Ask the user for diskcrypt passwords: https://ic.pics.livejournal.com/hansdegoede/13347631/1496/1496_900.png 2) Show a nice splash + progressbar when installing updates in offline updates mode: https://ic.pics.livejournal.com/hansdegoede/13347631/899/899_900.png Still this would be nice for the non diskcrypt case I guess, then we could not use plymouth during normal boot and only use it for offline updates and it would also be nice for various embedded cases.
Re: [PATCH 8/9] drm: Add infrastructure for platform devices
On Thu, Jun 25, 2020 at 02:00:10PM +0200, Thomas Zimmermann wrote:
> Platform devices might operate on firmware framebuffers, such as VESA or
> EFI. Before a native driver for the graphics hardware can take over the
> device, it has to remove any platform driver that operates on the firmware
> framebuffer. Platform helpers provide the infrastructure for platform
> drivers to acquire firmware framebuffers, and for native drivers to remove
> them lateron.
>
> It works similar to the related fbdev mechanism. During initialization, the
> platform driver acquires the firmware framebuffer's I/O memory and provides
> a callback to be removed. The native driver later uses this inforamtion to
> remove any platform driver for it's framebuffer I/O memory.
>
> The platform helper's removal code is integrated into the existing code for
> removing conflicting fraembuffers, so native drivers use it automatically.
>
> Signed-off-by: Thomas Zimmermann
I have some ideas for how to do this a notch cleaner in the next patch.
Maybe best to discuss the actual implmenentation stuff there.
Aside from that usual nits:
- kerneldoc for these please, pulled into drm-kms.rst.
- naming isn't super ocd with drm_platform.c but that prefix not used, but
I also don't have better ideas.
- I think the functions from drm_fb_helper.h for removing other
framebuffers should be moved here, and function name prefix adjusted
acoordingly
I'm wondering about the locking and deadlock potential here, is lockdep
all happy with this?
Cheers, Daniel
> ---
> drivers/gpu/drm/Kconfig| 6 ++
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/drm_platform.c | 118 +
> include/drm/drm_fb_helper.h| 18 -
> include/drm/drm_platform.h | 42
> 5 files changed, 184 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/drm_platform.c
> create mode 100644 include/drm/drm_platform.h
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index c4fd57d8b717..e9d6892f9d38 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -229,6 +229,12 @@ config DRM_SCHED
> tristate
> depends on DRM
>
> +config DRM_PLATFORM_HELPER
> + bool
> + depends on DRM
> + help
> + Helpers for DRM platform devices
> +
> source "drivers/gpu/drm/i2c/Kconfig"
>
> source "drivers/gpu/drm/arm/Kconfig"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 2c0e5a7e5953..8ceb21d0770a 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -32,6 +32,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
> drm-$(CONFIG_PCI) += drm_pci.o
> drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
> drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> +drm-$(CONFIG_DRM_PLATFORM_HELPER) += drm_platform.o
>
> drm_vram_helper-y := drm_gem_vram_helper.o
> obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o
> diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
> new file mode 100644
> index ..09a2f2a31aa5
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_platform.c
> @@ -0,0 +1,118 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +static LIST_HEAD(drm_apertures);
> +
> +static DEFINE_MUTEX(drm_apertures_lock);
> +
> +static bool overlap(resource_size_t base1, resource_size_t end1,
> + resource_size_t base2, resource_size_t end2)
> +{
> + return (base1 < end2) && (end1 > base2);
> +}
> +
> +static struct drm_aperture *
> +drm_aperture_acquire(struct drm_device *dev,
> + resource_size_t base, resource_size_t size,
> + const struct drm_aperture_funcs *funcs)
> +{
> + size_t end = base + size;
> + struct list_head *pos;
> + struct drm_aperture *ap;
> +
> + mutex_lock(_apertures_lock);
> +
> + list_for_each(pos, _apertures) {
> + ap = container_of(pos, struct drm_aperture, lh);
> + if (overlap(base, end, ap->base, ap->base + ap->size))
> + return ERR_PTR(-EBUSY);
> + }
> +
> + ap = drmm_kzalloc(dev, sizeof(*ap), GFP_KERNEL);
> + if (!ap)
> + return ERR_PTR(-ENOMEM);
> +
> + ap->dev = dev;
> + ap->base = base;
> + ap->size = size;
> + ap->funcs = funcs;
> + INIT_LIST_HEAD(>lh);
> +
> + list_add(>lh, _apertures);
> +
> + mutex_unlock(_apertures_lock);
> +
> + return ap;
> +}
> +
> +static void drm_aperture_release(struct drm_aperture *ap)
> +{
> + bool kicked_out = ap->kicked_out;
> +
> + if (!kicked_out)
> + mutex_lock(_apertures_lock);
> +
> + list_del(>lh);
> + if (ap->funcs->release)
> + ap->funcs->release(ap);
> +
> + if (!kicked_out)
> + mutex_unlock(_apertures_lock);
> +}
> +
> +static void drm_aperture_acquire_release(struct drm_device *dev, void *ptr)
> +{
Re: [PATCH 9/9] drm/simplekms: Acquire memory aperture for framebuffer
On Thu, Jun 25, 2020 at 02:00:11PM +0200, Thomas Zimmermann wrote:
> We register the simplekms device with the DRM platform helpers. A
> native driver for the graphics hardware will kickout the simplekms
> driver before taking over the device.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/tiny/Kconfig | 1 +
> drivers/gpu/drm/tiny/simplekms.c | 94 +++-
> 2 files changed, 92 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
> index 50dbde8bdcb2..a47ed337a7fe 100644
> --- a/drivers/gpu/drm/tiny/Kconfig
> +++ b/drivers/gpu/drm/tiny/Kconfig
> @@ -33,6 +33,7 @@ config DRM_SIMPLEKMS
> depends on DRM
> select DRM_GEM_SHMEM_HELPER
> select DRM_KMS_HELPER
> + select DRM_PLATFORM_HELPER
> help
> DRM driver for simple platform-provided framebuffers.
>
> diff --git a/drivers/gpu/drm/tiny/simplekms.c
> b/drivers/gpu/drm/tiny/simplekms.c
> index ae5d3cbadbe8..a903a4e0100a 100644
> --- a/drivers/gpu/drm/tiny/simplekms.c
> +++ b/drivers/gpu/drm/tiny/simplekms.c
> @@ -5,6 +5,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -17,6 +18,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -36,6 +38,12 @@
> #define SIMPLEKMS_MODE(hd, vd) \
> DRM_SIMPLE_MODE(hd, vd, RES_MM(hd), RES_MM(vd))
>
> +/*
> + * Protects the platform device's drvdata against
> + * concurrent manipulation.
> + */
> +static DEFINE_SPINLOCK(simplekms_drvdata_lock);
> +
> /*
> * Helpers for simplefb
> */
> @@ -211,6 +219,7 @@ struct simplekms_device {
> unsigned int pitch;
>
> /* memory management */
> + struct drm_aperture *aperture;
> struct resource *mem;
> void __iomem *screen_base;
>
> @@ -224,6 +233,8 @@ static struct simplekms_device
> *simplekms_device_of_dev(struct drm_device *dev)
> return container_of(dev, struct simplekms_device, dev);
> }
>
> +static void simplekms_device_cleanup(struct simplekms_device *sdev);
> +
> /*
> * Hardware
> */
> @@ -514,22 +525,72 @@ static int simplekms_device_init_fb(struct
> simplekms_device *sdev)
> * Memory management
> */
>
> +static void simplekms_aperture_kickout(struct drm_aperture *ap)
> +{
> + struct drm_device *dev = ap->dev;
> + struct simplekms_device *sdev = simplekms_device_of_dev(dev);
> + struct platform_device *pdev = sdev->pdev;
> +
> + if (WARN_ON(!sdev->aperture))
> + return; /* BUG: driver already got kicked out */
> +
> + drm_dev_unregister(dev);
>From a semantic pov I think the platform driver getting kicked out is more
like a hotunplug, so drm_dev_unplug(dev); here is imo better.
That then also gives you a nice drm_dev_enter/exit to sprinkle over the
various driver callbacks, instead of the racy ->aperture check reinvented
wheel here.
I also wonder whether we couldn't go full driver model for these platform
devices, and instead of this here call a core driver model function to
force the unbding of the driver. Only change we'd need it that our
->remove hook uses drm_dev_unplug().
Also I guess this nice plan doesn't work if efifb or vesafb don't have a
platform_device of their own that the drm_platform.c code could use to
nuke platform drivers. But if they have, we could just use
device_driver_detach() from drm_platform.c and wouldn't need any of this.
Worst case efi and vesa drm drivers could instantiate the platform device
they bind against themselves ...
I think that would be a lot cleaner than hand-rolling our own hotunplug
infrastructure here.
Adding Greg in case we're missing anything here.
> +
> + sdev->aperture = NULL; /* memory is released by platform helpers */
> +
> + spin_lock(_drvdata_lock);
> + sdev = platform_get_drvdata(pdev);
> + platform_set_drvdata(pdev, NULL); /* required; see simplekms_remove() */
> + spin_unlock(_drvdata_lock);
> +
> + /*
> + * Return if a concurrent simplekms_remove() cleans up the
> + * device. See simplekms_remove().
> + */
> + if (!sdev)
> + return;
> +
> + /*
> + * After the aperture has been released, there's no reason
> + * to keep the DRM device around.
> + */
> + simplekms_device_cleanup(sdev);
Uh, you already unregistered, this unregisters again. Maybe a bit too much
:-)
> +}
> +
> +static const struct drm_aperture_funcs simplekms_aperture_funcs = {
> + .kickout = simplekms_aperture_kickout,
> +};
> +
> static int simplekms_device_init_mm(struct simplekms_device *sdev)
> {
> + struct drm_device *dev = >dev;
> struct platform_device *pdev = sdev->pdev;
> struct resource *mem;
> + struct drm_aperture *ap;
> void __iomem *screen_base;
> + int ret;
>
> mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!mem)
> return -EINVAL;
>
> + ap =
Re: [PATCH 4/9] drm/simplekms: Add fbdev emulation
On Thu, Jun 25, 2020 at 02:00:06PM +0200, Thomas Zimmermann wrote: > This displays a console on the simplefb framebuffer. The default > framebuffer format is being used. > > Signed-off-by: Thomas Zimmermann > --- > drivers/gpu/drm/tiny/simplekms.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/tiny/simplekms.c > b/drivers/gpu/drm/tiny/simplekms.c > index dc7cf3983945..ac2ebfcedd22 100644 > --- a/drivers/gpu/drm/tiny/simplekms.c > +++ b/drivers/gpu/drm/tiny/simplekms.c > @@ -8,6 +8,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -469,6 +470,8 @@ static int simplekms_probe(struct platform_device *pdev) > if (ret) > return ret; > > + drm_fbdev_generic_setup(dev, 0); I think for the fastboot stuff what we could do is improve the generic fbdev code with essentially what intel_fbdev_init_bios does. Well actually just shovel that code into the helpers maybe, the other code to pick initial configs for fastboot has been moved already too. Otherwise lgtm ofc. Reviewed-by: Daniel Vetter > + > return 0; > } > > -- > 2.27.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/9] drm/simplekms: Acquire clocks from DT device node
On Thu, Jun 25, 2020 at 03:34:05PM +0200, Geert Uytterhoeven wrote:
> Hi Thomas,
>
> On Thu, Jun 25, 2020 at 2:00 PM Thomas Zimmermann wrote:
> > Make sure required hardware clocks are enabled while the firmware
> > framebuffer is in use.
> >
> > The basic code has been taken from the simplefb driver and adapted
> > to DRM. Clocks are released automatically via devres helpers.
> >
> > Signed-off-by: Thomas Zimmermann
>
> Thanks for your patch!
>
> > --- a/drivers/gpu/drm/tiny/simplekms.c
> > +++ b/drivers/gpu/drm/tiny/simplekms.c
>
> > @@ -210,6 +218,103 @@ static struct simplekms_device
> > *simplekms_device_of_dev(struct drm_device *dev)
> > return container_of(dev, struct simplekms_device, dev);
> > }
> >
> > +/*
> > + * Hardware
> > + */
> > +
> > +#if defined CONFIG_OF && defined CONFIG_COMMON_CLK
> > +/*
> > + * Clock handling code.
> > + *
> > + * Here we handle the clocks property of our "simple-framebuffer" dt node.
> > + * This is necessary so that we can make sure that any clocks needed by
> > + * the display engine that the bootloader set up for us (and for which it
> > + * provided a simplefb dt node), stay up, for the life of the simplefb
> > + * driver.
> > + *
> > + * When the driver unloads, we cleanly disable, and then release the
> > clocks.
> > + *
> > + * We only complain about errors here, no action is taken as the most
> > likely
> > + * error can only happen due to a mismatch between the bootloader which set
> > + * up simplefb, and the clock definitions in the device tree. Chances are
> > + * that there are no adverse effects, and if there are, a clean teardown of
> > + * the fb probe will not help us much either. So just complain and carry
> > on,
> > + * and hope that the user actually gets a working fb at the end of things.
> > + */
> > +
> > +static void simplekms_device_release_clocks(void *res)
> > +{
> > + struct simplekms_device *sdev = simplekms_device_of_dev(res);
> > + unsigned int i;
> > +
> > + for (i = 0; i < sdev->clk_count; ++i) {
> > + if (sdev->clks[i]) {
> > + clk_disable_unprepare(sdev->clks[i]);
> > + clk_put(sdev->clks[i]);
> > + }
> > + }
> > +}
> > +
> > +static int simplekms_device_init_clocks(struct simplekms_device *sdev)
> > +{
> > + struct drm_device *dev = >dev;
> > + struct platform_device *pdev = sdev->pdev;
> > + struct device_node *of_node = pdev->dev.of_node;
> > + struct clk *clock;
> > + unsigned int i;
> > + int ret;
> > +
> > + if (dev_get_platdata(>dev) || !of_node)
> > + return 0;
> > +
> > + sdev->clk_count = of_clk_get_parent_count(of_node);
> > + if (!sdev->clk_count)
> > + return 0;
> > +
> > + sdev->clks = drmm_kzalloc(dev, sdev->clk_count *
> > sizeof(sdev->clks[0]),
> > + GFP_KERNEL);
> > + if (!sdev->clks)
> > + return -ENOMEM;
> > +
> > + for (i = 0; i < sdev->clk_count; ++i) {
> > + clock = of_clk_get(of_node, i);
>
> clk_bulk_get_all()?
Plus then you can use devm_clk_bulk_get_all, even less code I think.
-Daniel
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/9] drm: Add simplekms driver
On Thu, Jun 25, 2020 at 02:00:05PM +0200, Thomas Zimmermann wrote:
> The simplekms driver is a DRM driver for simplefb framebuffers as
> provided by the kernel's boot code. This driver enables basic
> graphical output on many different graphics devices that are provided
> by the platform (e.g., EFI, VESA, embedded framebuffers).
>
> With the kernel's simplefb infrastructure, the kernel receives a
> pre-configured framebuffer from the system (i.e., firmware, boot
> loader). It creates a platform device to which simplekms attaches.
> The system's framebuffer consists of a memory range, size and format.
> Based on these values, simplekms creates a DRM devices. No actual
> modesetting is possible.
>
> Signed-off-by: Thomas Zimmermann
> ---
> MAINTAINERS | 6 +
> drivers/gpu/drm/tiny/Kconfig | 16 +
> drivers/gpu/drm/tiny/Makefile| 1 +
> drivers/gpu/drm/tiny/simplekms.c | 495 +++
> 4 files changed, 518 insertions(+)
> create mode 100644 drivers/gpu/drm/tiny/simplekms.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f17d99164a77..ac517dc8d05d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5505,6 +5505,12 @@ S: Orphan / Obsolete
> F: drivers/gpu/drm/savage/
> F: include/uapi/drm/savage_drm.h
>
> +DRM DRIVER FOR SIMPLE FRAMEBUFFERS
> +M: Thomas Zimmermann
> +S: Maintained
> +T: git git://anongit.freedesktop.org/drm/drm-misc
> +F: drivers/gpu/drm/tiny/simplekms.c
> +
> DRM DRIVER FOR SIS VIDEO CARDS
> S: Orphan / Obsolete
> F: drivers/gpu/drm/sis/
> diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
> index 2b6414f0fa75..50dbde8bdcb2 100644
> --- a/drivers/gpu/drm/tiny/Kconfig
> +++ b/drivers/gpu/drm/tiny/Kconfig
> @@ -28,6 +28,22 @@ config DRM_GM12U320
>This is a KMS driver for projectors which use the GM12U320 chipset
>for video transfer over USB2/3, such as the Acer C120 mini projector.
>
> +config DRM_SIMPLEKMS
> + tristate "Simple framebuffer driver"
> + depends on DRM
> + select DRM_GEM_SHMEM_HELPER
> + select DRM_KMS_HELPER
> + help
> + DRM driver for simple platform-provided framebuffers.
> +
> + This driver assumes that the display hardware has been initialized
> + by the firmware or bootloader before the kernel boots. Scanout
> + buffer, size, and display format must be provided via device tree,
> + UEFI, VESA, etc.
> +
> + On x86 and compatible, you should also select CONFIG_X86_SYSFB to
> + use UEFI and VESA framebuffers.
> +
> config TINYDRM_HX8357D
> tristate "DRM support for HX8357D display panels"
> depends on DRM && SPI
> diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
> index 6ae4e9e5a35f..e83fbbfa7344 100644
> --- a/drivers/gpu/drm/tiny/Makefile
> +++ b/drivers/gpu/drm/tiny/Makefile
> @@ -2,6 +2,7 @@
>
> obj-$(CONFIG_DRM_CIRRUS_QEMU)+= cirrus.o
> obj-$(CONFIG_DRM_GM12U320) += gm12u320.o
> +obj-$(CONFIG_DRM_SIMPLEKMS) += simplekms.o
> obj-$(CONFIG_TINYDRM_HX8357D)+= hx8357d.o
> obj-$(CONFIG_TINYDRM_ILI9225)+= ili9225.o
> obj-$(CONFIG_TINYDRM_ILI9341)+= ili9341.o
> diff --git a/drivers/gpu/drm/tiny/simplekms.c
> b/drivers/gpu/drm/tiny/simplekms.c
> new file mode 100644
> index ..dc7cf3983945
> --- /dev/null
> +++ b/drivers/gpu/drm/tiny/simplekms.c
> @@ -0,0 +1,495 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DRIVER_NAME "simplekms"
> +#define DRIVER_DESC "DRM driver for simple-framebuffer platform devices"
> +#define DRIVER_DATE "20200625"
> +#define DRIVER_MAJOR 1
> +#define DRIVER_MINOR 0
> +
> +/*
> + * Assume a monitor resolution of 96 dpi to
> + * get a somewhat reasonable screen size.
> + */
> +#define RES_MM(d)\
> + (((d) * 254ul) / (96ul * 10ul))
> +
> +#define SIMPLEKMS_MODE(hd, vd) \
> + DRM_SIMPLE_MODE(hd, vd, RES_MM(hd), RES_MM(vd))
> +
> +/*
> + * Helpers for simplefb
> + */
> +
> +static int
> +simplefb_get_validated_int(struct drm_device *dev, const char *name,
> +uint32_t value)
> +{
> + if (value > INT_MAX) {
> + drm_err(dev, "simplefb: invalid framebuffer %s of %u\n",
> + name, value);
> + return -EINVAL;
> + }
> + return (int)value;
> +}
> +
> +static int
> +simplefb_get_validated_int0(struct drm_device *dev, const char *name,
> + uint32_t value)
> +{
> + if (!value) {
> + drm_err(dev, "simplefb: invalid framebuffer %s of %u\n",
> + name, value);
> + return -EINVAL;
> + }
> + return simplefb_get_validated_int(dev, name, value);
> +}
> +
> +static const
Re: [PATCH 2/9] drm/format-helper: Add blitter functions
On Thu, Jun 25, 2020 at 02:00:04PM +0200, Thomas Zimmermann wrote:
> The blitter functions copy a framebuffer to I/O memory using one of
> the existing conversion functions.
>
> Signed-off-by: Thomas Zimmermann
Hm I guess reason for adding dst_pitch in the previous patch is so that
there wouldn't be a special case here. Makes sense.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_format_helper.c | 87 +
> include/drm/drm_format_helper.h | 8 +++
> 2 files changed, 95 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index 8d5a683afea7..0e885cd34107 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -344,3 +344,90 @@ void drm_fb_xrgb_to_gray8(u8 *dst, void *vaddr,
> struct drm_framebuffer *fb,
> }
> EXPORT_SYMBOL(drm_fb_xrgb_to_gray8);
>
> +/**
> + * drm_fb_blit_rect_dstclip - Copy parts of a framebuffer to display memory
> + * @dst: The display memory to copy to
> + * @dst_pitch: Number of bytes between two consecutive scanlines
> within dst
> + * @dst_format: FOURCC code of the display's color format
> + * @vmap:The framebuffer memory to copy from
> + * @fb: The framebuffer to copy from
> + * @clip:Clip rectangle area to copy
> + *
> + * This function copies parts of a framebuffer to display memory. If the
> + * formats of the display and the framebuffer mismatch, the blit function
> + * will attempt to convert between them.
> + *
> + * Use drm_fb_blit_dstclip() to copy the full framebuffer.
> + *
> + * Returns:
> + * 0 on success, or
> + * -EINVAL if the color-format conversion failed, or
> + * a negative error code otherwise.
> + */
> +int drm_fb_blit_rect_dstclip(void __iomem *dst, unsigned int dst_pitch,
> + uint32_t dst_format, void *vmap,
> + struct drm_framebuffer *fb,
> + struct drm_rect *clip)
> +{
> + uint32_t fb_format = fb->format->format;
> +
> + /* treat alpha channel like filler bits */
> + if (fb_format == DRM_FORMAT_ARGB)
> + fb_format = DRM_FORMAT_XRGB;
> + if (dst_format == DRM_FORMAT_ARGB)
> + dst_format = DRM_FORMAT_XRGB;
> +
> + if (dst_format == fb_format) {
> + drm_fb_memcpy_dstclip(dst, dst_pitch, vmap, fb, clip);
> + return 0;
> +
> + } else if (dst_format == DRM_FORMAT_RGB565) {
> + if (fb_format == DRM_FORMAT_XRGB) {
> + drm_fb_xrgb_to_rgb565_dstclip(dst, dst_pitch,
> + vmap, fb, clip,
> + false);
> + return 0;
> + }
> + } else if (dst_format == DRM_FORMAT_RGB888) {
> + if (fb_format == DRM_FORMAT_XRGB) {
> + drm_fb_xrgb_to_rgb888_dstclip(dst, dst_pitch,
> + vmap, fb, clip);
> + return 0;
> + }
> + }
> +
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL(drm_fb_blit_rect_dstclip);
> +
> +/**
> + * drm_fb_blit_dstclip - Copy framebuffer to display memory
> + * @dst: The display memory to copy to
> + * @dst_pitch: Number of bytes between two consecutive scanlines
> within dst
> + * @dst_format: FOURCC code of the display's color format
> + * @vmap:The framebuffer memory to copy from
> + * @fb: The framebuffer to copy from
> + *
> + * This function copies a full framebuffer to display memory. If the formats
> + * of the display and the framebuffer mismatch, the copy function will
> + * attempt to convert between them.
> + *
> + * See drm_fb_blit_rect_dstclip() for more inforamtion.
> + *
> + * Returns:
> + * 0 on success, or a negative error code otherwise.
> + */
> +int drm_fb_blit_dstclip(void __iomem *dst, unsigned int dst_pitch,
> + uint32_t dst_format, void *vmap,
> + struct drm_framebuffer *fb)
I do wonder whether we shouldn't have to some safety checks for this
stuff, like maybe something like:
struct dst_info {
void __iomem *dst;
unsigned int size;
unsigned int dst_pitch;
uint32_t dst_format;
};
And then the helpers would splat a WARNING if a driver ever gets this
wrong. Thinking about this because syzkaller has found tons of little
off-by-a-bit bugs in the vt/fbcon/fbdev code, and maybe we should try to
be better :-)
But that's material for another patch, and maybe once we have a few more
helpers in this library we can figure out a nice struct to package up
these long argument lists a bit.
Cheers, Daniel
> +{
> + struct drm_rect fullscreen = {
> + .x1 = 0,
> + .x2 = fb->width,
> + .y1 = 0,
> + .y2 = fb->height,
> + };
> + return
Re: [PATCH v9 00/11] Genericize DW MIPI DSI bridge and add i.MX 6 driver
Hi Adrian, On 09/06/2020 19:49, Adrian Ratiu wrote: > [Re-submitting to cc dri-devel, sorry about the noise] > > Hello all, > > v9 cleanly applies on top of latest next-20200609 tree. > > v9 does not depend on other patches as the last binding doc has been merged. > > All feedback up to this point has been addressed. Specific details in > individual patch changelogs. > > The biggest changes are the deprecation of the Synopsys DW bridge bind() > API in favor of of_drm_find_bridge() and .attach callbacks, the addition > of a TODO entry which outlines future planned bridge driver refactorings > and a reordering of some i.MX 6 patches to appease checkpatch. > > The idea behind the TODO is to get this regmap and i.MX 6 driver merged > and then do the rest of refactorings in-tree because it's easier and the > refactorings themselves are out-of-scope of this series which is adding > i.MX 6 support and is quite big already, so please, if there are more > refactoring ideas, let's add them to the TODO doc. :) I intend to tackle > those after this series is merged to avoid two complex inter-dependent > simultaneous series. This has been around here for a long time and you seem to have addressed all the reviews. > > As always more testing is welcome especially on Rockchip and STM SoCs. It has been tested on STM, but I'd like a feedback on RK platform before applying the bridge parts. Can the imx & stm patches be applied separately ? Neil > > Big thank you to everyone who has contributed to this up to now, > Adrian > > Adrian Ratiu (11): > drm: bridge: dw_mipi_dsi: add initial regmap infrastructure > drm: bridge: dw_mipi_dsi: abstract register access using reg_fields > drm: bridge: dw_mipi_dsi: add dsi v1.01 support > drm: bridge: dw_mipi_dsi: remove bind/unbind API > dt-bindings: display: add i.MX6 MIPI DSI host controller doc > ARM: dts: imx6qdl: add missing mipi dsi properties > drm: imx: Add i.MX 6 MIPI DSI host platform driver > drm: stm: dw-mipi-dsi: let the bridge handle the HW version check > drm: bridge: dw-mipi-dsi: split low power cfg register into fields > drm: bridge: dw-mipi-dsi: fix bad register field offsets > Documentation: gpu: todo: Add dw-mipi-dsi consolidation plan > > .../display/imx/fsl,mipi-dsi-imx6.yaml| 112 +++ > Documentation/gpu/todo.rst| 25 + > arch/arm/boot/dts/imx6qdl.dtsi| 8 + > drivers/gpu/drm/bridge/synopsys/Kconfig | 1 + > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 713 -- > drivers/gpu/drm/imx/Kconfig | 8 + > drivers/gpu/drm/imx/Makefile | 1 + > drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c| 399 ++ > .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 7 +- > drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 16 +- > 10 files changed, 1059 insertions(+), 231 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml > create mode 100644 drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/bridge: ti-sn65dsi86: Check the regmap return value when setting a GPIO
On 11/06/2020 16:34, Doug Anderson wrote:
> Hi,
>
> On Thu, Jun 11, 2020 at 2:58 AM Stephen Boyd wrote:
>>
>> Quoting Douglas Anderson (2020-06-08 10:48:35)
>>> The ti_sn_bridge_gpio_set() got the return value of
>>> regmap_update_bits() but didn't check it. The function can't return
>>> an error value, but we should at least print a warning if it didn't
>>> work.
>>>
>>> This fixes a compiler warning about setting "ret" but not using it.
>>>
>>> Fixes: 27ed2b3f22ed ("drm/bridge: ti-sn65dsi86: Export bridge GPIOs to
>>> Linux")
>>> Signed-off-by: Douglas Anderson
>>> ---
>>>
>>> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
>>> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
>>> index 1080e4f9df96..526add27dc03 100644
>>> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
>>> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
>>> @@ -999,6 +999,9 @@ static void ti_sn_bridge_gpio_set(struct gpio_chip
>>> *chip, unsigned int offset,
>>> ret = regmap_update_bits(pdata->regmap, SN_GPIO_IO_REG,
>>> BIT(SN_GPIO_OUTPUT_SHIFT + offset),
>>> val << (SN_GPIO_OUTPUT_SHIFT + offset));
>>> + if (ret)
>>> + dev_warn(pdata->dev,
>>> +"Failed to set bridge GPIO %d: %d\n", offset, ret);
>>
>> GPIO %u because it's unsigned?
>
> Sure. I'll plan to spin tomorrow in case anyone else has any
> feedback. If any maintainer would prefer me not to spin and would
> rather fix this when applying, please shout and I won't send out a v2.
>
> -Doug
>
Yes please respin, ping me on IRC if I forget to apply..
Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/9] drm/format-helper: Pass destination pitch to drm_fb_memcpy_dstclip()
On Thu, Jun 25, 2020 at 02:00:03PM +0200, Thomas Zimmermann wrote:
> The memcpy's destination buffer might have a different pitch than the
> source. Support different pitches as function argument.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
But I do have questions ... why did we allocate a source drm_framebuffer
with mismatching pitch? That sounds backwards, especially for simplekms.
Would be good to add the reasons why we need this to the commit message,
I'm sure I'll discover it later on eventually.
-Daniel
> ---
> drivers/gpu/drm/drm_format_helper.c| 9 +
> drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +-
> drivers/gpu/drm/tiny/cirrus.c | 2 +-
> include/drm/drm_format_helper.h| 2 +-
> 4 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index c043ca364c86..8d5a683afea7 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -52,6 +52,7 @@ EXPORT_SYMBOL(drm_fb_memcpy);
> /**
> * drm_fb_memcpy_dstclip - Copy clip buffer
> * @dst: Destination buffer (iomem)
> + * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> * @vaddr: Source buffer
> * @fb: DRM framebuffer
> * @clip: Clip rectangle area to copy
> @@ -59,12 +60,12 @@ EXPORT_SYMBOL(drm_fb_memcpy);
> * This function applies clipping on dst, i.e. the destination is a
> * full (iomem) framebuffer but only the clip rect content is copied over.
> */
> -void drm_fb_memcpy_dstclip(void __iomem *dst, void *vaddr,
> -struct drm_framebuffer *fb,
> +void drm_fb_memcpy_dstclip(void __iomem *dst, unsigned int dst_pitch,
> +void *vaddr, struct drm_framebuffer *fb,
> struct drm_rect *clip)
> {
> unsigned int cpp = fb->format->cpp[0];
> - unsigned int offset = clip_offset(clip, fb->pitches[0], cpp);
> + unsigned int offset = clip_offset(clip, dst_pitch, cpp);
> size_t len = (clip->x2 - clip->x1) * cpp;
> unsigned int y, lines = clip->y2 - clip->y1;
>
> @@ -73,7 +74,7 @@ void drm_fb_memcpy_dstclip(void __iomem *dst, void *vaddr,
> for (y = 0; y < lines; y++) {
> memcpy_toio(dst, vaddr, len);
> vaddr += fb->pitches[0];
> - dst += fb->pitches[0];
> + dst += dst_pitch;
> }
> }
> EXPORT_SYMBOL(drm_fb_memcpy_dstclip);
> diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
> b/drivers/gpu/drm/mgag200/mgag200_mode.c
> index f16bd278ab7e..7d4f3a62d885 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_mode.c
> +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
> @@ -1586,7 +1586,7 @@ mgag200_handle_damage(struct mga_device *mdev, struct
> drm_framebuffer *fb,
> if (drm_WARN_ON(dev, !vmap))
> return; /* BUG: SHMEM BO should always be vmapped */
>
> - drm_fb_memcpy_dstclip(mdev->vram, vmap, fb, clip);
> + drm_fb_memcpy_dstclip(mdev->vram, fb->pitches[0], vmap, fb, clip);
>
> drm_gem_shmem_vunmap(fb->obj[0], vmap);
>
> diff --git a/drivers/gpu/drm/tiny/cirrus.c b/drivers/gpu/drm/tiny/cirrus.c
> index 744a8e337e41..2dd9e5e31e3d 100644
> --- a/drivers/gpu/drm/tiny/cirrus.c
> +++ b/drivers/gpu/drm/tiny/cirrus.c
> @@ -327,7 +327,7 @@ static int cirrus_fb_blit_rect(struct drm_framebuffer *fb,
> goto out_dev_exit;
>
> if (cirrus->cpp == fb->format->cpp[0])
> - drm_fb_memcpy_dstclip(cirrus->vram,
> + drm_fb_memcpy_dstclip(cirrus->vram, fb->pitches[0],
> vmap, fb, rect);
>
> else if (fb->format->cpp[0] == 4 && cirrus->cpp == 2)
> diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
> index 5f9e37032468..2b5036a5fbe7 100644
> --- a/include/drm/drm_format_helper.h
> +++ b/include/drm/drm_format_helper.h
> @@ -11,7 +11,7 @@ struct drm_rect;
>
> void drm_fb_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
> struct drm_rect *clip);
> -void drm_fb_memcpy_dstclip(void __iomem *dst, void *vaddr,
> +void drm_fb_memcpy_dstclip(void __iomem *dst, unsigned int dst_pitch, void
> *vaddr,
> struct drm_framebuffer *fb,
> struct drm_rect *clip);
> void drm_fb_swab(void *dst, void *src, struct drm_framebuffer *fb,
> --
> 2.27.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] display/drm/bridge: TC358775 DSI/LVDS driver
Hi, On 21/06/2020 17:38, Vinay Simha BN wrote: > Signed-off-by: Vinay Simha BN > > --- > v1: > Initial version > > v2: > * Andrzej Hajda review comments incorporated > SPDX identifier > development debug removed > alphabetic order headers > u32 instead of unit32_t > magic numbers to macros for CLRSI and mux registers > ignored return value > > * Laurent Pinchart review comments incorporated > mdelay to usleep_range > bus_formats added > > v3: > * Andrzej Hajda review comments incorporated > drm_connector_status removed > u32 rev removed and local variabl is used > regulator enable disable with proper orders and delays > as per the spec > devm_drm_panel_bridge_add method used instead of panel > description modified > dual port implemented > > v4: > * Sam Ravnborg review comments incorporated > panel->connector_type removed > > * Reported-by: kernel test robot > parse_dt to static function > removed the if (endpoint), since data-lanes has to be > present for dsi dts ports I maybe missed something, but you should also post a YAML DT bindings file associated to the driver. Neil > --- > drivers/gpu/drm/bridge/Kconfig| 10 + > drivers/gpu/drm/bridge/Makefile | 1 + > drivers/gpu/drm/bridge/tc358775.c | 721 ++ > 3 files changed, 732 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/tc358775.c > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index 43271c21d3fc..084e9853944a 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -181,6 +181,16 @@ config DRM_TOSHIBA_TC358768 > help > Toshiba TC358768AXBG/TC358778XBG DSI bridge chip driver. > > +config DRM_TOSHIBA_TC358775 > +tristate "Toshiba TC358775 LVDS bridge" > +depends on OF > +select DRM_KMS_HELPER > +select REGMAP_I2C > +select DRM_PANEL > + select DRM_MIPI_DSI > +---help--- > + Toshiba TC358775 LVDS bridge chip driver. > + > config DRM_TI_TFP410 > tristate "TI TFP410 DVI/HDMI bridge" > depends on OF > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > index d63d4b7e4347..23c770b3bfe4 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -15,6 +15,7 @@ obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o > obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o > obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o > obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o > +obj-$(CONFIG_DRM_TOSHIBA_TC358775) += tc358775.o > obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ > obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o > obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o > diff --git a/drivers/gpu/drm/bridge/tc358775.c > b/drivers/gpu/drm/bridge/tc358775.c > new file mode 100644 > index ..8c9bd4e77bfd > --- /dev/null > +++ b/drivers/gpu/drm/bridge/tc358775.c > @@ -0,0 +1,721 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * tc358775 DSI to LVDS bridge driver > + * > + * Copyright (C) 2020 SMART Wireless Computing > + * Author: Vinay Simha BN > + * > + */ > +//#define DEBUG > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define FLD_MASK(start, end)(((1 << ((start) - (end) + 1)) - 1) << (end)) > +#define FLD_VAL(val, start, end) (((val) << (end)) & FLD_MASK(start, end)) > + > +/* Registers */ > + > +/* DSI D-PHY Layer Registers */ > +#define D0W_DPHYCONTTX 0x0004 /* Data Lane 0 DPHY Tx Control */ > +#define CLW_DPHYCONTRX 0x0020 /* Clock Lane DPHY Rx Control */ > +#define D0W_DPHYCONTRX 0x0024 /* Data Lane 0 DPHY Rx Control */ > +#define D1W_DPHYCONTRX 0x0028 /* Data Lane 1 DPHY Rx Control */ > +#define D2W_DPHYCONTRX 0x002C /* Data Lane 2 DPHY Rx Control */ > +#define D3W_DPHYCONTRX 0x0030 /* Data Lane 3 DPHY Rx Control */ > +#define COM_DPHYCONTRX 0x0038 /* DPHY Rx Common Control */ > +#define CLW_CNTRL 0x0040 /* Clock Lane Control */ > +#define D0W_CNTRL 0x0044 /* Data Lane 0 Control */ > +#define D1W_CNTRL 0x0048 /* Data Lane 1 Control */ > +#define D2W_CNTRL 0x004C /* Data Lane 2 Control */ > +#define D3W_CNTRL 0x0050 /* Data Lane 3 Control */ > +#define DFTMODE_CNTRL 0x0054 /* DFT Mode Control */ > + > +/* DSI PPI Layer Registers */ > +#define PPI_STARTPPI0x0104 /* START control bit of PPI-TX function. */ > +#define PPI_START_FUNCTION 1 > + > +#define PPI_BUSYPPI 0x0108 > +#define PPI_LINEINITCNT 0x0110 /* Line Initialization Wait Counter */ > +#define PPI_LPTXTIMECNT 0x0114 > +#define PPI_LANEENABLE 0x0134 /* Enables each lane at the PPI layer. */ > +#define PPI_TX_RX_TA0x013C /* DSI Bus Turn Around timing parameters */ > + > +/* Analog timer function enable */ > +#define PPI_CLS_ATMR
Re: [git pull] drm fixes for v5.8-rc3
On Fri, 26 Jun 2020, Dave Airlie wrote: > Usual rc3 pickup, lots of little fixes all over, The core VT > registration regression fix is probably the largest, otherwise ttm, > amdgpu and tegra are the bulk, with some minor driver fixes. No i915 > pull this week which may or may not mean I get 2x of it next week, > we'll see how it goes. Been really quiet here, basically I only got GVT fixes pending. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/connector: fix minor typos in comments
On Fri, Jun 26, 2020 at 10:42:52PM +0200, Antonio Borneo wrote:
> Some of these comments are part of the Linux GPU Driver Developer's
> Guide.
> Fix some minor typo in the comments and remove a repeated 'the'.
>
> Signed-off-by: Antonio Borneo
Queued up for 5.9 in drm-misc-next, thanks for your patch.
-Daniel
> ---
> drivers/gpu/drm/drm_connector.c | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index d877ddc6dc57..cb62fb8e594e 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -38,7 +38,7 @@
> * DOC: overview
> *
> * In DRM connectors are the general abstraction for display sinks, and
> include
> - * als fixed panels or anything else that can display pixels in some form. As
> + * also fixed panels or anything else that can display pixels in some form.
> As
> * opposed to all other KMS objects representing hardware (like CRTC,
> encoder or
> * plane abstractions) connectors can be hotplugged and unplugged at runtime.
> * Hence they are reference-counted using drm_connector_get() and
> @@ -129,7 +129,7 @@ EXPORT_SYMBOL(drm_get_connector_type_name);
>
> /**
> * drm_connector_get_cmdline_mode - reads the user's cmdline mode
> - * @connector: connector to quwery
> + * @connector: connector to query
> *
> * The kernel supports per-connector configuration of its consoles through
> * use of the video= parameter. This function parses that option and
> @@ -991,7 +991,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] =
> {
> * DP MST sinks), or high-res integrated panels (like dual-link DSI) which
> * are not gen-locked. Note that for tiled panels which are genlocked, like
> * dual-link LVDS or dual-link DSI, the driver should try to not expose the
> - * tiling and virtualize both _crtc and _plane if needed. Drivers
> + * tiling and virtualise both _crtc and _plane if needed. Drivers
> * should update this value using drm_connector_set_tile_property().
> * Userspace cannot change this property.
> * link-status:
> @@ -1131,7 +1131,7 @@ static const struct drm_prop_enum_list dp_colorspaces[]
> = {
> *
> * It will even need to do colorspace conversion and get all layers
> * to one common colorspace for blending. It can use either GL, Media
> - * or display engine to get this done based on the capabilties of the
> + * or display engine to get this done based on the capabilities of the
> * associated hardware.
> *
> * Driver expects metadata to be put in hdr_output_metadata
> @@ -1614,7 +1614,7 @@ EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
> * variable refresh rate capability for a connector.
> *
> * Returns:
> - * Zero on success, negative errono on failure.
> + * Zero on success, negative errno on failure.
> */
> int drm_connector_attach_vrr_capable_property(
> struct drm_connector *connector)
> @@ -1759,7 +1759,7 @@ EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
> * HDMI connectors.
> *
> * Returns:
> - * Zero on success, negative errono on failure.
> + * Zero on success, negative errno on failure.
> */
> int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector)
> {
> @@ -1788,7 +1788,7 @@ EXPORT_SYMBOL(drm_mode_create_hdmi_colorspace_property);
> * DP connectors.
> *
> * Returns:
> - * Zero on success, negative errono on failure.
> + * Zero on success, negative errno on failure.
> */
> int drm_mode_create_dp_colorspace_property(struct drm_connector *connector)
> {
> @@ -1840,7 +1840,7 @@ EXPORT_SYMBOL(drm_mode_create_content_type_property);
> * drm_mode_create_suggested_offset_properties - create suggests offset
> properties
> * @dev: DRM device
> *
> - * Create the the suggested x/y offset property for connectors.
> + * Create the suggested x/y offset property for connectors.
> */
> int drm_mode_create_suggested_offset_properties(struct drm_device *dev)
> {
> @@ -1963,7 +1963,7 @@ int drm_connector_update_edid_property(struct
> drm_connector *connector,
> size = EDID_LENGTH * (1 + edid->extensions);
>
> /* Set the display info, using edid if available, otherwise
> - * reseting the values to defaults. This duplicates the work
> + * resetting the values to defaults. This duplicates the work
>* done in drm_add_edid_modes, but that function is not
>* consistently called before this one in all drivers and the
>* computation is cheap enough that it seems better to
> @@ -2076,7 +2076,7 @@ void drm_connector_set_vrr_capable_property(
> EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
>
> /**
> - * drm_connector_set_panel_orientation - sets the connecter's
> panel_orientation
> + * drm_connector_set_panel_orientation - sets the connector's
> panel_orientation
> * @connector: connector for which to set the
Re: [PATCH v6 3/4] drm/bridge/sii8620: fix resource acquisition error handling
On 26/06/2020 12:01, Andrzej Hajda wrote:
> In case of error during resource acquisition driver should print error
> message only in case it is not deferred probe, using dev_err_probe helper
> solves the issue. Moreover it records defer probe reason for debugging.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/bridge/sil-sii8620.c | 21 +
> 1 file changed, 9 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
> b/drivers/gpu/drm/bridge/sil-sii8620.c
> index 92acd336aa89..389c1f029774 100644
> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
> @@ -2299,10 +2299,9 @@ static int sii8620_probe(struct i2c_client *client,
> INIT_LIST_HEAD(>mt_queue);
>
> ctx->clk_xtal = devm_clk_get(dev, "xtal");
> - if (IS_ERR(ctx->clk_xtal)) {
> - dev_err(dev, "failed to get xtal clock from DT\n");
> - return PTR_ERR(ctx->clk_xtal);
> - }
> + if (IS_ERR(ctx->clk_xtal))
> + return dev_err_probe(dev, PTR_ERR(ctx->clk_xtal),
> + "failed to get xtal clock from DT\n");
>
> if (!client->irq) {
> dev_err(dev, "no irq provided\n");
> @@ -2313,16 +2312,14 @@ static int sii8620_probe(struct i2c_client *client,
> sii8620_irq_thread,
> IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
> "sii8620", ctx);
> - if (ret < 0) {
> - dev_err(dev, "failed to install IRQ handler\n");
> - return ret;
> - }
> + if (ret < 0)
> + return dev_err_probe(dev, ret,
> + "failed to install IRQ handler\n");
>
> ctx->gpio_reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
> - if (IS_ERR(ctx->gpio_reset)) {
> - dev_err(dev, "failed to get reset gpio from DT\n");
> - return PTR_ERR(ctx->gpio_reset);
> - }
> + if (IS_ERR(ctx->gpio_reset))
> + return dev_err_probe(dev, PTR_ERR(ctx->gpio_reset),
> + "failed to get reset gpio from DT\n");
>
> ctx->supplies[0].supply = "cvcc10";
> ctx->supplies[1].supply = "iovcc18";
>
Nice helper, totally missed this patchset before !
Reviewed-by: Neil Armstrong
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 4/4] drm/bridge: lvds-codec: simplify error handling
On 26/06/2020 12:01, Andrzej Hajda wrote:
> Using dev_err_probe code has following advantages:
> - shorter code,
> - recorded defer probe reason for debugging,
> - uniform error code logging.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/bridge/lvds-codec.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
> b/drivers/gpu/drm/bridge/lvds-codec.c
> index 24fb1befdfa2..f19d9f7a5db2 100644
> --- a/drivers/gpu/drm/bridge/lvds-codec.c
> +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> @@ -71,13 +71,9 @@ static int lvds_codec_probe(struct platform_device *pdev)
> lvds_codec->connector_type = (uintptr_t)of_device_get_match_data(dev);
> lvds_codec->powerdown_gpio = devm_gpiod_get_optional(dev, "powerdown",
>GPIOD_OUT_HIGH);
> - if (IS_ERR(lvds_codec->powerdown_gpio)) {
> - int err = PTR_ERR(lvds_codec->powerdown_gpio);
> -
> - if (err != -EPROBE_DEFER)
> - dev_err(dev, "powerdown GPIO failure: %d\n", err);
> - return err;
> - }
> + if (IS_ERR(lvds_codec->powerdown_gpio))
> + return dev_err_probe(dev, PTR_ERR(lvds_codec->powerdown_gpio),
> + "powerdown GPIO failure\n");
>
> /* Locate the panel DT node. */
> panel_node = of_graph_get_remote_node(dev->of_node, 1, 0);
>
Reviewed-by: Neil Armstrong
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: drm_fourcc: Add generic alias for 16_16_TILE modifier
On Fri, Jun 26, 2020 at 05:48:00PM +0100, Brian Starkey wrote:
> In cases such as DRM_FORMAT_MOD_SAMSUNG_16_16_TILE, the modifier
> describes a generic pixel re-ordering which can be applicable to
> multiple vendors.
>
> Define an alias: DRM_FORMAT_MOD_GENERIC_16_16_TILE, which can be
> used to describe this layout in a vendor-neutral way, and add a
> comment about the expected usage of such "generic" modifiers.
>
> Changes in v2:
> - Move note about future cases to comment (Daniel)
>
> Signed-off-by: Brian Starkey
Reviewed-by: Daniel Vetter
> ---
> include/uapi/drm/drm_fourcc.h | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 299f9ac4840b..cb3db4a21012 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -345,8 +345,33 @@ extern "C" {
> * When adding a new token please document the layout with a code comment,
> * similar to the fourcc codes above. drm_fourcc.h is considered the
> * authoritative source for all of these.
> + *
> + * Generic modifier names:
> + *
> + * DRM_FORMAT_MOD_GENERIC_* definitions are used to provide vendor-neutral
> names
> + * for layouts which are common across multiple vendors. To preserve
> + * compatibility, in cases where a vendor-specific definition already exists
> and
> + * a generic name for it is desired, the common name is a purely symbolic
> alias
> + * and must use the same numerical value as the original definition.
> + *
> + * Note that generic names should only be used for modifiers which describe
> + * generic layouts (such as pixel re-ordering), which may have
> + * independently-developed support across multiple vendors.
> + *
> + * In future cases where a generic layout is identified before merging with a
> + * vendor-specific modifier, a new 'GENERIC' vendor or modifier using vendor
> + * 'NONE' could be considered. This should only be for obvious, exceptional
> + * cases to avoid polluting the 'GENERIC' namespace with modifiers which only
> + * apply to a single vendor.
> + *
> + * Generic names should not be used for cases where multiple hardware vendors
> + * have implementations of the same standardised compression scheme (such as
> + * AFBC). In those cases, all implementations should use the same format
> + * modifier(s), reflecting the vendor of the standard.
> */
>
> +#define DRM_FORMAT_MOD_GENERIC_16_16_TILE DRM_FORMAT_MOD_SAMSUNG_16_16_TILE
> +
> /*
> * Invalid Modifier
> *
> --
> 2.17.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/4] dt-bindings: display: renesas: lvds: RZ/G2E needs renesas,companion too
On Thu, May 14, 2020 at 08:44:19AM +0200, Geert Uytterhoeven wrote:
> On Thu, May 14, 2020 at 1:39 AM Laurent Pinchart
> wrote:
> > From: Fabrizio Castro
> >
> > Document RZ/G2E support for property renesas,companion.
> >
> > Signed-off-by: Fabrizio Castro
> > Reviewed-by: Laurent Pinchart
> > Signed-off-by: Laurent Pinchart
>
> > --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
> > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
> > @@ -81,9 +81,9 @@ properties:
> > $ref: /schemas/types.yaml#/definitions/phandle
> > description:
> >phandle to the companion LVDS encoder. This property is mandatory
> > - for the first LVDS encoder on D3 and E3 SoCs, and shall point to
> > - the second encoder to be used as a companion in dual-link mode. It
> > - shall not be set for any other LVDS encoder.
> > + for the first LVDS encoder on D3, R-Car E3 and RZ/G2E SoCs, and shall
>
> R-Car D3 and E3, and RZ/G2E SoCs
>
> > + point to the second encoder to be used as a companion in dual-link
> > mode.
> > + It shall not be set for any other LVDS encoder.
Laurent, I assume you will re-spin a ne version wth the changelog
corrected.
Sam
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1.2 4/4] dt-bindings: display: bridge: renesas, lvds: Convert binding to YAML
On Fri, May 15, 2020 at 12:42:11AM +0300, Laurent Pinchart wrote:
> Convert the Renesas R-Car LVDS encoder text binding to YAML.
>
> Signed-off-by: Laurent Pinchart
> Acked-by: Maxime Ripard
> ---
> Changes since v1:
>
> - Mention RZ/G1 and R2/G2 explicitly
> - Drop the part numbers in comments, only keep the SoC names
> - Use one address and size cell in the examples
Seems this was not picked up so I went ahead and applied to
drm-misc-next.
Sam
> ---
> .../bindings/display/bridge/renesas,lvds.txt | 85 --
> .../bindings/display/bridge/renesas,lvds.yaml | 248 ++
> 2 files changed, 248 insertions(+), 85 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> deleted file mode 100644
> index c62ce2494ed9..
> --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> +++ /dev/null
> @@ -1,85 +0,0 @@
> -Renesas R-Car LVDS Encoder
> -==
> -
> -These DT bindings describe the LVDS encoder embedded in the Renesas R-Car
> -Gen2, R-Car Gen3 and RZ/G SoCs.
> -
> -Required properties:
> -
> -- compatible : Shall contain one of
> - - "renesas,r8a7743-lvds" for R8A7743 (RZ/G1M) compatible LVDS encoders
> - - "renesas,r8a7744-lvds" for R8A7744 (RZ/G1N) compatible LVDS encoders
> - - "renesas,r8a774a1-lvds" for R8A774A1 (RZ/G2M) compatible LVDS encoders
> - - "renesas,r8a774b1-lvds" for R8A774B1 (RZ/G2N) compatible LVDS encoders
> - - "renesas,r8a774c0-lvds" for R8A774C0 (RZ/G2E) compatible LVDS encoders
> - - "renesas,r8a7790-lvds" for R8A7790 (R-Car H2) compatible LVDS encoders
> - - "renesas,r8a7791-lvds" for R8A7791 (R-Car M2-W) compatible LVDS encoders
> - - "renesas,r8a7793-lvds" for R8A7793 (R-Car M2-N) compatible LVDS encoders
> - - "renesas,r8a7795-lvds" for R8A7795 (R-Car H3) compatible LVDS encoders
> - - "renesas,r8a7796-lvds" for R8A7796 (R-Car M3-W) compatible LVDS encoders
> - - "renesas,r8a77965-lvds" for R8A77965 (R-Car M3-N) compatible LVDS
> encoders
> - - "renesas,r8a77970-lvds" for R8A77970 (R-Car V3M) compatible LVDS encoders
> - - "renesas,r8a77980-lvds" for R8A77980 (R-Car V3H) compatible LVDS encoders
> - - "renesas,r8a77990-lvds" for R8A77990 (R-Car E3) compatible LVDS encoders
> - - "renesas,r8a77995-lvds" for R8A77995 (R-Car D3) compatible LVDS encoders
> -
> -- reg: Base address and length for the memory-mapped registers
> -- clocks: A list of phandles + clock-specifier pairs, one for each entry in
> - the clock-names property.
> -- clock-names: Name of the clocks. This property is model-dependent.
> - - The functional clock, which mandatory for all models, shall be listed
> -first, and shall be named "fck".
> - - On R8A77990, R8A77995 and R8A774C0, the LVDS encoder can use the EXTAL or
> -DU_DOTCLKINx clocks. Those clocks are optional. When supplied they must
> be
> -named "extal" and "dclkin.x" respectively, with "x" being the DU_DOTCLKIN
> -numerical index.
> - - When the clocks property only contains the functional clock, the
> -clock-names property may be omitted.
> -- resets: A phandle + reset specifier for the module reset
> -
> -Required nodes:
> -
> -The LVDS encoder has two video ports. Their connections are modelled using
> the
> -OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> -
> -- Video port 0 corresponds to the parallel RGB input
> -- Video port 1 corresponds to the LVDS output
> -
> -Each port shall have a single endpoint.
> -
> -Optional properties:
> -
> -- renesas,companion : phandle to the companion LVDS encoder. This property is
> - mandatory for the first LVDS encoder on D3 and E3 SoCs, and shall point to
> - the second encoder to be used as a companion in dual-link mode. It shall
> not
> - be set for any other LVDS encoder.
> -
> -
> -Example:
> -
> - lvds0: lvds@feb9 {
> - compatible = "renesas,r8a77990-lvds";
> - reg = <0 0xfeb9 0 0x20>;
> - clocks = < CPG_MOD 727>;
> - power-domains = < R8A77990_PD_ALWAYS_ON>;
> - resets = < 727>;
> -
> - renesas,companion = <>;
> -
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - reg = <0>;
> - lvds0_in: endpoint {
> - remote-endpoint = <_out_lvds0>;
> - };
> - };
> - port@1 {
> - reg = <1>;
> - lvds0_out: endpoint {
> - };
> - };
Re: [PATCH 1/2] drm/panel-simple: add support for NEC NL10276BC13-01C panel
On Mon, May 11, 2020 at 11:29:24PM +0300, Maksim Melnikov wrote:
> The NL10276BC13-01C is a 6.5" 1024x768 XGA TFT LCD panel with LVDS interface.
> It is used for industrial purposes in devices such as HMI.
>
> Signed-off-by: Maksim Melnikov
> ---
> drivers/gpu/drm/panel/panel-simple.c | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 3ad828eae..7ded13157 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2372,6 +2372,31 @@ static const struct panel_desc nec_nl4827hc19_05b = {
> .bus_flags = DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
> };
>
> +static const struct display_timing nec_nl10276bc13_01c_timing = {
> + .pixelclock = { 6260, 6820, 7810 },
> + .hactive = { 1024, 1024, 1024 },
> + .hfront_porch = { 15, 64, 159 },
> + .hback_porch = { 5, 5, 5 },
> + .hsync_len = { 1, 1, 256 },
> + .vactive = { 768, 768, 768 },
> + .vfront_porch = { 3, 40, 99 },
> + .vback_porch = { 2, 2, 2 },
> + .vsync_len = { 1, 1, 128 },
> + .flags = DISPLAY_FLAGS_DE_HIGH,
> +};
> +
> +static const struct panel_desc nec_nl10276bc13_01c = {
> + .timings = _nl10276bc13_01c_timing,
> + .num_timings = 1,
> + .bpc = 8,
> + .size = {
> + .width = 132,
> + .height = 99,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA,
> + .connector_type = DRM_MODE_CONNECTOR_LVDS,
Sorry for getting back so late.
Please include .bus_flags too.
We want the description to be complete.
Sam
> +};
> +
> static const struct drm_display_mode netron_dy_e231732_mode = {
> .clock = 66000,
> .hdisplay = 1024,
> @@ -3634,6 +3659,9 @@ static const struct of_device_id platform_of_match[] = {
> }, {
> .compatible = "nec,nl4827hc19-05b",
> .data = _nl4827hc19_05b,
> + }, {
> + .compatible = "nec,nl10276bc13_01c",
> + .data = _nl10276bc13_01c,
> }, {
> .compatible = "netron-dy,e231732",
> .data = _dy_e231732,
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/dsi: use stack buffer in mipi_dsi_dcs_write()
On Tue, May 05, 2020 at 05:03:27PM +0100, Emil Velikov wrote:
> Currently the function heap allocates when we have any payload. Where in
> many case the payload is 1 byte - ouch.
>
> >From casual observation, vast majority of the payloads are smaller than
> 8 bytes - so use a stack array tx[8] to avoid the senseless kmalloc and
> kfree dance.
>
> Cc: Jani Nikula
> Cc: Thierry Reding
> Signed-off-by: Emil Velikov
Applied to drm-misc-next. Sorry for taking so long.
Sam
> ---
> drivers/gpu/drm/drm_mipi_dsi.c | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> index 55531895dde6..b96d5b4629d7 100644
> --- a/drivers/gpu/drm/drm_mipi_dsi.c
> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> @@ -748,26 +748,26 @@ ssize_t mipi_dsi_dcs_write(struct mipi_dsi_device *dsi,
> u8 cmd,
> {
> ssize_t err;
> size_t size;
> + u8 stack_tx[8];
> u8 *tx;
>
> - if (len > 0) {
> - size = 1 + len;
> -
> + size = 1 + len;
> + if (len > ARRAY_SIZE(stack_tx) - 1) {
> tx = kmalloc(size, GFP_KERNEL);
> if (!tx)
> return -ENOMEM;
> -
> - /* concatenate the DCS command byte and the payload */
> - tx[0] = cmd;
> - memcpy([1], data, len);
> } else {
> - tx =
> - size = 1;
> + tx = stack_tx;
> }
>
> + /* concatenate the DCS command byte and the payload */
> + tx[0] = cmd;
> + if (data)
> + memcpy([1], data, len);
> +
> err = mipi_dsi_dcs_write_buffer(dsi, tx, size);
>
> - if (len > 0)
> + if (tx != stack_tx)
> kfree(tx);
>
> return err;
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/mipi: use dcs write for mipi_dsi_dcs_set_tear_scanline
On Tue, May 05, 2020 at 05:03:29PM +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> The helper uses the MIPI_DCS_SET_TEAR_SCANLINE, although it's currently
> using the generic write. This does not look right.
>
> Perhaps some platforms don't distinguish between the two writers?
>
> Cc: Robert Chiras
> Cc: Vinay Simha BN
> Cc: Jani Nikula
> Cc: Thierry Reding
> Fixes: e83950816367 ("drm/dsi: Implement set tear scanline")
> Signed-off-by: Emil Velikov
> ---
> Robert, can you please test this against the only user - the Raydium
> RM67191 panel driver that you introduced.
>
> Thanks
>
> Vinay, can you confirm if this is a genuine typo or there's something
> really subtle happening.
> ---
> drivers/gpu/drm/drm_mipi_dsi.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
The discussion did not reveal anything new. Followed the advice of
Thierry and applied.
Sam
>
> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> index b96d5b4629d7..07102d8da58f 100644
> --- a/drivers/gpu/drm/drm_mipi_dsi.c
> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> @@ -1082,11 +1082,11 @@ EXPORT_SYMBOL(mipi_dsi_dcs_set_pixel_format);
> */
> int mipi_dsi_dcs_set_tear_scanline(struct mipi_dsi_device *dsi, u16 scanline)
> {
> - u8 payload[3] = { MIPI_DCS_SET_TEAR_SCANLINE, scanline >> 8,
> - scanline & 0xff };
> + u8 payload[2] = { scanline >> 8, scanline & 0xff };
> ssize_t err;
>
> - err = mipi_dsi_generic_write(dsi, payload, sizeof(payload));
> + err = mipi_dsi_dcs_write(dsi, MIPI_DCS_SET_TEAR_SCANLINE, payload,
> + sizeof(payload));
> if (err < 0)
> return err;
>
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/panel: use mipi_dsi_dcs_write_buffer where possible
On Mon, May 11, 2020 at 12:28:40PM +0100, Emil Velikov wrote:
> On Tue, 5 May 2020 at 17:05, Emil Velikov wrote:
> >
> > From: Emil Velikov
> >
> > A few of the new panels create a local macro wrapping around
> > mipi_dsi_dcs_write. At the same time, they don't really care about the
> > command/payload split.
> >
> > mipi_dsi_dcs_write does a kmalloc/memcpy/kfree for payload > 7 bytes.
> > kmalloc - avoid that all together by using the _buffer function.
> >
> Seems like I've left an extra word here - will fix in v2, alongside
> any review feedback.
> s/kmalloc - avoid/Avoid/
>
> > Aside:
> > panel-xinpeng-xpp055c272.c calls its wrapper "generic" although it
> > should be "dcs". But that for another day/patch.
> >
> > Cc: Heiko Stuebner
> > Cc: Heiko Stuebner
> > Cc: Thierry Reding
> > Cc: Sam Ravnborg
> > Signed-off-by: Emil Velikov
Fixed up changelog when applied to drm-misc-next.
Sam
> > ---
> > drivers/gpu/drm/panel/panel-elida-kd35t133.c | 4 ++--
> > drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c | 4 ++--
> > drivers/gpu/drm/panel/panel-xinpeng-xpp055c272.c | 4 ++--
> > 3 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> > b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> > index 711ded453c44..00e3d67af812 100644
> > --- a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> > +++ b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> > @@ -52,9 +52,9 @@ static inline struct kd35t133 *panel_to_kd35t133(struct
> > drm_panel *panel)
> > }
> >
> > #define dsi_dcs_write_seq(dsi, cmd, seq...) do { \
> > - static const u8 d[] = { seq }; \
> > + static const u8 b[] = { cmd, seq }; \
> > int ret;\
> > - ret = mipi_dsi_dcs_write(dsi, cmd, d, ARRAY_SIZE(d)); \
> > + ret = mipi_dsi_dcs_write_buffer(dsi, b, ARRAY_SIZE(b)); \
> > if (ret < 0)\
> > return ret; \
> > } while (0)
> > diff --git a/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
> > b/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
> > index 5a7a31c8513e..eaa9da3ebbea 100644
> > --- a/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
> > +++ b/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
> > @@ -246,9 +246,9 @@ struct ltk050h3146w *panel_to_ltk050h3146w(struct
> > drm_panel *panel)
> > }
> >
> > #define dsi_dcs_write_seq(dsi, cmd, seq...) do { \
> > - static const u8 d[] = { seq }; \
> > + static const u8 b[] = { cmd, seq }; \
> > int ret;\
> > - ret = mipi_dsi_dcs_write(dsi, cmd, d, ARRAY_SIZE(d)); \
> > + ret = mipi_dsi_dcs_write_buffer(dsi, b, ARRAY_SIZE(b)); \
> > if (ret < 0)\
> > return ret; \
> > } while (0)
> > diff --git a/drivers/gpu/drm/panel/panel-xinpeng-xpp055c272.c
> > b/drivers/gpu/drm/panel/panel-xinpeng-xpp055c272.c
> > index 1645aceab597..9e07d7e86807 100644
> > --- a/drivers/gpu/drm/panel/panel-xinpeng-xpp055c272.c
> > +++ b/drivers/gpu/drm/panel/panel-xinpeng-xpp055c272.c
> > @@ -62,9 +62,9 @@ static inline struct xpp055c272
> > *panel_to_xpp055c272(struct drm_panel *panel)
> > }
> >
> > #define dsi_generic_write_seq(dsi, cmd, seq...) do { \
> > - static const u8 d[] = { seq }; \
> > + static const u8 b[] = { cmd, seq }; \
> > int ret;\
> > - ret = mipi_dsi_dcs_write(dsi, cmd, d, ARRAY_SIZE(d)); \
> > + ret = mipi_dsi_dcs_write_buffer(dsi, b, ARRAY_SIZE(b)); \
> > if (ret < 0)\
> > return ret; \
> > } while (0)
> > --
> > 2.25.1
> >
>
> Humble poke?
>
> -Emil
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #33 from Michel Dänzer (mic...@daenzer.net) --- (In reply to rtmasura+kernel from comment #24) > xfwm4 --replace --vblank=glx & FWIW, I recommend xfwm4 --vblank=xpresent instead. --vblank=glx is less efficient and relies on rather exotic GLX functionality which can be quirky with Mesa. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/zte: remove unneeded semicolon
On Mon, May 04, 2020 at 07:32:30PM +0800, Jason Yan wrote:
> Fix the following coccicheck warning:
>
> drivers/gpu/drm/zte/zx_vga.c:158:2-3: Unneeded semicolon
> drivers/gpu/drm/zte/zx_vga.c:171:2-3: Unneeded semicolon
> drivers/gpu/drm/zte/zx_vga.c:179:2-3: Unneeded semicolon
>
> Signed-off-by: Jason Yan
Applied to drm-misc-next.
Sam
> ---
> drivers/gpu/drm/zte/zx_vga.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/zte/zx_vga.c b/drivers/gpu/drm/zte/zx_vga.c
> index a7ed7f5ca837..0f9bbb7e3b8d 100644
> --- a/drivers/gpu/drm/zte/zx_vga.c
> +++ b/drivers/gpu/drm/zte/zx_vga.c
> @@ -155,7 +155,7 @@ static int zx_vga_register(struct drm_device *drm, struct
> zx_vga *vga)
> if (ret) {
> DRM_DEV_ERROR(dev, "failed to init encoder: %d\n", ret);
> return ret;
> - };
> + }
>
> drm_encoder_helper_add(encoder, _vga_encoder_helper_funcs);
>
> @@ -168,7 +168,7 @@ static int zx_vga_register(struct drm_device *drm, struct
> zx_vga *vga)
> if (ret) {
> DRM_DEV_ERROR(dev, "failed to init connector: %d\n", ret);
> goto clean_encoder;
> - };
> + }
>
> drm_connector_helper_add(connector, _vga_connector_helper_funcs);
>
> @@ -176,7 +176,7 @@ static int zx_vga_register(struct drm_device *drm, struct
> zx_vga *vga)
> if (ret) {
> DRM_DEV_ERROR(dev, "failed to attach encoder: %d\n", ret);
> goto clean_connector;
> - };
> + }
>
> return 0;
>
> --
> 2.21.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/bridge: dw-hdmi: Always add the bridge in the global bridge list
Hi Laurent,
On Sun, 2020-06-28 at 11:22 +0300, Laurent Pinchart wrote:
> Hi Liu,
>
> (CC'ing Sam)
>
> Thank you for the patch.
Thanks for your review.
>
> On Tue, Jun 16, 2020 at 05:04:52PM +0800, Liu Ying wrote:
> > It doesn't hurt to add the bridge in the global bridge list also
> > for
> > platform specific dw-hdmi drivers which are based on the component
> > framework. This can be achieved by moving the drm_bridge_add()
> > function
> > call from dw_hdmi_probe() to __dw_hdmi_probe(). Moreover, putting
> > the
> > drm_bridge_add() function call prior to the interrupt registration
> > and
> > enablement ensures that the mutex hpd_mutex embedded in the
> > structure
> > drm_bridge can be initialized in drm_bridge_add() beforehand, which
> > avoids accessing the uninitialized mutex in case people want to
> > call
> > function drm_bridge_hpd_notify() with the mutex locked internally
> > to
> > handle hot plug detection event in the interrupt handler
> > dw_hdmi_irq().
> >
> > Cc: Andrzej Hajda
> > Cc: Neil Armstrong
> > Cc: Laurent Pinchart
> > Cc: Jonas Karlman
> > Cc: Jernej Skrabec
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: Boris Brezillon
> > Cc: Jerome Brunet
> > Cc: Cheng-Yi Chiang
> > Cc: Dariusz Marcinkiewicz
> > Cc: Archit Taneja
> > Cc: Jose Abreu
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: NXP Linux Team
> > Signed-off-by: Liu Ying
> > ---
> > Laurent,
> >
> > I may see the uninitialized mutex accessing issue with
> > i.MX dw-hdmi after applying your below patch set[1].
> > I think patch '[22/27] drm: bridge: dw-hdmi: Make connector
> > creation optional'
> > triggers the issue.
> >
> > [1]
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fcover%2F11569709%2Fdata=02%7C01%7Cvictor.liu%40nxp.com%7Cca86b38a5fbc49a44b1c08d81b3c5cde%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637289293354715359sdata=C7kz8HONVSNMYkQGb4h9uVcdZHqJVSmtwgnN4J2cKws%3Dreserved=0
> >
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 34 ++-
> >
> > 1 file changed, 15 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > index da84a91..4711700 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > @@ -3247,17 +3247,25 @@ __dw_hdmi_probe(struct platform_device
> > *pdev,
> >
> > dw_hdmi_init_hw(hdmi);
> >
> > + hdmi->bridge.driver_private = hdmi;
> > + hdmi->bridge.funcs = _hdmi_bridge_funcs;
> > +#ifdef CONFIG_OF
> > + hdmi->bridge.of_node = pdev->dev.of_node;
> > +#endif
> > +
> > + drm_bridge_add(>bridge);
>
> This would introduce a race condition where a display driver could
> get
> hold of the bridge before it is fully initialized.
Yes, it seems it's a bit too early to add the bridge in the global
bridge list.
>
> I fear the right fix for this may be to add a drm_bridge_init()
> function
> to move mutex initialization away from drm_bridge_add(). That's a
> rather
> intrusive change I'm afraid :-(
Looking into the issue more closely, it may be solved by moving
drm_bridge_add() from dw_hdmi_probe() to __dw_hdmi_probe() just before
__dw_hdmi_probe() returns successfully and a counterpart movement for
drm_bridge_remove(). The key is that hdmi->bridge.dev must be !NULL
when drm_bridge_hpd_notify() is called in dw_hdmi_irq() and
hdmi->bridge.dev is set in drm_bridge_attach() after drm_bridge_add()
is called.
This looks more safe because there is no logic change as
dw_hdmi_probe()/dw_hdmi_remove() see and just an additional
drm_bridge_add()/drm_bridge_remove() call as
dw_hdmi_bind()/dw_hdmi_unbind() see.
I plan to test this with i.MX dw-hdmi tomorrow.
>
> > +
> > irq = platform_get_irq(pdev, 0);
> > if (irq < 0) {
> > ret = irq;
> > - goto err_iahb;
> > + goto err_irq;
> > }
> >
> > ret = devm_request_threaded_irq(dev, irq, dw_hdmi_hardirq,
> > dw_hdmi_irq, IRQF_SHARED,
> > dev_name(dev), hdmi);
> > if (ret)
> > - goto err_iahb;
> > + goto err_irq;
> >
> > /*
> > * To prevent overflows in HDMI_IH_FC_STAT2, set the clk
> > regenerator
> > @@ -3290,12 +3298,6 @@ __dw_hdmi_probe(struct platform_device
> > *pdev,
> > hdmi->ddc = NULL;
> > }
> >
> > - hdmi->bridge.driver_private = hdmi;
> > - hdmi->bridge.funcs = _hdmi_bridge_funcs;
> > -#ifdef CONFIG_OF
> > - hdmi->bridge.of_node = pdev->dev.of_node;
> > -#endif
> > -
> > if (hdmi->version >= 0x200a)
> > hdmi->connector.ycbcr_420_allowed =
> > hdmi->plat_data->ycbcr_420_allowed;
> > @@ -3357,6 +3359,8 @@ __dw_hdmi_probe(struct platform_device *pdev,
> >
> > return hdmi;
> >
> > +err_irq:
> > + drm_bridge_remove(>bridge);
> > err_iahb:
> >
Re: [PATCH 1/4] usb: cdns3: gadget: Replace trace_printk by dev_dbg
On 20-06-27 15:03:04, Nicolas Boichat wrote:
> trace_printk should not be used in production code, replace it
> call with dev_dbg.
>
> Signed-off-by: Nicolas Boichat
>
> ---
>
> Unclear why a trace_printk was used in the first place, it's
> possible that some rate-limiting is necessary here.
>
> drivers/usb/cdns3/gadget.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c
> index 5e24c2e57c0d8c8..c303ab7c62d1651 100644
> --- a/drivers/usb/cdns3/gadget.c
> +++ b/drivers/usb/cdns3/gadget.c
> @@ -421,7 +421,7 @@ static int cdns3_start_all_request(struct cdns3_device
> *priv_dev,
> if ((priv_req->flags & REQUEST_INTERNAL) ||
> (priv_ep->flags & EP_TDLCHK_EN) ||
> priv_ep->use_streams) {
> - trace_printk("Blocking external request\n");
> + dev_dbg(priv_dev->dev, "Blocking external request\n");
> return ret;
> }
> }
> --
Reviewed-by: Peter Chen
--
Thanks,
Peter Chen
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: panel: simple: Drop drive/sample bus flags for LVDS panels
В Sun, 28 Jun 2020 10:54:01 +0300 Laurent Pinchart пишет: > The DRM bus flags reporting on which clock edge the pixel data and > sync signals are sampled or driven don't make sense for LVDS panels, > as the bus then uses sub-clock timings to send data. Drop those flags > and add a warning in the probe function to make sure the mistake > won't be repeated. > > Signed-off-by: Laurent Pinchart > --- > drivers/gpu/drm/panel/panel-simple.c | 30 > +--- 1 file changed, 18 insertions(+), 12 > deletions(-) > > diff --git a/drivers/gpu/drm/panel/panel-simple.c > b/drivers/gpu/drm/panel/panel-simple.c index > bff1cab529d2..537d75ef7fc2 100644 --- > a/drivers/gpu/drm/panel/panel-simple.c +++ > b/drivers/gpu/drm/panel/panel-simple.c @@ -549,6 +549,14 @@ static > int panel_simple_probe(struct device *dev, const struct panel_desc > *desc) panel_simple_parse_panel_timing_node(dev, panel, ); } > > + if (desc->connector_type == DRM_MODE_CONNECTOR_LVDS) > + /* Catch common mistakes for LVDS panels. */ > + WARN_ON(desc->bus_flags & > + (DRM_BUS_FLAG_PIXDATA_POSEDGE | > + DRM_BUS_FLAG_PIXDATA_NEGEDGE | > + DRM_BUS_FLAG_SYNC_POSEDGE | > + DRM_BUS_FLAG_SYNC_NEGEDGE)); Very nice! Thank you! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/6] gpu: host1x: Put gather's BO on pinning error
This patch fixes gather's BO refcounting on a pinning error. Gather's BO
won't be leaked now if something goes wrong.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/host1x/job.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index a954bd41aa79..89b6c14b7392 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -105,6 +105,7 @@ static unsigned int pin_job(struct host1x *host, struct
host1x_job *job)
{
struct host1x_client *client = job->client;
struct device *dev = client->dev;
+ struct host1x_job_gather *g;
struct iommu_domain *domain;
unsigned int i;
int err;
@@ -194,7 +195,6 @@ static unsigned int pin_job(struct host1x *host, struct
host1x_job *job)
return 0;
for (i = 0; i < job->num_gathers; i++) {
- struct host1x_job_gather *g = >gathers[i];
size_t gather_size = 0;
struct scatterlist *sg;
struct sg_table *sgt;
@@ -204,6 +204,7 @@ static unsigned int pin_job(struct host1x *host, struct
host1x_job *job)
dma_addr_t *phys;
unsigned int j;
+ g = >gathers[i];
g->bo = host1x_bo_get(g->bo);
if (!g->bo) {
err = -EINVAL;
@@ -223,7 +224,7 @@ static unsigned int pin_job(struct host1x *host, struct
host1x_job *job)
sgt = host1x_bo_pin(host->dev, g->bo, phys);
if (IS_ERR(sgt)) {
err = PTR_ERR(sgt);
- goto unpin;
+ goto put;
}
if (host->domain) {
@@ -236,7 +237,7 @@ static unsigned int pin_job(struct host1x *host, struct
host1x_job *job)
host->iova_end >> shift, true);
if (!alloc) {
err = -ENOMEM;
- goto unpin;
+ goto put;
}
err = iommu_map_sg(host->domain,
@@ -245,7 +246,7 @@ static unsigned int pin_job(struct host1x *host, struct
host1x_job *job)
if (err == 0) {
__free_iova(>iova, alloc);
err = -EINVAL;
- goto unpin;
+ goto put;
}
job->unpins[job->num_unpins].size = gather_size;
@@ -255,7 +256,7 @@ static unsigned int pin_job(struct host1x *host, struct
host1x_job *job)
DMA_TO_DEVICE);
if (!err) {
err = -ENOMEM;
- goto unpin;
+ goto put;
}
job->unpins[job->num_unpins].dir = DMA_TO_DEVICE;
@@ -273,6 +274,8 @@ static unsigned int pin_job(struct host1x *host, struct
host1x_job *job)
return 0;
+put:
+ host1x_bo_put(g->bo);
unpin:
host1x_job_unpin(job);
return err;
--
2.26.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/6] gpu: host1x: debug: Dump push buffer state
When job hangs and there is a memory error pointing at channel's push
buffer, it is very handy to know the push buffer's state. This patch
makes the push buffer's state to be dumped into KMSG in addition to the
job's gathers.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/host1x/hw/debug_hw.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/host1x/hw/debug_hw.c b/drivers/gpu/host1x/hw/debug_hw.c
index 02125842071c..f31bcfa1b837 100644
--- a/drivers/gpu/host1x/hw/debug_hw.c
+++ b/drivers/gpu/host1x/hw/debug_hw.c
@@ -192,8 +192,14 @@ static void show_gather(struct output *o, phys_addr_t
phys_addr,
static void show_channel_gathers(struct output *o, struct host1x_cdma *cdma)
{
+ struct push_buffer *pb = >push_buffer;
struct host1x_job *job;
+ host1x_debug_output(o, "PUSHBUF at %pad, %u words\n",
+ >dma, pb->size / 4);
+
+ show_gather(o, pb->dma, pb->size / 4, cdma, pb->dma, pb->mapped);
+
list_for_each_entry(job, >sync_queue, list) {
unsigned int i;
--
2.26.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/6] drm/tegra: gr2d: Add tiled PATBASE address register
There are two PATBASE address registers, one for linear layout and other
for tiled. The driver's address registers list misses the tiled PATBASE
register.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/gr2d.c | 1 +
drivers/gpu/drm/tegra/gr2d.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c
index 48363f744bb9..1a0d3ba6e525 100644
--- a/drivers/gpu/drm/tegra/gr2d.c
+++ b/drivers/gpu/drm/tegra/gr2d.c
@@ -177,6 +177,7 @@ static const u32 gr2d_addr_regs[] = {
GR2D_DSTC_BASE_ADDR,
GR2D_SRCA_BASE_ADDR,
GR2D_SRCB_BASE_ADDR,
+ GR2D_PATBASE_ADDR,
GR2D_SRC_BASE_ADDR_SB,
GR2D_DSTA_BASE_ADDR_SB,
GR2D_DSTB_BASE_ADDR_SB,
diff --git a/drivers/gpu/drm/tegra/gr2d.h b/drivers/gpu/drm/tegra/gr2d.h
index 2398486f0699..9b7d66e15b9f 100644
--- a/drivers/gpu/drm/tegra/gr2d.h
+++ b/drivers/gpu/drm/tegra/gr2d.h
@@ -14,6 +14,7 @@
#define GR2D_DSTC_BASE_ADDR0x2d
#define GR2D_SRCA_BASE_ADDR0x31
#define GR2D_SRCB_BASE_ADDR0x32
+#define GR2D_PATBASE_ADDR 0x47
#define GR2D_SRC_BASE_ADDR_SB 0x48
#define GR2D_DSTA_BASE_ADDR_SB 0x49
#define GR2D_DSTB_BASE_ADDR_SB 0x4a
--
2.26.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/6] gpu: host1x: Optimize BOs usage when firewall is enabled
We don't need to hold and pin original BOs of the gathers in a case of
enabled firewall because in this case gather's content is copied and the
copy is used by the executed job.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/host1x/job.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index a10643aa89aa..a954bd41aa79 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -27,10 +27,13 @@ struct host1x_job *host1x_job_alloc(struct host1x_channel
*ch,
u32 num_cmdbufs, u32 num_relocs)
{
struct host1x_job *job = NULL;
- unsigned int num_unpins = num_cmdbufs + num_relocs;
+ unsigned int num_unpins = num_relocs;
u64 total;
void *mem;
+ if (!IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL))
+ num_unpins += num_cmdbufs;
+
/* Check that we're not going to overflow */
total = sizeof(struct host1x_job) +
(u64)num_relocs * sizeof(struct host1x_reloc) +
@@ -183,6 +186,13 @@ static unsigned int pin_job(struct host1x *host, struct
host1x_job *job)
job->num_unpins++;
}
+ /*
+* We will copy gathers BO content later, so there is no need to
+* hold and pin them.
+*/
+ if (IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL))
+ return 0;
+
for (i = 0; i < job->num_gathers; i++) {
struct host1x_job_gather *g = >gathers[i];
size_t gather_size = 0;
@@ -216,7 +226,7 @@ static unsigned int pin_job(struct host1x *host, struct
host1x_job *job)
goto unpin;
}
- if (!IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL) && host->domain) {
+ if (host->domain) {
for_each_sg(sgt->sgl, sg, sgt->nents, j)
gather_size += sg->length;
gather_size = iova_align(>iova, gather_size);
--
2.26.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Host1x/TegraDRM UAPI (drm_tegra_channel_map)
28.06.2020 14:16, Mikko Perttunen пишет:
> On 6/26/20 7:35 PM, Dmitry Osipenko wrote:
>> 26.06.2020 10:34, Thierry Reding пишет:
>>> On Fri, Jun 26, 2020 at 01:47:46AM +0300, Dmitry Osipenko wrote:
23.06.2020 15:09, Mikko Perttunen пишет:
> ### DRM_TEGRA_CHANNEL_MAP
>
> Make memory accessible by the engine while executing work on the
> channel.
>
> ```
> #define DRM_TEGRA_CHANNEL_MAP_READWRITE (1<<0)
>
> struct drm_tegra_channel_map {
> /*
> * [in] ID of the channel for which to map memory to.
> */
> __u32 channel_id;
> /*
> * [in] GEM handle of the memory to map.
> */
> __u32 handle;
>
> /*
> * [in] Offset in GEM handle of the memory area to map.
> *
> * Must be aligned by 4K.
> */
> __u64 offset;
Could you please give a use-case example for this partial mapping?
I vaguely recalling that maybe it was me who suggested this in the
past..
I kinda see that this could be useful for a case where userspace
allocates a large chunk of memory and then performs sub-allocations in
the userspace driver. But do we have a real-world example for this
right
now?
>>>
>>> I think the main point about this IOCTL was to make mapping/unmapping
>>> more efficient and avoid relocations for situations where we know it is
>>> safe to do so.
>>>
>>> The fact that this can be used to create partial mappings is mostly just
>>> an added bonus, in my opinion. Doing this doesn't create much complexity
>>> but in turn gives us a lot more flexibility.
>>>
>>> A couple of places where I think this could be useful are OpenGL and
>>> Vulkan, both of which support buffer suballocation. This has a couple of
>>> advantages on modern GPUs where sometimes you want to use very large
>>> allocation granularity, etc.
>>>
>>> Now, I don't think that we'll see much of that in Tegra DRM directly,
>>> although grate could certainly make use of this, I suspect. However, I
>>> think for interoperation of dGPU and Tegra DRM (with VIC for post-
>>> processing, or hopefully some of the other hardware acceleration
>>> engines at some point), this might come in handy.
>>>
>>> There are other possible use-cases within just Tegra DRM as well. We may
>>> want to only partially map planar buffers for video post-processing, for
>>> example. Or map each plane separately.
>>>
Please see more below.
> /*
> * [in] Length of memory area to map in bytes.
> *
> * Must be aligned by 4K.
> */
> __u64 length;
>
> /*
> * [out] IOVA of mapped memory. Userspace can use this IOVA
> * directly to refer to the memory to skip using
> relocations.
> * Only available if hardware memory isolation is enabled.
> *
> * Will be set to 0x___ if unavailable.
> */
> __u64 iova;
>
> /*
> * [out] ID corresponding to the mapped memory to be used for
> * relocations or unmapping.
> */
> __u32 mapping_id;
> /*
> * [in] Flags.
> */
> __u32 flags;
>
> __u32 reserved[6];
> };
It looks to me that we actually need a bit different thing here.
This MAP IOCTL maps a portion of a GEM and then returns the mapping_id.
And I think we need something more flexible that will allow us to use
GEM handles for the relocation IDs, which should fit nicely with the
DMA-reservations.
What about an IOCTL that wraps GEM into another GEM? We could wrap a
portion of GEM_A into a GEM_B, and then map the GEM_B using the MAP
IOCTL.
It could be something like this:
### DRM_TEGRA_BO_WRAP
struct drm_tegra_wrap_bo {
__u32 bo_handle_wrapped; // out
__u32 bo_handle; // in
__u64 offset;
__u64 length;
};
### DRM_TEGRA_CHANNEL_MAP
struct drm_tegra_channel_map {
__u32 channels_mask;
__u32 mapping_id;
__u32 bo_handle;
__u32 flags;
__u64 iova;
};
===
This allows multiple mapping_ids to have the same backing GEM, so the
mapping_id could be resolved into a BO during of job's submission for
the DMA-reservations handling.
>>>
>>> That's pretty much what we have already above, isn't it? Just because we
>>> call the field "mapping_id" doesn't mean that in the background we can't
>>> create a GEM object and return it's handle as "mapping_id".
>>>
>>> One advantage of Mikko's proposal is that we have a single IOCTL rather
>>> than
[PATCH v2 0/6] Tegra DRM / Host1x drivers improvements and corrections
Hello! This small series fixes a few minor long-standing problems of the Tegra DRM and Host1x drivers. It also adds a push buffer dumping support, which is a minor debugging feature. Changelog: v2: - The drm/tegra and host1x patches got aggregated into this common series because I'm a bit worried that the standalone patches may become forgotten for a long time. - In the patch "gpu: host1x: debug: Dump push buffer state" I fixed the printk formatting problem on ARM64 that was reported by kernel test robot for a previous version of this patch. Dmitry Osipenko (6): drm/tegra: gr3d: Assert reset before power-gating drm/tegra: gr2d: Add tiled PATBASE address register gpu: host1x: Optimize BOs usage when firewall is enabled gpu: host1x: Put gather's BO on pinning error gpu: host1x: debug: Fix multiple channels emitting messages simultaneously gpu: host1x: debug: Dump push buffer state drivers/gpu/drm/tegra/gr2d.c | 1 + drivers/gpu/drm/tegra/gr2d.h | 1 + drivers/gpu/drm/tegra/gr3d.c | 2 ++ drivers/gpu/host1x/debug.c | 4 drivers/gpu/host1x/hw/debug_hw.c | 6 ++ drivers/gpu/host1x/job.c | 27 --- 6 files changed, 34 insertions(+), 7 deletions(-) -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Host1x/TegraDRM UAPI (sync points)
28.06.2020 12:44, Mikko Perttunen пишет:
> On 6/28/20 2:27 AM, Dmitry Osipenko wrote:
>> 23.06.2020 15:09, Mikko Perttunen пишет:
>>>
>>> ### IOCTL HOST1X_ALLOCATE_SYNCPOINT (on /dev/host1x)
>>>
>>> Allocates a free syncpoint, returning a file descriptor representing it.
>>> Only the owner of the file descriptor is allowed to mutate the value of
>>> the syncpoint.
>>>
>>> ```
>>> struct host1x_ctrl_allocate_syncpoint {
>>> /**
>>> * @fd:
>>> *
>>> * [out] New file descriptor representing the allocated
>>> syncpoint.
>>> */
>>> __s32 fd;
>>>
>>> __u32 reserved[3];
>>> };
>>
>> We should need at least these basic things from the sync points API >
>> - Execution context shouldn't be able to tamper sync points of the other
>> contexts.
>
> This is covered by this UAPI - when submitting, as part of the
> syncpt_incr struct you pass the syncpoint FD. This way the driver can
> check the syncpoints used are correct, or program HW protection.
>
>>
>> - Sync point could be shared with other contexts for explicit fencing.
>
> Not sure what you specifically mean; you can get the ID out of the
> syncpoint fd and share the ID for read-only access. (Or the FD for
> read-write access)
I enumerated the overall points that UAPI should provide to us, just for
clarity. Not like you haven't covered any of them, sorry for the
confusion! :)
Please see more comments below!
>>
>> - Sync points should work reliably.
>>
>> Some problems of the current Host1x driver, like where it falls over if
>> sync point value is out-of-sync + all the hang-job recovery labor could
>> be easily reduced if sync point health is protected by extra UAPI
>> constraints. >
>> So I think we may want the following:
>>
>> 1. We still should need to assign sync point ID to a DRM-channel's
>> context. This sync point ID will be used for a commands stream forming,
>> like it is done by the current staging UAPI.
>>
>> So we should need to retain the DRM_TEGRA_GET_SYNCPT IOCTL, but
>> improve it.
My point here is that the UAPI shouldn't be able to increment the job's
sync point using SYNCPOINT_INCREMENT IOCTL, which is another UAPI
constraint.
I'm suggesting that we should have two methods of sync point allocations:
1) Sync point that could be used only by a submitted job.
2) Sync point that could be incremented by CPU.
The first method will allocate a raw sync point ID that is assigned to
the channel's context. This ID will be used for the job's completion
tracking. Perhaps this method also could optionally return a sync point
FD if you'd want to wait on this sync point by another job.
We don't need a dedicated sync point FD for all kinds of jobs, don't we?
For example, I don't see why a sync point FD may be needed in a case of
Opentegra jobs.
>> 2. Allocated sync point must have a clean hardware state.
>
> What do you mean by clean hardware state?
I mean that sync point should have a predictable state [1], it shouldn't
accidentally fire during of hardware programming for example.
[1]
https://github.com/grate-driver/linux/blob/master/drivers/gpu/host1x/soc/syncpoints.c#L132
For a submitted job, the job's sync point state could be reset at a
submission time, for example like I did it in the grate-kernel's
experimental driver [2].
[2]
https://github.com/grate-driver/linux/blob/master/drivers/gpu/host1x/soc/channel.c#L145
>>
>> 3. Sync points should be properly refcounted. Job's sync points
>> shouldn't be re-used while job is alive.
>>
>> 4. The job's sync point can't be re-used after job's submission (UAPI
>> constraint!). Userspace must free sync point and allocate a new one for
>> the next job submission. And now we:
>>
>> - Know that job's sync point is always in a healthy state!
>>
>> - We're not limited by a number of physically available hardware sync
>> points! Allocation should block until free sync point is available.
>>
>> - The logical number of job's sync point increments matches the SP
>> hardware state! Which is handy for a job's debugging.
>>
>> Optionally, the job's sync point could be auto-removed from the DRM's
>> context after job's submission, avoiding a need for an extra SYNCPT_PUT
>> IOCTL invocation to be done by userspace after the job's submission.
>> Could be a job's flag.
>
> I think this would cause problems where after a job completes but before
> the fence has been waited, the syncpoint is already recycled (especially
> if the syncpoint is reset into some clean state).
Exactly, good point! The dma-fence shouldn't be hardwired to the sync
point in order to avoid this situation :)
Please take a look at the fence implementation that I made for the
grate-driver [3]. The host1x-fence is a dma-fence [4] that is attached
to a sync point by host1x_fence_create(). Once job is completed, the
host1x-fence is detached from the sync point [5][6] and sync point could
be recycled safely!
[3]
Re: [RFC] Host1x/TegraDRM UAPI (drm_tegra_submit_command)
28.06.2020 13:28, Mikko Perttunen пишет:
> On 6/28/20 1:32 AM, Dmitry Osipenko wrote:
>> 23.06.2020 15:09, Mikko Perttunen пишет:
>>> /* Command is an opcode gather from a GEM handle */
>>> #define DRM_TEGRA_SUBMIT_COMMAND_GATHER 0
>>> /* Command is an opcode gather from a user pointer */
>>> #define DRM_TEGRA_SUBMIT_COMMAND_GATHER_UPTR 1
>>> /* Command is a wait for syncpt fence completion */
>>> #define DRM_TEGRA_SUBMIT_COMMAND_WAIT_SYNCPT 2
>>> /* Command is a wait for SYNC_FILE FD completion */
>>> #define DRM_TEGRA_SUBMIT_COMMAND_WAIT_SYNC_FILE 3
>>> /* Command is a wait for DRM syncobj completion */
>>> #define DRM_TEGRA_SUBMIT_COMMAND_WAIT_SYNCOBJ 4
>>>
>>> /*
>>> * Allow driver to skip command execution if engine
>>> * was not accessed by another channel between
>>> * submissions.
>>> */
>>> #define DRM_TEGRA_SUBMIT_CONTEXT_SETUP (1<<0)
>>>
>>> struct drm_tegra_submit_command {
>>> __u16 type;
>>> __u16 flags;
>>
>> Shouldn't the "packed" attribute be needed if a non-32bit aligned fields
>> are used?
>
> I guess we should change these to u32 for consistency.
>
>>
>>> union {
>>> struct {
>>> /* GEM handle */
>>> __u32 handle;
>>>
>>> /*
>>> * Offset into GEM object in bytes.
>>> * Must be aligned by 4.
>>> */
>>> __u64 offset;
>>
>> 64bits for a gather offset is a bit too much, in most cases gathers are
>> under 4K.
>>
>> u32 should be more than enough (maybe even u16 if offset is given in a
>> dword granularity).
>
> I guess this can be changed to u32, though I don't think there is any
> particularly pressing reason not to use u64.
>
> In any case, I think we concluded that we'll drop the GEM gather command
> for now.
Sure, I commented this just in a case, for the future :)
>>
>>> /*
>>> * Length of gather in bytes.
>>> * Must be aligned by 4.
>>> */
>>> __u64 length;
>>
>> u32/16
>>
>>> } gather;
>>
>>> struct {
>>> __u32 reserved[1];
>>>
>>> /*
>>> * Pointer to gather data.
>>> * Must be aligned by 4 bytes.
>>> */
>>> __u64 base;
>>> /*
>>> * Length of gather in bytes.
>>> * Must be aligned by 4.
>>> */
>>> __u64 length;
>>> } gather_uptr;
>>
>> What about to inline the UPTR gather data and relocs into the
>> drm_tegra_submit_command[] buffer:
>>
>> struct drm_tegra_submit_command {
>> struct {
>> u16 num_words;
>> u16 num_relocs;
>>
>> gather_data[];
>> drm_tegra_submit_relocation relocs[];
>> } gather_uptr;
>> };
>>
>> struct drm_tegra_channel_submit {
>> __u32 num_syncpt_incrs;
>> __u32 syncpt_idx;
>>
>> __u64 commands_ptr;
>> __u32 commands_size;
>> ...
>> };
>>
>> struct drm_tegra_submit_command example[] = {
>> cmd.gather_uptr{},
>> ...
>> gather_data[],
>> gather_relocs[],
>> cmd.wait_syncpt{},
>> ...
>> };
>>
>> This way we will have only a single copy_from_user() for the whole
>> cmdstream, which should be more efficient to do and nicer from both
>> userspace and kernel perspectives in regards to forming and parsing the
>> commands.
>>
>
> I'm not sure I agree it being nicer with regard to forming and parsing
> - Can you actually place multiple unsized arrays in a struct without
> pointers?
No :) But there are no unsized arrays here. The parser will read first
command and then move pointer to the next command based on size of the
parsed command.
> - gather_data's length is a multiple of 4, and so since we have u64's in
> drm_tegra_submit_relocation, alignment needs to be taken care of
> manually, both when forming and kernel needs to validate it while
> parsing. Depending on number of words in the gather, padding would need
> to be inserted. We could swap the two around but it still feels more
> brittle.
Yes, there will be unaligned reads on ARM64, but I don't think it's a
problem. Isn't it?
> Also, if we read the gather from a separate address, userspace doesn't
> necessarily need to know the length of the gather (and number of relocs)
> upfront, so it's easier to have a builder pattern without needing to
> copy things later.
Usually there are 2-3 relocs per gather, so userspace could simply
maintain a fixed-sized static buffer for the relocs (say 32 relocs).
Once gather is sliced by userspace, the stashed relocs will be appended
to the comands buffer and next gather will be formed.
The
[PATCH v2 1/6] drm/tegra: gr3d: Assert reset before power-gating
Tegra TRM documentation states that hardware should be in a default state
when power partition is turned off, i.e. reset should be asserted. This
patch adds the missing reset assertions.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/gr3d.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/tegra/gr3d.c b/drivers/gpu/drm/tegra/gr3d.c
index c0a528be0369..b0b8154e8104 100644
--- a/drivers/gpu/drm/tegra/gr3d.c
+++ b/drivers/gpu/drm/tegra/gr3d.c
@@ -381,10 +381,12 @@ static int gr3d_remove(struct platform_device *pdev)
}
if (gr3d->clk_secondary) {
+ reset_control_assert(gr3d->rst_secondary);
tegra_powergate_power_off(TEGRA_POWERGATE_3D1);
clk_disable_unprepare(gr3d->clk_secondary);
}
+ reset_control_assert(gr3d->rst);
tegra_powergate_power_off(TEGRA_POWERGATE_3D);
clk_disable_unprepare(gr3d->clk);
--
2.26.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/6] gpu: host1x: debug: Fix multiple channels emitting messages simultaneously
Once channel's job is hung, it dumps the channel's state into KMSG before tearing down the offending job. If multiple channels hang at once, then they dump messages simultaneously, making the debug info unreadable, and thus, useless. This patch adds mutex which allows only one channel to emit debug messages at a time. Signed-off-by: Dmitry Osipenko --- drivers/gpu/host1x/debug.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/host1x/debug.c b/drivers/gpu/host1x/debug.c index c0392672a842..1b4997bda1c7 100644 --- a/drivers/gpu/host1x/debug.c +++ b/drivers/gpu/host1x/debug.c @@ -16,6 +16,8 @@ #include "debug.h" #include "channel.h" +static DEFINE_MUTEX(debug_lock); + unsigned int host1x_debug_trace_cmdbuf; static pid_t host1x_debug_force_timeout_pid; @@ -52,12 +54,14 @@ static int show_channel(struct host1x_channel *ch, void *data, bool show_fifo) struct output *o = data; mutex_lock(>cdma.lock); + mutex_lock(_lock); if (show_fifo) host1x_hw_show_channel_fifo(m, ch, o); host1x_hw_show_channel_cdma(m, ch, o); + mutex_unlock(_lock); mutex_unlock(>cdma.lock); return 0; -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208179] [amdgpu] black screen after exiting X
https://bugzilla.kernel.org/show_bug.cgi?id=208179 Shlomo (shl...@fastmail.com) changed: What|Removed |Added Kernel Version|5.7.2,5.7.4,5.8-rc1 |5.7.2,5.7.4,5.8-rc1,5.8-rc2 --- Comment #4 from Shlomo (shl...@fastmail.com) --- Confirmed fixed in v5.8-rc3. -- You are receiving this mail because: You are on the CC list for the bug. You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: sun4i: hdmi: Remove extra HPD polling
From: Chen-Yu Tsai
The HPD sense mechanism in Allwinner's old HDMI encoder hardware is more
or less an input-only GPIO. Other GPIO-based HPD implementations
directly return the current state, instead of polling for a specific
state and returning the other if that times out.
Remove the I/O polling from sun4i_hdmi_connector_detect() and directly
return a known state based on the current reading. This also gets rid
of excessive CPU usage by kworker as reported on Stack Exchange [1] and
Armbian forums [2].
[1]
https://superuser.com/questions/1515001/debian-10-buster-on-cubietruck-with-bug-in-sun4i-drm-hdmi
[2]
https://forum.armbian.com/topic/14282-headless-systems-and-sun4i_drm_hdmi-a10a20/
Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index ce07ddc3e058..557cbe5ab35f 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -259,9 +259,8 @@ sun4i_hdmi_connector_detect(struct drm_connector
*connector, bool force)
struct sun4i_hdmi *hdmi = drm_connector_to_sun4i_hdmi(connector);
unsigned long reg;
- if (readl_poll_timeout(hdmi->base + SUN4I_HDMI_HPD_REG, reg,
- reg & SUN4I_HDMI_HPD_HIGH,
- 0, 50)) {
+ reg = readl(hdmi->base + SUN4I_HDMI_HPD_REG);
+ if (reg & SUN4I_HDMI_HPD_HIGH) {
cec_phys_addr_invalidate(hdmi->cec_adap);
return connector_status_disconnected;
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
